BBD10002 Credit Card Process v01

Business Blueprint Document BBD10002 Cards Reconciliation
BP Accelerator DART
1
BBD10002 Cards Reconciliation
Document version control:
LAST SAVED:
01/05/2007
12:43:00 PM
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
PRINTED:
File /var/www/apps/conversion/tmp/scratch_4/286753098.doc
PAGE 1 OF 18
Business Blueprint Document 286753098.doc

BP Accelerator DART
Table of contents
1.
2.
Glossary................................................................................................................................... 3
Management Summary............................................................................................................ 4
2.1
Business background........................................................................................................ 4
2.2
Payment Card Processing Overview................................................................................4
2.3
Scope of this document.................................................................................................... 5
3. Process Description................................................................................................................. 7
3.1
Requirements................................................................................................................... 7
3.2
Assumptions..................................................................................................................... 7
3.3
Cards Settlement Process................................................................................................8
3.4
Cards Reconciliation Process........................................................................................... 9
3.4.1
Data Flow.................................................................................................................. 9
3.4.2
Regional Variations.................................................................................................... 9
3.4.3
Tracing Factor.......................................................................................................... 10
3.4.4
Process Harmonisation............................................................................................11
3.4.5
Reconciliation by Batch........................................................................................... 12
3.4.6
Controlling and Managing Postings.........................................................................12
3.4.7
Analysis of Commissions......................................................................................... 13
3.4.8
Field Mapping for Batch Numbers...........................................................................13
4. Business Controls.................................................................................................................. 15
5. Business Scenarios............................................................................................................... 15
6. Timing and Frequency........................................................................................................... 15
6.1
Timing............................................................................................................................. 15
6.2
Frequency....................................................................................................................... 15
6.3
Scheduling Requirements............................................................................................... 15
7. Inputs and Outputs................................................................................................................. 16
7.1
Input details.................................................................................................................... 16
7.2
Output details.................................................................................................................. 16
8. Reporting Requirements........................................................................................................ 16
9. Process requirements............................................................................................................ 17
9.1
Retalix............................................................................................................................. 17
9.1.1
EPS Terminal Batch Number and Acquirer Batch Number......................................17
9.1.2
EPS Tender Key...................................................................................................... 17
9.2
SAP................................................................................................................................. 17
9.3
Informatica/POS DM....................................................................................................... 17
9.4
Gaps, ABAP development requirements.........................................................................17
9.5
Change Impact............................................................................................................... 17
10. Country specific requirements (not covered by harmonised template solution).....................17
11. Appendix: Related Document - Payment Card Batch Processing..........................................18
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 2 OF 18

BP Accelerator DART
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 BP
BOS - 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 BW
Closure Message - An electronic communication from a sender system to trigger a
reciprocal action by the receiver system
DGI - DART GSS Integration
EBS - Electronic Bank Statement
EPS - 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
format
IFSF - 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 POS
POP - 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 Informatica
Reconciliation Account - A GL account, to which transactions in the subsidiary ledgers
(such as in the customer, vendor or assets areas) are updated automatically
Retalix - 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/3
SAP BW - The SAP Business Information Warehouse
SAP R/3 - The SAP R/3 Retail system
Settlement - Transaction at the POS to trigger a payment by Acquirer
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 3 OF 18

BP Accelerator DART
2.
2.1
Management Summary
Business background
Among 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 is
Retalix creates daily files and these files are transported by infrastructure applications (XcelleNet
and IntraNect) to Informatica
Informatica re-maps file data and exports the data to POS DM
POS DM validates data from Informatica, generates and exports IDocs to SAP
SAP 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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 4 OF 18

BP Accelerator DART
"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 document

This 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 and
reconciliation 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.
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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 5 OF 18

BP Accelerator DART
Here is an illustration of a sales document posting:
Site Customer Account Dr
To Sales
To Local VAT
Lottery purchases Dr
To Lottery purchase accrual
E-PAY purchases Dr
To E-PAY accrual
100.00
85.85
14.15
1.00
1.00
1.50
102.50
1.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
Cash Control account Dr
Payment Card Receivables Dr
Purchases Food Services Dr
Till Shorts Dr
Payment Card Commissions Dr
Fuel variance Dr
To Sales Fuels
To Indebtedness
To Site Customer Account
41.00
0.50
55.50
2.19
0.08
0.83
0.07
100.17
<< Cash
<< Cheques
<< Payment Cards
<< P&L Account

0.07
0.10
100.00
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
To Payment Card Receivables
55.50
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
To Bank Clearing Account
55.50
55.50
55.50
55.50
With this, the realisations by the site of card collections are confirmed as banked.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 6 OF 18

BP Accelerator DART
3.
3.1
Process Description
Requirements
Req.
No.
3.2
LAST SAVED:
01/05/2007
12:43:00 PM
Description
Category
94
Prepay and
Settlement
Reconciliation
Business
process
226
Payment card
reconciliation
process
Business
process
GSS
Impact
DART
Impact
Remarks
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)
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
PRINTED:
PAGE 7 OF 18

BP Accelerator DART
3.3
Cards Settlement Process

This 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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 8 OF 18

BP Accelerator DART
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":
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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 9 OF 18

BP Accelerator DART
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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 10 OF 18

BP Accelerator DART
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
LAST SAVED:
01/05/2007
12:43:00 PM
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
PRINTED:
PAGE 11 OF 18

BP Accelerator DART
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 twostep 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 and
a "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 Acquirers
Reconcile the pay-out statement of the Acquirers with the credits in the Bank account and
Reconcile 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 Code
Card Type
Department
Commission Group
Customer 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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 12 OF 18

BP Accelerator DART
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
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 13 OF 18

BP Accelerator DART
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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 14 OF 18

BP Accelerator DART
4.
Business Controls
Business 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.
5.
Business Scenarios
Scenario
ID
6.
6.1
The Change Request created for Retalix has

been analysed and the Functional
Specifications have been approved for the
data to be provided.
Scenario Name
Scenario short description
Cash and Banking
Cards Reconciliation
Timing and Frequency

Timing
The 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
Frequency
Daily
6.3
Scheduling Requirements
Account 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.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 15 OF 18

BP Accelerator DART
7.
7.1
7.2
8.
Inputs and Outputs

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
Output
name
Output description
Destination
N/A
N/A
N/A
Output details
Reporting Requirements
Report name
Report description
Type/Origin
N/A
N/A
N/A
All reporting requirements are met by standard SAP FI Line Item listings.
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 16 OF 18

BP Accelerator DART
9.
9.1
9.1.1
9.1.2
9.2
Process requirements
Retalix
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
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.
SAP
Local 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 DM
Informatica: 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 Impact
None.
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").
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 17 OF 18

BP Accelerator DART
11.
Appendix: Related Document - Payment Card Batch Processing

PaymentCardBatchPr
ocessing_v0 9b.doc
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.
FNS10320_Open_Ite
m_Clearing
LAST SAVED:
01/05/2007
12:43:00 PM
PRINTED:
PAGE 18 OF 18

BBD10002 Credit Card Process v01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BBD10002 Credit Card Process v01

Uploaded by

Copyright:

Available Formats

Business Blueprint Document BBD10002 Cards Reconciliation

Document version control:

Short description of modification

Included comments from Terry

Revised with additional inputs

Added reference to FNS10320

Business Blueprint Document 286753098.doc

Business Blueprint Document 286753098.doc

Business Blueprint Document 286753098.doc

Payment Card Processing Overview

Business Blueprint Document 286753098.doc

Scope of this document

Business Blueprint Document 286753098.doc

<< P&L Account

Business Blueprint Document 286753098.doc

This process in SAP is

Req. 94 ("Prepay and Settlement Reconciliation"): The Fuel

Req. 226 ("Payment card reconciliation process"): It is assumed

Business Blueprint Document 286753098.doc

Cards Settlement Process

Business Blueprint Document 286753098.doc

Cards Reconciliation Process

Business Blueprint Document 286753098.doc

Business Blueprint Document 286753098.doc

Business Blueprint Document 286753098.doc

The reconciliation requirements for the process are:

Controlling and Managing Postings

Business Blueprint Document 286753098.doc

Field Mapping for Batch Numbers

Business Blueprint Document 286753098.doc

Business Blueprint Document 286753098.doc

Means of achieving control objective

Acquirers and Banks use inconsistent

Statements from Acquirers and Banks may

Acquirers' and Banks' electronic

The Change Request created for Retalix has

Scenario short description

Cash and Banking

Timing and Frequency

Business Blueprint Document 286753098.doc

Inputs and Outputs

Payment Card collections as reported by site

Retalix (via Informatica/

Electronic statement issued by Acquirer for

Electronic statement issued by bank for

Business Blueprint Document 286753098.doc

Gaps, ABAP development requirements

Country specific requirements (not covered by harmonised template

Business Blueprint Document 286753098.doc

Appendix: Related Document - Payment Card Batch Processing

You might also like