SSDT strongly recommends ITCs run test imports on their district's data two months before the dual-processing period. When running a test import, please review the Balancing Reports listed below to ensure account and transaction totals are correct.
There are a few processes that need to be setup and verified after the USAS data has been imported.
- Go to System/Configuration
- Classic Migration Configuration: Enter the 'Fiscal Year Closed' date and time from Classic's USASDAT/USACON. This is the date and time Classic's ADJUST program was run when closing the fiscal year prior to extracting the district's data.
- EIS Classic Integration Configuration: If the district is currently using Classic's EIS (Equipment Inventory System), enter the 'Pending Threshold' amount from Classic and either checkmark the 'automatic' box for it to automatically update the pending file for 6xx object codes or leave unchecked and the user will be prompted for both 5xx and 6xx object codes.
- EMIS SOAP Service Configuration: Enter the fiscal year the district will be reporting for the next Period H submission. This is required before running the EMIS extract option under the Extracts menu.
- Transaction Configuration: Specify the highest transaction number used instead of the system using the highest number retrieved from the database. This will be helpful in eliminating gaps in transaction numbers.
- Go to System/Modules to install the following modules:
- Classic Requisition Approval Module: must be installed if they use Onbase or RAM).
- File Transfer Notification Services: must be installed if they use RAM
- USPS Integration Module: must be installed in order to post USPS-R payroll, Board Retirement and Board Share of Distribution files into USAS-R
- Windows Active Directory Service Authentication: must be installed if they would like to use Active Directory
- Go to Transactions/Activity Ledger. If the following warning message is displayed, please be advised that the ledgers have not finished posting and the data you are seeing in the Activity Ledger is incomplete. Once this message no longer displays, the posting of the ledgers has completed and all data is available from the import.
- Go to Core/Delivery Addresses: By default, all delivery addresses imported from Classic are inactive. Checkmark the 'Active' box to activate a delivery address.
Once your data has been imported into the redesign, your ITC may contact you with a list of errors that occurred during import. Errors may include, but are not limited to:
We're seeing a lot of errors related to vendor addresses. Specifically an incorrect state abbreviation or trailing hyphens in postal codes. You'll need to edit the vendor to correct the erroneous data.
After the import process completes you'll want to run, at a minimum, the following reports in both Classic and the Redesign to check totals and ensure all of your amounts balance. Don't be surprised if you notice a few differences, especially with the Carryover Encumbrances. Don't panic, we're here to help and each difference can be explained. Once you understand the reason for the difference, you may decide that you need to post adjusting entries to ensure your expendable amounts are what they should be.
You are seeing a difference because the calculation of remaining encumbrance in the Redesign is different from that of Classic. We have corrected some of the deficiencies in Classic's calculations of remaining encumbrance. There were certain circumstances where Classic simply could not get this calculation correct.
|APPSUM||SSDT Appropriation Summary||When your run these reports, if your Carryover Encumbrances do not match you will want to run a Budget Summary report to narrow it down to the Budget that was impacted. You'll also want to run the SSDT Carry Over Reconciliation Report, see explanation below.|
|BUDSUM||SSDT Budget Summary||Compare the totals on the Budget Summary Report report to Classic's BUDSUM figures.|
|BUDLED||SSDT Budget Account Activity Report||Compare the totals on the Budget Account Activity report to the totals on Classic's BUDLED. You can run it for the current month and/or the current year on both systems to make sure everything is in balance.|
|FINDET||SSDT Financial Detail Report||Compare the totals on the Financial Detail to the totals on classics' FINDET report. You can run it for the current month and/or the current year on both systems to make sure everything is in balance.|
|FINSUMM||SSDT Cash Summary Report||Compare the totals on the Cash Summary report to the totals on Classic's FINSUMM.|
|REVSUM||SSDT Revenue Summary||Compare the totals on the Revenue Summary report to Classic's REVSUM.|
|REVLED||SSDT Revenue Account Activity Report||Compare the totals on the Revenue Account Activity report to the totals on Classic's REVLED. You can run it for the current month and/or the current year on both systems to make sure everything is in balance.|
|PODETL||SSDT Purchase Order Detail Report|
If you run this report for outstanding purchase orders, you'll want to take into consideration that the Redesign does not consider purchase order amounts that have been invoiced to be outstanding. You will need to compare an outstanding Classic report to an outstanding Purchase Order Detail Report and includes invoices from the Payables UI. You can run a report from the Payables grid to get a total of filled invoices and add it to your Purchase Order Detail Report in the redesign to equal the amount you see on Classic's PODETL.
The PO Total on the report is the original PO amount. 'Adjusted' in classic is taking into consideration any cancelled amounts. Currently, PO cancelled amount is not included in the Redesign so when comparing against the PO adjusted in classic, you have to take the PO original amount minus cancelled PO amounts.
|CHEKPY||SSDT Disbursement Summary||You can run reports for all checks and/or outstanding checks. If you want to run a report for outstanding checks, select 'outstanding' on the Disbursement Summary report and compare the figures to Classic's outstanding CHEKPY. Classic includes transfer checks.. redesign doesn't. Reconcile memo checks.|
|REQSUM||SSDT Requisition Summary Report||You can run both reports for outstanding requisition amounts. If the amounts do not balance (and Redesign amount is higher), there may be requisitions appearing in the Redesign as outstanding when they are considered closed in Classic. This is caused by closed (converted) requisitions in Classic where the associated PO is no longer on file in Classic (i.e. PO was deleted). In this case, the requisition will be imported with 'converted' equals false (outstanding requisition) and if the requisitions amount are being tracked, the amounts will be included on the accounts. If these requisitions should not be included in the import, please delete the requisitions in Classic before doing a live import of the district's data.|
|SM2||SM2 Spending Plan Summary||If the districts runs the SM2 on a monthly basis, compare the SM2 Spending Plan Summary to Classic's SM2M from the SM12 program to compare totals.|
|SSDT Carry Over Reconciliation Report||This report summarizes the differences between Classic's imported carryover encumbrances and the Redesign's calculated amount. The adjustments are derived by taking the carryover encumbrance imported from Classic, calculating the carryover encumbrance according to the Redesign's more correct calculations, and finding the difference between the two amounts.|
|SSDT Impact on Encumbrance Report||If you run the report for a particular PO, you will see all associated transactions that had an impact on the original encumbrance for that PO. Please keep in mind, this will NOT list every transaction associated with the PO, only those that had an impact on encumbrance. For example, creating an invoice that partially fills a charge for less than the total amount does NOT impact encumbrance. However, partially filling an item for more than the original charge amount DOES impact encumbrance, increasing it by the difference of the original charge and the invoiced amount.|
Differences in Carryover Encumbrances
When Classic's Carryover Encumbrance amounts do not balance with Redesign's Carryover Encumbrance amounts, the Redesign's 'Classic Carryover Reconciliation' report should be run to see the accounts involved and the carryover amounts adjusted. The 'Grand Total' on the report should match the difference between Redesign and Classic's carryover encumbrances.
HELPFUL TIP: The Impact on Encumbrance report may be helpful in determining the positive and negative adjustments that were made. You can filter the report by entering the account from the classic carryover reconciliation to find the PO transactions tied to that account.
A positive adjusted carryover encumbrance means Redesign had to increase the carryover encumbrance figure from classic due to one of the following reasons:
- In Classic, backdating an invoice to a date in the prior fiscal year. For example, you are in July 2018 (FY19) processing but you entered an invoice with a FY18 date. Redesign import thinks the invoice was in FY18 and increases the prior carryover encumbrances.
A negative adjusted carryover encumbrance means Redesign had to decrease the carryover encumbrance figure from classic due to one of the following reasons:
- In Classic, modifying a prior year PO date to a date in the current fiscal year. Redesign import thinks the encumbrance should be reflected in the current FY and will reduce the prior carryover encumbrances.
In Classic, deleting a prior year PO in the current fiscal year and re-adding it with a date in the current fiscal year. Redesign import thinks the encumbrance should be reflected in the current FY and will reduce the prior carryover encumbrances.
In the two situations above, the district intentionally changed the prior year PO date to reflect the current fiscal year. Redesign import corrected the CO encumbrances by decreasing the amounts on the CO figure so that the encumbrances are reflective in the new year and no longer in the prior year. District should keep this CO reconciliation report on file to show the adjustments in encumbrances that were made because the Redesign figures are correct.
In Classic, defaulting an invoice date to the current system date (July) when you are still in June processing. For example, posting invoices on July 2nd using the default July 2nd date when you are still in June processing. Redesign import thinks the invoice is a current year invoice and will reduce the prior carryover encumbrances.