© 2002 Six Sigma Academy and Helix Systems1 Interface Overview Version 1.0

1© 2002 Six Sigma Academy and Helix Systems

Interface OverviewVersion 1.0


Interface File: Orientation

Nightly Incremental Data Feeds from Source A/R Systems. Changed/modified data only is extracted, transaction parenting occurs, Residual or Partial payment methodology treatment applied, and cash movement activity. Data validation and integrity checked against trailer file(s).

Business UnitX

Business UnitX

Business UnitY

Business UnitZ

METREQMETREQ

SourceSourceA/RA/R

SystemsSystems OracleOracle SAPSAP JDEJDE Other…Other…


Interface File: Process Overview

Identify Source Accounting System

and scope of coverage

Evaluate Source A/R System Operating

Environment, Business Rules and Data, Size

infrastructure Requirements

Business develops Source System extract

file and applies appropriate extract

processing logic and data modification

requirements

Identify and allocate

appropriate resources

Validate data and tied-out to source

A/R

Control totals and data integrity

checks performed

DataIntegrity?

no

yesValidated?

no

yes

Determine the Root Causes of

Errors

Elevate to Production

End

Start

CorrectProgramming

Errors

Send extract to Metreq


Interface File(s) Data Contents

The METREQ data feeds are transactional based – meaning that only the activity to Customer and/or Transaction records is sent to METREQ in the interface data feed. Further, METREQ DOES NOT send data ‘upstream’ to the source A/R system (System of Record). The interface files are produced and sent to METREQ on a schedule determined by the organization – typically each evening.

Because METREQ is transactional based, the system maintains Source System Double-Entry accounting. All debits and credits are monitored, tracked, and applied appropriately.

METREQ maintains all open AND closed transaction items – to include all transaction data (all Debit and Credit activity), line item details, and comment activity. Items reflect the true and accurate status within the Source A/R system – For Example: an item will remain open in METREQ until closed in the source A/R system… the ‘closing’ activity is subsequently captured, send to METREQ, and the item is closed within METREQ.

Further, because METREQ maintains all closed items, it is able to re-open a transaction should it become re-opened within the source A/R system – e.g. a credit is applied.

The retaining of closed items also enables trending and long term process capability analysis and performance measurements, cash forecasting, and goal deployment activities.


Interface Files

METREQ incorporates the use of multiple data files to extract, process, format, and deliver the receivables data from the Source A/R system. Customer Master Transaction Master Transaction Line Item Bill-To Master Ship-To Master Synchronization

These files are used in both pre-production initialization as well as steady-state. During initialization of the system these files will deliver current-state account and transaction detail to METREQ. Post-Initialization, a.k.a. “Steady-State”, the data contained in the interface files will be incremental in nature – or Activity Based, covering a time range specified by the organization.

In addition, in conjunction with system initialization, METREQ may receive a Historic Data Load from the source A/R system. The historic load contains the following files and accompanying data Customer Comments Customer Contacts Invoice Comments Dispute Detail


Organization and Data Relationships

Business Organization RelationshipsCustomer Organization RelationshipsTransaction Organization Relationships

METREQ utilizes and relies on relationships in three key areas forfunctionality of the application:

These relationships determine the treatment and workflow processesapplied to the receivables.


Business Organization Relationships

Defines the organizations reporting, strategic, and operational relationships as related to business organization and accountability100% Definable and Configurable by the business

Example:

StrategicBusiness

Unit(SBU) “A”

StrategicBusiness

Entity (SBE)A1

StrategicBusiness

Entity (SBE)A2

StrategicBusiness

Entity (SBE)A3

Lineof Business

A1A

Lineof Business

A1B

Profit Center A1A1

Profit Center A1A2

Profit Center A1A3

METREQ refers to theseBusiness Organization Relationships

as the“Organizational Hierarchy”


Customer Organization Relationships

Defines your customers organization structureAllows a Single-Voice treatment to the customer across multiple lines of businessDifferent relationship definitions may exist between collection activities and reporting/risk management activitiesFacilitates and enables consolidated customer risk management and reporting activities100% Definable and Configurable by the business – ability to segment, or “break” relationships for alternate treatment at any level – Across A/R platforms

Example:ACME

Customer1

ACMEJDEdwards

1A

ACMEOracle

1B

ACMESAP1C

ACMEWidget Div.

1A1

ACMEChassis Div.

1A2

ACMEChassis Div.

1A3

METREQStrategic CustomerACME 1

METREQStrategic

CustomerACME 1C

METREQ provides the flexibilityto define and treat the customer

as the situation requires.

METREQ refers to theseCustomer Organization Relationships

as “Parenting”,or “Strategic Customers”


Transaction Organization Relationships

Double-Entry accounting activity is maintained and capturedItem activity must carry and identify the original (or Parent) invoice number/identifierItem activity, e.g. offsets, are identified to the original item by carrying the Parent Identifier

ACMECustomer

1

InvoiceI-87AS21

PaymentP-345837

Credit MemoCM-03298

Credit OffsetP-345837

Credit OffsetCM-03298

Associated Item activities are managedand grouped with the original

item/transaction – full history ismaintained for all items.

Debit Offset Debit Offset

METREQ refers to theseTransaction Organization Relationships

as “Transaction Parenting”


Record Type Transaction Type Item Number Amount Status Parent Invoice

Original Invoice I398S459 8,000.00 Open I398S459Offset-O1 Payment P49083 (6,500.00) Open I398S459Offset-O2 Write-Off WO4689 (1,250.00) Open I398S459Offset-O3 Credit Memo CM92093 (250.00) Closed I398S459


Transaction Parenting Example:

The Original Item Number MUST BE carried in the Parent Invoice FieldImportant: Item Number must be carried in the Parent Invoice Field for the Original Transaction



There are two Cash Application Methodologies: Residual Payment Methodology:

– A new and unique Debit Item is created for each credit item that doesn’t fully offset the debit (e.g. Short-Payment)

– A new and unique Credit Item is created for Over-Payments against an item Partial Payment Methodology

– The original invoice remains open until fully offset by either Debits or Credits

Requirements for/in METREQ If a Short-Payment is encountered, only the payment information is sent to METREQ

– Remember: Must include the Parent Invoice Number in the Parent Invoice Field !!! Residual Items should NOT be sent to METREQ If offsetting transactions aren’t created in the Source A/R system they MUST be

created as part of/in the Interface Program

The Cash Application Methodology and Configuration in the Source A/RSystems MUST be reviewed and addressed…



Transaction Parenting and Cash Application Illustration #1Typical “Straight Forward” Scenario…

This example represents Source A/R System activity. If off-settingtransactions are not captured in/by the Source A/R system, the

interface process/program must generate them and send them to Metreq.

-Note that in the above example, there are four activities sent to Metreq

Cash Application Example: Typical Scenario

Date Activity Type Transaction Type Item Number Amount Status Parent

InvoiceARMS Activity

1/1/2002 Original Invoice I398S459 8,000.00 Open I398S459 X2/1/2002 Original Payment CK6785 (8,000.00) Open CK6875 X2/2/2002 Credit Offset Payment CK6785-I398S459 (8,000.00) Closed I398S459 X2/2/2002 Debit Offset Payment CK6785*I398S459 8,000.00 Closed CK6785 X



Transaction Parenting and Cash Application Illustration #2Typical “Straight Forward Multiple Payment” Scenario…



-Note that in the above example, there are seven activities sent to Metreq

Cash Application Example: Single Invoice, Multiple Payment Example



1/1/2002 Original Invoice I398S459 8,000.00 Open I398S459 X2/1/2002 Original Payment CK6785 (4,000.00) Open CK6875 X2/1/2002 Credit Offset Payment CK6785-I398S459 (4,000.00) Open I398S459 X2/1/2002 Debit Offset Payment CK6785*I398S459 4,000.00 Closed CK6785 X

2/15/2002 Original Payment CK6786 (4,000.00) Open I398S459 X2/15/2002 Credit Offset Payment CK6786-I398S459 (4,000.00) Closed I398S459 X2/15/2002 Debit Offset Payment CK6786*I398S459 4,000.00 Closed CK6786 X



Transaction Parenting and Cash Application Illustration #3Typical “Multiple Invoice, Single Payment” Scenario…



-Note that in the above example, there are seven activities sent to Metreq

Cash Application Example: Multiple Invoice, Single Payment Example



1/1/2002 Original Invoice I398S459 8,000.00 Open I398S459 X1/1/2002 Original Invoice I398S499 6,000.00 Open I398S459 X2/1/2002 Original Payment CK6785 (14,000.00) Open CK6875 X2/1/2002 Credit Offset Payment CK6785-I398S459 (8,000.00) Closed I398S459 X2/1/2002 Credit Offset Payment CK6785-I398S499 (6,000.00) Closed I398S459 X2/1/2002 Debit Offset Payment CK6785*I398S459 8,000.00 Open CK6785 X2/1/2002 Debit Offset Payment CK6786*I398S499 6,000.00 Closed CK6786 X



Transaction Parenting and Cash Application Illustration #4Typical “Straight Forward Multiple Payment” Scenario…



-Note that in the above example, there are four activities sent to Metreqand that the Original Invoice item remains open

Cash Application Example: Short Payment Treatment



1/1/2002 Original Invoice I398S459 8,000.00 Open I398S459 X2/1/2002 Original Payment CK6785 (7,000.00) Open CK6875 X2/1/2002 Credit Offset Payment CK6785-I398S459 (7,000.00) Open I398S459 X2/1/1900 Debit Offset Payment CK6785*I398S459 7,000.00 Closed CK6785 X


Interface Considerations

System Configuration Business Organizational Relationships, or “Organizational Parenting”,

configuration Which transactions to/are associated with the various business levels Identify and define Resolvers by business level/entity – who owns the

responsibility for the various transaction/dispute types within each business level

Escalation paths– Across business levels– Across A/R systems

Source System Cash Application Treatment Residual Payment Methodology Partial Payment Methodology Automatic Write-off configurations

– Write-off activity must be captured and fed to Metreq The treatment of cash movement between customer accounts


Interface File Development

Data MappingFunctional DesignDesign Review Review source system configuration and data treatment Validate approach and logic

Development Reviews Demonstrate ability to provide Transactional Organizational Relationship,

“Transaction Parenting”, under all scenarios Review Code and Logic Review Data Validation

– Trailer Records– Synchronization Files– User “Eyeball” validation

Elevate to Production


Production Elevation Criteria

Interface file development is complete when: Source A/R System Ties out and balances with Metreq at the following

levels…– System– Customer– Business– Transaction

There are no rejected records


Interface Development Process Flow

InterfaceRequirement

DocumentProvided to

Business UnitFinancial App.

Support

Start

Business UnitDevelops Extract

Files

Develop CustomerMaster File

Develop Bill-to/Ship-to File

DevelopTransactionMaster File

DevelopTransaction Detail

File

DevelopSynchronization

File

Test Data FeedFile(s)

Pass ValidityTest(s)?

Perform Cause &Effect / FMEA

Analysis

Plan CorrectiveAction

No

ImplementCorrections

User Data Tie-out

Yes

Source A/R SystemData Feeds

Tied Out?

No

Yes

Obtain CustomerSignoff & ApprovalEnd Elevate to

Production

Are thereReject

Records?

No

Yes



Source System

RejectedRecords

(SequenceOrder)

ControlTotals

DiscrepancyCheck for Data

Accuracy

DoDiscrepancies

Exist?

End

No

ReconciliationReport is CreatedYes

ReconciliationReport

ReconciliationReport Sent via E-

Mail to SourceSystem

Administrator

Review andCorrect

ReconciliationErrors

Data Reconciliation



ARMS

RejectedRecords

Create CustomerTotals File

Data Tables

CustomerTotals

Source A/RSystem

Customer TotalFile is Created

Source A/RCustomerTotals File

FTP Source A/RCustomer Totals

File to ARMS

Customer TotalDiscrepancy

Check

DiscrepancyExist?

End

No

CreateDiscrepancy

Report

DiscrepancyReport

DiscrepancyReport Sent via E-

Mail to SourceSystem

Administrator

A

A

Address andCorrect

Discrepancies

Data Synchronization

Documents

© 2002 Six Sigma Academy and Helix Systems1 Interface Overview Version 1.0