1 / 6

ITAS Cash Management Integration to an ERP

Business Requirements and Limitations The Solution Issues Faced Evolution Business Benefits. ITAS Cash Management Integration to an ERP. POWERED BY HIVEDOME. ISSUES FACED. REQUIREMENTS. SOLUTION. BUS. BENEFITS. EVOLUTION. Business Requirements for Phase 1. Cash Management.

townson
Download Presentation

ITAS Cash Management Integration to an ERP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. ISSUES FACED REQUIREMENTS SOLUTION BUS. BENEFITS EVOLUTION 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. ISSUES FACED BUS. BENEFITS REQUIREMENTS SOLUTION EVOLUTION Overview of the solution provided Cash Management • 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 BUS. BENEFITS REQUIREMENTS SOLUTION 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. ISSUES FACED BUS. BENEFITS REQUIREMENTS SOLUTION EVOLUTION Cash Management Evolution Cash Management • 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 Phase 1 - In order to track payment status we introduced the State Machine • 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 • 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 Phase 2 - To address limitations with State Machine for this project we introduced Document Status

  6. ISSUES FACED BUS. BENEFITS REQUIREMENTS SOLUTION EVOLUTION Issues faced with the current architecture Cash Management Solution Requirement

More Related