Skip to end of metadata
Go to start of metadata

This space will be used to provide information and gather feedback on the USAS Redesign project as it progresses towards production releases.   Starting in 2016, the USAS-R project has entered a new phase.  The SSDT is now releasing "Preview Releases" intended to gather feedback from both end-user and ITC personnel.

Pilot Releases

Please see the Pilot Releases page for details about the Pilot Releases.  All current (or potential) State Software Users are encouraged to participate.  To do so, please contact your ITC to request a test instance.  

Demo Version

A demo version of the latest Pilot Release is available at:

The demo version contains limited training data.  Feel free to experiment with the system by adding or changing data.  This database will be periodically reset.  

If you wish to experience USAS-R with your own district's data, please contact your ITC and request they install an instances of the Pilot Release for you.

Accessing the Wiki

If you do not yet have a username for the SSDT Wiki, contact the SSDT for a wiki account. After completing the signup, you will  have rights to post comments on the wiki. You may also use the same username and password to access SSDT JIRA.

If you already have an SSDT JIRA username, we recommend you use the same username and password on both Wiki and JIRA. In the future, these accounts will be merged into a single directory.

Accessing JIRA

If you already have an SSDT JIRA username, you may continue to use your existing JIRA username. If you do not have an existing username, then you should create a Wiki username as described above. Your Wiki username will give you access to both the SSDT Wiki and JIRA applications.




  • No labels


  1. I did a quick test of Milestone 4.  I like the drop down menus.  It gives more room for the information below.  Some of the query information is very tiny.  I had to zoom in quite a bit.  For instance - check information.  I tried it with both IE and Firefox just to see if there would be a difference.  Both were a bit hard on the eyes.

    I'll test more later.  Just wanted to give first impressions.

    1. Unknown User (diemer)

      Thanks for your feedback Nancy.  We agree it may be starting a bit too small right now.  We will be continuing to refine the styling on the page as we go, there are still some inconsistencies we've seen that need ironed out.  We will definitely appreciate feedback if you notice any other areas of concern, things that look strange, etc.


  2. I am testing the import for Milestone 8.  I have tried two districts, and also tried limiting the amount of data pulled from USAS for the load, and received the same error each time.  The load stops on the POHIST file with the error

    2014-02-19:10:00:53 : [Error: Vendor 175516 cannot be assigned to purchase order 4134 because the vendor is inactive from Rule 'purchase order vendor is active in org.ssdt_ohio.usas.model.po']

    When I query on the PO in the USASR, it is showing a status of New, but when I look at it in the VMS, it is completely paid with a date one or two years ago.  Are they not allowed to inactivate any vendors in their live files if there is any history still in the live files that may be attached to that vendor?



    1. Unknown User (diemer)

      No, that was not the intention.  I believe you have found a bug caused by a new validation rule written since the last milestone.  We will discuss the best way to handle this at our next meeting.  We may have to disable this during the import, or only apply the validation if the purchase order is still open.   I have added a JIRA feedback issue for Milestone 8 on your behalf, it is number USASRFB-87.

      As far as why the PO shows as New, if the import did not complete the rest of the loads properly, then this would cause the status to be wrong.  We will take a look at this too, because I believe that the import should have recorded the error but continued on with the loading process.

      1. Melissa,

        When you go the Import area, the elapsed time continues to increment, but the status is 'failed' and no more records are loaded after the error.

        1. Unknown User (diemer)

          I just set this up to try it myself and was able to recreate this behavior.  I created a 2nd feedback issue, USASRFB-88, for the fact that the import is stopping instead of recording the error and continuing on.   Thanks for reporting this.



  3. I just tried Milestone 9 for the first time.  The payables is nice.  One thing I'm not sure on - I had a po that had several items.  I did two invoices for the PO so I could try out the grouping by invoices.  Two or three different items filled on each invoice.  In the payables, I guess I expected it to be listed twice - once for each invoice.  Instead each item was listed and had to be check marked.  That seems cumbersome and redundant to me.  Is that the way it was designed?  Am I not thinking correctly?

    One suggestion on invoicing - I would click the check box and then forget to click the fill items before clicking Post.  A message would come up that Invoice Does Not Have Any Items.  But it was all in gray and no red Error heading with it.  Maybe it should stand out more so people quickly realize they screwed up?  Lol!

    Distributions totally confused me.  I tried to create one with two items - one positive to a 'wrong' account and a negative to a 'right' account.  Is that how it is supposed to work?  When I tried putting in a specific account it was nice that accounts popped up.  But I couldn't tell what order they were in.  When I put in 001, it popped up with a 001 1110 640 account.  I then added a 1110 function and it would skip the 111 object codes and start with 113.  When I put in 111, it would skip the 020000 subject code and go to a subject code starting with 03.  Is this something I should put in Jira?  I just tried doing 001–-640 and that brought up general fund accounts with 640 object codes.  Though I would have expected to only need to put in one hyphen instead of two between 001 and 640.  


  4. Just tried find accounts by description.  That works nicely!

  5. Unknown User (diemer)

    The Payables were designed by item in order to be able to do the same selections that CKPROC can do now and provide more flexibility on exactly what the district wants to pay.  For instance, there are several specific fund options in CKPROC which could cause some items on an invoice to be paid but not others.  Maybe they could select the po or invoice number they want to pay using the query first to make selection easier.

    We can look at the errors in the old user interfaces, they could probably be styled to change the color of the message.

    You are correct on the distributions.  We designed it to be able to just enter + and - thinking this would be the easiest.  We didn't want to use just one amount with a from and to account, because this gets more cumbersome if for instance you want to redistribute the amount from one account into a whole bunch of other accounts  (think about how ACTMOD works now and how ugly it is to use).  We wanted to be able to just enter the "from" account once with the amount you are moving from it, and then enter the "to" account(s) with the amounts you need to expend from those accounts. Of course you could have multiple "from" accounts involved as well.  We're thinking of them more like journal entries from more traditional accounting systems, but we made them an actual transaction type so it was easier to find and report on them.

    I don't think the accounts coming up are sorted in any particular order when they're displayed, with a database they typically just come in random order.  We can discuss this at our next meeting and see if there's any way to sort them without affecting the performance too much. 

    We welcome any continuing discussion on any of these or other topics.