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

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

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

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

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

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