bbd10002 credit card process v01

Business Blueprint Document – BBD10002 Cards ReconciliationBP Accelerator DART

1BBD10002 Cards Reconciliation

Document version control:

Document Version

Date Authors Status Short description of modification

0.1 26/04/06 Pete Donachie Draft Initial Draft

… … Pete Donachie Draft Revised Draft

0.9 10/06/06 Umesh Lohit Draft Revised Draft

1.0 16/06/06 Umesh Lohit Draft Included comments from Terry Mahoney

1.1 21/06/06 Umesh Lohit Final Revised with additional inputs from Terry Mahoney

1.2 27/04/07 Umesh Lohit Final Added reference to FNS10320

LAST SAVED: PRINTED: File /tt/file_convert/563db9e5550346aa9aa0e256/document.doc

01/05/2007 07:43:00 PM

PAGE 1 OF 18

Business Blueprint Document – document.docBP Accelerator DART

Table of contents

1. Glossary................................................................................................................................... 32. Management Summary............................................................................................................4

2.1 Business background........................................................................................................42.2 Payment Card Processing Overview................................................................................42.3 Scope of this document....................................................................................................5

3. Process Description................................................................................................................. 73.1 Requirements...................................................................................................................73.2 Assumptions.....................................................................................................................73.3 Cards Settlement Process................................................................................................83.4 Cards Reconciliation Process...........................................................................................9

3.4.1 Data Flow.................................................................................................................. 93.4.2 Regional Variations....................................................................................................93.4.3 Tracing Factor..........................................................................................................103.4.4 Process Harmonisation............................................................................................113.4.5 Reconciliation by Batch...........................................................................................123.4.6 Controlling and Managing Postings.........................................................................123.4.7 Analysis of Commissions.........................................................................................133.4.8 Field Mapping for Batch Numbers...........................................................................13

4. Business Controls..................................................................................................................155. Business Scenarios...............................................................................................................156. Timing and Frequency...........................................................................................................15

6.1 Timing............................................................................................................................. 156.2 Frequency....................................................................................................................... 156.3 Scheduling Requirements...............................................................................................15

7. Inputs and Outputs................................................................................................................. 167.1 Input details....................................................................................................................167.2 Output details..................................................................................................................16

8. Reporting Requirements........................................................................................................169. Process requirements............................................................................................................17

9.1 Retalix............................................................................................................................. 179.1.1 EPS Terminal Batch Number and Acquirer Batch Number......................................179.1.2 EPS Tender Key......................................................................................................17

9.2 SAP................................................................................................................................. 179.3 Informatica/POS DM.......................................................................................................179.4 Gaps, ABAP development requirements........................................................................179.5 Change Impact...............................................................................................................17

10. Country specific requirements (not covered by harmonised template solution).....................1711. Appendix: Related Document - Payment Card Batch Processing..........................................18


01/05/2007 07:43:00 PM

PAGE 2 OF 18


1. Glossary

Acquirer - The Bank or other payment agency that effects payments collected by sites via payment cards

Bank - The Bank where the business accounts are held (where the Acquirers make payment to)

Bank Account - Banking Account of BPBOS - Back Office System, typically used to refer to the server that integrates data from

all the tills at the retail outlet. The tills are all connected to the BOS and all data transfers and communication between the retail systems and SAP happen through the BOS. The term may be used in this document, where the context so admits, interchangeably with Retalix and POS.

BW - Same as SAP BWClosure Message - An electronic communication from a sender system to trigger a

reciprocal action by the receiver systemDGI - DART GSS IntegrationEBS - Electronic Bank StatementEPS - Electronic Payment System: A system to enable communication co-ordination

between the FEPs and POSs for payment card transctions.EPS Terminal Batch Number - This is the identifier of the POS payment period and is

managed by the EPS. The POS logs this identifier assigned by the EPS. This batch number is incremented by the EPS on receipt of a closure message from the POS.

FEP - Front End Processor: the online processing system that receives card authorisation requests from the EPS.

GL - General Ledger (in financial accounting)Informatica - Middleware used for transformation of data from Retalix to SAP readable

formatIFSF - International Forecourt Standards Forum: A forum of international oil companies

with the common objective of harmonisation of equipment interconnectivity and communication standards for achieving interoperability of forecourt equipment through open standards.

Payment Card - Credit, Debit or other cards used for payment at the POSPOP - Point of Purchase equipment used to read cards presented for payment and enter

PIN and fleet card data.POS - Point of Sale system typically used to refer to the retail tills at the BP retail outlet.

The term may be used, where the context so admits, interchangeably with Retalix and BOS.

POS DM - SAP POS Data Manager used for enhancement of data from InformaticaReconciliation Account - A GL account, to which transactions in the subsidiary ledgers

(such as in the customer, vendor or assets areas) are updated automaticallyRetalix - The company providing the software solution used for integration of BP Retail

operations at the retail outlet level. This solution is implemented for BP as the Global Site System. The term may be used in this document, where the context so admits, interchangeably with POS and BOS and the software solution itself.

SAP - Same as SAP R/3SAP BW - The SAP Business Information WarehouseSAP R/3 - The SAP R/3 Retail systemSettlement - Transaction at the POS to trigger a payment by Acquirer


01/05/2007 07:43:00 PM

PAGE 3 OF 18


2. Management Summary

2.1 Business backgroundAmong their daily routines, sites receive goods, sell goods and realise billings by payments from customers be they in the form of cash, cheques, fuel cards, credit cards or other payment cards. As a part of the day-end procedures, the transactions of the day are transferred from the site system (Retalix) to SAP R/3 where appropriate financial accounting documents are created.

When a site runs its day-end procedures to close the business day and start the next business day, detailed transaction files are generated by Retalix. These transaction files (referred in Retalix as "un-reconciled files") are loaded to SAP BW. In the GSS Global Template, this end-of-day procedure runs automatically at a pre-configured time.

After having run the day-end procedures, typically on the next day, the site manager checks the transactions of the day, matches collections with billing, checks cash balances, card settlements etc. and confirms the day as "closed" in Retalix whereupon, Retalix generates a new set of transaction files that are referred in Retalix as the "reconciled files". These files contain data (including card settlements) aggregated by the day and these are the files that get loaded to SAP R/3.

The data transfer process isRetalix creates daily files and these files are transported by infrastructure applications (XcelleNet and IntraNect) to InformaticaInformatica re-maps file data and exports the data to POS DMPOS DM validates data from Informatica, generates and exports IDocs to SAPSAP receives IDocs, creates and posts sales, goods movements and accounting transactions

As part of the procedures of the day, the site also settles (with one or more Acquirers) sales realisations by payment cards. The settlement results in the Acquirers arranging to pay the payment card collections into the Bank account. For the payments made, the Acquirer sends a statement of settlements (and corresponding payments into the Bank account) and the Bank sends a statement with credits corresponding to the payments made by the Acquirer. These statements are received into SAP and first, data received from Retalix is reconciled with the Acquirer's statement and then, the Acquirer's statement is reconciled with the Bank statement.

It may be noted that the Acquirer and the Bank could be distinct entities or the same entity. In the event of the former, distinct statements are received and the event of the latter, either two distinct statements or a single Bank statement may be received. Both the Acquirer's statement and the Bank's statement are treated as Electronic Bank Statements for the purpose of processing in SAP using standard SAP functionality.

Note: This document only addresses payment cards (i.e., Credit Cards, Debit Cards, Charge Cards etc.) and does not address cards or modes of payment that are by a discount on bills raised by a site. Such discounts are charged off to expense when Retalix returns that information to SAP. This note has been explicitly inserted since the term "Cards" had raised the issue of possible interpretation that could include "Discount" or "Gift" cards.

2.2 Payment Card Processing Overview

Processing of payment cards is a sub-set of site operations and it involves a number of components revolving around the EPS: When a payment card transaction is required, the POS notifies the EPS which then, using the appropriate FEP, processes the card transaction. Most of the processing is done on aggregated sets of transactions (referred to as “batches”) for a particular site.

"EPS Terminal Batch" is the identifier of the POS payment period and is managed by the EPS. The POS logs this identifier assigned by the EPS. This batch number is incremented by the EPS (typically each day) on receipt of a closure message from the POS.


01/05/2007 07:43:00 PM

PAGE 4 OF 18


"EPS Acquirer Batch" identifies the acquirer settlement period by the FEP for payment cards. The control of the Acquirer Batch depends on the system architecture of the EPS and is usually assigned by the EPS. Initiation by the FEP of a close of the Acquirer Batch results in the EPS incrementing the Acquirer Batch Number. In most countries, there is one Acquirer Batch per EPS Terminal Batch because the cards settlement period coincides with the business day. In some countries (like the USA), there are multiple Acquirer Batches per EPS Terminal Batch.

In the data exported from Retalix*, the EPS Terminal Batch and EPS Acquirer Batch are both included and are appropriately used to trace payments from the settlement at site to the credit in the Bank account.

* See also section 3.4.2 "Regional Variations" for exceptions/variations.

2.3 Scope of this documentThis process overview may include a number of site transactions but they are included only for the context of the Card Reconciliation Process - the process addressed only considers

revenues realised at sites by payment cards,payments realised by settlement of those transactions andreconciliation of the realised payments with the amounts credited by the Bank.

Inter alia, the reconciliations also involve the calculation and analysis of commissions on the payment card transactions.

Informatica

Financial Postings for Sales and Tenders

Statement in SAP compatible format?

POS DM

BW

Card & Settlement

Data in Daily Export Files

IDocs from Reconciled Files

Mapped Daily Export Files

Formatted Electronic Statements

Yes

NoUnreconciled Files

Settlement Data

Electronic Statement

Acquirer Bank

ConfigurationConfiguration

Master DataMaster Data

Mapping TablesMapping Tables Reconciliation with Bank Statement

Reconciliation with Acquirer Statement

Acquirer StatementAcquirer Statement

(EBS) Upload(EBS) Upload

Electronic Bank Electronic Bank Statement UploadStatement Upload

BOS

Site System

EPS FEPRetail Customer

Sal

es

Pa

yments

POPs

POS

Req

uest R

esponse

Informatica

Financial Postings for Sales and Tenders

Statement in SAP compatible format?

POS DM

BW

Card & Settlement

Data in Daily Export Files

IDocs from Reconciled Files

Mapped Daily Export Files

Formatted Electronic Statements

Yes

NoUnreconciled Files

Settlement Data

Electronic Statement

Acquirer BankAcquirer Bank

ConfigurationConfiguration

Master DataMaster Data

Mapping TablesMapping Tables Reconciliation with Bank Statement

Reconciliation with Bank Statement

Reconciliation with Acquirer Statement

Acquirer StatementAcquirer Statement

(EBS) Upload(EBS) Upload

Electronic Bank Electronic Bank Statement UploadStatement Upload

BOS

Site SystemSite System

EPS FEPRetail Customer

Sal

es

Pa

yments

POPs

POS

Req

uest R

esponse

The pre-requisite to the Cards Process is the posting of sales documents against which the payments by cards are collected by the site: when the site transaction data is received by SAP in the form of IDocs, the first posting is to the Site Customer account for the sales and billings of the site (in the Sales IDoc) as a receivable from the Site Customer account. Accruals arising from sales are also posted in this document.


01/05/2007 07:43:00 PM

PAGE 5 OF 18


Here is an illustration of a sales document posting:Site Customer Account Dr 100.00To Sales 85.85To Local VAT 14.15Lottery purchases Dr 1.00To Lottery purchase accrual 1.00E-PAY purchases Dr 1.50To E-PAY accrual 1.50

102.50 102.50

The lines other than the debit to the Site Customer Account are not relevant to the processes described in this document.

For tenders against the sales, a Tenders IDoc is then posted and the Site Customer account is cleared (indicating that the billings have been realised at the site):

Cash Control account Dr 41.00 << CashCash Control account Dr 0.50 << ChequesPayment Card Receivables Dr 55.50 << Payment CardsPurchases Food Services Dr 2.19Till Shorts Dr 0.08Payment Card Commissions Dr 0.83 << P&L AccountFuel variance Dr 0.07To Sales Fuels 0.07To Indebtedness 0.10To Site Customer Account 100.00

100.17 100.17

Here, again, the lines that are relevant to the Cards Process are the credit to the Site Customer account, the debit to the Payment Card Receivables account and the debit to the Payment Card Commissions account (an expense). If the Site Customer Account continues to display a debit balance, the posting of tenders is incomplete and provides the first point of control (at the point of collection of tenders) for tracking Payment Card Receivables.

Variations of accounting exist for the next stage of the accounting process. Where the Acquirer and the Bank are distinct entities and both provide distinct statements, the Acquirer's statement is first uploaded to SAP using the EBS upload functionality. This upload matches the Payment Card Receivables with the Acquirer's statement of payments and clears the Payment Card Receivables statement by posting the receivables to the Bank Clearing Account:

Bank Clearing Account Dr 55.50To Payment Card Receivables 55.50

55.50 55.50

This works as the second point of control of the Cards Process: Where amounts are not cleared from the Payment Card Receivables account, either the Acquirer has not received the settlement made by site (and the entry is missing from the Acquirer's statement) or the calculated commission posted in SAP for the Acquirer differs from the commission charged by the Acquirer or the amount reported as settled by the site is not the same as the amount settled by the Acquirer. In all three events, the cause is investigated through the site and manual entries are posted in SAP for rectification, if required.

The final control point is the receipt and upload of the Bank statement with which the Cards Process loop completes. The resultant postings in SAP are

Bank Account Dr 55.50To Bank Clearing Account 55.50

55.50 55.50

With this, the realisations by the site of card collections are confirmed as banked.


01/05/2007 07:43:00 PM

PAGE 6 OF 18


3. Process Description

3.1 Requirements

Req. No. Description Category

GSS Impact

DART Impact Remarks

94 Prepay and Settlement Reconciliation

Business process

226 Payment card reconciliation process

Business process

X X This process in SAP is dependent on data capture by Retalix and onward mapping by Informatica and POS DM.

(BP CRD # 283 and # 422 for Retalix)

3.2 Assumptions

No. Assumption Source

1. Req. 94 ("Prepay and Settlement Reconciliation"): The Fuel Systems hold the liability therefore the data coming to SAP from the BOS must be net of POS prepay activities to allow settlement reconciliation to take place at the batch level. This requirement is related to prepay cards process for the US and will be managed as a local deployment activity and therefore is out of the scope of this document.

Derek O'Hagan

2. Req. 226 ("Payment card reconciliation process"): It is assumed that the basic interface architecture including the custom table ZFIC_CARDTYPES and condition type ZNL1 will continue to be available and continue to be used.

Tim Empson

3. Retalix will be able to return both the EPS Terminal Batch Number and the Acquirer Batch Number to Informatica so that these may be appropriately mapped and posted in SAP.

BP CRD # 283 for Retalix


01/05/2007 07:43:00 PM

PAGE 7 OF 18


3.3 Cards Settlement ProcessThis section outlines briefly the Cards Settlement Process so that the business process background is better understood. The explanation here is very simplified and is provided only for conceptual understanding of payment card processing.

Payment card acquirers operate one or more FEPs to provide authorization processing for card transactions from retail sites. FEPs communicate with the EPS and also the BP head office settlement systems.Retalix POSs communicate with the EPS.When a payment card is presented for payment of a sales receipt at the POS, the POS communicates with the EPS and the EPS (with its related components) processes the acceptance of the card.When the POS sends a daily closure message (called "ReconciliationWithClosure" message in the IFSF standard) to the EPS, the EPS initiates a settlement through the FEP simultaneously incrementing the EPS Terminal Batch number (and closing the Acquirer Batch if the Acquirer Batch is used) and sending a "ReconciliationWithClosure" response to the POS. Once so incremented, all subsequent card payments are identified by the new (incremented) EPS Terminal Batch number and the old batch number is no longer available for POS transactions. In some regions, the FEP and EPS also maintain an "Acquirer Batch Number" with the EPS. Thus, for a number of card payments at a POS till, the "EPS Terminal Batch Number" would be common and would be the grouping criterion for card payments collected by all POS devices using the same EPS in a given EPS processing period. This "EPS Terminal Batch Number" could have one or more corresponding "Acquirer Batch Numbers" in regions where the Acquirer Batch number is used.The POS and EPS use the EPS Terminal Batch number to identify all cards transactions processed within a single EPS processing period.

Every sales realisation (by payment cards) in Retalix would thus have an "EPS Terminal Batch Number" and this "EPS Terminal Batch Number" could be traced to an "Acquirer Batch Number" that, in turn would provide the trace for credit in the Bank account*. It may be noted that there could be multiple EPS Terminal Batch Numbers in the same day for payment card transactions at a POS till and multiple EPS Terminal Batch Numbers could be associated with a single Acquirer Batch Number. Retalix, in the reconciled files, would return the card type (viz. MasterCard, VISA, Maestro, American Express etc.), EPS Terminal Batch Number, Acquirer Batch Number, transaction count and amount so that appropriate entries are created in SAP (including for commissions payable to the Acquirer or per card type).

* See also section 3.4.2 "Regional Variations" for exceptions/variations.


01/05/2007 07:43:00 PM

PAGE 8 OF 18


3.4 Cards Reconciliation Process

3.4.1 Data Flow

This schematic representation of the Cards Reconciliation Process data flow is to be read in conjunction with section 3.3 "The Cards Settlement Process" and section 3.4.2 "Regional Variations":

Bank

Informatica

POS DM

Settlement information

EPS Batch NumberAcquirer Batch Number

Electronic Statements

Daily Export File (Tenders and Banking Interface)

MappedDaily Export Files

(Tenders and Banking Interface)

SAP

IDocscreated from reconciled files(Tenders and Banking Interface)


DGI Interface

Acquirer

EPS

Settlement Information

Acquirer Batch Number

FEP(s)Acquirer Controlled Systems

Settlement(by Batch)

Bank

Informatica

POS DM

Settlement information

EPS Batch NumberAcquirer Batch Number


Daily Export File (Tenders and Banking Interface)

MappedDaily Export Files

(Tenders and Banking Interface)

SAP

IDocscreated from reconciled files(Tenders and Banking Interface)


DGI Interface

Acquirer

EPS

Settlement Information

Acquirer Batch Number

FEP(s)Acquirer Controlled Systems

Settlement(by Batch)

3.4.2 Regional Variations

The Cards Reconciliation Process is dependent on the country, acquirer and local business practices.

In some regions, the Acquirer is the same as the Bank, in some others, they are different entities.In some regions, the Acquirer uses the "EPS Terminal Batch Number" to identify payments and passes it on to the Bank so that the "EPS Terminal Batch Number" is the only tracing factor required.In yet other regions, the Acquirer and the Bank use the "Acquirer Batch Number".In Australia and New Zealand, the Acquirers do not use the EPS Terminal Batch number for referencing but use only the business date.In the USA, the Acquirer systems use the Acquirer Batch number for referencing and not the EPS Terminal Batch number.

The Cards Reconciliation Process needs to be able to work with all these variations.


01/05/2007 07:43:00 PM

PAGE 9 OF 18


3.4.3 Tracing Factor

As evident, the Cards Reconciliation Process is about tracing monies from site realisations to Acquirer settlements to the Bank account. In order to trace the flow of transactions, a tracing factor, such as a consistent reference used by the Site, Acquirer and Bank, is necessary to identify realisations at site with the statement (if any) issued by the Acquirer and the subsequent statement issued by the Bank. However, as pointed out in section 3.4.2 above, a consistent tracing factor may not be available across regions due to regional business practices.

Dependency of the process, therefore, switches to the data reported by Retalix to SAP and subsequent regional adaptations of use of the reported data for the process.

Consider the following illustration to depict the handling and reporting of data by Retalix: Some regions use a single EPS for a site and in some regions, there could be multiple EPSs for a Site leading to a single or multiple EPS Terminal Batch Number in a business day. Even if there is a single Acquirer/EPS Terminal Batch per business day, the “batch” of payment card transactions from the processor and in the Retalix day batch (for which Retalix generates the reconciled files) may not coincide.

Card Type Value Card Type Value Card Type Value Remarks06:00 0043 MasterCard 21.00 MasterCard 94.00 AmEx 32.0007:00 0043 Maestro 51.00 MasterCard 90.00 VISA 32.0008:00 0043 AmEx 54.00 AmEx 24.00 Maestro 65.0009:00 0043 Maestro 57.00 VISA 77.00 VISA 95.0010:00 0043 MasterCard 5.00 Maestro 28.00 Maestro 38.0011:00 0043 AmEx 10.00 AmEx 39.00 MasterCard 38.0012:00 0043 MasterCard 72.00 VISA 42.00 AmEx 49.0013:00 0043 VISA 72.00 MasterCard 37.00 AmEx 29.0014:00 0043 Maestro 56.00 VISA 30.00 AmEx 79.0015:00 0043 AmEx 61.00 MasterCard 49.00 AmEx 45.0016:00 0043 MasterCard 31.00 MasterCard 64.00 Maestro 38.0017:00 0043 Maestro 37.00 VISA 34.00 MasterCard 97.0018:00 0043 Maestro 88.00 AmEx 22.00 MasterCard 68.0019:00 0043 MasterCard 36.00 MasterCard 31.00 VISA 93.0020:00 0043 MasterCard 61.00 VISA 96.00 MasterCard 96.0021:00 0043 Maestro 97.00 MasterCard 50.00 VISA 9.00 EPS Terminal Batch Close22:00 0044 MasterCard 23.00 VISA 75.00 MasterCard 34.0023:00 0044 VISA 93.00 MasterCard 87.00 MasterCard 93.0000:00 0044 AmEx 3.00 AmEx 99.00 VISA 60.0001:00 0044 Maestro 26.00 Maestro 50.00 MasterCard 64.00 BOS Day Close02:00 0044 AmEx 15.00 MasterCard 10.00 VISA 49.0003:00 0044 VISA 41.00 VISA 32.00 AmEx 62.0004:00 0044 MasterCard 96.00 VISA 16.00 Maestro 96.00 POS 2 Day Close05:00 0044 AmEx 62.00 Maestro 85.00 VISA 18.0006:00 0044 Maestro 9.00 AmEx 95.00 VISA 83.0007:00 0044 AmEx 57.00 Maestro 54.00 VISA 17.0008:00 0044 MasterCard 20.00 Maestro 80.00 MasterCard 99.0009:00 0044 MasterCard 25.00 MasterCard 12.00 MasterCard 75.00

The areas marked 1, 2 and 3 represent the time and EPS Terminal Batch Numbers valid for that time. The areas marked 4, 5 and 6 represent the transactions at POS 1 (corresponding to the batch numbers alongside), areas 7, 8 and 9 represent transactions at POS 2 and areas 10 and 11 represent transactions at POS 3 (all with corresponding batch numbers alongside).

Day n data transmitted in reconciled files from RetalixCard type Batch Total POS 1 POS 2 POS 3AmEx 0043 444.00 125.00 85.00 234.00AmEx 0044 102.00 3.00 99.00 0.00Maestro 0043 555.00 386.00 28.00 141.00Maestro 0044 76.00 26.00 50.00 0.00MasterCard 0043 940.00 226.00 415.00 299.00MasterCard 0044 301.00 23.00 87.00 191.00VISA 0043 580.00 72.00 279.00 229.00VISA 0044 228.00 93.00 75.00 60.00

Day n+1 data transmitted in reconciled files from RetalixCard type Batch Total POS 1 POS 2 POS 3MasterCard 0044 337.00 141.00 22.00 174.00VISA 0044 256.00 41.00 48.00 167.00AmEx 0044 291.00 134.00 95.00 62.00Maestro 0044 324.00 9.00 219.00 96.00

MasterCard xxxx 114.00 32.00 12.00 70.00VISA xxxx 32.00 14.00 6.00 12.00AmEx xxxx 913.00 103.00 451.00 359.00Maestro xxxx 82.00 26.00 50.00 6.00

POS 1 POS 2 POS 3Time

EPS Term. Batch #

1

2

3

4

5

6

7

8

9

10

11

Data in Reconciled files ofDay n

Data in Reconciled files ofDay n + 1

Other batches of Day n+1 (not in the table above)

Batches of Day n+1 (in the table above)


01/05/2007 07:43:00 PM

PAGE 10 OF 18


Cards transactions could be in flight between POS close and the ReconciliationWithClosure response being received by the POS, especially at multi-POS sites sharing a single EPS. This can result in the EPS and/or FEP logging the transaction in one business day and the Retalix system logging them in a different business day.

As in the illustration, (please note that the time mentioned is only to represent its passage), if the EPS Terminal Batch number at POS1 is incremented but POS2 closes a bit later and if only POS3's batch closure matches the day closure at the site, the batch numbers would overlap two days on some POSs and would be unique to a day on some others.

When the day close is initiated in Retalix for generation of reconciled files, Retalix identifies the card types, the EPS Terminal Batch numbers and values that actually correspond to the day being closed and sends the aggregated data to be uploaded to SAP. Using the illustration above, the aggregated data sent by Retalix for Day n would be the data from areas 1, 2, 4, 5, 7 and 10. The residual data of batch numbers used during the actual day would be part of the reconciled files transmitted for the next business day (closure of Day n+1). Each card type would use one line per batch number and the data would be aggregated by the day for posting the Tenders IDoc in SAP (as illustrated above). Retalix would also include the corresponding Acquirer Batch number where available and where not available, Retalix would populate the field with zeroes.

Typically, a number of card types could be processed by a single Acquirer that accepts and settles the payments. The Acquirer would also levy a commission for the payments and this commission could be deducted from the amounts settled per "Acquirer Batch Number" or per business day or could be separately levied by a distinct charge (debit) reflected in the statement of account of the Acquirer. The matter of commissions is specifically addressed in section 3.4.6 "Controlling and Managing Postings".

3.4.4 Process Harmonisation

The first requirement is of accounts in SAP. As described in section 2.3 (Scope of this document), the required accounts are one each for Payment Cards Receivables and Bank Clearing with the other accounts available by default (Site Customer Account, Payment Card Commissions Account and Bank Account).

When the site "settles" its payment card transactions for the day, the Acquirer makes a payout to a designated bank account (House Bank). Subsequently, the Acquirer issues a statement of payouts made with references of the settlements made by the site and the House Bank issues a statement of pay-ins or credits for a period. The site settlements are first matched with the Acquirer's statement and the Acquirer's statement is then matched with the House Bank statement and the Bank account is updated.

When the Acquirer is different from the Bank, an Initial Clearing account is required to credit the site for payment card collections. On receipt of the Acquirer's statement, the Initial Clearing account is cleared and the receivables are now posted to a Bank Clearing (Suspense) account. Finally, on receipt of the Bank's statement, the Bank Clearing (Suspense) account is cleared and the receivables are realised in the Bank's GL account.

When the Acquirer is the same as the Bank, the Initial Clearing account is not required and the site settlements are directly posted to the Bank Clearing (Suspense) account and then cleared on receipt of the Bank's statement by realisation in the Bank's GL account.

Thus, where the Acquirer is different from the Bank, two clearing accounts are required and where the Acquirer is the same as the Bank, one clearing account is required. If multiple Acquirers exist with one Bank, one Initial Clearing account is required for each Acquirer and one Bank Clearing (Suspense) account is required and if multiple Acquirers exist with multiple Banks, one Initial Clearing account is required for each Acquirer - Bank combination (i.e., for each Acquirer that makes payouts to a Bank).

The Initial Clearing account mentioned in the process above could either be a GL account or an Accounts Receivable account assigned to one reconciliation account for "Payment Card Receivables". If mapped to a GL account, the advantage would be that the EBS


01/05/2007 07:43:00 PM

PAGE 11 OF 18


process would be uniform and the granularity of visibility would be very fine (at Acquirer level) in the GL and the key disadvantage would be the requirement of numerous GL accounts that cannot be subsequently deleted or otherwise suppressed. The number of accounts could vary unpredictably since the business is dynamic and Acquirers could change over a relatively short period of time. The impact would be an accumulation of redundant GL accounts.

If mapped to an Accounts Receivable account, the EBS process would need to be a template and this template could be easily adapted to suit any local banking practice (by account mapping for EBS). The visibility in the GL account (the reconciliation account that would group the AR accounts) would be an aggregation of Acquirers and that would be adequate representation in the Balance Sheet. The complete details would anyway be available at the "customer" account level. Redundancy of accounts would be limited to one customer account group and the number of accounts would not be an issue. A further advantage over the use of GL accounts would be that the global process would be two-step with the first step being optional. This would allow for a more flexible solution without compromising the integrity of the solution.

It may be noted that it is common business practice for the Acquirers to issue two statements:

a payment file comprising a statement of payment card transactions that are valid and authorised anda "charge-back" file comprising a statement of invalid payment card transactions with values to be credited back to the Acquirers.

For both statements, the SAP standard functionality of EBS upload is used (please see section 3.4.6 "Controlling and Managing Postings" for an explanation of the EBS upload functionality).

3.4.5 Reconciliation by Batch

The reconciliation requirements for the process are:Reconcile the site reported cards collections (as received in the Tenders IDoc) with the pay-out statements of the AcquirersReconcile the pay-out statement of the Acquirers with the credits in the Bank account andReconcile the commission charged by the Acquirers.

As explained earlier in this document, each payment is associated with a batch number ("EPS Terminal Batch Number"/"Acquirer Batch Number") where available and it is these batch numbers that provide the trace for reconciliations.

Further, each payment is associated with a card type and this card type provides the basis for reconciling commissions charged by acquirers.

3.4.6 Controlling and Managing Postings

The postings of the Tenders IDocs are controlled by custom table ZFIC_CARDTYPES. This is an existing table in SAP and will continue to be used as is. The table contains the following fields:

Company CodeCard TypeDepartmentCommission GroupCustomer Account

"Company Code" determines if the entry in the table is valid for that Company Code. Card type is used for the mapping of the "EPS Tender Key" field as received from Retalix. The "Department" field is used for identification of the Card Type (viz. MasterCard, VISA, Maestro, American Express etc.), Commission Group is a two character identification of a grouping of commission rates and the AR account is the identifier of the Acquirers "Customer Account" in SAP.


01/05/2007 07:43:00 PM

PAGE 12 OF 18


The commission rates are maintained in a condition table and during the FI document posting in SAP, the pre-processing commission for the Acquirer - Card Type combination is calculated and posted to expense.

For post-processing commission, no commission group is maintained in the ZFIC_CARDTYPES table. Post-processing commission would be recorded in SAP either when an invoice is presented by the Acquirer or when the Acquirer's statement is uploaded to SAP. The latter occurs due to the SAP functionality of Electronic Bank Statement upload: as noted earlier, the Acquirer's statement of account is also treated as a bank statement. The transaction key (Credit for collections, Debit for Commissions, Debit for other Charges etc. usually represented by a code) in the statement is mapped to a "Transaction Type" in SAP. These "Transaction Types" determine "Posting Rules" that use "Account Keys" to determine the accounts posted to.

In the EBS Upload configuration for the Acquirers' statement, the Commission charges are pointed to the appropriate account in SAP so that the post-processing commissions are captured:

If the post-processing commission is invoiced, the manually posting is credited to the Acquirers' "customer" account (by debit to the Commission Charges account) so that the EBS upload clears that line item. Where no invoice is presented, the EBS upload is configured to directly post the charges. This behaviour of the EBS upload is configured appropriately to suit the regional requirement (as part of Local Deployment).

Thus, both the Acquirer's "customer" account to be posted and the pre-processing Commission due to the Acquirer are controlled by entries in ZFIC_CARDTYPES.

The technical details of how the controls work are out of scope of this document (being a blueprint) and will be covered in the Functional/Technical Specifications associated with this process.

3.4.7 Analysis of Commissions

As explained in the preceding section, Acquirers' charges of commissions are posted either with the Tenders IDoc posting or with the EBS upload or by manual posting.

Standard SAP reports (using transaction code FBL5N for customer account line item listings and FBL3N for GL account line item listings) are used to identify payments by Acquirer by Card Type and commissions due are manually calculated and matched with the commissions posted in SAP to reconcile Commission charges by Acquirers.

3.4.8 Field Mapping for Batch Numbers

To trace the "EPS Terminal Batch Number" and "Acquirer Batch Number" for payments at site realised by payment cards, BP CRD # 283 and # 422 for Retalix have been raised by the GSS Global Design Authority for reporting both these Batch Numbers by Retalix. If either number is not available (see 3.4.2 "Regional Variations"), Retalix will populate the fields with a string of zeroes.

SAP functionality of Substitution will be used for creating the tracing factor appropriate for the region of implementation of this solution.

Currently POS DM populates the line item text field of the postings from Retalix with "ELECTRONIC STATEMENT" to allow identification of the line item as having been received via the Tenders IDoc.

The proposal is to now to map both the "EPS Terminal Batch Number" and "Acquirer Batch Number" into the same field: the line item text field from POS DM would now have "ELECTRONIC STATEMENT TTTTTTTTTT AAAAAAAAAA" where "TTTTTTTTTT" is the "EPS Terminal Batch Number" and "AAAAAAAAAA" is the "Acquirer Batch Number". These values would have fixed lengths i.e., the number of characters would be fixed for both the batch numbers. The string length of "ELECTRONIC STATEMENT" is known to be 20. The "EPS Terminal Batch Number" of length 10 would occupy the next 10 characters and the following 10 characters would be the "Acquirer Batch Number" (the


01/05/2007 07:43:00 PM

PAGE 13 OF 18


length of 10 is arbitrary and the exact length would be determined only after appropriate data is available).

This would be the uniform data available from Retalix Informatica POS DM SAP. Within SAP, local deployment would determine if "EPS Terminal Batch Number" needs to be the tracing factor or "Acquirer Batch Number" needs to be the tracing factor. Depending on the requirement, local deployment would set up substitution rules (that are, by design, Company Code specific) to first copy the "EPS Terminal Batch Number" to the line item "Assignment" field and then copy the "Acquirer Batch Number" to the line item "Reference 1" field. These would be in steps 1 and 2 of the substitution. The third step would strip the line item text of both the batch numbers so that now, the posting looks the same as current. Where the "Acquirer Batch Number" is required to be the tracing factor, this would be the substitution in the "Assignment" field and "EPS Terminal Batch Number" would be written to the "Reference 1" field.

Thus both the tracing factors would be available in the posted line items for further analysis and only the EBS upload clearing criterion would be in the "Assignment" field.

Where these "Batch" numbers are not available, indicated by strings of zeroes reported by Retalix, the date of transactions would be the only criterion and the date would therefore be populated in the "Assignment" field for clearing by EBS upload and where even the date is an inconsistent reference (due to a lag between the date of Bank credit and value date of the credit by Acquirer), the Site and amount would become the only criteria for clearing and therefore, the Site number would be populated in the "Assignment" field.

See also 9.1.2 EPS Tender Key for extended use of this method for payment card type.


01/05/2007 07:43:00 PM

PAGE 14 OF 18


4. Business ControlsBusiness Risk Means of achieving control objective

Acquirers and Banks use inconsistent referencing with neither the "EPS Terminal Batch Number" nor the "Acquirer Batch Number" nor a combination providing the trace.

Statements from Acquirers and Banks may need to be manually modified or an algorithm for transformation by Informatica needs to be set up locally.

Acquirers' and Banks' electronic statements may not be compatible with the formats used in EBS upload to SAP.

Retalix cannot provide data by business day with EPS and Acquirer Batch references.

The Change Request created for Retalix has been analysed and the Functional Specifications have been approved for the data to be provided.

5. Business ScenariosScenario ID

Scenario Name Scenario short description

Cash and Banking Cards Reconciliation

6. Timing and Frequency

6.1 TimingThe Cards Reconciliation Process will be triggered by the daily data feed from Retalix to SAP. Account open item clearing jobs for the tenders interface are created for a daily background run. These daily jobs clear both the site account for collections and the Payment Cards Receivables customer accounts.The process of EBS upload is also daily or the same frequency as receipt of the electronic statements from the Bank and/or Acquirer.

6.2 FrequencyDaily

6.3 Scheduling RequirementsAccount Open Item Clearing created as background jobs run daily - Programs SAPF124 or ZFIC_SAPF124 could be used. ZFIC_SAPF124 allows greater flexibility in selection of clearing criteria than SAPF124. Please see FNS10320 included in the appendix.


01/05/2007 07:43:00 PM

PAGE 15 OF 18


7. Inputs and Outputs7.1 Input details

Input name Input description Source

Tenders IDoc Payment Card collections as reported by site Retalix (via Informatica/ POS DM)

Acquirer Statements

Electronic statement issued by Acquirer for Payments and Charge-backs

Acquirer

Bank Statement

Electronic statement issued by bank for credit payments by Acquirer

Bank

7.2 Output details

Output name

Output description Destination

N/A N/A N/A

8. Reporting RequirementsReport name Report description Type/Origin

N/A N/A N/A

All reporting requirements are met by standard SAP FI Line Item listings.


01/05/2007 07:43:00 PM

PAGE 16 OF 18


9. Process requirements

9.1 Retalix9.1.1 EPS Terminal Batch Number and Acquirer Batch Number

Both these batch numbers will be part of a new record type from Retalix provided in the reconciled Daily Export files:

CRD 283 and 422: Mapping of Batch Numbers to "reconciled" Daily Export files

9.1.2 EPS Tender Key

This is a key assigned by the EPS and used by Retalix to identify the payment card type in the tenders file. The EPS Tender Key can be different for the same card in different countries. This will also form a part of the daily transmission sent from Retalix to Informatica and onward to POS DM. At POS DM, this field will also be mapped to the SAP line item text field and substitution will be used to copy the card type to the "Reference 2" field of the SAP line item.

The route of populating the line item text field at POS DM and then substitution in SAP is proposed to minimise effort on middleware modifications so that no localisations are built into the middleware.

9.2 SAPLocal Customisation of EBS, FI Substitution Rules (for mapping "Card Type", "EPS Terminal Batch Number" and "Acquirer Batch Number" from the line item text to "Reference 2", "Reference 1" and "Assignment" fields of the line item), maintenance of table ZFIC_CARDTYPES and condition records for pre-processing commissions.

9.3 Informatica/POS DMInformatica: Mapping "Card Type", "EPS Terminal Batch Number" and "Acquirer Batch

Number" from Retalix Daily export files to POS DM fields.POS DM: Mapping "Card Type", "EPS Terminal Batch Number" and "Acquirer Batch

Number" to SAP Line Item Text field of the Tenders IDoc.

9.4 Gaps, ABAP development requirements

None.

9.5 Change ImpactNone.

10. Country specific requirements (not covered by harmonised template solution)Country-specific Electronic Bank Statement formats require the use of country-specific configuration for EBS upload.Country-specific substitution rules are required for population of tracing factors ("EPS Terminal Batch Number"/"Acquirer Batch Number").


01/05/2007 07:43:00 PM

PAGE 17 OF 18


11. Appendix: Related Document - Payment Card Batch Processing

Copies of BP CRDs 283 and 422 and the related functional specifications cannot be provided in this document due to their current status - CRD 283 has been tested and delivered and CRD 422 is in process. The GSS team would have to be contacted for the current status/versions of the documents.

As a result of SCR0484 and SCR0507, FNS10320 has been created for added flexibility in clearing open items. Please refer to Solution Manager for the current version of this document.


01/05/2007 07:43:00 PM

PAGE 18 OF 18

bbd10002 credit card process v01

Documents

payment agency

payment cardsbank

eps terminal batch number

pos payment period

business scenarios156

business controls155

business background42

business accounts