Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Subscribe to the SSDT Newsletter by clicking here.  Your email will be added to a distribution list.             


Looking Back

We are thrilled to report all USAS and USPS migrations from the Classic software are complete!  What a huge accomplishment for everyone involved!  I believe the saying "The only time you should look back is to see how far you've come" can't be more true of the migration effort.   We would like to thank the OEDSA attendees who celebrated with the SSDT last month at our 'Classic Retirement' reception held during the conference.  It was great to see so many there who were involved from the very beginning. The support we have received has been overwhelming and what's even more exciting is the anticipation of bigger and better things to come with the redesigned software.  However, we do have one more milestone to go and that is successfully completing the Classic EIS migrations before the end of the calendar year. Considering Inventory was released late summer of 2021,  both the ITCs and districts are making huge strides successfully migrating over 350 districts from the classic system.  


Inventory Depreciation 

During migration balancing, issues with Classic's EIS depreciation were brought to our attention.  ITCs were reporting differences when trying to balance fiscal-to-date (FTD) depreciation on the balancing reports.  FTD depreciation is calculated on the fly in both Classic and Redesign and is not a stored figure like LTD depreciation is. For a specific case (we have dubbed the 'perfect storm' scenario), active items, marked for depreciation, that contain invalid beginning depreciation dates and are not fully depreciated may cause balancing issues on the EIS102's Book Value amounts, EIS104's continuing items amounts and EIS305's FTD amounts when comparing to their redesign counterparts.  After several conversations with the auditors, it was ultimately decided that the incorrect depreciation data needs to be corrected.  AOS has also notified field auditors of possible incorrect depreciation figures.  

Why are the beginning depreciation dates invalid in Classic in the first place?

The Classic EISIX>EISIMP program was used by ITCs to import EIS data for districts when a new inventory was done and also used by districts to import new items to their existing data.  The import file specifications are documented in detail, with valid formats provided for each field.  However, the program itself was not performing validations on beginning depreciation dates when loading it.  This apparently went undetected by districts and was not discovered during audits. 

During migration, does it indicate the beginning depreciation dates are invalid?

Yes, the import log includes warnings on the item import for all items that contain invalid beginning depreciation dates (i.e. 201500 or apr-11).  This warning is explained in detail in the common import errors and warnings documentation which includes steps on how to fix them in Classic or Redesign.  Invalid beginning depreciation dates do not migrate thus resulting in blank beginning depreciation dates in Inventory.  Many of these items may already be fully depreciated, disposed of and/or will not affect FTD balancing.  However, the 'perfect storm' scenario does affect report balancing and needs to be addressed before migrating to Inventory.

Could invalid beginning depreciation dates have also affected my LTD depreciation calculation in Classic all of these years?

It's very possible.  A beginning depreciation date of apr-11 may not have calculated LTD depreciation correctly since inception.  It's really on a case-by-case basis.  But invalid beginning depreciation dates may not be the only cause for an incorrect LTD depreciation figure.  The LTD depreciation field in Classic has always been modifiable and is not validated.  If an incorrect LTD figure was imported via EISIX>EISIMP, was entered or updated incorrectly via EISSCN>ITMSCN, or the fields involved in calculating LTD (depreciation method, beginning depreciation date, salvage value, life and original cost) were changed and the LTD was not re-calculated, the current LTD figure may be incorrect.  For example, if a FY2019 item is tracking depreciation but the life expectancy field was not entered, the item's existing LTD depreciation would be $0.  Classic cannot calculate LTD due to the missing life field.  If in FY2022, it was then realized the life expectancy was missing and update at that time, it will not automatically update the LTD depreciation nor will it update completely when EISCLS ran at the end of the year. This particular item's LTD depreciation would need to be recalculated.

I have not migrated from EIS to Inventory yet.  What can I do to fix my invalid beginning depreciation dates as well as possibly my LTD depreciation figures.

SSDT's strong recommendation is for the data to be cleaned up in Classic EIS for ease in balancing.  An SSDT Notices email was sent to ITCs last week explaining this in more detail along with a link to the Life-To-Date Depreciation Discrepancies wiki page that details the specific scenario and steps to fix the invalid beginning depreciation dates in Classic.  Also recommended is running an EISDEPR Projection report after to see if the LTD depreciation needs to be re-calculated on those items with invalid dates (as well as others causes explained in the paragraph above).  The EISDEPR report includes the 'old' and 'new' LTD depreciation figures on ALL active items. Please contact your auditor so they can review the tags listed on your EISDEPR projection report in order to determine if the EISDEPR actual option should be run to allow Classic to recalculate LTD from scratch.  

I have already migrated and I was informed that I had multiple items with invalid beginning depreciation dates on my import log, however my migration reports balanced.  Do I still need to update these items to include valid beginning depreciation dates?  Should I also be concerned about other causes in Classic that may have resulted in incorrect LTD figures?

The field auditors are aware that incorrect LTD depreciation amounts carried over from Classic may exist.  In your case, it may not have affected your FTD balancing because you had valid beginning depreciation dates but the auditors may also be reviewing your existing LTD depreciation amounts due to the other causes explained above.    The SSDT is currently looking into the steps needed to recalculate LTD depreciation if needed and we will be sending out another SSDT Notices email to the ITCs soon on how incorrect them as well as provide an update in next month's newsletter.

Could fixing invalid depreciation dates, existing LTD depreciation amounts or any other fields that affect LTD depreciation also affect my existing EIS104/Schedule of Change in Depreciation and my EIS305/Book Value reports?

Yes, it very well could.  Changes made to the LTD figures for capitalized assets will impact GAAP beginning balances in the EIS104/Schedule of Change in Depreciation.  Automatic adjustments will be made on the items beginning balances so that beginning balances will no longer match the ending balances on the prior year's report.  The EIS305/Book Value amounts  (LTD, FTD, Total Depreciation and Book Value figures) will also be automatically adjusted.  The LTD amount on the current EIS305/Book Value will no longer match the prior year's Total Depreciation on the EIS305/Book Value.  Also, if you are performing some clean up on very old, active, non-capitalized assets by deleting (removing) them (instead of disposing them), it will affect the EIS305 because those items will no longer be included on the current EIS305/Book Value reports, thus no longer being able to balance the current year's LTD depreciation back to the prior year's Total Depreciation).


Inventory Reports

Within the last few releases, SSDT has provided additional FYE related reports as well as released the Inventory Report Bundle.  The Fiscal Year Ending Balances and Depreciation Posting reports must be run before the fiscal year period is closed.  The Inventory Report Bundle will generate when the fiscal year period is closed.

  • Fiscal Year Ending Balances Report replicates Classic's EISCLS report.  It displays what the ending balances (original cost) will be for the current fiscal year when the fiscal period is closed.  This is a projection only report.
  • Depreciation Posting Report replicates Classic EISCLS' EISDEP report and includes both capitalized and non-capitalized items, sorted by fund.
  • Both of the above reports are included on the Inventory FYE Report Bundle which is the replacement for Classic's EISCD. The reports will be zipped and emailed to the email address(es) specified in Core>Configuration.  In order for the report bundle to be emailed, the Email Address in Core>Configuration must be populated with valid email address(es) and the Email Configuration tab under System>Configuration must be populated as well

We are also aware of some performance improvements that need to be addressed with the FYE Report Bundle as well as the Audits report and have existing JIRA issues to resolve these on a future release of the software. 

A few trouble spots on some of the existing Inventory reports are currently being worked on and will be available within the next couple of releases.  Sorting and subtotaling improvement are currently being made on the following:

  • Book Value
  • Asset Listing by Source
  • Brief Asset Listing
  • Location Worksheet
  • Leased Asset Listing
  • Pending Items List

Inventory FAQs 


Useful links:


Did You Know?

Pay Account Selections Just Got Easier!

A new Configuration option has been added.  This can be found by going to System>Configuration>Specific Account Search Limit Configuration.  By default this option is enabled.

When this option is enabled and a pay account is added to a payment, only those pay accounts with a 1xx object code will be listed.

If you are wanting to see all pay accounts regardless of the object code, the 'Include All Accounts' checkbox can be marked.   

This option can be disabled by going to System>Configuration>Specific Account Search Limit Configuration and unmarking the checkbox.  


Did You Know?

Anyone Missing Classic's PAYDED Report?  Wait no more...

Once the Outstanding Payables are processed, the Payables Payment Report now includes totaling detail like Classic's PAYDED provided.  

The report can also be generated by going to Payments>Payee, selecting all check lines and clicking the new Payee Payment Report option.





REDESIGN STATUS

619

Sites Live on Redesign

121

Total Wave 8 Sites

17

Participating ITCs

649

Total Districts Participating


Please view the Current List of Districts & Status to see a comprehensive list of school districts along with their ITC, implementation status and the wave they are scheduled to migrate from Classic to Redesign.

The following terminology is used to determine where in the implementation process the entity is currently at:

  • Implementing: The ITC is running test imports and balancing reports on the entity.  The district and ITC are working to schedule dates to begin dual processing and go live.

  • Paralleling: The entity is inputting all production transactions into both Classic and Redesign.

  • Live: The entity is using Redesign for production processing; no parallel processing is being performed;  Classic is available in 'read-only' mode.


Did You Know?

PO Repair: Vendor Change

After a recent update, users can now change a vendor on a "new" PO without reopening the posting period associated with the PO date. To change the Vendor, select the Repair option on the PO.  From the vendor tab modify the vendor to a different vendor.

Click Here for more information about PO Repair.






  • No labels