Differences from Classic USAS

This page describes primary functionality differences between Classic USAS and USAS-R.  It does NOT attempt to describe changes which are just changes to the user interface.  See the relevant chapters for details on how each option functions.

Enhanced Queries and Grids

In USAS-R, most data types show up in customizable grids.  The user is able to select the fields that they want to appear in each grid, as well as the order of the columns.  Grid results are "lazy-loaded", meaning that you can scroll down through all of the data and it gets loaded as you go.  This means there is no limit on the maximum number of records that can be returned, which means no "page numbers" to deal with to see your results.  Clicking on a row in the grid brings up a highlight view of the record you selected.  

Users are also no longer limited on the fields that they can do queries on.  USAS-R users will be able to filter grid results directly via a "filter row".  In addition, there is also an advanced query that allows querying against virtually any field related to the type of data being queried.  The advanced queries can be saved and recalled later, and will also be available as filters in the dynamic reports described below.

Dynamic Reporting Capabilities

USAS-R contains very dynamic reporting capabilities which allow you to select data from nearly any data type, filter the data, determine which columns to include on your report and the order of the columns, sort by any field, and do control breaks with totals.  You can output to a variety of formats including text, pdf, excel, and csv format, along with other lesser known formats, and select between portrait or landscape orientations.  The report criteria can be saved and recalled later.  The saved reports can also be shared with other district users via the role(s) they are granted, or downloaded and shared with other districts.

Classic vs. Redesign Report Comparisons

When comparing Classic USAS reports to those in the Redesign, please note the following differences:

• PODETL/POSUMM:  An outstanding PODETL/POSUMM in Classic will not match the Redesign's Purchase Order Detail or Purchase Order Summary report run with "invoiceable = true".  This is because Classic's definition of outstanding includes POs with a status of new, partially filled, partially paid and completely filled.  The Redesign did not carry forward these statuses.  The Redesign report will not include any POs that are completely filled, only those POs that are still able to be invoiced (invoiceable = true).

Custom Fields

Custom Fields are fields that districts can create for themselves to hold a wide variety of data that was not available in Classic USAS.  They will be available in nearly all user interfaces.  Custom fields can be used anywhere a normal field is used, including in queries and reports.  They can also be enabled or disabled as desired by the district.  The district can specify whether each Custom Field should be included in the Basic Query options for reports, and whether it should be included as a column in the query results.

Custom Fields can be any of the following types:  Text, Code, Money, Number, Date, Date/Time, Web Address, Email, User, or Boolean (True/False).  With the "Code" type you can define your own list of valid values with their definitions and these will be used to produce drop-down boxes in the user interface.  In addition, there are special Custom Field types for Created Date/Time, Last Modified Date/Time, Created User, and Last Modified User which will be updated automatically by the system and can optionally be used to keep track of this information for any data type.

Some of the fields from Classic USAS have been turned into Custom Fields.  Since you can disable Custom Fields, this has the advantage of allowing districts to remove fields that they don't use or care about.  

The following fields from Classic USAS have been turned into Custom Fields:

• All "User Defined" fields

• All "Entered Date" and "Posted By User" fields (these are automatically updated for you by the system)

• Vendor

  • Category

  • Withhold Child Support Flag

  • Minority Vendor Flag

  • Email Address

  • ACH fields 

• Cash Account

  • Bank Code

  • EMIS Fund Category

• Project-to-date Expended and Received (from Budget and Revenue Account)

• Project-to-Date Expended and Received (from Cash Account - shows up on Project)

• OPU Central Office flag

• Requisition

  • Type

  • Requisition Approval Status 

  • Requisition Workflow Context  

• P.O. Transmitted flag

  
  
  

Wildcards

USAS-R gives users the same ability to use wildcards as you did in Classic, but using a different character.  In Classic you were used to using the asterisk * as a wildcard when limiting accounts during report generation.  In the redesign you'll use the percent sign % to accomplish the same goal.  

Posting Periods

The ability to have multiple posting periods open at one time will be available within USAS-R.  It will no longer be necessary to completely close out before opening the next reporting period.  It will also be possible to re-open prior periods when corrections need to be made.  

Transaction dates will be required to be in an open (not necessarily current) posting period.

Customizable Business Rules

USAS-R uses a "Rules Engine" which allows various types of business rules to be written in a text format and easily applied to the system "on the fly" – without even logging out or shutting it down.  USAS-R will come with its own set of required business rules, as well as a number of optional business rules that the district may enable or disable as they desire.  Customized rules can also be written for each district, either by district personnel with the appropriate access to do so, or with help from their ITC or the SSDT.  A few examples of using customized business rules are custom validations, sending email or Twitter notifications, or even updating fields based on certain criteria.  These can also be used in conjunction with Custom Fields.

Security

USAS-R has much more fine-grained security capabilities than Classic USAS.  The district will be able to create "roles" for various security configuration needs in their district, and then assign the fine-grained permissions to those roles.  Each primary data type will at a minimum have at least a Create, View, Update, Delete, and Report permission.  Users may be assigned one or more "roles" based on their job duties.

Accounts

Xref codes will be much more useful.  They will be available in all of the account types and visible in all transaction entry options for all districts (there will no longer be a district configuration for these).   They will be fully integrated in the system, and thus can be used in queries or for filtering, sorting, or inclusion on any reports that include account codes.

Appropriation codes will default to the same budget "roll-up" criteria as Classic USAS (two digits of function code with one digit of object code).  However, using the Rules Engine, it will be possible to customize these levels to use any account code dimensions desired for the roll-up criteria.  The criteria used must be the same within a fund, but different criteria may be used for different funds.

For the purpose of advanced queries and reporting, the Classic "budget account" is split between a "Budget" and "Expenditure Account" in USAS-R.  The Classic "revenue account" is split between an "Anticipated Revenue" and "Revenue Account" in USAS-R.  Budgeting will all be transaction-based and these transactions can be reported on using the BudgetTransaction and AnticipatedRevenueTransaction objects, or via the "Transactions", "FYTD Transactions", or "MTD Transactions" folders under the "Budget" or "AnticipatedRevenue" objects.

The following fields are new or are named differently than in Classic:

Projects

This is a new option which can be used to view your projects and project-to-date information.  For the initial versions of USAS-R this will remain one project per cash account, however in the future this will be updated to allow more flexibility in the creation of projects by tying them to budgets and anticipated revenues, even across multiple cash accounts.

Vendors

Memo vendor numbers are no longer required.  The vendor will have a field called "Default Payment Type", which can have a value of Check, Electronic, or ACH.  Memo vendors will be imported with a default value of Electronic, while all other vendors will be defaulted to a value of Check.  There will be no need in USAS-R to have a separate range of numbers used for "memo" vendors.

The multi-vendor flag is obsolete.  Purchase Orders which are non-vendor specific will have no vendor entered.  The vendor may then be entered on each invoice, just as is done in Classic USAS invoice entry.  

A vendor may now have multiple locations entered. The user will need to designate which location to use as the default purchase order address, default check address, and default 1099 address.  For now it will still be necessary to maintain multiple vendors for different locations, but In the future it is anticipated that the user would be able to combine these into a single vendor record and select the correct location when processing any transactions which have a vendor.

A permission USAS_PRIVACY_TAXID will need to be granted in order for users to be able to see the 1099 and New Hire Taxpayer Id fields.

The following fields are new or are named differently than in Classic:

Requisitions

It is no longer necessary to enter a vendor at the time the requisition is created.  If the district wishes to require the vendor, this can be done via an optional business rule.

It is no longer necessary to enter an account code on each line item when entering the requisition.  If the district wishes to require the account code, this can be done via an optional business rule.

The audit trail from requisition to purchase order is now maintained correctly by the system.  Once a requisition has been converted to a purchase order it may not be changed or deleted.  The same requisition may also not be converted to multiple purchase orders, thus allowing each requisition to accurately track to the purchase order it is related to.  Also, when a requisition is updated, it continues to keep track of the original "posted by" user rather than updating the posted by user to the person updating the requisition as it does in Classic USAS.

The following fields are new or are named differently than in Classic:

Purchase Orders

A vendor is optional on the Purchase Order.   The vendor may be entered at any time prior to entering the first invoice.  If a vendor is not entered prior to the first invoice, it will be assumed to be a non-vendor specific (i.e.,multi-vendor) purchase order and the vendor will need to be entered at invoicing time.  In this case, once an invoice has been processed against the purchase order, it will no longer be possible to enter a vendor on the purchase order.

The following fields are new or are named differently than in Classic:

The process of canceling items in the redesign no longer requires an invoice.  This option applies to any item that has not yet been invoiced.  If you need to cancel an item that has been partially filled or paid, you'll still need to process an invoice to cancel the remaining encumbrance as you did in Classic.  To cancel a "new" item, or item that has not been invoiced or paid, you simply need to amend the po and click the cancel button for that item.  The button you're used to seeing for the delete option is a cancel button in amend mode.  Hover over the button in amend mode to see the word "Cancel" appear.  You'll see a popup display asking you if you are sure you want to cancel the item.  Click "Ok" to confirm or "Cancel" to cancel this operation.  Once you cancel the item it will appear in the UI with a line through the details, like this:

Open

Invoices

The following fields are new or are named differently than in Classic:

Please see the Purchase Orders topic for information on how to cancel encumbrances on items that have not been invoiced or paid.

Payables

USAS-R has a new concept called Payables.  The Payables option will contain all outstanding invoices and allow them to be processed into Disbursements.  Once the invoice has been paid, it will be removed from Payables.

Disbursements (Checks)

Checks will now be called Disbursements in USAS-R.  Disbursements will consist of physical checks, ach transactions, and other electronic postings.

The payee name and address information will now be stored on the disbursement record at the time of posting, in addition to a reference to the vendor used.  This provides an additional level of security over Classic USAS which only stores the vendor number.

When processing disbursements, payable items can now be grouped either by vendor or by invoice.  Grouping by vendor works similarly to a Classic CKPROC run.  Grouping by Invoice will allow you to get a separate disbursement per invoice for cases where you may need multiple checks for the same vendor.

When a disbursement is voided, the user can now decide whether to void the invoice and re-open the purchase order, or reuse the invoice.  If reusing the invoice, a new payable will be created automatically.

The following fields are new or are named differently than in Classic:

Bank Accounts

A new option will allow you to enter information on each of your bank accounts.  When Disbursements are posted, you will be able to indicate which bank account the checks are being created from.

Distributions/Error Corrections

This option is similar to Classic's ACTMOD option, but is much simpler to use in USAS-R, and works for both expenditure and revenue accounts.  No purchase order or check will be required,  the user simply enters a transaction with items that have a positive or negative amount in order to increase or decrease expenditures or receipts in the accounts.  This is also anticipated to replace the frequently used practice of posting positive and negative reduction of expenditure items to correct the expenditure account charged.

Account Filters

This option will contain your account filters from USASDAT/USASEC.  However, rather than matching on username, each user may be assigned to the correct set of account filters via the Admin/User option.

Pending Transactions

This new option will show transactions sent from USPS that are waiting to be posted in USAS.  You will be able to review the transaction, validate the account balances, and then either post the transaction to USAS or reject them back to USPS.

General Ledger

USAS-R contains the concept of a "General Ledger", which currently records only transactions affecting cash (Disbursements, Receipts, Refunds, and Distributions).  The General Ledger is automatically updated when these transactions are posted.  There is currently no user interface for viewing the General Ledger, but you can report on the General Ledger information using the GLJournalEntry and GLJournalItem objects. 

Budgeting System

USAS-R contains a new method of preparing and calculating next years budgets.  Programs such as BUDWRK, REVWRK, NYPINT, NYPMNT have (or are) being replaced with a new 'Budgeting' module.  The Budgeting module supports the creation and management of Excel spreadsheets used to calculate or enter proposed amounts.  The Excel spreadsheets created by the module contain the same information as the BUDWRK and REVWRK reports, including the prior three years of history, and may also be customized by the user.    Once the budgets are prepared, they can be applied to Budget accounts as "next year proposed" amounts and used to set initial temporary or permanent budgets.  See Budgeting for more information.

Crosswalks

In this section you’ll find a list of crosswalks from Classic. These crosswalks will be preserved here for reference but will not be maintained as USAS updates continue.

SSDT Template Reports

A downloadable crosswalk of the Template Reports and their Classic Counterpart is available here.

Core Menu

For a printable version of the crosswalk, click here.

Transaction Menu

For a printable version of the crosswalk, click here.