Skip to end of metadata
  • Created by Former user, last modified by Former user on May 03, 2016
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 2 Next »

 

This page contains initial topics for discussion between the SSDT and AOS for the USAS-R and USPS-R projects.

Differences between Classic and Redesign Software

In Classic USAS, you can only work within the current processing month and cannot process checks or receipts for the next month until you close out the current month.    Amounts are stored in "Accumulators" for Month-to-Date, Fiscal-to-Date, and Calendar-to-Date.  These accumulators get cleared by the ADJUST program, which the district runs to close out each month, and also at the end of the calendar and fiscal year periods.

USAS-R contains the concept of a posting period.  There are no accumulators, all amount fields are calculated on the fly from ledgers or transactions.  Thus, there is no "ADJUST" process needed any more.

  • Classic USAS:
    • User works within the current processing month
    • Cannot process checks or receipts for the next month until current month is closed
    • Amounts stored in "Accumulator" fields 
      • Month-to-Date
      • Fiscal-to-Date
      • Calendar-to-Date
    • Accumulators cleared by ADJUST process monthly, and at end of fiscal and calendar years
    • Future Purchase Orders allowed via special "future" processing
      • Don't actually get posted as a purchase order until the future month becomes the current month
    • It is a standard practice for ITC's to create a copy of USAS data files prior to closing with ADJUST.  If audit adjustments are needed for the prior year, they may be made in the copy of the files and reports re-generated. 
  • USAS-R
    • Contains concept of "Posting Period"
    • No accumulators
    • Amount fields all calculated "on the fly" from ledgers or transactions
    • Can have any number of posting periods open, but only one "Current" posting period
    • Currently can process transactions in any open posting period
    • No special process for future purchase orders, but does require an open posting period for the "future" date
    • Likewise will be able to begin processing checks and receipts in the next month before closing the current month
    • Software allows re-opening of prior closed posting periods
      • Currently, restricts to periods in current fiscal year plus June of prior fiscal year

USPS-R has a similar concept of posting periods for its monthly, quarterly, calendar and fiscal years, and no accumulators for dollar amounts.

Posting Periods

We are looking to determine what controls are needed around posting periods, and especially around the re-opening of closed posting periods.

The following link outlines some reasons why users might want to re-open closed posting periods and discussion questions:

https://wiki.ssdt-ohio.org/x/WIIhAg

In addition, the following questions have come up:

  • How does the ability to re-open closed posting periods affect monthly reporting?
    • Do monthly reports have to be generated and stored?
    • If yes, do they need to be regenerated if changes are made in a prior period?
    • Or, can they be created for the prior periods on an "as-needed" basis?
  • Are there any restrictions that should be in place on use of future periods?

Standardized Reports for Audit

In Classic USAS, standardized monthly reports are run at the end of the month via MONTHLYCD, and at the end of the fiscal year via FISCALCD.  

  • How important is the ability to generate standard reports between districts?  Are differences in sorting/subtotaling significant?  
  • If these are important, which reports are needed?

Distributions/Error Corrections

  • Are printed receipts for a "receipt book" still required by AOS?
  • If yes, do account distributions/error corrections require a printed document to be created for filing purposes?

Printing Signatures on Purchase Orders and Checks

  • What controls are needed for us to allow electronic signatures to be printed on purchase orders or checks? 

Transfers/Advances

In Classic, transfers and advances are processed using a purchase order, check, and receipt document, and are included as part of expenditures and revenues using the function and receipt codes designated by AOS.

  •  Is this the desired reporting for this, or should they be handled differently?

"No-Vendor" Purchase Orders

Classic allows for multi-vendor purchase orders by using a special vendor designated as a "multi-vendor".

In USAS-R, a multi-vendor purchase order is defined as one that does not have a vendor at all. The vendor is then assigned at invoice processing time.

  • Users have expressed concern that this will not be allowed by audit.  Is this a valid concern?

 

  • No labels