1. OEDSA Conference September 2015

2. This presentation will focus on: 1) The programs and features that are currently implemented in USAS-R, with special highlight on changes made for USAS-R 2) Related features that are built into the database model for future implementation. 3) Demo of new user interface

3.  Currently importing nearly all USAS data ◦ Includes importing of all USAS users  Full control over both the export and the import process allows for a simple, seamless process

4.  Support for the existing SOAP Service used by various 3 rd party vendors has been built into USAS-R  This will allow 3 rd party vendors to continue integrating as they are now with little or no changes. Later they will be migrated to a new service that matches the new database model.

5.  We are using a new web framework that allows a better user experience  Behaves more like a desktop application  Provides more flexibility ◦ Customizable grid columns, order of columns, sorting by multiple columns, in-column filtering of results in addition to advanced/expert query  Lazy-loads data at bottom instead of paging

6.  Few accumulated amounts stored in database ◦ Calculated “on the fly” from underlying transactions ◦ Will eliminate balancing issues  Fully integrated XREF codes  Supports flexible Appropriation accounts  Valid account codes now loaded and all account validations being done

7.  Budget and Expenditure Account info split in Database Model  Will allow for more flexible budgeting later ◦ Multiple Expenditure Accounts assigned to single “budget”  Budgeting will be transaction based; currently enter additions/deductions as you do now and transactions are created in the database  Database Model allows for NYProposed for multiple fiscal years and multiple scenarios

8.  New Project option written to define each project  Currently imported based on cash level Project-to-Date flags, and can assign/re- assign specific cash account to the Project  Later, will be able to attach any budgets and anticipated revenues to the project; will not have to be cash-account specific

9.  Limited support added for multiple “Locations”  New Default Payment Type field ◦ Check, Electronic, ACH ◦ Memo vendors will be imported as Electronic ◦ No longer need to use specific range for memo vendors  Multi-vendor flag eliminated ◦ Can now create purchase order with no vendor ◦ Can assign prior to invoicing or use as multi-vendor po  Supports entry of ACH fields from VENSCN via an optional ACH module

10.  Vendor/Account not required ◦ District can optionally require via Rule  Requisition Category split ◦ Separate fields for Category & Template ◦ Category is now a Custom Field  Mass Convert option written

11.  Items split into items and charges, will allow later enhancements: ◦ Eliminate current restrictions on split items ◦ Allow for more flexible charging, percentages, etc.  Database model set up to allow multiple requisitions to be converted to one Purchase Order (not yet implemented)

12.  Optional module written to replace USACON option for tracking requisitioned amounts  Includes balance check rules to include or exclude pre-encumbrance amounts

13.  Optional Requisition Approval module written that mimics Classic “Using Requisition Approval” functionality  Full workflow based requisition approval module will be written later

14.  Database model was updated to allow for later enhancements ◦ Supplier Invoice # tied to Vendor instead of P.O.  Invoice # can’t be re-used for same vendor  Same invoice # can be used for multiple po’s ◦ Memo Invoices ◦ Invoice Adjustment items added

15.  New option which shows all outstanding invoices, used for posting disbursements  Currently has Detail (item) and Vendor tabs  Can create separate check for each Vendor or for each Invoice  Will use Default Payment Type from Vendor, no separate memo vs. regular runs needed  Physical check number assigned at print ◦ Allows for multiple posting runs followed by single printing run

16.  New Disbursement option written  Types are now Accounts Payable, Refund, Payroll  No Vendor or P.O. needed for Payroll checks  Options written to resequence, void, reconcile, unreconcile

17.  Can currently print a simple check format, needs more work to be fully functional  Initial plan is to support customizable printing of pre-printed laser checks  Later, intention is to also support customizable printing onto blank check stock  Creation of XML file is currently in-progress

18.  New screen to set up information on bank accounts ◦ Account number ◦ Description ◦ Start and Stop Date ◦ Custom Fields  Select bank account when processing payables  No longer has to be tied to the cash account

19.  No significant changes currently  Later, vendor will be optional for Refund checks; will be able to just specify Payee name and address

20.  New option written which replaces ACTMOD Distribution/Error Correction option and use of +/- reduction of expenditures for corrections  Supports both expenditure and revenue accounts  No PO or Check needed  Amounts entered as +/- with account  Account entry box ◦ Single box instead of each dimension ◦ Automatically filters by account/xref/description

21.  Integration will be handled via a web service call  New “Pending Transactions” option was written; will show transactions received from USPS (and maybe other systems later)  USAS User will be able to validate, post, or reject the pending transactions  Can currently post payroll, voids, & unvoids

23.  New option written to replace USASDAT/USASEC account filters  A filter can be attached to one or more users  No longer need to match the username  Will be imported initially from USASEC filters

24.  Every transaction is assigned a posting period based on its date  Can have multiple open periods, with one “Current” period  Can begin posting transactions before closing out prior month  Can post adjustments to prior month/fy  New option written which allows opening, closing and setting periods to current

25.  Currently available via Detail Reports only  Journal Entries that reflect all affect on cash are automatically posted from transactions ◦ Receipts ◦ Refunds ◦ Disbursements ◦ Distributions  Currently Cash only, but allows flexibility for other types of journals later if needed

26.  Allows you to define your own fields and attach to any primary data type  Various types: ◦ Text, Code, Money, Number, Date, Date/Time, WebAddress, Email, User, Boolean (True/False)  Code – Can enter valid values, becomes dropdown list  Boolean – Will be shown as a checkbox  Some classic fields changed to Custom Fields ◦ Can disable if you don’t use them and get them off of your screens

27. Control order of field: For each field you can: Enable/Disable: Include in Query or Grid: Group together in screens: Specify label to use: Specify property name Specify type of field: Specify Parent object:

28.  Allows each school to customize the actual behavior of their own system, including… ◦ Custom Validations, using both standard and custom fields ◦ Custom Notifications, i.e. send an email or Twitter notification when a particular event occurs ◦ Updating of fields when an event occurs  Most initial default validation rules are done

30.  District has much more control over which users can see what types of data  District defines Roles with desired Permissions  Permissions are defined by the software ◦ Each data type has at least:  Create, Update, Delete, Read, Report  One or more roles are assigned to each user  Initial Roles will mimic Classic security id’s

31.  Flexible report writer written ◦ User interface improved ◦ All data types, all related properties ◦ Multiple views of some (e.g., header vs. item) ◦ Supports Sorts, control breaks, sum/min/max/ave ◦ Flexible selection criteria ◦ Multiple output types supported  PDF, CSV, Excel, html, text, XML, jasper ◦ Portrait or Landscape, various paper sizes ◦ Save/Recall report settings  Will still need to write some “canned” reports

32.  Organization – Basic district data  OPU’s – Same as Classic  Module Configuration - Maintain config data  Modules – View/Manage Modules  DBA – Database Queries and Backup  Monitor – events, slow queries, exceptions

33. Demo