1. ITAS Cash Management Integration to an ERP
Business Requirements and Limitations
The Solution
Issues Faced
Evolution
Business Benefits
POWERED BY HIVEDOME

2. Business Requirements for Phase 1
SOLUTION
ISSUES FACED
EVOLUTION
BUS. BENEFITS
Business Requirements for Phase 1
Cash Management
Seamless integration between ITAS & external Corporate Treasury systems
Problems to solve
No linkage between invoice and cash beyond manual input
Missed invoice payments/receipts generated penalties, cash flow issues
No visibility on payment status
ITAS is used to manage risk and position reporting, trading activities and invoicing
Corporate Treasury System is used to manage banking facilities; payments/receipts with regards to trading
Payment within ITAS CASH processes needed to be blocked if the invoice was accepted for external payment through Corporate Treasury System
The process was to be transparent, traceable and scalable
Business Requirements for Phase 2
Business landscape expected to change, wider use of ITAS data for external accounting
External control of ITAS document status required
State management to be configured by middleware services

3. Overview of the solution provided
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Overview of the solution provided
Cash Management
ITAS (API)
Corporate Treasury System
Middle Tier
SAP
Standard system Integration pattern built around EE (Event Engine) Notifications and ITAS API
EE Notifications for informing external subscribers (users, processes, 3rd party systems) that an ‘event’ has happened in ITAS, to contain enough key information to take next step
ITAS API provides endpoints for ‘notified’ external subscriber to be able to retrieve all necessary data in relation to the notification
Phase 1
CORPORATE TREASURY SYSTEM
Phase 2
Reason for the solution provided
To create a re-usable model, future proof and de-coupled from any 3rd party system requirements
Provides toll for Client middleware developers to build their own workflows and utilise their knowledge of an open architecture or bring in specific skills around this (e.g. working with SAP API)
Many unknowns about future requirements, tapping into the natural evolution of the Events Engine and ITAS API allows self-service development without Hivedome having to always be involved

4. Issues faced in Phase 1 Issues faced in Phase 2 Cash Management
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Cash Management
Issues faced in Phase 1
Limited API, self-built definition library
Workflow required ability to share invoice (payment) status with users on both sides
Potential multiple workflows due to different business models across Commodity platforms and other products
Corporate Treasury System has no direct API, adapters required to transform request to suit message bus
Issues faced in Phase 2
Additional complexity of notifications to SAP which has own API but multiple versions so needed to future-proof any solution
More granular identification of type of invoice required, i.e. distinction between purchase provisional/final and a reversal document
Required concept of ‘locking down’ invoices whilst payment request within external workflow

5. Cash Management Evolution
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Cash Management Evolution
Cash Management
Phase 1 - In order to track payment status we introduced the State Machine
Met requirement to allow customised set of states - controlled via API
Some Trading Entities states using CASHAUTH so their states differed from those that didn’t
Well worked but ITAS users lacked information as states were just numbers and meaning was applied by consumer
Configuration was a scripting exercise and these needed to be distributed each time a Trading Entity was on-boarded
Transaction records locked with a generic flag (txx_chqsel=‘NOT’)
Transaction Header records marked as ‘Sent to Cash Management’
CASH would check these values and prevent selection
Manual process was introduced to allow user override
Phase 1 - To prevent Invoices being paid whilst in Corporate Treasury System workflow
Moving status codes into Heritage allows clients to create codes more applicable/relevant to ITAS processes
Codes can be changed using the ITAS API at Transaction level meaning the use can be more widespread
Default of Open or Locked means that the functionality is available to a wider range of clients
Lock Status concept can now be built into any applicable Heritage application to allow client- configured control beyond Cash Management workflow, e.g. invoice reversals
Phase 2 - To address limitations with State Machine for this project we introduced Document Status

6. Issues faced with the current architecture
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Issues faced with the current architecture
Cash Management
Requirement
Solution
Notify external system(s) when invoice created in ITAS
Notification raised using Alerts process
Able to distinguish different document types within Notification, e.g. provisional from a final
Events Mapping allows assignment of client specific code at document level + style information (e.g. sale vs purchase)
Prevent invoices being paid within ITAS
Document Status codes can be managed through ITAS API
Allow reporting to users of current status of payment
ITAS API provides endpoint for reading current status (full code details); lookup based on ITAS or external system reference
Lockdown activity on invoices in relation to payment status
Lock State associated with Document Status code, can be applied to any accounting document-based function/process
Manual override process
Document Status can be privilege-controlled to allow activity to continue
Notify ITAS users when payment made
No version dependency on Corporate Treasury System, SAP etc
Middle tier development means that there is no tight coupling with specific technology or workflow processes, ITAS API is version controlled
No major UAT effort required for production companies currently using Cash Management through v1
Phase 1 and 2 solutions can work side-by-side, endpoints for phase 2 on dedicated port due to new security protocols, Heritage configuration
Open documentation of endpoint definitions
APIARY is version controlled