Known Third-Party Vendors
All known third party vendors listed below have been contacted by the SSDT and provided with details concerning the SOAP bridge and other points of potential integration for both USPS-R and USAS-R. A copy of the email sent to them is also included below. Each of these vendors were also offered a test instance maintained on SSDT servers to facilitate the verification of their applications' compatibility with the redesigned projects. The redesign status column tracks the status of this testing as currently known by the SSDT.
| Vendor name | Description | Redesign Test Instance Requested | Known to be working with USAS USPS | |
|---|---|---|---|---|
| Automated Business Machines (ABM) | Printing vendor; uses XML, Also has ability to create vendor ACH files from .DAT files. Printing: checks, POs, receipts |  | | |
ABS Money Systems | Printing vendor Create-A-Check software; uses . Note: ABS resells Create-a-check software from AvidXChange/Piracle, see below. Printing: PO, checks, 1099s. | | | |
| American Fidelity | enrollment and deduction data pulls | |||
| AvidXChange/Piracle | Software vendor for Create-A-Check software sold by ABS. Printing: PO | | | |
| Bonefish | Fraud detection software, eVas (USAS) and ePas (Payroll). Uses a combination of SOAP integration and check .DAT files. | | | |
| BuySpeed | Purchasing integration using AUTOPOST, written for Cincinnati with help from HCCA | |||
| CloudBuy | Purchasing Portal; newer vendor started working on integration in Dec. 2015, working with Ohio Schools Council and John Mitchell from CONNECT ITC. Note, this vendor is located in the UK. | |||
| Edge | Printing vendor; uses XML Printing: Reqs, POs, Checks, 1099s & W2s. | | | |
| EqualLevel | Requisition Approval system using the SOAP service; newer vendor started integration in March 2016, working with Ohio Schools Council and John Mitchell from the CONNECT ITC. Contacts: Director Solutions Management: Pete Freimayer, Director of Business Development: Cathy Boyd, Developer: Bryan Way | | | |
| ESchoolMall | eProcurement system using SOAP service. | |||
| MCOECN Kiosk | Provides employee self service capabilities. | | | |
| OnBase | Implementations by ITCs
| | | |
SPS EZPay Pay Schools Payforit | Integrates with DASL to post fee payments for student accounts directly to DASL; integrates with USAS via the SOAP service to post receipts for the fees. | | | |
| PayTheory | Working to integrate with state software to post Receipts. | | ||
ProcessMaker (bought out Formshare) | Workflow approval system; has requisition approval plus various other types of approval workflows available, including some for payroll, student-related, etc. | | ||
| Red Rover | USPS, similar to AESOP | |||
| Requisition Approval Manager (RAM) | Requisition approval system where users still enter requisitions and convert to po's in USAS. RAM just handles the approval pieces. Handled via an hourly export of requisitions. | | ||
SC Strategic Solutions SCView | Provides a Requisition authorization system, post Reqs and POs into USAS. Getting into time sheets with USPS. Printing: checks |
| | |
Copy of SSDT Correspondence Sent to Vendors
We have you listed as a vendor that currently integrates with Ohio's State Software. We are approaching the finish line on our software redesign, so we are reaching out to all of the known third party vendors that integrate with classic USPS and/or USAS. We want to ensure you understand how our redesign may affect your product's integration.
As you may already be aware we are currently running a limited pilot of our new USPS and USAS products with a projected production release date of January 2018. There will be several waves of migration from the classic software to our new products, so for a period of time there will be a subset of schools using classic and another subset using our redesigned products.
If you integrate using the existing classic .DAT print files, information about the new XML formats that will replace these files in USXS-R (a blanket term that covers both USPS-R and USAS-R) can be found here.
As part of the redesign project we have also created what we refer to as "the SOAP bridge" for both USPS-R and USAS-R. The SOAP bridge is an API to our new systems that behaves almost identically to the classic SOAP service that you may be using currently for integration. There are a few minor differences in behavior that we have attempted to track for USPS-R here and for USAS-R here.
If you would like a test instance of our new applications, so that you can verify compatibility with the new SOAP bridge, you can request one from us by sending a message to
- USAS/Inventory: Jodi Becher becher@ssdt-ohio.org
- USPS/Workflows/ESS: Marc Davis davis@ssdt-ohio.org.
There were also a few other integration points third party vendors may have used such as CSV extracts, USPIMPORT, USPLOAD and USALOAD. Most of these applications also have equivalents in USXS-R, so integration via extract and load will be supported.
The CSV file for the USPS-R replacement of USPIMPORT uses the same format, so no modifications should be required to load attendance / absence information using this method.
The USPLOAD replacement in USPS-R is now called Mass Load and does require different file headers, so modifications to the load files will be required. Further documentation on this can be found here (please note this documentation is a work in progress).
The ACCLOAD replacement in USAS-R is now called Mass Load and does require different file headers, so modifications to the load files will be required. Further documentation on this can be found here (please note this documentation is a work in progress).
The VENLOAD replacement for USAS-R is not complete. We will be working on implementing this functionality soon.
If you are currently integrating in some other fashion not detailed above, you will want to notify us and inquire whether your form of integration will continue to be supported in USXS-R.
At this stage the XML files, SOAP bridge, load programs etc. are fairly stable, though minor changes and enhancements are still possible as we move toward production.
All questions concerning integration or requests to setup test accounts should be handled by the ITC. The ITC can create a DEMO instance in VRA for the third-party vendor to test integration with state software applications.