What you need before you start:

To use the Hub Testing Integration System (HITS), you’ll need the following:

• A HITS testing account - apply from the Request an account section of the HITS Dashboard.
• This will give you access to your own testing environment 
• Your testing environment will provide you with all necessary authentication and access tokens to work with the HITS API.

You’ll also need a basic knowledge of SIF REST:

• Here is some information from the SIF Association.
• Here is a short (1-day) course in developing with SIF 3 REST.

You need to know how to work with a use case in HITS and access the HITS API

If you get stuck: drop us a line at info@nsip.edu.au

How to implement financial processing

1. What’s the business problem?

Allow schools to carry out financial transactions using draft SIF Financial objects, including purchase orders, receipts, invoices, journalling, and payments. More…

2. Use case description & pre-conditions

A 3rd Party Finance application connects to HITS as a jurisdiction hub, collecting the relevant information and publishing back finances records to the centralised system.

Finances conceptual model

The following diagram gives some wider context around school-level interactions for this use case. Note that some possible interactions shown here may not be covered within this technical use case.

Finances data flow

This diagram shows the data flows for finances between student, school and vendors.

Assumptions:

3rd Party Vendor is a current supplier of a Finances product in schools or has knowledge of finances reporting processes in K-12 Schools.

Pre-conditions:

• Vendor has access to HITS
• HITS has been provisioned with School Data
• Vendor has mapped the relevant SIF Objects to their systems:
  • Invoice
  • FinancialAccount
  • ChargedLocationInfo
  • PaymentReceipt
  • PurchaseOrder
  • VendorInfo
  • Journal
  • Debtor
  • EquipmentInfo
  • StaffPersonal
  • StudentContactPersonal
  • SchoolInfo, StudentSchoolEnrollment, Staff Assignment (if clients interact only with a single-school zone, mapping these objects is not necessary. See School Zone Objects. If the current school is a charged location, it will be included among the ChargedLocationInfo objects retrieved from HITS.)

3. Use Case Workflow

Workflow summary:

3.1. Join

3.2. Consume

3.3. Process

3.4. Provide

3.5. Assurance

3.1. Join school zone

Join:

• Third party app connects to Jurisdiction-established Zone for the School (“HITS Zone 1”)
• Third party app authenticates to Jurisdiction-established Zone for the School (“HITS Zone 1 Authz”)
• Jurisdiction Zone authorises read access to objects in the Jurisdiction Zone for the School (“HITS Zone 1 Authn”)

3.2. Consume base data from HITS

Vendor-facing (pull); HITS represents the Jurisdiction and is the data source for seed information.

• Consume:
• on the Jurisdiction-established Zone for the App, Third party app accesses all available AccountingPeriod, FinancialAccount, VendorInfo, and Debtor objects
• Third party app ingests the relevant SIF Objects.

(The following is a list of calls that need to be made to consume the required information)

1. Get FinancialAccount: http://.../FinancialAccounts
2. Get VendorInfo: http://.../VendorInfos
3. Get Debtor: http://.../Debtors
4. Get ChargedLocationInfo: http://.../ChargedLocationInfos
5. Get StaffPersonal: http://.../StaffPersonals
6. Get StudentContactPersonal: http://.../StudentContactPersonals

Endpoints may support additional queries for retrieving data - refer to Query-by-example or service paths for HITS guidance on queries.

3.3. Process in 3rd Party Application

3rd Party App uses the consumed data to generate appropriate transaction information. The definition and automation of this process is out of scope of HITs.

Steps:

• Third party app processes information and gathers financials Information
• Third party application creates return financials objects specific to the School
• The transaction information generated by the App is represented by the following financials objects:
  • PurchaseOrder
  • Invoice
  • PaymentReceipt
  • Journal (transfer from one account to another)

3.4. Provide authoritative data**

Prior to providing:

Third party expresses return information in SIF/XML:

• Third party app connects to Jurisdiction-established Zone for the School (“HITS Zone 1”)
• Third party app authenticates to Jurisdiction-established Zone for the School (“HITS Zone 1 Authz”)
• Jurisdiction-established Zone authorises write access to objects in the Jurisdiction Zone for the School (“HITS Zone 1 Authn”)
• Following is provided by the 3rd Party App back to HITs:
  1. Post Invoice to URL http://.../Invoices
  2. Post PaymentReceipt to URL http://../PaymentReceipts
  3. Post PurchaseOrders to URL http://../PuchaseOrders
  4. Post Journal to URL http://../Journals

3.5. Self – confirm use case support

1. Validate Invoice records
2. Validate PaymentReceipts records
3. Validate PurchaseOrder records
4. Validate Journal records

The SIF/XML data sent by the 3rd Party app to the Jurisdiction Zone for the app must satisfy the following conditions: - Any SIF object published by the App must be valid against the SIF-AU 3.4 schema - All mandatory elements of the submitted SIF objects are provided - All SIF objects posted by the App must have referential integrity. Any RefId contained in the SIF object must refer to a SIF object provisioned to the App—e.g. AccountingPeriod, FinancialAccount—or to another SIF object posted by the App (e.g. Payment referring to Billing).This condition applies recursively to all additional SIF objects posted by the App. The test of this condition is done only when the App indicates that it has finished publishing to the Zone the objects required for the test.

More…

More information

What business problem does this use case address?

In brief:

• Allow schools secure access to finance information
• Allow schools to use the financials product of their choice
• Allow 3rd Party Financials apps automated access to base information
• Allow 3rd Party Financials apps to publish financial data (including ledger updates) to a jurisdiction hub.

This use case responds to the growing interest in using SIF AU to exchange financial data. Anyone seeking to engage with this use case is encouraged to familiarise themselves with the proposed SIF AU financials objects.

This use case assumes that SIF is required only to exchange information about individual transactions (e.g. purchase orders, invoices, receipts, journals), and that reporting will be done out of existing applications—although those reports may be based on the transactional information received through SIF. 

This use case assumes that payroll transactions are out of scope; payroll has not been modelled in SIF-AU as of this writing.

This use case presupposes that there are processes in place for transactions to take place with external parties (debtors and creditors); it does not specify any mechanisms outside of SIF. A purchase order for example may be transmitted to a vendor as a SIF Purchasing object, or as a printed document drawing on information included in the SIF Purchasing object. The mechanisms for generating and sending such a printed document are outside the scope of this use case, and would be provided by existing financial applications. 

The following lists the priority areas of interest in finance (numbers in parentheses refer to the diagrams below) :

1. Receipting – the ability to produce receipts for (1a) Families/ Debtors and (1b) General Ledgers.
2. Purchase Orders – the ability to (2a) produce commitments into ledgers for purchases and (2b) send these to creditors as an approval method for purchases. Ability to (2c) draw down the purchase order at time of payment, to enable the commitment to be used.
3. Invoices – The ability to produce invoice for Debtors, recovery of hire costs in particular.
4. Entering invoices into the system to get these approved before the payment is produced and sent off.
5. Payments – ability to produce a file to be imported into the bank; most payments are made through EFT, but departments need to be able to produce cheques also.
6. Ability to run an end of period process including (6a) a bank reconciliation and (6b) produce reports that go to the Principal, school board, that provides the basis of producing the monthly BAS, and that gives reports to various teachers, faculty or as requested.
7. Ability to run end of year, as schools operate on a calendar year rather than financial year.
8. Ability to do (8a) journals to correct ledger errors, GST errors; (8b) ability to make adjustments to the schools budget; (8c) ability produce the schools budget prior to presentation and approval of the budget.

The following three workflows are SIF-based exchanges which realise most of these priority areas:

The following two workflows represent reporting processes which do not require SIF support, as they are already internally to common financial applications:

Use case preconditions for assurance

None.

Relevant Service Paths Supported on HITS

• SchoolInfos/{}/StaffPersonals
• SchoolInfos/{}/StudentContactPersonals

Relevant Queries By Example Supported on HITS

<SchoolInfo>
    <LocalId>{schoolCode}</LocalId>
</SchoolInfo>

<StaffPersonal>
    <LocalId>{eNumber}</LocalId>
</StaffPersonal>

<FinancialAccount>
  [<ParentAccountRefId>{refid}</ParentAccountRefId>]
  <AccountNumber>{number}</AccountNumber>
  <ClassType>{type}</ClassType> <!-- TBD -->
</FinancialAccount>

<VendorInfo>
  <Name>{name}</Name>
  [<CustomerId>{number}</CustomerId>]
  [<ABN>{abn}</ABN>]
</VendorInfo>

<Debtor>
  <BilledEntity SIF_RefObject="{objectclass}/>
</Debtor>

<ChargedLocationInfo>
  <LocationType>{type}</LocationType>
  <LocalId>{id}</LocalId>
</ChargedLocationInfo>

<StudentContactPersonal>
  <LocalId>{id}</LocalId>
  <PersonInfo>
    <Name>
      <FamilyName>{familyName}</FamilyName>
      <GivenName>{givenName}</GivenName>
    </Name>
  </PersonInfo>
</StudentContactPersonal>

<StudentContactRelationship>
  <StudentPersonalRefId>{refid}</StudentPersonalRefId>
  <StudentContactPersonalRefId>{refid}</StudentContactPersonalRefId>
</StudentContactRelationship>

<Invoice>
  <FormNumber>{number}</FormNumber>
  <BillingDate>{date}</BillingDate>
  <DueDate>{date}</DueDate>
</Invoice>

<PaymentReceipt>
  <TransactionType>{type}</TransactionType>
  [<VendorInfoRefId>{refId}</VendorInfoRefId>]
  [<DebtorRefId>{refId}</DebtorRefId>]
  <TransactionDate>{date}</TransactionDate>
</PaymentReceipt>

<PurchaseOrder>
  <FormNumber>{number}</FormNumber>
  [<VendorInfoRefId>{refId}</VendorInfoRefId>]
</PurchaseOrder>

<Journal>
  [<DebitFinancialAccountRefId>{refId}</DebitFinancialAccountRefId>]
  [<CreditFinancialAccountRefId>{refId}</CreditFinancialAccountRefId>]
</Journal>