For the purposes of this Use Case, the focus is on Cash Management where Invoicing is generated within ITAS but the Invoice Authorisation (pre-payments for example) is managed in a 3rd party Financial Management system. This is typical in larger Enterprises, where the financing department can operate at a Corporate level and may or may not use ITAS for the authorisation/processing of Invoices.

Key Components

EVENTSMAP allows nomination of the styles of accounting document that need to be included in the Cash Management workflow. This is achieved by assigning a mapping code that will be passed through in the notification. For example, if it is only necessary to pass through Purchase Invoices then mapping codes associated with these can be assigned with these invoice types (provisional, final, reversal).

It is also possible to control a default lock status if appropriate (see DOCSTATE). This is useful in this scenario to prevent actions such as reversals whilst the invoice is in the process of being authorised/approved. Through configuration, 'Locking' an Invoice will flag it for other ITAS applications to follow due process (warn or prevent altogether a reversal request for example).

Workflow Sample

On the basis of the nominated Invoice Type (see above), a Notification is generated by the Invoicing application on creation of an unauthorised* Invoice.

The Notification is picked up by the Subscriber and information about the Invoice is extracted (see Working with the ITAS Events API), including Trading Entity, Document Reference and Type of Invoice (mapping code - see above).

Details relating to the Invoice can be retrieved in a number of ways. The ITAS (REST) API has a dedicated set of endpoints (TransactionHeader, UnPostedTransaction) that contain the most common properties, whereas ClientServices API will allow a more bespoke approach to constructing a query as it uses GraphQL. As well as the Data Entities mentioned previously, the PhysicalTradeBase provides access to all Contract-related properties where relevant.

The Workflow can then perform its activities involving the 3rd Party software (API, flat-file exchange) to create the Invoice/notify the approver in the other system.In time when the Invoice has been authorised/approved it will trigger the next step which will be to notify ITAS that the Invoice is ready to be Posted which can be achieved using AuthoriseForPosting endpoint.

* A similar workflow can be built around simple notifications when an Invoice is posted; corresponding endpoint is PostedTransaction