Documents - Tips - Configrationale FSCM Ihc

Project
AP326EVO EVO
Configuration rationale
TCM area
Version: 2.4
Configuration rationale 358155987.doc 2.4
16 June 2017
Document Control
Document History
Location: https://teamrooms-vista.vodafone.com/eRoom/Global43/EVOTeamRoom/0_4c238
Author Date Version Comment
Document Owner 18/07/2007
Nuno Ferreira V1 0 First version
Related
Owning Documents
SAP ArchTeam
Team 24/07/2007 V1 0 Author and comments from SAP Arch Team
Review
Title Comment / Link
FI
Nuno Ferreira 26/07/2007 V1 1 Nuno
ChangesFerreira
based on review from SAP Arch Team
cbmSAPArch_AP326_Configuration_Rationa https://teamrooms-
le_V0.1.doc
Soobrayen vista.vodafone.com/eRoom/Global43/EVOTeamRoom/0_3635a
03/08/2007 V1 1 Review
Adacen
Nuno Ferreira 13/08/2007 V1 2 Changes based on review from SAP
Tanveer Yaqoob 17/08/2007 V1 2 Review
Nuno Ferreira 20/08/2007 V1 3 Changes based on review from Tanveer
Document Review & Signoff
Robert Hawker 17/08/2007 V1 2 Review
Name Position Action Approved
Nuno Ferreira 20/08/2007 V1 4 Changes based on review from Tanveer
Thomas Light Team Lead S
Matt Parlour 15/08/2007 V1 2 Review
Adacen SAP QA
Nuno Ferreira
Soobrayen 20/08/2007 V1 4 Changes based on review from Matt Parlour
Andrea Aleotti
Tom Light SAP Arch
15/08/2007 FR
V1 2 Approved
Review 26/07/07
Nuno Ferreira 20/08/2007 V1 4 Changes based on review from Tom Light
S
Review from Belinda / June Chandler / Steve Pierce /
Belinda 22/08/2007 V1 4 =
Thomas Light / Matt Parlour
Nuno Ferreira 31/08/2007 V1 5 Changes based on review
Soobrayen / Jos Last reviews received from June and inputs from
Fernandes / Matt 31/08/2007 V1 6 meeting with Soobrayen / Jos Fernandes / Matt
Parlour / June Parlour )
Nuno Ferreira 31/08/2007 V1 6 Changes based on review
Nuno Ferreira 30/10/2007 V1.6 Exchange rate triangulation and minor changes
Nuno Ferreira 30/12/2007 V1 7 Changes based on presentation of IHC
Nuno Ferreira 07/01/2008 V1 8 Changes based on Review from Thomas
Nuno Ferreira 13/02/2008 V1 9 Update with IHC pieces and ER config. paper
Nuno Ferreira 20/02/2008 V2 0 Changes based on Review from Thomas
Nuno Ferreira 22/02/2008 V2 1 Changes based on points raised (R2R alignment)
Nuno Ferreira 27/02/2008 V2 2 Changes based on points raised by Soobi
Nuno Ferreira 11/04/2008 V2 3 Changes based on review by Soobi
Marta Gonzalez 25/03/2009 V2.4 Include with DE configuration
Signed Approval Required, QA= Quality Assurance Review Required, FR = Formal Review Required, IR = Informal
Review, I = For Information.
Modified: 6/16/2017 5:40 PM Page 2 of Last modified by: Romo Navarrete, Pablo
184
Table of Contents:
1. Introduction........................................................................................................................................................ 8
1.1 Purpose.................................................................................................................................................... 8
1.2 Overview................................................................................................................................................... 8
1.2.1 Target audience........................................................................................................................................ 8
1.2.2 Document lifecycle.................................................................................................................................... 8
2. Configuration rationale details......................................................................................................................... 9
3. Principles guiding design and configuration.................................................................................................. 9
4. SAP In House Cash.......................................................................................................................................... 11
4.1 Key decisions regarding In House Cash................................................................................................. 11
4.2 Benefits of In House cash....................................................................................................................... 12
4.3 Internal Payments................................................................................................................................... 13
4.4 Periodic Processing JOB CHAIN and Closing cockpit.........................................................................13
4.4.1 End of day processing............................................................................................................................ 16
4.4.2 Month end processing............................................................................................................................. 17
4.5 Organizational Units................................................................................................................................ 20
4.5.1 Company Codes..................................................................................................................................... 20
4.6 Integration of Systems............................................................................................................................ 20
4.6.1 ALE - Application Link Enabling - Customizing in the SAP In-House Cash System................................20
4.6.1.1 Define Logical System..................................................................................................................... 21
4.6.1.2 Assign Logical System to Client....................................................................................................... 22
4.6.1.3 Define Target Systems for RFC Calls.............................................................................................. 23
4.6.1.4 Create Transactional RFC Port........................................................................................................ 24
4.6.1.5 Process Partner Profiles for Business Partners Manually................................................................25
4.6.1.6 Process Partner Profiles Manually for Logical Systems...................................................................26
4.6.1.7 Define In-House Cash Centre as Bank............................................................................................ 28
4.6.1.8 Function module for IBAN................................................................................................................ 29
4.6.1.9 GL Variant maintenance.................................................................................................................. 30
4.6.2 ALE - Application Link Enabling - Customizing in the Subsidiary Company System...............................31
4.6.2.1 Define Logical System..................................................................................................................... 31
4.6.2.2 Assign Logical System to Client....................................................................................................... 32
4.6.2.3 Configure Systems in Network, Define Target Systems for RFC Calls............................................34
4.6.2.4 Process Partner Profiles Manually................................................................................................... 35
4.6.2.5 Process Partner Profiles Manually for Logical Systems...................................................................36
4.6.3 Business Customizing............................................................................................................................. 37
4.6.3.1 Customizing Financial Accounting for Subsidiary Companies.........................................................37
4.6.3.2 Set up payment methods per country for payment transactions......................................................37
4.7 Set up Payment methods per Company code for payment transactions................................................41
4.8 Set up Bank determination for payment transactions..............................................................................44
4.8.1.1 Define House Banks intercompany settlements...........................................................................47
4.8.1.2 Bank determination.......................................................................................................................... 49
4.8.2 Customizing the In-House Cash Centre.................................................................................................. 51
4.8.2.1 Define In-House Cash Centre as Bank Area....................................................................................51
4.8.2.1.1 Set Up Number Ranges for Log................................................................................................... 52
4.8.2.1.2 Set Up Number Ranges for IHC Payment Orders........................................................................53
4.8.2.1.3 Define how in House cash data is transferred to Financial accounting........................................55
4.8.2.1.4 Activate SAP Component SAP In-House Cash............................................................................56
4.8.2.2 Master Data..................................................................................................................................... 57
4.8.2.2.1 Process Products......................................................................................................................... 57
4.8.2.2.1.1 Conditions............................................................................................................................. 58
4.8.2.3 Maintain Formats for Bank Statements............................................................................................ 59
184
4.8.2.4 Account Management...................................................................................................................... 60

4.8.2.4.1 Maintain Accounts for Payment Transactions..............................................................................60
4.8.2.4.2 Define Account Determination..................................................................................................... 61
4.8.2.5 Periodic Tasks (General Ledger Transfer).......................................................................................61
4.8.2.5.1 Maintain GL Variants.................................................................................................................... 62
4.8.2.5.2 Transfer Postings Payables/Receivables.....................................................................................63
4.8.2.6 Maintain General Ledger Transaction for General Ledger Transfer.................................................64
4.8.2.7 Assign Payment Transaction Type to General Ledger Transaction.................................................66
4.8.2.8 Maintain General Ledger Group...................................................................................................... 68
4.8.2.9 Define GL Account Assignment: Current Accounts..........................................................................69
4.9 Configuring Component-Specific Master Data........................................................................................ 71
4.9.1 Create Business Partner Roles in SAP In-House Cash..........................................................................72
4.9.2 Master Data: account creation in IHC..................................................................................................... 72
4.9.3 Create Customer / Vendor account - Intercompany................................................................................73
4.9.4 Central bank reporting............................................................................................................................ 76
4.10 Ongoing Setting Process steps........................................................................................................ 77
4.10.1 Current setting for updating the posting date for payment transaction and closing.............................77
4.10.1.1 Update Posting Date for Payment Transactions..............................................................................77
4.10.1.2 Update Posting Date for closing manually.......................................................................................78
4.11 Reassignment of short term IHC call account positions to long term call accounts.............................79
4.11.1 Define In-House Cash Centre as Bank Area.......................................................................................79
4.11.2 Cash concentration Short term to long term call account - Transition and End game.....................81
4.11.3 Cash Concentration............................................................................................................................. 82
4.11.4 Reassignment of short term IHC call account other currencies to functional currency short term call
accounts positions................................................................................................................................................ 85
4.11.5 Cash concentration Short term different currencies to functional currency call accounts - Transition
and End game...................................................................................................................................................... 85
4.12 Interest................................................................................................................................................ 89
4.13 Non-invoice driven VOCH call account changes.................................................................................94
4.13.1 Cash sweeps....................................................................................................................................... 94
4.13.2 Bank statement configuration OpCo.................................................................................................96
4.13.3 Configure the Electronic Bank Statement............................................................................................96
4.13.4 Create account symbol........................................................................................................................ 97
4.13.5 Assign accounts to account symbol.................................................................................................... 98
4.13.6 Create Keys for posting rules.............................................................................................................. 99
4.13.7 Define posting rules........................................................................................................................... 101
4.13.8 Define Search String for Electronic Bank statement..........................................................................102
4.13.9 Create transaction type..................................................................................................................... 103
4.13.10 Assign external transaction type to posting rules..............................................................................104
4.13.11 Assign bank accounts to transaction type.........................................................................................106
4.13.12 Bank statement configuration IHC.................................................................................................. 107
4.13.13 Central cash receipt / Incoming bank statements IHC....................................................................108
4.13.13.1 Set Up Connection to IHC in FI...................................................................................................... 108
4.13.13.2 IHC Account Determination from External Bank Account..............................................................109
4.13.13.3 Set Up Account Determination for Incoming Payment....................................................................111
4.13.13.4 Define Transaction Types for Incoming Payment...........................................................................112
4.13.13.5 Conclusion:.................................................................................................................................... 113
4.14 Treasury (eTC) transactions with loan settlement..............................................................................114
4.14.1 Payment Items................................................................................................................................... 114
5. Finance FI-BL.............................................................................................................................................. 116
5.1 Set Country-specific checks.................................................................................................................. 119
5.2 Define House Banks............................................................................................................................. 124
5.3 Bank Chains......................................................................................................................................... 126
5.3.1 Define Scenario.................................................................................................................................... 126
184
5.3.2 Activate Bank Chain.......................................................................................................................... 127

5.3.3 Create General Bank Chain............................................................................................................. 129
5.4 Define Factory Calendar per Currency................................................................................................. 130
5.5 Define Tolerance Groups for users....................................................................................................... 132
5.6 Configure the Electronic Bank Statement.............................................................................................135
5.6.1 Create account symbol......................................................................................................................... 136
5.6.2 Assign accounts to account symbol...................................................................................................... 138
5.6.3 Create Keys for posting rules................................................................................................................ 140
5.6.4 Define posting rules.............................................................................................................................. 142
5.6.5 Create transaction type......................................................................................................................... 144
5.6.6 Assign external transaction type to posting rules..................................................................................146
5.6.7 Assign bank accounts to transaction type.............................................................................................148
5.7 Define Accounts for Exchange Rate Differences..................................................................................155
6. Finance TR CM............................................................................................................................................ 156
6.1 Define Planning Levels......................................................................................................................... 157
6.2 Define Source Symbols.................................................................................................................... 162
6.3 Define Planning Groups........................................................................................................................ 163
6.4 Define Cash Management Account Name............................................................................................ 165
6.5 Define Groupings and Maintain Headers..............................................................................................166
6.6 Maintain Structure................................................................................................................................. 167
6.7 Define Planning Types.......................................................................................................................... 170
6.8 Define planning levels for Logistics....................................................................................................... 172
6.9 Maintain Blocked Levels....................................................................................................................... 173
6.10 Define Number Ranges..................................................................................................................... 174
7. Exchange Rates Table................................................................................................................................... 177
7.1 Types.................................................................................................................................................... 177
7.2 Application............................................................................................................................................ 180
7.3 Rates.................................................................................................................................................... 180
7.4 Exchange rate triangulation.................................................................................................................. 181
7.5 FX rounding rules.................................................................................................................................. 183
8. Appendix A FIMA configuration rational alignment.................................................................................183
8.1.1 Treatment of exchange rate differences................................................................................................183
8.1.2 Accounts for Exchange rate differences...............................................................................................184
8.1.3 Account for bank charges..................................................................................................................... 185
8.1.4 Bank clearing accounts and bank accounts.......................................................................................... 185
8.1.5 Potential extra accounts that will be requested by TCM.......................................................................185
9. Appendix B Steps involved in new OpCo setup in IHC and Test script.........................................................186
EDI
184
1. Introduction
1.1 Purpose
This deliverable documents the guidelines and rationales for the packaged software configuration to meet the specific
business and IT requirements defining the framework for the configuration activities of the application SW into EVO.
The focus is of this document is on the SAP configuration (SAP parameters) and specifically on the key parameters.
The software development of SAP and the other tools (e.g. Informatica) will be addressed into the Application
development standards during the Design Phase.
These specifications represent the key component of the design of the standard SW and must be followed by the
release implementation teams.
1.2 Overview
This document is part of the configuration rationale composite deliverable. The composite deliverable is articulated in
the following documents:
o Configuration rationale cross: owned by the Sap Architecture, describes the general rules and guidelines
related to the configuration rationale. It also describes the cross application parameters (e.g. countries,
languages) and the enterprise structure
o Configuration rationale FIN area: owned by the Finance team, describes the configuration rationale for the
Finance related application components (e.g. ECC-FI, ECC-CO, ECC-EC, etc.)
o Configuration rationale SCM area: owned by the SCM team, describes the configuration rationale for the
SCM related application components (e.g. ECC-SD, ECC-MM, SCM-APO, SRM-EBP)
o Configuration rationale HR area: owned by the HR team, describes the configuration rationale for the HR
related application components (e.g. ECC-PA, eRecruiting, eLearning)
To enable an easier navigation across the content, the configuration shall be articulated following the application
breakdown of SAP and the IMG flow.
1.2.1 Target audience

The target audience of the document are:
o DDP team/release management team: they have to configure the solution following the configuration
rationale
o Other functional teams (FIN, SCM, HR) responsible for the detailed configuration of the system.
o CoEx will use this document to maintain a consistent design of the solution during the implementation
1.2.2 Document lifecycle

This document is planned to be completed in the design stage. It will be maintained during the release management
by the responsible organization identified by the DDP team.
184
2. Configuration rationale details

This chapter contains the configuration rationale specifications, articulated by application components/module.
For each key parameter the following information are reported:

o SAP specifications: it contain a brief explanation of:
o the standard meaning of the object
o the role of the object inside the SAP solution
o the SAP guidelines (when available) in configuring the parameter
o SAP technical specification: contain the reference on how reach the parameter (SAP transaction),
technical name of the parameter (field/table), field features (e.g. alpha 10 Char) and dependency inside
SAP (e.g. client dependent, company code dependent)
o When appropriate (complex to manage) the configuration steps required to configure the object
o EVO specifications: it contains:
o The planned usage of the parameter in EVO
o The coding rule to be applied to the parameter
o When meaningful (at core level and stable), the configuration values considered for the configurations
(e.g. for the vendor master account group)
o The planned management of the parameter in EVO in term of:
Area: Cross, FIN, SCM, HR
Ownership: Global, OpCo
Expected activity: Standard (mainly no config. planned), Core (Template/core set of values),
Release (mainly implemented during the release implementation), OnGoing (requires
activities after the release)
Change mgm: CTS (correction and Transport), Production (activity performed directly in
production (applicable only to some data as posting periods, etc.)
Detailed specification about the configuration of the specific parameter (e.g. attributes of the parameter) shall be
included in the more detailed configuration design.
Intercompany configuration requirements within this document should be referenced back to the FI-Intercompany
Configuration Rationale. Where there is a conflict in the requirements or configuration details relating to
Intercompany, the FI-Intercompany Configuration Rationale takes precedence over this document.
3. Principles guiding design and configuration

The purpose of EVO is to deliver standard common processes, a common language for products and terminology,
independent of OpCos or geography, to identify the best commercial solutions and to apply a single source of the
truth for information across all of our functions.
From these project goals, the TCM workstream identified the micro-principles to drive the design:
184
Improve control Consolidate presence

- Consolidate banking relationships
Deliver solution which eliminates Introduce latest banking solutions
need to manually complete Excel
intra-group settlement spreadsheets, EVO TCM to enable real time consolidated
reporting information
manual consolidations and
reconciliations foundation Develop bank account structure so
non-forecast cash is automatically
Improve audit trail visibility through
banking system consolidation principles transferred with Group Treasury
Eliminate current manual interfaces

used for cash positioning
Reduce cost structure

Introduce Single European Payments Area (SEPA) for cross border payments
Introduce one-touch payments process (eliminating duplication)
Minimise correspondent bank charges by working with Deutsche Bank which has shared global
footprint
Centralise volumes with Deutsche Bank to obtain best pricing
Lower Vodafones switching costs through standardisation of payment file formats & processes
Increased process automation, key is fully automated intercompany settlements
184
4. SAP In House Cash

The SAP In-House Cash (IHC) component is a solution that can be used to manage the settlement of both
intercompany and external commitments. Through the use of internal bank accounts it eliminates the need for cash
transfers between recourse VF entities. IHC can also be configured so that it channels external commitments from a
number of VF entities through one bank account, adjusting internal bank accounts appropriately.
4.1 Key decisions regarding In House Cash
The Evo design is to use IHC for recourse intercompany settlements, but not for external settlements. The decision to
not use IHC for external settlements was taken for following reasons:
- Single European Payments Initiative (SEPA) initiative will mean that all Euro payments made to other EU
participating states will be charged at a rate close to local Automated Clearing House (ACH) rates (i.e.
domestic payments)
- To benefit from local ACH pricing on cross boarder payments, IHC would be configured so that VOCH would
make payments on behalf of other VF entities (with a VOCH account in each country). However, in order to do
this there would need to be a significant local ACH data collection exercise (currently OpCos would only hold
international banking details of cross boarder suppliers)
- Using IHC on behalf of model there would be some know your customer legal complications in some
countries
- Lack of visibility of a VF entities settlements and reconciling items
- Solution would require more bank accounts (given OpCos will need an overlay account regardless of solution
for EVO settlements)
IHC is part of the EVO design for intercompany settlements. In the below illustration, steps 1-3 are the same as the
steps taken for an external payment run. The IHC centre acts as a bank, changing the payee and beneficiary internal
bank accounts upon receipt of payment instruction. The IHC centre then sends a bank statement to both internal
companies. As with the receipt of external bank statements, the statement drives the clearing of related items in the
OpCos GL. The internal bank account adjustment itself drives the update of the VOCH to OpCo call (loan) account.
184
4.2 Benefits of In House cash
Implementation of the IHC component for recourse intercompany settlements will:
Eliminate need to manually populate Excel spreadsheets

Eliminate need to manually aggregate Excel spreadsheets
Eliminate risk of re-keying errors
Significantly reduce resourcing requirements
Improve flexibility of process (currently monthly process, proposal is to make daily)
Eliminate manual allocation/ reconciliation (and risk of this process being duplicated for same
transactions in different VF entities.
The IHC component will sit within the VOCH and replace the existing Intragroup settlement process. Therefore, the
internal short term loans will move from being held with VDG to the VOCH. These short term positions will be cleared
down to the existing long term positions held with VG/VFL. Until all VF entities are on EVO SAP we will need to
maintain the ability to settle through existing Intragroup settlement process a consideration which is reflected in
following documentation.
Intercompany transactions with VF defined non-recourse entities will continue to be settled cash and are therefore out
of scope for above detailed IHC process.
184
4.3 Internal Payments
This is the description off all the process of internal payments. The responsibility of TCM is only after step 2.
Task Department Description

Execute payment run - P2P
post automatic payment Run and post automatic payments for all participating
program (F110) subsidiaries using payment method Z Intercompany
payments;
Clear intercompany vendor items
Generate IDOC = PAYEXT
Current account Central Treasury Postings in the respective bank accounts are generated via
postings Dep. the IDOC (PAYEXT). Monitor IDOC creation.
Bank statements Central Treasury Generate internal bank statements (IDOC=FINSTA) and
Dep. delivered to the respective subsidiaries
Posting of the internal Central Treasury
bank statements Dep. Clears clearing accts in the paying subsidiary
Clears customer accounts in receiving subsidiary.
Adjust VOCH-OpCo call accounts
IHC payment reports Central Treasury Check accounts, posting and balances
Dep.
4.4 Periodic Processing JOB CHAIN and Closing cockpit
The decision of having closing cockpit functionality is being still decided (assessment made day 27/02/08). To have a
job chain in place and if the decision of having closing cockpit is still pending in R1 (IHC implementation deadline) the
job chain must be created as detailed below.
If closing cockpit is in place the configuration to support the job chain steps will be described in this document (in a
appendix)
To comply with the required end day processing the configuration to support the job chin processing is described
below. We will create 2 job chains. One for the basic end of the day processing and the other for month end:
The job chain should be only triggered end of the day. And all the external IHC processes, dependent on external
parties, interfaces or manual procedures - DB bank statement import (funding/depositing sweeps), Cross currency
loan clear down and eTC treasury data import should be schedule before the end of the day IHC job chain. Before
running the job chains is needed that the following steps are completed:
DB bank statement import (funding/depositing sweeps) Batch job uploading bank statements from D.B. -
cbmFIN_TCM_AP357 Interface Design_I01 - FI-TCM-IF-02
Cross currency loan cleardown manual or automatic detailed in document Reassignment of short term
IHC call account positions to long term call accounts V0 4 Since the process could be manual in the interim
solution the manual process should be done before the Job chain being triggered
184
Cash concentration (reassignment of short term balances to LT balances) Detailed in document

Reassignment of short term IHC call account positions to long term call accounts V0 4 and included in Job
chain
eTC treasury data import detailed in document FI-TCM-IF-6 - Interface to SAP from eTC
Posting cut-off for payment transactions described in this document and included in Job chain
Interest calculation and capitalisation - Account balancing : Calculates and posts interest and charges for
accounts that are due - and included in Job chain
Send out IHC statements to OpCos - Generate bank statements: Mass run for transferring the bank
statement data to the relevant interface. Bank statements can be generated periodically or upon request.
included in the Job Chain
All the external steps to IHC are - DB bank statement import (funding/depositing sweeps), Cross currency loan
cleardown and eTC treasury data import. For them to be included in the Job Chain they will need to have a report
to be attached to the job chain. To include those in the processing chain they must be entered when chosen -
Specify the Sequence of Mass Processing.
Activities
1. Choose new entries.
2. Enter the report name and the description.
3. Set the indicator continue, showing if the end of day processing chain continues directly after the start of the
next report ('X') or not (' '). If the indicator is set, it is possible that (in the case of direct continuation) several
reports run at the same time (in parallel) after being called up / scheduled ('X'). If the indicator is not set, the
customer-own report must start the next report in the processing chain. For this, there are two prerequisites:
- The two parameters P_LAUFD and P_LAUFI are mandatory report parameters.
- At the end of processing the report must call up the function module BKK_CHAIN_START_NEXT_STEP,
with which the next report is started as a job.
It is also possible to set a return code using module BKK_CHAIN_DB_SET_RETURNCODE. The constants
G_CON_REPRETURN_OP (no errors), G_CONREPRETURN_WARNING (warnings),
G_CON_REPRETURN_ERROR (single error) and G_CON_REPRETURN_ABORTED (termination) are available
for this. In the case of termination, it is advisable not to start the next step.
Create report to be run at end of the day:
184
For the organization of your mass runs, for example, for end of day processing, you have the option of establishing
end of day processing chains (as alternative to scheduling batch jobs). In this section you define these chains.
Activities
1. Choose the processing sequence.
2. Create the processing sequence. Issue the key and appropriate names for the processing sequence. You can
freely choose the key.
3. Choose individual steps
4. Define the corresponding reports for each processing sequence. You define the order with the sequential number.
For each report enter a variant with which this report is to be called up as a matter of standard.
184
4.4.1 End of day processing
The following reports should be included within the end-of-day processing in this sequence:
Posting cut-off for payment transactions: Once the posting cut-off time is set, all subsequent postings take the
date of the next working day. This means that while account balancing is running, you cannot make any more
postings in the period that is being closed (back-dated postings are still possible). The account balancing
postings themselves are not affected by the cut-off, and therefore still fall within the account balancing period.
Account balancing: Calculates and posts interest and charges for accounts that are due.
Generate bank statements: Mass run for transferring the bank statement data to the relevant interface. Bank
statements can be generated periodically or upon request.
Set Balancing Posting Date - Set next posting date for account balancing: This date should be incremented
on a daily basis, even if no account balancing run takes place. This ensures that the posting date for account
balancing activities is always at the end of the period you want to close.
Balance sheet preparation - Balance sheet preparation (division into payables / receivables) for BCA
accounts. The transfer postings for the FI general ledger are prepared, but no FI documents are posted.
Transfer to general ledger: Independent of the other periodic activities. The interest accrual/deferral run and
G/L transfer would usually be run daily after end-of-day
processing
In terms of configuration this are the reports to support this activities

RFBKPDT2: Set Payment Transaction Posting Date
RFBKCONC: Account Balancing
RFBKBSST: Bank Statement
184
RFBKCLEB: Set Balancing Posting Date (only when Acct Balancing is scheduled)
RFBKGLBSPREP: Balance Sheet Preparation
RFBKGL01: General Ledger Transfer
4.4.2 Month end processing
The following reports should be included within the month end processing in this sequence the difference is the
cash concentration only done monthly:
RFBKPDT2: Set Payment Transaction Posting Date

RFBKCONC: Account Balancing
RFBKKC20: Cash Concentration Generates carry-forwards from accounts that are organised in the cash
concentration hierarchy type.
RFBKBSST: Bank Statement
RFBKCLEB: Set Balancing Posting Date (only when Acct Balancing is scheduled)
RFBKGLBSPREP: Balance Sheet Preparation
RFBKGL01: General Ledger Transfer
Assumption: The job for the end-of-day processing should run each day for the current In-House Cash posting day.
The end of day processing should be done end of business day, after receiving bank statements and updating all the
IHC accounts. Also taking in account the eTC movements that will update via payment items the call accounts. The
end of day or month end process can be selected using the selection criteria in the transaction F9N11
184
Posting Date for Payment Transactions
The posting date of the internal payments in IHC must correspond to the posting date of the payment generated by
the payment program. The posting date of the clearing entry in the receiving subsidiary must also be the same.
Account Balancing
During the account balancing operation all interests and charges defined will be calculated and posted in the
individual current accounts.
Posting Date for Account Balancing
The posting date for all account balancing items must be the last day of the month.
Dispatch of internal Bank Statements

Message type that dispatches and posts the items is FINSTA
The dispatch of bank statements will be executed on a daily basis
The postings that are generated are the following:
o clearing of open items on customer accounts at recipient of internal payment
o clearing of open items on bank clearing accounts at sender of internal payment
184
o postings of payment transactions, charges, interest
The General Ledger Transfer in IHC
IHC = sub ledger
balance sheet preparation this step must be executed before the G/L transfer, even though it does not
make any postings in the system.
G/L transfer
Balance Sheet Preparation

Aggregation and preparation of balances, checks
Even though it does not make any postings in the system, this step must be executed before the G/L transfer
to guarantee correct postings.
Transfer to the final account

Creation of FI documents
1. post transactions between IHC tech. clearing account and respective offsetting account
2. transfer to the final bank account
Transfer of trading partner number
Implemented Notes for In House Cash
SAP Note Title of SAP Note Usage
OSS Note 522747 For general ledger transfer trading During the general ledger transfer in
partner not filled the In-House Cash Center, field
"Trading partner" in role account
holder of the business partner should
be transferred to field "Trading
partner" in the customer/vendor
account.
OSS Note 532499 Activating several SAP R/3 Enterprise Application menu update for In-House
extensions Cash
OSS note 376180 Change IHC bank BNKAIN if the In-House bank is created
incorrectly using FI01 and not FIHC:
Central SAP Notes for SAP In-House
Cash Changing the characteristics
of the In-House bank in case they are
created in transaction FI01 and not
in FIHC (note that Bank ID created
also as to be used in vendor data of
184
all trading partner
4.5 Organizational Units
4.5.1 Company Codes
All the company codes that are to participate in the IHC must be created in the SAP system during the release
phases. The company codes are assigned then to an internal house bank In house cash centre and the accounting.
For configuration purposes and more detail - cbmFI_AP326_Configuration_Rationale_R2R
4.6 Integration of Systems
This section contains information about integrating system landscape.

This includes, for example:
1 Defining and configuring logical systems

2 Generating and editing partner profiles
3 Completing the configuration settings and carrying out additional activities required
SSC
VOCH
In House Cash Centre
Integrate In
House cash
and Company
iDoc PEXR2002 iDoc FINSTA01 iDoc PEXR2002 iDoc FINSTA01 codes for them
Payment file Bank Statement Payment file Bank Statement to
communicate
via iDoc
OpCo A OpCo A
Same system landscape for all entities
4.6.1 ALE - Application Link Enabling - Customizing in the SAP In-House Cash System
Here you make the ALE - Application Link Enabling - Customizing settings required for the SAP In-House Cash
component from the view of the system in which SAP In-House Cash and Financial Accounting for the Company that
184
manages the In House cash centre (VOCH) are run. For payment orders from companies affiliated with the in-house
cash centre, use message type PAYEXT with basic type PEXR2002 and transaction code PEXR as the inbound
parameter. For bank statements from the in-house cash centre to affiliated companies, use message type FINSTA
with basic type FINSTA01 and the transaction code FINS as the inbound parameter.
EVO OpCo accounting, IHC accounting and IHC bank are all on same box in the system landscape since the OpCos
and the in House cash centre will work in the same system.
4.6.1.1 Define Logical System
SAP specifications:
Meaning of the object:

A logical system is an application system in which the applications are coordinated to work in one common database.
In SAP terms, a logical system corresponds to a client.
Role of the object:

Define the logical systems in your distributed system.
SAP guidelines:
You store system names here for the logical systems for SAP In-House Cash, the OpCos and Financial Accounting of
the head office
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_TBDLS-LOGSYS
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
SPRO SAP Net Weaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) IDoc
Interface / Application Link Enabling (ALE) Basic Settings Logical Systems Define Logical System
EVO Specifications
Financial Accounting of the head office in house cash centre is in the same client as SAP In-House Cash, you will
make an entry here to show that an RFC - Remote Function Call - connection is not used, for example, LOCAL.
Planned usage:
This is the planned usage for the object:
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
184
To create a logical system, choose Edit -> New Entries.

Enter a name for the logical system that you want to create.
Enter a description of the logical system.
If you want to change this entry:
a) Select the appropriate line.
b) Choose Edit -> Change field contents.
c) Enter the new text.
d) Choose Replace.
Save your entries.
4.6.1.2 Assign Logical System to Client
SAP specifications:
Meaning and role of the object:
Here you assign a client to the system for SAP In-House Cash.
Attribute details:
Technical name T000-MANDT
Field type CLNT
Field length 3
SAP level Client
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Basic
Settings Logical Systems Assign Logical System to Client
EVO Specifications:
Here you assign a client to the system for SAP In-House Cash. Generally, this assignment has already made. So,
for configuration purposes you only need to check if this assignment has already been made.
Planned usage:
Area FI
Ownership Global
For this customizing process the values that should be already there for this step are
184
Field name Description User Action and Values

Client Client To be defined
City City Blank value
Logical System Logical system To be defined
Std currency Standard currency Blank value
Changes and transports for client - Changes and transports for client - Indicator Changes without
specific objects specific objects automatic recording
Changes to repository and cross-
Cross client object changes Cross client object changes
client Customizing allowed
Protection: Client copier and Protection regarding client copy
Protection Level 0: no restriction
comparison tool program and comparison tools
Indicator that starting CATT
Restrictions Restrictions
processes is permitted
4.6.1.3 Define Target Systems for RFC Calls
SAP specifications:

RFC: Remote Function Call (RFC) . RFC is an SAP interface protocol based on CPI-C.
Role of the object:
It is used to simplify the programming of communication processes between systems. RFCs enable call and execute
predefined functions in a remote system - or in the same system. They manage the communication process,
parameter transfer, and error handling.
SAP guidelines:
Here you define the subsidiary system as the target system and a technical user; this means that the system is still
accessible even if the personal user is deleted.
Attribute details:
SAP transaction SM59
Technical name -
Field type -
Field length -
SAP level -
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling
(ALE) Communication Create RFC Connections
Choose R/3 connections and Edit -> create

Enter the parameters required for that type (connection type: 3)
Save and click on Test Connection to test the connection. (Here you can define a technical user. This means
that the system is still accessible even if the personal user is deleted)
184
EVO Specifications:
Financial Accounting of the head office is the same client as In-House Cash so its not needed to create an RFC
connection.
Planned usage:
Area FI
Ownership Global
N/A
4.6.1.4 Create Transactional RFC Port
SAP specifications:

Ports are a fundamental requirement for communicating by means of the IDoc Interface. At least one port must exist
for each external system. The process flow depends on the port type, in our case, a Transactional RFC port has to be
created.
EVO Specifications:
The SAP In-House Cash and the subsidiary companies are in the same client. So the configuration steps will be
done as followed.
You can execute this activity if you enter in the transaction WE21 or if you follow the path:
SAP easy Access Accounting Financial Supply Chain Management In-house Cash Environment
Idoc and EDI Basis Administration Port Definition
Carry the following activity because SAP In-House Cash and the OpCos are in the same client.
o Choose Create to create a transactional RFC port.
Field Name Description Use Action and Values

Let the system generate a port
Port Port
name or assign your own port name
Description Description Send IDocs to self
184
RFC destination RFC destination NONE

o Choose Save to create a transactional RFC port.
Carry out the following activity (SAP In-House Cash and Financial Accounting of the head office are in the
same client.)
o Choose Create to create a transactional RFC port.

Let the system generate a port
Port Port
name or assign your own port name
Description Description Loopback to local system
RFC destination RFC destination NONE
4.6.1.5 Process Partner Profiles for Business Partners Manually
SAP specifications:

Partners with whom you communicate via IDocs in the partner profiles: choose the message to be sent to the partner
and define the path to be used, as well as how inbound messages are processed.
Attribute details:
SAP transaction WE20
Technical name VEDI_TDPP1-PARNUM
Field type CHAR
Field length 10
SAP level
Accounting Financial Supply Chain Management In-house Cash Environment Idoc and EDI Basis
Administration Partner profile
EVO Specifications:
Maintain the partners, that are the OpCos, previously defined as Business Partners, with whom the In house cash
centre communicates via IDocs in the partner profiles: choose the message to be sent to the partner and define the
path to be used, as well as how inbound messages are processed.
Planned usage:
Area FI
Ownership Global
184
Select Partner Type GP.

Choose Create.
Choose Outbound Parameters.

Message Type Message Type FINSTA
Receiver port Receiver port The port you generated
Output mode Output mode Indicator: Transfer IDoc immediately
Basic type Basic type FINSTA01
Syntax check Syntax check Select
Choose Inbound Parameter.
Field Name Description Use Action and Values Note

Message Type Message Type PAYEXT
Processing of incoming
Process code Process code PEXN
payments
Only in test phase,
Processing by function Processing by function
Trigger immediately otherwise Trigger by
module module
background program
You have to make entries for each OpCo. You can copy the entries as follows:
Select the partner.
Choose Create Copy.
4.6.1.6 Process Partner Profiles Manually for Logical Systems
Role of the object:

Here you process the clearing partners in partner type LS Logical Systems.
Attribute details:
Field type CHAR
Field length 10
SAP level Company code
SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and
EDI Basis Administration Partner profile
184
EVO Specifications:
Maintain the LS partner in terms of message types in terms of payment orders and bank statement processing for the
system to be able to communicate via iDoc.
Planned usage:
Area FI
Ownership Global
Choose Create.

Logical system of Financial
Partner no. Partner number
Accounting
Partn. Type Partner Type LS
Agent Agent User ID
Lang. Language
Choose Outbound Parameters.

Configuration values
- FI of head office is
Message Code Message code
in the same client as
IHC
Message function Message function
IHC
Basic type Basic type PEXR2002
Choose Inbound Parameters

Message Code Message code
IHC
Message function Message function Configuration values
184
IHC
Process code Basic type PEXR
Processing by function Processing by function
Trigger immediately
module module
4.6.1.7 Define In-House Cash Centre as Bank
SAP specifications:
Meaning of the object

Each house bank of a company code is represented by a bank ID in the SAP system, every account at a house bank
by an account ID.
Role of the object:
In the SAP system, you use the bank ID and the account ID to specify bank details. These specifications are used, for
example, for automatic payment transactions to determine the bank details for payment. Define the in-house cash
centre as your house bank and choose EDI partner profiles.
SAP guidelines:
Work out the specifications you have to enter in the system for your house banks.
Define your house banks and the corresponding accounts in the system under a bank ID or an account ID.
Note: To avoid problems when checking the length of the bank key or the bank number, use transaction code FIHC.
Attribute details:
SAP transaction FIHC
Technical name V_T012-HBKID
Field type CHAR
Field length 5
SAP level Client
EVO Specifications:
The company that manage the in-house cash centre activities will be defined as the bank country.
Planned usage:
Area FI
Ownership Global
184
Configuration Values:

Country of the in house
Bank Country Bank Country HU
cash centre
Bank Key Bank Key 99999999 to differentiate from
the other banks
In House Cash Centre
Bank Name Bank Name
Bank
4.6.1.8 Function module for IBAN
SAP specifications:
Meaning of the object
In this IMG activity, you can define one function per country for creating a BBAN (Basic Bank Account Number)
Role of the object:
The BBAN is a conventional bank and account identification consisting IID (institute identification) and BAN (bank
account number), all together max. 30 alphanumeric characters. It is used to create an IBAN (International Bank
Account Number).
IID: Institute ID (Institute label): fixed length per country, any number of characters in the context of BBAN (in
practice 4 to 12 characters); corresponds to the current BC number (5 characters)
BAN: Customer account number: fixed length per country, any number of characters in the context of BBAN (in
practice 8 to 20 characters)
SAP guidelines:
Its needed to define the function module.
Attribute details:
Technical name V_TBKK06 - FBNAME
Field type CHAR
Field length 30
EVO Specifications:
This is required when creating the call/current accounts in the IHC.
Planned usage:
184
Area FI
Ownership Global
In transaction SM30 on the Maintain table view: Initial Screen, enter V_TBKK06 in Table/View field, and then
choose the Maintain button.

Country (CTY) Country All OpCos and IHC centre
Configuration
Countries with BBAN conversion
BKK_IBAN_CREATE_BBAN_DE values equal to all
companies in IHC scope function
OpCos
Note: This value will be done for all countries that have companies in IHC scope.
4.6.1.9 GL Variant maintenance
SAP specifications:
General ledger variants serve as model for transfer to the general ledger
Role of the object:
Allocate general ledger transactions and general ledger groups to a general ledger variant. The general ledger variant
defines how the transfer from BCA to the FI general ledger takes place.
All settings are made in relation to a general ledger variant. Especially the general ledger accounts are defined. To
this end, an account plan, among other things, is assigned to the general ledger variant.
The Clearing accounts to identify are technical clearing account for the purpose of splitting high volume line items in
IHC company code.
SAP guidelines:
SAP supplies sample customizing that relates to the standard account framework supplied by SAP. To make things
clearer, additional general ledger accounts have been created. Create these too in accordance with the pre-settings
on the general ledger.
184
Technical name V_TBKKCVAR-GLVAR
Field type CHAR
Field length 4
SAP level Client
SPRO Financial Supply Chain Management In-House Cash periodic tasks Maintain GL variant
EVO Specifications:
Planned usage:
Area FI
Ownership Global
The transfer of the values in the IHC account and the IHC G/L account will be done daily
Description GL ChAc Clearing Doc. Type Posting Key Posting Key

Variant Account Debit Credit
Transfer FI Transfer FI Transfer FI
Bank General Ledger General General
Area Ledger Ledger
V_TBKK0 V_TBKKCVAR- V_TBKKC V_TBKK01D- V_TBKKCV V_TBKKCVAR V_TBKKCVAR

1D- T_GLVAR VAR- CHARGE_ACT AR-BLART -BSCHL_S -BSCHL_H
BKKRS KTOPL
In-House Cash 0EVO 48520000 SI 40 50
Centre EVO
IHCE
Note: Document splitting is currently under discussion and is a SAP recommendation. Splitting documents from a
Profit Centre perspective is not a requirement, but following SAP recommendations and taking into account that it can
be necessary in the future, it will be configured in such a way that the documents are zero balanced at profit centre
level, and the partner field is the profit centre.
Every business transaction that is entered is analyzed during the document splitting process. In this process, the
system determines which splitting rule is applied to the document. In order that the system can determine the splitting
rule to each document type. With the document types delivered in the standard system, SAP delivers a classification
for document splitting. This classification is a proposal that needs to check against how the document types are
organized.
Reference for configuration: cbmFIN_R2R_AP326_Configuration_rationale
184
4.6.2 ALE - Application Link Enabling - Customizing in the Subsidiary Company System
Here you make the ALE Customizing settings required for the SAP In-House Cash component from the
view of the OpCos.
For payment orders from companies affiliated with SAP In-House Cash, use message type PAYEXT with
basic type PEXR2002 as the outbound parameter.
For bank statements from the in-house cash centre to affiliated companies, use message type FINSTA
with basic type FINSTA01 and process code FINS as the inbound parameter.
When you create PAYEXT, EUPEXR is created automatically.
4.6.2.1 Define Logical System
SAP specifications:

A logical system is an application system in which the applications are coordinated to work in one common database.
In SAP terms, a logical system corresponds to a client.
Role of the object:
Here you define the system for the OpCo and the system for SAP In-House Cash.
Attribute details:
Technical name V_TBDLS-LOGSYS
Field type CHAR
Field length 10
SAP level
(ALE) Basic Settings Logical Systems Define Logical System
EVO Specifications:
The subsidiary is in the same system as the in-house cash centre, the system entry already exists
since the underlying table is cross-client.
Planned usage:
Area FI
Ownership Global
184
4.6.2.2 Assign Logical System to Client
SAP specifications:
Role of the object:
Here you assign a client to the OpCo system.
Attribute details:
SAP transaction
Technical name T000-MANDT
Field type CLNT
Field length 3
SAP level
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Basic
Settings Logical Systems Assign Logical System to Client
EVO Specifications:
These settings will be already created in the system configuration. Nevertheless check if these values the
configuration values are there.
Planned usage:
Area FI
Ownership Global
Select one line.

Choose: Goto -> Details.
The 'Client Details' screen appears and the following fields must be filled:

Client Client Client used in the system
City City
Logical system Logical system
184
Std currency Standard currency

Changes and transports for client Changes and transports for client Select indicator: automatic
specific objects specific objects recording of changes
No changes to Repository and
Cross-client object changes Cross client object changes
cross client
Protection: client copier and Protection regarding client copy
Protection level 0: No restriction
comparison tool program and comparison tools
Indicator that starting CATT
Restrictions Restrictions
processes is permitted
.
Note: In the field Logical system, enter the name of the logical system to which you want to assign the
selected client.
4.6.2.3 Configure Systems in Network, Define Target Systems for RFC Calls
SAP specifications:
Role of the object:
Here you define the SAP In-House Cash system as your target system.
Attribute details:
Technical name -
Field type -
Field length -
SAP level Client
(ALE) Communication Create RFC Connections
EVO Specifications:
Check if the customizing settings are already created in the system
Planned usage:
Area FI
Ownership Global
184
Choose R/3 connections and Edit -> create

Enter the parameters required for that type (connection type: 3)

RFC destination RFC destination
Connection type Connection type 3
Description Description
Logon/Security Logon/Security
4.6.2.4 Process Partner Profiles Manually
Role of the object:
Here you create the in-house cash centre as your house bank in partner type B.
Attribute details:
Field type CHAR
Field length 10
SAP level Client
SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and
EDI Basis Administration Partner profile
EVO specifications:
Planned usage:
Area FI
Ownership Global
Select Partner Type B

Choose Create.

Partner no. Partner number 99999999 Bank key defined
184
for in house bank

Type US
Agent Agent User ID
Lang. Language
Choose Outbound Parameters. You have to create two messages types: PAYEXT and EUPEXR. The
values to introduce are the followings:
Field Name Use Action and Values Use Action and Values
Message Type PAYEXT EUPEXR
Receiver port The port you generated
Indicator: Transfer IDoc Indicator: Transfer IDoc
Output mode
immediately immediately
Basic type PEXR2002 IDCREF01
Syntax check Select Select
Choose Inbound Parameters
Field Name Use Action and Values

Message Type FINSTA
Process code FINS
Syntax check Select
Processing by function module Trigger immediately
4.6.2.5 Process Partner Profiles Manually for Logical Systems
SAP specifications:
Role of the object:
Here you process the clearing partners in partner type LS.
Attribute details:
SAP transaction WE 20
Technical name -
Field type -
Field length -
SAP level Client
SAP Easy Access Tools ALE ALE Administration Runtime Settings Port Maintenance Partner
Profiles
184
EVO Specifications:
OpCo is in the same system as the in-house cash centre, you have to make these entries for the
logical systems. Make sure that the partner profile is active (partner status A)
Planned usage:
Area FI
Ownership Global
Select Partner Type LS.

Choose your logical system.
The OpCo is in the same system as the in-house cash centre, you effectively send IDocs to the same
system. This means that in partner type LS, the message types PAYEXT and FINSTA have identical inbound
and outbound parameters. You only define message type EUPEXR in the outbound parameters.
4.6.3 Business Customizing

4.6.3.1 Customizing Financial Accounting for Subsidiary Companies
In this section you make the settings required for the payment program of the subsidiary companies: You define the
in-house cash centre as new house bank. You define a new payment method for payments via the in-house cash
centre. You carry out the Customizing for the incoming electronic account statement from the in-house cash centre.
These settings are required for internal payments.
4.6.3.2 Set up payment methods per country for payment transactions
SAP specifications:

The Countries are standard in the SAP system. The two-character ISO code in accordance with ISO 3166, which is
delivered by SAP as a default, is usually used. The payment method determines how payments are to be made, e.g.
by cheque, bank transfer or bill of exchange. Payment methods are entered in the master records of vendors in order
to specify how payments are made.
Role of the object:

To identify one of the several payments methods used in each country. The country key contains information which
the system uses to check entries such as the length of the postal code or bank account number.
Before every payment run the payment methods need to be specified. If a payment method is specified in open items
or in the master record of the vendor and if that payment method is permitted for that payment run, the payment
program selects this payment method. The payment method in the open items takes precedence over any payment
method defined in the master record.
184
SAP guidelines:
You have to specify which payment methods are to be used in each country. Enter the following details for the
payment method:
Payment method either for incoming or outgoing payments.
Characteristics for classifying payment method.
Required entries in master record.
Posting specifications.
Which procedure is to be used to issue the accompanying payment form.
Attribute details:
SAP transaction Transaction: FBZP
Technical name V_T042ZL-ZLSCH
Field type CHAR
Field length 1
SAP level Company Code
Financial Accounting -> Accounts Receivable and Accounts Payable -> Business Transactions -> Outgoing Payments
-> Automatic Outgoing Payments -> Payment Method/Bank Selection for Payment Program->Set Up Payment
Methods per Country for Payment Transactions
If its a new entry select a country code and a key for the payment method. Add a description for it;
Set the payment method as an outgoing payment;
Set the classification of the payment method (bank transfer, cheque, Bill/ex, Cheque/bill/ex.);
Set the master data required address/bank data;
Select the payment medium required for the payment method as an output for the payments,
Enter the currencies allowed screen, and enter those currencies that are permitted for this payment method. Note:
Leaving this table empty will mean that all currencies are permitted.
EVO specifications:
Planned usage:
Some of the outgoing payment methods which are going to be created in some OpCos are already identified, such
as bank transfers, cheque, and direct debit. However, specific payment methods are going to be evaluated during
Rollout phase.
Payment methods will be identified based on the specific country key. Currently 18 countries are in scope of EVO
(considering also VPC located in Luxemburg).
For intercompany settlement the payment method Z is used which is valid for all countries and all currencies.
The table below provides additional details:
Area FI
Ownership Global
Expected activity Core
184
Coding rule:
To identify the country:

Use the general coding rule Country ISO code.
The countries in scope have the following standards:
Country Country
ISO CODE
Albania AL
Australia AU
Czech Republic CZ
Egypt EG
Germany DE
Greece GR
Hungary HU
Ireland IE
Italy IT
Luxemburg LU
Malta MT
Netherlands NL
New Zealand NZ
Portugal PT
Romania RO
Spain ES
Turkey TR
United Kingdom GB
Each payment method is assigned with one alphanumeric identification code.
For each country the payment method can already be created with a different identification code but means the same.
A standard payment method must be identified for each country as each Op Co. rolls out.
Payment method Posting details Required Master data Specifics Payment

classification Medium
Payment Out Ba C Bill Che Docu Clearin Bank A/C IBAN SWIFT Use Use
Method goin nk h /ex ck/ ment g Details No Reqd code paym Classi
g tra e bil/ type docum Reqd Reqd ent cal
pay nsf c ex for ent medi paymn
men er k paym type um t
t ent work mediu
benc m
h progra
184
ACH X X ZP ZV X X X
SEPA X X ZP ZV X X X X
SDP X X ZP ZV X X X
Direct Debit ZP ZV X X X
Check X X ZP ZV X
TT X X ZP ZV X X X X X
Z X X ZP ZV X X X
Y X X ZP ZV X
Currencies allowed
GBP
EUR
USD
HUF
Others (local currencies)
Note: The currencies table and payment method table is just example. . Please refer to assumptions below for
details of currency usage.
Assumptions:
1. Payment Method
The EVO Payment Method will be there are local configuration values that have to be gathered during each
release:
External IDOC files will need to be produced for the below payment methods, as well as
financial posting
PMT
method Name Usage
C Cheques Paper Payments
E ACH 3 day payment
G SDP International Same day payment to US
H SDP Eurozone Same day payment IBAN & BIC required
S SEPA 3 day payment inside Europe. IBAN & BIC required
No external IDOC will be required.

PMT
method Name Usage
D Direct Debit Financial postings only - no bank files to be produced
Intercompany Legacy
Y settlement Financial postings only - no bank files to be produced
O Standing Orders Financial postings only - no bank files to be produced
T Telegraphic Transfer For BCP use
Z Inter.In house cash payment Used to settle incompany payments for EVO opco;s
184
2. Document Type
For all EVO the document type for payment to posting details will be the standard ZP payment posting.
3. Currency Allowed
The currencies allowed by payment method will be defined by company. Standard rules will be:
Cheque will just allow the currencies of the bank account currency
TT will allow any currency and will not produce a payment file during the payment run, just a booking to
ensure they auto-allocate on statement upload as agreed with TCM
SDP (Same Day Payment) or local equivalent will allow any currency (as a working principle - in reality there
will be restrictions as to what currencies we can pay out of bank account);
ACH (Local Automated Clearing House) or local equivalent will allow the currencies of the bank account
currency;
Intercompany settlement and intercompany legacy system payments should be available for all currencies
and all countries.
It means for country code and payment method the allowed currencies should be defined such as GBP,EUR,USD
and others (local currencies).
4.7 Set up Payment methods per Company code for payment transactions
SAP specifications:

This object defines which payments methods can be used per company code and determine the conditions under
which a payment method should be used.
Role of the object:

Specified which payment methods can be used in each company code and determine the conditions under which a
payment method should be used.
Amount limits for payments within which the payment program can select the payment method.
Specifications for grouping items for payment.
Specifications for foreign/foreign currency payments
Specifications for optimizing bank selection.
Specifications for the form to be used for the payment medium.
Specifications for issuing payment advice notes.
SAP guidelines:
The payment method per company code can be optimized either by bank groups or by postal codes. If you optimize
by bank groups, money is transferred from the house bank to the business partner's bank in the shortest possible
time. For this to be possible, you assign all banks in the master records to a bank group defined by you (in alignment
with Treasury settings).
If you specify that the payment method can also be used for foreign currencies, all currencies are permitted. In the
previous configuration object described, you can also specify certain currencies per payment method and country.
Only payments in these specified currencies are then made using this payment method.
Attribute details:
184

Technical name V_T042E-ZLSCH
Field type CHAR
Field length 1
-> Automatic Outgoing Payments ->Payment Method/Bank Selection for Payment Program-> Set Up Payment
Methods per Company Code for Payment Transactions
Enter the amount limits for considering the payment processing, and the foreign payments settings;
Enter the bank selection control data;
Enter the Name of the form with which a payment medium with documents is to be created and the sorting type.
EVO specifications:
Planned usage:
This configuration is applied to all the payment methods defined in the previous configuration steps.
The payment methods to be used for specific company code would be a business decision which would be dealt at
localization level.
Area FI
Ownership Op but following Global methodology
Coding rule:
Not applicable because for each company code and payment method several fields will be filled.
The combination between company codes and payment transaction will be defined during localization.
184
Note: The previous screen is just an example. The final one will contain the details specified by company code and
payment method.
Assumptions:
For all EVO the payment program will select the payment method with the following amount limits:
Minimum amount: 5 GBP
Maximum amount: 200m GBP
Foreign currency will be allowed for all payment methods except cheque + Automated clearing house.
Company
code Name City
V_T042E- V_T042E-
ZBUKR V_T042E-BUTXT ORT01
DE04 Vodafone D2 GMBH Dsseldorf
Vodafone Services
DE05 GMBH Dsseldorf
GB06 Peoples Phone Limited London
GB07 Vodafone Limited London
Vodafone UK Services
GB11 Ltd. London
GB34 Vodafone UK Limited London
Vodafone Group Serv.
GB85 Ltd. London
Vodafone Panafon
GR02 Hellenic Athens
Vodafone Procurement
LU07 Sarl Luxembourg
LU99 Dummy VPC Luxembourg
Vodafone
HU00 Magyarorszg zrt Budapest
184
Payment method per company code
Foreign cust/vendor
business Foreign bank
Pmt Minimum Maximum partner currency abroad
method Name amount amount allowed allowed allowed
V_T042E- V_T042E- V_T042E- V_T042E- V_T042E-
ZLSCH V_T042E-TEXT1 VONBT V_T042E-BISBT XAUSL XFWAE XAUSB
E ACH 5,0 200.000.000,00 x x
S SEPA 5,0 200.000.000,00 x x x
H SDP 5,0 200.000.000,00 x x x
D Direct Debit 5,0 200.000.000,00 x x x
C Cheque 5,0 200.000.000,00
T TT 5,0 200.000.000,00 x x x
Intercompany 200.000.000,00
Z settlements 5,0 x x x
Intercompany legacy 200.000.000,00
Y settlement 5,0 x x x
Note: The previous screen is just an example. The final one should contain the details specified by
company code and payment method.
Intercompany in-house cash settlement and intercompany legacy system payments should be available for
all currencies and all countries.
Note1: The previous currency is just the currency allowed in EVO. The final one will contain the specified currency
allowed for each company code and payment method.
Note2: Document splitting is currently under discussion and is a SAP recommendation. Splitting documents from a
organized.
Its necessary to flag bank details. This is essential as this allows IHC to work seamlessly to debit credit correct
current account. This is essential as this allows IHC to work seamlessly to debit credit correct current account.
184
Regarding the payment medium program, it will be maintained the RFF0EDI1
4.8 Set up Bank determination for payment transactions
SAP specifications:

Specified settings that the payment program uses to select the banks or bank accounts from which payment is to be
made.
For payment transactions you need house banks and possibly the bank details of your vendors. House banks are
banks with which your company code maintains accounts.
Role of the object:

This object allows you to define the following:
Ranking order of banks: you specify which house banks are permitted and rank them in a list.
Bank accounts: for each house bank and payment method (and currency, if required), you specify which bank
account is to be used for payments.
Available amounts: for each account at a house bank, you enter the amounts that are available for the
payment run. You enter separate amounts for incoming and outgoing payments. Specifying available
amounts enables you to control which bank account is to be used for payments. You can specify the amounts
depending on the value date at the bank.
Value date: You specify how many days elapse between the posting date of the payment run and the value date at the
bank, dependent on the payment method, bank account, payment amount, and currency.
.
SAP guidelines:
Ensure that payment methods have defined both in country and company code as described in the previous steps.
Also ensure that all house banks and bank accounts required have been created on these company codes.
184
Depending on the payment method used, you may/may not require the bank details of your vendor. For example, you
require the bank details of your vendor for transfers, but not for clearing cheques. Enter vendor bank details in master
records.
You can enter as many sets of bank details in master records as you want, both for your company codes and for your
vendors. You can determine the bank that is selected by:
An explicit specification in the master record of the customer/vendor or in the open items. The specification in
the item has higher priority.
The payment program, which determines according to specified rules, the most suitable house bank or the
optimal combination of house bank and customer/vendor's bank.
.
Attribute details:
Technical name V_T042BD-ZBUKR
Field type CHAR
Field length 4
-> Automatic Outgoing Payments -> Payment Method/Bank Selection for Payment Program->Set Up Bank
Determination for Payment Transactions
For each payment method in the company code, enter a ranking position and its related house bank;
For the Bank Accounts, per each combination house bank/payment method/currency, enter an account ID,
the related bank sub account to be posted when the payment run is performed;
For the Available Amounts and, per each combination house bank/bank account/, enter the currency and the
maximum amounts for outgoing payments.
EVO specifications:
Planned usage:
Specific Bank account and accounts will be created within EVO in order to post each type of outgoing payment. For
automatic payment purposes, clearing accounts will be used.
Bank account and clearing accounts are yet to be finalized and will be updated during the roll out phase.
Area FI
Ownership Op Co
Coding rule:
Not applicable because for each paying company code several fields will be filled.
184
First of all, make all specifications that are required for a country-specific payment method: set the indicator
for required specifications in the master record for the bank connection.
Note: Use the standard payment media program RFFOEDI1. Use also the In-House Bank has a
bank for this payment method.
Then define per company code the terms under which a payment method can be used (all OpCos).
When defining the House banks for intercompany payment method Z - Define the house bank for each OpCo - the
In House Bank created with transaction FIHC. This will enable the intercompany settlements to be process by an in
house bank and not by an external bank. The Evo system will already have during this activity the in house bank
created.
All Ranking order, Bank account, available amounts per company code will be updated during the rollout phase.
Assumptions:
1. Ranking Order:
The sequence number ranking controls the order in which the payment program checks the house banks to
determine whether the payment has to be made from a particular bank account.
If a payment has to be done with a currency in which the company code has a bank account, the payment will be
done through this account; otherwise it will be done through the functional currency account.
Ranking Order is not applicable to EVO since our official banking partners are only the Deutsch Bank.
2. Bank Accounts:
For each company code several Bank accounts will be defined to the different currencies.
The Clearing account will be defined by payment method and House Bank. Each bank account will have separate GL
account, and each bank will have its own set of clearing accounts (defined by types of payment that can be made
from that account) e.g. for a VF UK $ account we would not set up a cheque clearing account.
Paying House Bank Payment Currency Account ID Bank Sub

company code Method account
GB06 1 C 1254 24003020
GB06 1 TT 1257 24003021
GB06 2 C 1287 24003022
GB06 2 TT 1982 24003023
3. Available Amounts:
SAP Standard functionality will be used to calculate value dates (based on payment method and currency)
For all EVO the amount available for outgoing payments will be 9.999.999.999.999,00. This amount is only used for
payments with which the bank debit entry is expected during the number of days displayed.
184
Company House Account Available for outgoing Scheduled incoming

Code Bank ID Days Currency payment payment
GB06 00001 1254 999 GBP 9.999.999.999.999,00 9.999.999.999.999,00
Note: The previous tables are just an example. The final ones should contain the details specified by company code.
4.8.1.1 Define House Banks intercompany settlements
by an account ID.
Role of the Object:
example, for automatic payment transactions to determine the bank details for payment.
SAP guidelines:
Several house banks are supplied as examples in the standard system in order to enable configuration of the
payment program.
Attribute details:
SAP transaction FI12
Technical name V_T012-HBKID
Field type CHAR
Field length 5
SAP Netweaver General settings Set countries Set country-specific checks
EVO Specifications:
Planned usage:
Area FI
Ownership Local
184
Values will be established when creating the in house bank.

Values, when creating the house banks in the OpCos will be maintained. The EDI partner created in the in house
configuration and EDI payment methods - in this case the intercompany payment method created will be maintained
in transaction FI12
EDI partner:
EDI payment methods:
Payment Methods Name

Z Intercompany clearing
For intercompany legacy settlement payment method, transition payment method for intercompany settlements, there
is no iDoc generated. So in this case, for payment method X there is no need to setup a EDI partner.
Payment Methods Name

Y Intercompany legacy settlement
4.8.1.2 Bank determination
SAP specifications:

Specified settings that the payment program uses to select the banks or bank accounts from which payment is to be
made.
For payment transactions you need house banks and possibly the bank details of your vendors. House banks are
banks with which your company code maintains accounts.
Role of the object:

This object allows you to define the following:
Ranking order of banks: you specify which house banks are permitted and rank them in a list.
Bank accounts: for each house bank and payment method (and currency, if required), you specify which bank
account is to be used for payments.
Available amounts: for each account at a house bank, you enter the amounts that are available for the
payment run. You enter separate amounts for incoming and outgoing payments. Specifying available
184
amounts enables you to control which bank account is to be used for payments. You can specify the amounts
depending on the value date at the bank.
Value date: You specify how many days elapse between the posting date of the payment run and the value
date at the bank, dependent on the payment method, bank account, payment amount, and currency.
.
SAP guidelines:
Ensure that payment methods have defined both in country and company code as described in the previous steps.
Also ensure that all house banks and bank accounts required have been created on these company codes.
You can enter as many sets of bank details in master records as you want, both for your company codes and for your
vendors. You can determine the bank that is selected by:
An explicit specification in the master record of the customer/vendor or in the open items. The specification in
the item has higher priority.
The payment program, which determines according to specified rules, the most suitable house bank or the
optimal combination of house bank and customer/vendor's bank.
.
Attribute details:
Technical name V_T042BD-ZBUKR
Field type CHAR
Field length 4
-> Automatic Outgoing Payments -> Payment Method/Bank Selection for Payment Program->Set Up Bank
Determination for Payment Transactions
For intercompany payment method in the company code, enter in the ranking position the in-house bank;
For the Bank Accounts, for intercompany combination house bank/payment method/currency, enter an
account ID of the house bank, the related bank sub account to be posted when the payment run is
performed;
For the Available Amounts and, per each combination house bank/bank account/, enter the currency and the
maximum amounts for outgoing payments.
EVO specifications:
Planned usage:
Specific Bank account and accounts will be created within EVO in order to post intercompany type of outgoing
payment. For this case, automatic payment, clearing accounts will be used.
Bank account, accounts and clearing accounts are not still defined, only the ranges and logic (see Appendix A); the
determination and decision about bank accounts needed in each country will be done in each release phase and for
clearing accounts usage will be defined with D.B. inputs.
184
Area FI
Ownership Global
Intercompany payment method in the company code, enter in the ranking position the in-house bank (IHC
house bank);
Bank Accounts, for intercompany combination house bank/payment method/currency, enter an account ID
of the house bank (IHC house bank)
Value date for accurate cash position reporting define value date same day value date - Probable
number of days before a debit and/or a credit memo is carried out to the bank account. The number of days
is added to the posting date and results in the date relevant for cash management and forecast on which the
debit and/or credit memo is to be expected on the bank account. These dates will be provided by D.B. or
correspondence banks in order to have an accurate cash position. This will depend in the country, so will be
define in the release phase.
Assumptions:
1. Bank Accounts:
For each company code several Bank accounts will be defined to the different currencies.
The Clearing account will be defined by payment method and House Bank. Each bank account will have separate GL
account, and each bank will have its own set of clearing accounts (defined by types of payment that can be made
from that account)
2. Available Amounts:
SAP Standard functionality will be used to calculate value dates (based on payment method and currency)
For all EVO the amount available for outgoing payments will be 9.999.999.999.999,00. E.g.:
Company House Account Available for outgoing Scheduled incoming

Code Bank ID Days Currency payment payment
GB06 00001 9999 999 GBP 9.999.999.999.999,00 9.999.999.999.999,00
Note: The previous tables are just an example. The final ones will contain the details specified by company code.
4.8.2 Customizing the In-House Cash Centre

As a virtual house bank, the in-house cash centre receives payment orders from subsidiary companies
in the form of PAYEXT IDocs and posts them to the corresponding current accounts. The in-house cash
centre creates and sends account-statement-relevant data in the form of a FINSTA IDoc.
4.8.2.1 Define In-House Cash Centre as Bank Area
SAP specifications:
184

The bank area is the central organizational unit of current accounts and affects just about every unit of the system.
You determine certain defaults which will or can affect all accounts within the bank area.
Role of the object:
Define the bank area that you require for your organization and determine certain defaults which will or can affect all
accounts within the bank area. Within a bank area, complete and independent account management and account
processing takes place. This means there must be clear and unmistakable account numbers within a bank area. A
bank key (for example, in Germany the bank identification number) is assigned to each bank area. You normally
create an own bank area for every banking organization for which a bank key exists. You create accounts and
conditions specifically for a bank area. Note that within a bank area there must be clear and unmistakable account
numbers.
SAP guidelines:
SAP recommends that you create a bank area for each organization managed in the system which has its own bank
key. Generally, you will only need one bank area. The bank country to be entered (where the institute is located)
controls how the bank key is treated and which underlying control mechanisms apply. The bank country also
determines the maximum length of account numbers that the system uses in this bank area.
Attribute details:
Technical name IHC_V_BANK_AREA-BKKRS
Field type CHAR
Field length 4
SAP level Client
Financial Supply Chain Management In-House Cash Basic Settings Bank Area Define Bank Area
EVO Specifications:
Planned usage:
The bank area specified for EVO intercompany solution will have one location. There will be several bank areas to
support the Vodafone intercompany requirements. It is organization unit in SAP for a self contained virtual in-house
bank. It has its own configuration and master data (accounts, conditions, products). Vodafone will only have one bank
area globally and this will be managed by the VOCH.
Area FI
Ownership Global
Enter a bank area and the global settings. Take account the meaning and the values for the following fields:
184
Bank area currency: The bank area currency is usually the same as the local currency of the company code
to which the bank area is assigned.
Company code: Each company code is assigned to a bank area
General ledger variant: The GL variant defines how the transfer from bank area to FI general ledger takes
place. The variant can only be entered here if previously defined
Bank Description Bank Bank Exchange Company GL

Area Bank Area country Keys Rate Type code Variants
key
IHC_V_B IHC_V_BANK IHC_V_BA IHC_V_B IHC_V_BAN IHC_V_BAN IHC_V_
ANK_AR _AREA- NK_AREA- ANK_AR K_AREA- K_AREA- BANK_
EA- T_BKKRS BANKS EA- RATETYPE BUKRS AREA-
BKKRS BANKL GLVAR
EVO IHC Bank HU 99999999 M HU01 IHCE
(Vodafone
IHCE Op.Centre
Hungary)
Activate LOG and IHC active
4.8.2.1.1 Set Up Number Ranges for Log
SAP specifications:
Meaning and Role of the object:
A payment order originated from OpCo accounting and integrates seamlessly into IHC. In the event that an error
occurs, a log is created and referenced by a unique error log number. This configuration is required to specify the
number range which the error log references will use. The number range is year dependent allowing for adequate
value range.
Attribute details:
SAP transaction IHCN1
Technical name INRDP-NRRANGENR
Field type CHAR
Field length 2
SAP level Client
Financial Supply Chain Management In-House Cash Basic Settings Set Up Number Ranges for Log
EVO Specifications:
Planned usage:
184
To Log the payment orders regarding technical reasons it must be defined a number log.
Area FI
Ownership Global
Enter 01 as the Number range number.

Create only one number range.
Define an interval of your choice with at least 100000 numbers.
Do not set the indicator for external numbering.
4.8.2.1.2 Set Up Number Ranges for IHC Payment Orders
SAP specifications:
IHC payment orders are numbered automatically. A payment item is created in IHC as a result of the payments
generated by OPCO payments. This number range is used for assigning a unique reference to each payment item.
The number range is year dependent allowing for adequate value range. This is used to enter a payment transaction.
An IHC payment order documents a payment from a bank account to a recipient account and contains a payer and a
recipient position. The IHC payment order holds these payment items together but strictly speaking it does not post
anything.
Role of the object:
In this activity, you process the number range intervals.
Attribute details:
SAP transaction IHCN3
Field type CHAR
Field length 2
SAP level Client
SAP guidelines:
184
Create the number range interval 01 with internal number assignment for each bank area and year.
Create a separate number range interval for each year.
You can execute this function introducing the transaction code IHCN3 or following the path:
Financial Supply Chain Management In-House Cash Basic Settings Bank Area Set Up Number
Ranges for IHC Payment Orders
EVO Specifications:
Planned usage:
For the IHCE bank area create a number range interval for IHC payment orders.
Area FI
Ownership Global
4.8.2.1.3 Define how in House cash data is transferred to Financial accounting
SAP specifications:
Set how the transfer of the general ledger data to financial accounting is to take place.
Role of the object:
In this section you can set the +/- sign with which postings are to be displayed by the system.
You have the option of giving credits, that is, incoming payments from the perspective of the account, a minus sign,
as is customary from the perspective of general ledger accounting and also internationally customary for credit
postings. Alternatively, you can have debit postings that are, outgoing payments, negatively displayed.
You can also set in this section how the transfer of the general ledger data to financial accounting is to take place.
You can choose if the FI general ledger and BCA are in the same system or in different systems.
184
You specify the condition type for the sales tax postings on the FI general ledger.
You can also specify that there is to be a check of the general ledger data before it is transferred to the general
ledger. The system always performs this check in a simulation run. This enhancement is particularly meaningful for
test systems and in the case of changes to Customizing. Do not use this additional check if the general ledger is in an
external system and productive operation is in progress.
Attribute details:
Technical name TBKK00-GL_TRANSFERTYPE
Field type CHAR
Field length 1
SAP level Bank area
SPRO Financial Supply Chain Management In-House Cash Basic Settings Basic Settings - Postings
Set +/- Sign Postings/GL Transfer/Name Check
EVO Specifications:
Planned usage:
The following is pre-set in the standard system:
-Minus sign for debit postings (debits)
-FI general ledger in the same system as BCA
-General ledger data check before transfer
Setting the indicator "+/- sign for debit postings" only influences the display form on the interface. Processing and
internal saving of the postings takes place independently of this.
Here you define the +/- sign with which outgoing payments are displayed in BCA. Incoming payments are displayed
with the inverse sign. Saving on the database is independent of this and is clear and unmistakable.
For that, outgoing payments are defined to have (-sign) - Choose the FI general ledger transfer type
If necessary, delete the indicator for the additional check of the general ledger data before transfer after test phase.
Area FI
Ownership Global
Field Name Description User Action and Values Note

+/- sign for outgoing The system proposes
+/- Outgoing Payments - sign
Payments negative signs by default
Trans.Type FI Gen.Led Transfer type of FI general ledger and The FI general ledger is
184
general ledger data to BCA are in the same in the same system as
FI system BCA per default.
Blank value - BCA is in
RFC destination RFC destination the same system that
the FI general ledger
Blank Value - BCA is in
Model view Model view of ALE the same system that
the FI general ledger
Condition type for sales Condition type for sales
Tax Tax
The default setting will
Check G/L Data before Check G/L Data before Check G/L data before
be the G/L data before
Transfer Transfer transfer.
transfer.
Necessary Word Necessary Word
Length for Incorrect Length for Incorrect Blank value
Letter Letter
4.8.2.1.4 Activate SAP Component SAP In-House Cash
SAP specifications:
The business transaction event (BTE) interface can be used to transfer created or changed material master data to
customer-defined processes.
Role of the object:

Specify which P/S modules (business transaction events) of the SAP components you wish to use.
Attribute details:
SAP transaction BF11
Technical name
Field type
Field length 1
SAP level Client
You can execute this function in the transaction BF11 or following the path:
SPRO Financial Supply Chain Management Basic Settings In-House Cash Basic Settings Business
Transaction Events/Event Control Activate SAP Components
EVO Specifications:
Planned usage:
Set the active indicator for the components SAP In House Cash and Standard Accounting.
Deactivate the components BKK and TR-LO.
If there is an entry for IHB, delete it.
184
Save your entries.
Area FI
Ownership Global
4.8.2.2 Master Data

4.8.2.2.1 Process Products
SAP specifications:
The product represents the scope of functions of a current account.
Role of the object:
In the SAP current account system, the product is the result of the definition of fields, features and payment
transaction operations. Using products you control general processing characteristics, these processing
characteristics being transferred to the assigned accounts.
The products serve as a template and framework for accounts. Assign the products to the bank area in which they
are to be used. You can use a product in several bank areas.
SAP guidelines:
When creating a new product SAP recommends to copy from an existing, standard one.
Attribute details:
SAP transaction F9MBP
Technical name V_TBKKH1-PRODEXT
Field type CHAR
Field length 10
SAP level Bank Area
SPRO Financial Supply Chain Management In-House Cash Master Data Product Definition
Product Assign Products to Bank Areas
EVO Specifications:
Planned usage:
Use standard product - IHC MAX that gives the ability to the user, when he creates an IHC account, can use the
type of conditions, limits, authorizations that is defined. For that:
Assign the product IHC MAX to use in IHCE.
184
Please take account the following:

Do not forget to activate the products and assign them to IHCE.
Area FI
Ownership Global
4.8.2.2.1.1 Conditions
SAP specifications:

Typically, when an account is created, certain standard conditions are already assigned to it by virtue of the choice of
the product and the condition group defined for it.
Role of the object:
Create conditions dependent on a condition area that you assign to the product.
Attribute details:
SAP transaction F98E
Technical name BKK83-CONDAREA
Field type CHAR
Field length 4
SAP level Bank Area
SAP Easy Access In-House Cash Conditions Condition Assignment Edit
Note: After create the conditions you have to define the condition area in the conditions. To do this you have to follow
the path: SPRO Financial Supply Chain Management In-House Cash Master Data Product Definition
Product Change Product; Or execute the transaction FIPRD2
EVO Specifications:
Planned usage:
Check to see if the required combination of standard conditions already exists in a previously defined
condition group. If this is not the case, create a new condition group and assign the conditions to it.
Within the account, change the assigned condition group for the corresponding condition group category.
Use the standard condition area 0001
Area FI
184
Ownership Global
4.8.2.3 Maintain Formats for Bank Statements
SAP specifications:

When you maintain accounts you can assign these formats for specific accounts. The format is also transferred to the
bank statement interface when the bank statement is transferred. Evaluation and operational conversion of the
formats must be realized in the bank statement printing solution that is relevant.
Role of the object:
Define the formats for the bank statements received.
Attribute details:
Technical name V_TBKKM9-BKST_FORMAT
Field type CHAR
Field length 6
SAP level Bank Area
SPRO Financial Supply Chain Management In-House Cash Master Data Account Maintain
Formats for Bank Statements
EVO Specifications:
Planned usage:
Area FI
Ownership Global
Enter the format that is the one used by intercompany:
1 FINSTA
4.8.2.4 Account Management
184
4.8.2.4.1 Maintain Accounts for Payment Transactions
SAP specifications:
Clearing account: Bank-internal account on which transaction charges and transaction interest are stored.
Role of the object:
A clearing account for transaction charges and transaction interest that cannot be charged to the recipient (e.g. for
returns) and guaranteed amounts for which the bank is liable if a check is returned.
Per bank area and currency you must specify one of each account.
SAP guidelines:
When you create accounts, create a clearing account for each bank area and for each currency within this bank area.
Technical name V_TBKK01D-CHARGE_ACT
Field type CHAR
Field length 35
SAP level
SPRO Financial Supply Chain Management In-House Cash Account Management Maintain
Accounts for Payment Transactions
EVO Specifications:
Planned usage:
Area FI
Ownership Global
Bank Currency CpD Acct. for Clearing Account for

Area Payment Payment Transactions
Transactions
V_TBKK0 V_TBKK01D- V_TBKK01D- V_TBKK01D-
1D- WAERS CPD_ACT CHARGE_ACT
BKKRS
EUR Bank-internal account on Clearing account number
which business defined in the G/L
IHCE transactions are posted accounts for IHC
collectively
184
4.8.2.4.2 Define Account Determination
1. Define business transaction codes (posting category 70, transaction type 0150, and business transaction code 020
for debit notes and posting category 71, transaction type 5110, and business transaction code 051 for credit notes).
2. Maintain transaction types (double click on transaction type)
3. Assign offsetting transaction types
4. Maintain posting categories
5. Assign posting categories to transaction types
SAP recommends that in SAP In-House Cash, you use posting category 70, transaction type 0150, and business
transaction code 020 for debit notes. For credit notes, SAP recommends posting category 71, transaction type 5110,
and business transaction code 051. If required, add to the Customizing settings, for example, for bank collection.
4.8.2.5 Periodic Tasks (General Ledger Transfer)
4.8.2.5.1 Maintain GL Variants
SAP specifications:
General ledger variants serve as model for transfer to the general ledger. You allocate general ledger transactions
and general ledger groups to a general ledger variant.
Role of the object:
You must define the following details for a general ledger variant:
The chart of accounts you use on the general ledger. This chart of accounts must exist for all subsequently
assigned company codes of the general ledger. When you maintain a chart of accounts, this must already
have been created in SAP FI.
A clearing account, needed for technical reasons for internal purposes during transfer when very large
amounts or a large number of document lines are being transferred. After transfer, the balance of the clearing
account is zero.
The document type with which the transfer is to be posted (sensibly a self-defined G/L account document
type for all transfers from the current account system) and a bank key each for posting receivables (debit
posting) and payables (credit posting).
SAP guidelines:
Keep the maintenance required for assigning several bank areas to a minimum. Create general ledger
variants as transfer templates and assign them to several bank areas. In the general ledger variant,
transaction types are grouped in general ledger transactions. The accounts are grouped in general
ledger groups. These details enable you to specify the transfer precisely.
Attribute details:
Technical name V_TBKKCVAR-GLVAR
Field type CHAR
Field length 4
SAP level
184
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
Maintain GL Variants
EVO Specifications:
Planned usage:
In EVO system for the transfer to the FI general ledger, a clearing account on the general ledger is needed if the
number of document lines or the amounts are very large. In this case, several FI documents must be posted and
normally an additional posting to the clearing account is necessary for a zero balance on the FI document.
At the end of the transfer the balance on the clearing account is zero.
Area FI
Ownership Global
Copy from standard SAP variant and change values
Description Clearing Document Posting Key debit /

Chart of
GL Variant GL Variant Account Type credit
Accounts
Transfer
V_TBKKCVAR- V_TBKKCVAR- V_TBKKCVAR- V_TBKKCVAR- V_TBKKCVAR- V_TBKKCVAR-BSCHL
GLVAR T_GLVAR KTOPL VKONT VKONT
In-House Cash 0EVO 48520000 SI 40 / 50
IHCE
Centre
4.8.2.5.2 Transfer Postings Payables/Receivables
SAP specifications:
In this section you define the receivables and payables accounts to which the balances transferred from the current
account system are to be distributed.
Role of the object:
The balance of an account first transferred to a clearing account (clearing account general ledger) is then transferred
to the appropriate receivables/payables account, depending on its +/- sign. These accounts can be specified
separately for every clearing account. Netting of accounts is taken into consideration.
SAP guidelines:
184
SAP supplies example settings for general ledger accounts. Review these and adapt them to suit the chart of
accounts you use.
Technical name V_TBKKCCLR-GLACCT_CLR
Field type CHAR
Field length 10
SAP level Client
Transfer Postings Payables/Receivables
EVO Specifications:
Planned usage:
Area FI
Ownership Global
Select GL variant defined and enter a receivables and a payables account for every clearing account.
Chart of GL Account GL Account

accounts Receivables /Paybles Receivables/
Debit / Credit payables
GL Clearing Account Transfer Debit / Credit
V_TBKKCCL V_TBKKCCLR- V_TBKKCCLR-
V_TBKKCCLR-GLACCT_CLR R-KTOPL GLACCT_D GLACCT_C
48520000 I/Co IHC Clearing 0EVO GL Account Debit 48520000 *
Here are defined the accounts for IHC to
which the clearing and receivables / 0EVO GL Account Credit 48520000 **
payables are posted
Even if you do not require a
breakdown of receivables and
payables, you still have to specify a
clearing account. The entries in the
Customizing table for transfer postings
are also required. If these details are
missing, you cannot change the general
ledger group.
*Loan balances due to Vodafone Group Plc and its subsidiaries, analysed by the Group company to which they are
due. The dividends should match with those shown in account BA4400 Loans due from group companies, in the
184
books of the debtor company. The amounts should be agreed between companies on a monthly basis with
differences posted to the intra-group debtor or creditor suspense accounts.
**Loan balances due from Vodafone Group Plc and its subsidiaries, analysed by the Group company from which they
are due. The dividends should match with those shown in account BA4500 Loans due to group companies, in the
books of the creditor company. The amounts should be agreed between companies on a monthly basis with
differences posted to the intra-group debtor or creditor suspense accounts.
4.8.2.6 Maintain General Ledger Transaction for General Ledger Transfer
SAP specifications:
A general ledger transaction groups postings for several transactions in the current account system
into a single transaction that enables assignment to a general ledger account or posting type.
Role of the object:
Here you have to assign a general ledger transaction to each transaction type involved in the payment
transaction.
SAP guidelines:
Create the general ledger transactions you need and in the next step allocate the corresponding transactions of the
current account system to them. When planning general ledger transactions, ensure that all payment transaction
operations and all income related transactions are summarized to one general ledger transaction.
Attribute details:
Technical name V_TBKKCACT-GLACT
Field type CHAR
Field length 6
SAP level Client
Maintain GL Transaction
EVO Specifications:
Planned usage:
Within a GL variant, transaction types are grouped together by a GL transaction. Thus a GL transaction summarizes
several postings in the IHC sub-ledger enabling the assignment to a general ledger account or to the updating type.
184
Area FI
Ownership Global
Copy from the standard SAP GL transactions for the IHC variant for intercompany configuration

GL
GVar Tr. Desc.GL Variant Desc. GL Transaction
IHCE 0001 In-House Cash Center EVO Payments
IHCE 0002 In-House Cash Center EVO Temporary Postings
IHCE 1000 In-House Cash Center EVO Tax on Sales/Purchases
IHCE 1020 In-House Cash Center EVO Plus Debit Interests
IHCE 2015 In-House Cash Center EVO Treasury Deals Debit
IHCE 2200 In-House Cash Center EVO Cash Concen. Outflow Int.
IHCE 2210 In-House Cash Center EVO Cash Concen. Outflow Ext.
IHCE 2400 In-House Cash Center EVO IHC Payments
IHCE 4010 In-House Cash Center EVO Cred. Interest (Customer)
IHCE 4020 In-House Cash Center EVO Reimbursements
IHCE 4050 In-House Cash Center EVO IVA Addition
IHCE 6020 In-House Cash Center EVO Plus Credit Interests
IHCE 7015 In-House Cash Center EVO Treasury Deals Credit
IHCE 7200 In-House Cash Center EVO Cash Concen. Inflow Int.
IHCE 7210 In-House Cash Center EVO Cash Concen. Inflow Ext.
IHCE 7400 In-House Cash Center EVO IHC Receipts
IHCE 8010 In-House Cash Center EVO Deb. Interest (Customer)
IHCE 8020 In-House Cash Center EVO Charges
IHCE 8050 In-House Cash Center EVO IVA Reversal Current Year
IHCE 8070 In-House Cash Center EVO Loss on Receivables
IHCE 8080 In-House Cash Center EVO Loss on val. adj. rec.
IHCE 8090 In-House Cash Center EVO Interest income tax
IHCE 8091 In-House Cash Center EVO Reunification tax
Currency Changeover
IHCE 9000 In-House Cash Center EVO EURO
In House Cash Center
IHCE IHCE In-House Cash Center EVO EVO
IHCE IHCP In-House Cash Center EVO In-House Cash pays/recs
4.8.2.7 Assign Payment Transaction Type to General Ledger Transaction
SAP specifications:
Role of the object:
For the general ledger transfer, assign a general ledger transaction type to each transaction type in
the current account system.
184
SAP guidelines:
You can assign several payment transaction types to one general ledger transaction type.
Attribute details:
Technical name V_TBKKCTTP-TRNSTYPE
Field type CHAR
Field length 4
SAP level Client
Assign Transaction Type for Payment Transaction to GL Transaction
EVO Specifications:
Planned usage:
The transaction type is the internal representation of a business transaction. The attributes defined
with the transaction type control how the payment item is processed.
General ledger transaction for account determination for FI transfer - For this you must assign a
general ledger transaction to every transaction type of payment transactions.
Area FI
Ownership Global
Copy from standard SAP variant 0001 to variant created IHC the TA types below:
GVar TA Desc.GL Variant Description Trans. Type GL Desc. GL Transaction
Type Tr.
In-House Cash Center
IHCE 0150 EVO Bank transfer 0001 Payments
IHCE 1010 EVO Debit interest 8010 Deb. Interest (Customer)
IHCE 1020 EVO Plus Debit Interest 8010 Deb. Interest (Customer)
IHCE 1100 EVO Overdraft Interest 8010 Deb. Interest (Customer)
IHCE 1150 EVO Minus Credit Interest 4010 Cred. Interest (Customer)
IHCE 1300 EVO Direct Charges 8020 Charges
IHCE 2015 In-House Cash Center Treasury Deal - Debit 2015 Treasury Deals Debit
184
GVar TA Desc.GL Variant Description Trans. Type GL Desc. GL Transaction

Type Tr.
EVO
In-House Cash Center Cash Concen. Outflow Cash Concen. Outflow
IHCE 2200 EVO Int. 2200 Int.
In-House Cash Center Cash Concen. Outflow Cash Concen. Outflow
IHCE 2210 EVO Ext. 2210 Ext.
IHCE 2400 EVO IHC Payments 0001 Payments
IHCE 5110 EVO Credit Transfer 0001 Payments
IHCE 6010 EVO Credit Interest 4010 Cred. Interest (Customer)
IHCE 6020 EVO Plus Credit Interest 4010 Cred. Interest (Customer)
IHCE 6100 EVO Minus Debit Interest 8010 Deb. Interest (Customer)
IHCE 6110 EVO Minus Overdraft Interest 8010 Deb. Interest (Customer)
IHCE 7015 EVO Treasury Deal - Credit 7015 Treasury Deals Credit
IHCE 7200 EVO Cash Concen. Inflow Int. 7200 Cash Concen. Inflow Int.
IHCE 7210 EVO Cash Concen. Inflow Ext. 7210 Cash Concen. Inflow Ext.
IHCE 7400 EVO IHC Receipts 0001 Payments
In-House Cash Center Loss Val.Adj.
IHCE 8080 EVO Receivables 8080 Loss on val. adj. rec.
4.8.2.8 Maintain General Ledger Group
SAP specifications:

The general ledger group of a current account is criterion for account determination. With this you define the general
ledger accounts to which you post for the current account.
Role of the object:
Using general ledger groups you can summarize current accounts into account groups.
SAP guidelines:
Check to see how far you need to sub-divide the current accounts for transfer to the general ledger and
define the appropriate general ledger groups.
Note: Ensure to make an entry in the field general ledger group when you create an account. Do this by configuration
the field as a required field or having the field filled automatically. To this end there is an event during account creation
via which a function module can individually take on the automatic filling of the field general ledger group.
Attribute details:
Technical name V_TBKKCGRP-GLGRP
Field type CHAR
Field length 4
Modified:
SAP level 6/16/2017 5:41 PM Page 66 of Last modified by: Romo Navarrete, Pablo
184
Maintain GL Group
EVO Specifications:
G/L groups - using general ledger groups you can summarize current accounts into account groups. You assign an
account to an account group (relevant for general ledger transfer) when you create the account by maintaining the
appropriate field.
Planned usage:
Area FI
Ownership Global
Copy from standard SAP variant 0001 to variant created IHCE
GVar GLGr Desc.GL Variant Description GL Group

IHCE IHCP In-House Cash Centre In-House Cash pays/recs
4.8.2.9 Define GL Account Assignment: Current Accounts
SAP specifications:
Role of the object:

In this section you define which accounts are to be posted to first when the current account system items are
transferred to the general ledger. You can make these entries depending on the general ledger group, the general
ledger transaction and the account currency.
SAP guidelines:
Define the account assignments in such a way that all current accounts are included.
Enter the general ledger account to which the aggregated items are to be transferred (general ledger clearing
account) and also an offsetting account for the corresponding general ledger posting (for payment
transactions the payment transactions clearing account, for income-related transactions the corresponding
income account). Note that all transactions concerning a current account (payment and income-related) will
184
be transferred to the same general ledger clearing account. If you post cash deposits and cash payments as
payment items, treat these in the same way as income-related postings. In this case the offsetting account is
a balance sheet account "Funds".
If the general ledger transaction is tax relevant, select accordingly and enter the appropriate FI tax key,
depending on the sales tax rate.
To make entering the general ledger account assignment easier you can set default values by leaving the
appropriate key field blank. Note that the field to the left of the default field must have an entry. Priority
decreases from left to right. If there are several overlapping settings, the more detailed one counts.
Attribute details:
Technical name V_TBKKCGRP-GLGRP
Field type CHAR
Field length 4
SAP level
Define GL Account Assignment: Current Accounts
EVO Specifications:
In this step we define (in the in House cash centre) the account assignments in such a way that all current accounts
are included.
Planned usage:
Area FI
Ownership Global
Copy from standard SAP variant 0001 to variant created IHCE
GLGr GL Tr. CACur Desc.GL Variant ChAc ClearActGL OffsetAcct

The general General ledger The The
ledger group of transaction for currencies in offsetting
a current account which the account
account is determination for FI account is posted to
criterion for transfer. managed during
account For this you must transfer to
determination. assign a general the FI
184
With this you ledger transaction to general

define the every ledger. For
general ledger transaction type of payments
accounts to payment you usually
which transactions. enter a
you post for the clearing
current account. account
payment
transactions
and for
other
general
ledger
transactions
an income-
related
account.
IHCP All GL trans. Types In-House Cash EVO Clearing GL None
related Centre account
IHCP 0001 In-House Cash 0EVO 48520000 28510000
Centre
Centre
Centre
Centre
Centre
Centre
Centre
Centre
Centre
Centre
Centre
Centre
*48520000 - I/Co IHC Clearing Intercompany In House Cash Clearing. This account is within the group for
intercompany loans payable and is mapped to the Hyperion line B4500.ICB Loans Due to Group Companies. This
account is posted to with an intercompany trading partner. If the process runs correctly, then the balance on this
account at the month end should be zero (normal case). If the posting from the clearing account to Loans Due to
Group Companies is outstanding at the month end, no further posting will be necessary to ensure correct Hyperion
reporting based on the mapping to B4500.ICB (exceptional case). An adjustment will be required if the clearing
account has a balance which needs to be recorded under loans receivable (exceptional case).
184
**28510000 Loans Receivable From Group Companies and 48510000 Loans Due To Group Companies - the account
chosen will be a local decision based on whether the month-end position with VOCH is normally a payable or
receivable. The balance on the loan account configured needs to be reviewed at the month end to ensure that the
month end position is consistent with its location in the chart of accounts and the related Hyperion mapping. If
necessary, the OpCo should perform a GL transfer from the balance on the loan account used to the correct account
(28510000 or 48510000)
***Cash sweep clearings from bank statement, will use the 24XXXXXX12 'Other' Clearing account since the volume
of transactions does not merit a separate clearing account.
4.9 Configuring Component-Specific Master Data
4.9.1 Create Business Partner Roles in SAP In-House Cash
SAP guidelines

This application enables you to create, maintain and manage business partners, and use them for integration with
other functions.
SAP guidelines:
Create account holder: The account holder is the owner of the current account. Exactly one
account holder is assigned to each account.
Create authorized drawer: The authorized drawer is not the owner of the account. You can
assign several authorized drawers to each account.
Create correspondence recipient.
Create contact person: The contact person must be a natural person.
Attribute details:
SAP transaction BP
Technical name BUS_JOEL_MAIN-CHANGE_NUMBER
Field type CHAR
Field length 10
SAP level
SAP Easy Access Accounting Financial Supply Chain Management In-House Cash Business
Partners
This is referenced in detail in the MDA object definition paper Business Partner
EVO Specifications:
The Business Partners (BP) forms the one of the basis of intercompany settlements using In-House Cash Module
within Vodafone. The SAP In-House Cash (IHC) component is a solution that is used to manage the settlement of
184
intercompany settlements. The IHC component will sit within the VOCH and replace the existing Intragroup
settlement process. This document will define the meaning, usage and SAP features used within the In-House Cash
Module Business Partners. The EVO Business Partner will form the way that the OpCos and the In-House Cash
Centre of Vodafone (VOCH) will be related and linked. The business partner is a master data object used to store the
details of all of the Operating Companies that interact with one another.
4.9.2 Master Data: account creation in IHC
SAP guidelines

The account is the central element of the current account system. The system provides convenient entry options for
creating the account master records
Role of the object:
Create the accounts
SAP guidelines:
Choose Account Create.

Specify the bank area to which the account is to be assigned.
If necessary, change the opening date.
Specify the product to which the account relates.
If required, set the checkboxes to Offer and Deactivate Check Digit.
Enter a bank control key.
Choose Continue.
You can trigger manual account statements several times per day. However, this does not apply to mass runs. Mass
runs can only be started once a day because a day is the smallest possible unit for processing frequencies of account
statements. As soon as an account statement has been generated in a mass run, the system automatically increases
the date in the account by one day. This means that you are unable to generate a second account statement for this
date. Define the general ledger group for the general ledger transfer.
Attribute details:
SAP transaction F9K1
Technical name IBKK50-ACNUM_EXT
Field type CHAR
Field length 35
SAP level
SAP Easy Access In-House Cash Account Create
EVO Specifications:
The account is the central object of the current IHC account system.
184
The accounts within the current account system for the normal purposes of a current account (demand deposit
account). The components of a current account are supported, such as balance-based balancing and processing
payment transactions.
4.9.3 Create Customer / Vendor account - Intercompany
SAP guidelines

The account is the central element of the current account system. The system provides convenient entry options for
creating the account master records
Role of the object:
Create the accounts
SAP guidelines:
Choose Account Create.

Specify the bank area to which the account is to be assigned.
If necessary, change the opening date.
Specify the product to which the account relates.
If required, set the checkboxes to Offer and Deactivate Check Digit.
Enter a bank control key.
Choose Continue.
You can trigger manual account statements several times per day. However, this does not apply to mass runs. Mass
runs can only be started once a day because a day is the smallest possible unit for processing frequencies of account
statements. As soon as an account statement has been generated in a mass run, the system automatically increases
the date in the account by one day. This means that you are unable to generate a second account statement for this
date. Define the general ledger group for the general ledger transfer.
Attribute details:
SAP transaction FD01 / FK01
Technical name RF02D-KUNNR / RF02K-LIFNR
Field type CHAR
Field length 16
SAP level
SAP Easy Access Accounting Financial accounting Accounts Receivable or Accounts Payable
Master Record Create
EVO Specifications:
Planned usage:
For EVO an intercompany settlement is needed that the OpCos using in house cash must have a costumer / vendor
record. Being this in scope / responsibility of OTC and P2P, for in house purposes, when creating this master data its
required to create in this costumer vendor master record the trading partner for each one of the OpCos and also in
184
the payment transaction tab each OpCo with master data will have the bank details of the in house bank created and
the virtual bank account created for each one of the subsidiaries.
Area FI
Ownership Global
Change management
Create Costumer:
Update IHC bank details
Activate flag Payment Advice by EDI in the Payments tab of the company code details
The option Clear with vendor will be deactivated.
Create vendor:
Vendor master data of all participating companies must be updated with the relevant details for centralized
payments:
Address data (for check payments and correspondence, i.e. payment advices)
Reconciliation account
Partner bank connection - bank details
Partner bank type the payment program will pay the vendor via the previously predefined bank (IHC house
bank)
184
Payment methods - one internal payment method is to be used with no payment advices necessary
( payment method Z intercompany)
Payment terms
Remove flag Clearing w/ Customer Note this mean no intercompany costumers and vendors roaming
netting
4.9.4 Central bank reporting
SAP guidelines

Before you can run the report, you have to define the state central bank indicator in Customizing for Financial
Accounting (FI).
Role of the object:
184
In this activity, you define information using an indicator which is needed for reporting according to foreign trade
regulations for foreign payment transactions and which shows the reason for payment.
You must enter the indicator in the line item. The reasons for payment stored for the indicator is transferred when you
print the form or in the corresponding data medium exchange.
Attribute details:
Technical name V_T015L-LZBKZ
Field type CHAR
Field length 3
SAP level Client
Spro Financial accounting Accounts Receivable and Accounts Payable Business transactions
Incoming Invoices/Credit Memos
EVO Specifications:
Planned usage:
This is be referred in Configuration Rational OTC - chapter 2.4.2.1.2 - Posting keys (for invoices) where is made the
definition of the field needed when posting an invoice
Area FI
Ownership Global
4.10 Ongoing Setting Process steps

4.10.1 Current setting for updating the posting date for payment transaction and closing
4.10.1.1 Update Posting Date for Payment Transactions
SAP specifications:

In this section you increase the date on which the postings are executed in the system.
Role of the object:

This must always be done daily, even if no other balancing tasks are performed.
184
SAP guidelines:
Posting date of payment transactions:
The date used as posting date for all postings of internally and externally initiated payment transactions (you
can individually control the value date in payment transactions). Standing orders are also generated with this
date. You set this date to the following day by executing a posting cut-off.
You have the following options for this:
o You can set the posting cut-off manually. To do this, choose Periodic tasks Posting date
Payment transactions and specify the next posting date for each bank area.
o You can have the posting cut-off executed automatically by the system at a fixed time. You find the
settings for this in the Implementation Guide (IMG) by choosing Basic settings Bank area
Define bank area.
Attribute details:
SAP transaction F9B1
Technical name PDAT_NEW
Field type DATS
Field length 4
SAP level
Sap Easy Access Accounting Financial Supply Chain Management In-House Cash Periodic
Processing Posting Date Payment Transactions
4.10.1.2 Update Posting Date for closing manually
SAP specifications:

In this section you increase the date on which the postings are executed in the system.
Role of the object:

This must always be done daily, even if no other balancing tasks are performed.
SAP guidelines:
Posting date for the balancing postings:
The postings generated by the system as part of cash concentration and account balancing are posted with
this balancing date.
Attribute details:
184
SAP transaction FBL4

Technical name CDAT_ACT_N
Field type DATS
Field length 8
SAP level
Sap Easy Access Accounting Financial Supply Chain Management In-House Cash Periodic
Processing Posting Date Closing
To set this date, proceed as follows:
Choose Periodic tasks Posting date Closing and specify the bank area. The posting date for the
balancing postings is then set to the current posting date for payment transactions.
EVO specifications:
Each day, before processing the bank statements, actualize the date running the transaction FBL4
4.11 Reassignment of short term IHC call account positions to long term call
accounts
For the purposes of funding, depositing, hedging and intercompany settlements, OpCos will hold a short term call
(current) account with the VOCH (IHC centre).
Any cash swept to/from OpCo bank accounts will be aggregated by the VOCH and any net surplus/ deficit position
will be swept to VG. However, the intercompany settlements, which will update the IHC current accounts held by the
OpCos with the VOCH, will not impact the VOCH VG position (i.e. whilst VOCH IHC position should be zero, part of
this will be back-to-back with VG, part will be back-to-back between two OpCos.
On a monthly basis, OpCos short term balance (+ interest) with the VOCH IHC centre needs to be swept to the
OpCos long term loan (which is likely to be held with Vodafone Group or Vodafone Finance Limited). Primarily this is
to avoid withholding tax which would become due on any positions held for more than 364 days, and to aid month
end reconciliations. Where the OpCo has an underlying long term loan the OpCo will offset unfavourable loan interest
with cash generated rather than carry the cost of the loan (to deposit rate) spread. The VOCH short term position with
VG will be cleared down this driven by the OpCo drawing on their current accounts. This process is illustrated
below:
184
4.11.1 Define In-House Cash Centre as Bank Area
SAP specifications:

The bank area is the central organizational unit of current accounts and affects just about every unit of the system.
You determine certain defaults which will or can affect all accounts within the bank area.
Role of the object:

Define the bank area that you require for your organization and determine certain defaults which will or can affect all
accounts within the bank area. Within a bank area, complete and independent account management and account
processing takes place. This means there must be clear and unmistakable account numbers within a bank area. A
bank key (for example, in Germany the bank identification number) is assigned to each bank area. You normally
create an own bank area for every banking organization for which a bank key exists. You create accounts and
conditions specifically for a bank area. Note that within a bank area there must be clear and unmistakable account
numbers.
SAP guidelines:
SAP recommends that you create a bank area for each organization managed in the system which has its own bank
key. Generally, you will only need one bank area. The bank country to be entered (where the institute is located)
controls how the bank key is treated and which underlying control mechanisms apply. The bank country also
determines the maximum length of account numbers that the system uses in this bank area.
184
Attribute details:
Technical name IHC_V_BANK_AREA-BKKRS
Field type CHAR
Field length 4
SAP level Client
Financial Supply Chain Management In-House Cash Basic Settings Bank Area Define Bank Area
EVO Specifications:
Planned usage:
The bank area specified for EVO intercompany solution will have one location. Manage by VOCH the bank area will
be just one in the short term / transition solution, when VG isnt still in the EVO system. The final solution will
contemplate multiple Bank Areas one for each entity with which underlying loans are held i.e. VOCH, VGPLC, VFL,
VILSarl, VIHBV etc... It is organization unit in SAP for a self contained virtual in-house bank. It has its own
configuration and master data (accounts, conditions, products). Vodafone will have multiple bank areas globally and
this will be managed by the VOCH and Group treasury
Area FI
Ownership Global
Enter a bank area and the global settings. Take account the meaning and the values for the following fields:
Bank area currency: The bank area currency is usually the same as the local currency of the company code
to which the bank area is assigned.
Company code: Each company code is assigned to a bank area
General ledger variant: The GL variant defines how the transfer from bank area to FI general ledger takes
place. The variant can only be entered here if previously defined
184
Bank Description Bank Bank Exchange Company GL

Area Bank Area country Keys Rate Type code Variants
key
IHC_V_B IHC_V_BANK IHC_V_BA IHC_V_B IHC_V_BAN IHC_V_BAN IHC_V_
ANK_AR _AREA- NK_AREA- ANK_AR K_AREA- K_AREA- BANK_
EA- T_BKKRS BANKS EA- RATETYPE BUKRS AREA-
BKKRS BANKL GLVAR
IHCE EVO IHC Bank HU 99999999 M HU01 IHCE
Activate LOG and IHC active
4.11.2 Cash concentration Short term to long term call account - Transition and End
game
During transition period (when VG is not setup in the system has a company code) the cash concentration will be
done affecting only accounts in VOCH in house cash centre. For the transaction solution to work the OpCos in the
releases and VG will be setup with accounts in only one Bank area the VOCH one.
The end game will have multiple bank areas (as per 1.1) and the cash concentration functionality will work using the
OpCos accounts in the IHC centres (Short term with VOCH, Long term with the appropriate centre) At month end,
cash concentration will clear the accounts in the VOCH (ST loan accounts) and will update the Long term position in
the appropriate centre.
4.11.3 Cash Concentration
SAP specifications:
Cash concentration means that payment orders are generated either to be credited to or debited to accounts within
an account hierarchy you have created.
Role of the object:
Cash concentration is the object which allows funds and/or loan balances between IHC centres to be moved/re-
assigned from one entity to another.
SAP guidelines:
When you use the hierarchy type for cash concentration, you can clear or fill account balances. To do this, in the
hierarchy you define the required data for:
The minimum balance to which an account is filled.
184
The maximum balance, amounts above which are transferred to a superior account.
A trivial amount limit for the transfer of funds.
Attribute details:
SAP transaction F9H6
Technical name --
Field type --
Field length --
SAP level Client
Process steps:
Accounting Financial Accounting Financial Supply Chain Management In-House Cash Periodic processing
Cash Concentration new run Mass Run
EVO Specifications:
Planned usage:
Using Cash Concentration the VOCH IHC centre creates a transfer to the VG IHC centre. The VOCH would have
borrowed/deposited all the cash it received from OpCo back to back with VG. Therefore, this transfer, when released
to the GL, clears down the existing VOCH-VG position. This will be done by the cash concentration functionality
Area FI
Ownership Global
Transition phase Values should be setup in IHC accounts and Account Hierarchy based on the Master Data Object
definition for these two objects.
The bank area should be one IHCE

The IHC accounts should be created for the OpCos in scope for each release and also for VG in VOCH IHC
centre
Cash concentration will be processed by transaction F9H6 at month end
End Game Values should be setup following IHC accounts and Account Hierarchy based on the Master Data
Object definition for these two objects.
There will be multiple bank areas (as defined above)

The IHC accounts should be created for all the OpCos in scope in VOCH IHC centre and additional IHC
centres as required
Cash concentration will be processed by transaction F9H6 at month end, the account hierarchy should be
between two bank areas
184
The values of the cash concentration procedure for Group treasury and eTC to have that information are the ones
displayed using transaction SE16 and using table BKKIT
The selection criteria should be:
Bank area: VOCH bank area

Value Date Monthly range
Transaction Type :
2200 Cash Concen. Outflow Int.
7200 Cash Concen. Inflow Int.
Then download the results to an excel spreadsheet and send to Vodafone Group Treasury
184
The format and data is exemplified below. The data have the accounts that were sweep, the overlay accounts (LT call
accounts), the amounts and the dates:
Cash Concentration
Refer to Master data objects Account Hierarchy and IHC accounts
4.11.4 Reassignment of short term IHC call account other currencies to functional currency
short term call accounts positions
Any cash swept to/from OpCo bank accounts will be aggregated by the VOCH and any net surplus/ deficit position
will be swept to VG. However, the intercompany settlements, which will update the IHC current accounts held by the
OpCos with the VOCH, will not impact the VOCH VG position (i.e. whilst VOCH IHC position should be zero, part of
this will be back-to-back with VG, part will be back-to-back between two OpCos.
On a monthly basis, OpCos short term balance (+ interest) in other currencies different than Euro should be sweep to
a Euro short term call account within the VOCH IHC centre before the monthly sweep into the OpCos long term loan
(which is likely to be held with Vodafone Group or Vodafone Finance Limited).
4.11.5 Cash concentration Short term different currencies to functional currency call
accounts - Transition and End game
During transition period (when VG is not setup in the system has a company code) the cash concentration will be
done affecting only accounts in VOCH in house cash centre. For the transaction solution to work the OpCos in the
releases and VG will be setup with accounts in only one Bank area the VOCH one.
184
At month end, cash concentration will clear the accounts in the VOCH (ST loan accounts) in other currencies to Euro
ST call account.
Cash concentration doesnt work with different currencies. For having this the steps in the first phase will be
performed manually using payment order functionality.
Payment order
At month end the total balance from an OpCo of the ST call accounts from different currencies must be sweep to
functional currency ST call account:
The balance of non Euro call accounts must be accessed after account balancing (interests posted in these accounts)
With the selection criteria being described bellow:
The IHC centre is the VOCH one (in this example IHCE)
The currencies, selecting the multiple selection button, select the currencies that the call accounts are needed to
sweep to functional currency call accounts
Run the report, accessing all the balances in the accounts in foreign currencies
184
With the data retrieved we can have an updated balance of the foreign currency ST call accounts to be sweep to
functional currency call accounts
184
Afterwards the balances should be processed via Payment orders to a Euro ST call account in the same OpCo.
Using the payment order Internal, we process the balances from non functional currency to functional currency call
accounts in the same IHC centre and within the same OpCo following the steps below:
Bank area VOCH bank area

Account number the OpCos foreign currency accounts with balances
Transaction type Internal bank transfer
Transaction amount The total balance extracted in the transaction F970
Transaction currency Euro
Recipient Euro call account defined in the VOCH IHC centre for the OpCo
Process the transaction for each foreign currency account with balance held in the VOCH IHC centre
184
Note: This manual procedure should be performed until an automatic procedure is defined and created Extension.
The cash concentration functionality cannot be performed when using different currencies.
This extension should perform this steps automatically accessing at month end, before the cash concentration
between bank areas is executed.
The extension should access balances in foreign currencies for each OpCo call accounts in foreign
currencies at month end and automatically generate payment order to process this balances to a
Euro call account defined for that OpCo
4.12 Interest
To replicate arms length pricing, all internal/intercompany loans are subject in interest. The loans are priced by
counterparty (OpCo) and by term (Long Term (LT) vs. Short Term (ST)). A monthly interest rate is applied to both LT
and ST positions. ST deposits are applied an interest rate of EURIBOR flat and ST loans EURIBOR+12 basis points.
This rate is fixed at the beginning of each month (when the call a/cs roll over and applies for a month period at a
time. LT deposits are applied interest at EURIBOR flat also. LT loan positions are applied EURIBOR + margin (fixed
on a monthly basis) or a fixed interest rate applicable for the duration of the loan, as stated in the loan agreement. To
minimise the administrative burden, and avoid having to record a separate rate for each OpCo, the margin will be
recorded against the IHC current account, and will be used to adjust the standard table rate (Libor/Euribor).
The interest calculation should be based on the daily closing position (which can only be calculated after the cash
sweep per DB bank statement. To reduce the administrative burden, the interest should only be capitalised (added to
the loan) monthly.
184
SAP Configuration and Master data setup (see Conditions Master Data Document):
When the same rates need to be applied to several IHC accounts Short term loan accounts -
184
When different rates need to be applied to IHC accounts - of Long Term loan accounts with different interests applied
The product used is standard - IHC MAX That allows us to create the accounts supporting the business
requirements. In the area of the IHC accounts, product definition flexibly supports products and their special features
for every individual account groups. Products can be configured, step by step, much along the lines of a 'building
block' principle. An account is characterized by the attributes of the freely definable product assigned to it. Contained
184
in the product are the possible conditions, relevant transaction types and functions, and also the media with which the
OpCo has access to the account. You can create products in several versions, enabling that when IHC accounts are
created and conditions are linked to those accounts the system enables more or less flexibility in the creation.
The condition groups created depend on the different interests that Vodafone wants to apply to the accounts. If its
defined that all the Short term loan accounts will use the same interest rate, one condition group is created for all the
short term loan accounts.
Usually the ST interest rate will be a reference percentage EURIBOR Setup field in condition create transaction:
Type of Description Field usage: Values:

condition:
Interest calculation method - The interest

Interest Daily over balance
calculation method is defined by the quotients DAYS /
DAILY BASIS and leads as factor from the percentage
calculation to the time period-dependent percentage
calculation, the interest calculation variants.
Straight-line interest calculation: Amount = calculation
basis * percentage rate/ 100 * DAYS/ DAILY BASIS
Exponential interest calculation: Amount = calculation
basis * ( q ** (DAYS / DAILY BASIS) - 1 ) with the
compounding factor q = 1 + percentage rate / 100
and ** as potentiator.
Description for a condition. - Enter a description for Short Term Accounts

the condition to be created.
Currency Key - Currency key for amounts in the Currency of the accounts associated
system.
Interest Reference
Interest reference Euribor, Libor
For conditions depending on a reference interest rate
you do not enter the percentage rate directly in the See Example:
condition but rather a reference to a table in which the
interest rates are saved. Every change made to the
interest rate in the table leads to a change in the Loan Index
interest rate for the account.
184

condition:
Scaled/Interval Calculation - Use this field to define Value = 0 No Scaled/Interval Calculation

that different condition items should be applied,
depending on the account balance or number of
items.
Scaled calculation
The appropriate condition item is applied to the whole

balance or the whole number of items.
Interval calculation
The single condition item is only valid for the

individual part of the balance or number of items.
Scaled calculation with contact amount
The appropriate condition item is selected based on

the contract amount defined for the term agreement.
Markup/Markdown Reference Interest - Possible Markups / markdowns used with reference

interest markups/markdowns on the reference interest interests Euribor + Value
rate from the Reference interest rate table. You must
enter the interest mark-up/markdown in percentage See Example:
points (absolute). When you enter a markdown you
must enter a minus sign after the amount. Enter
markups without a +/- sign.
Loan Index
Long Term loan accounts with different interests applied:

condition:
Interest Percentage rate - Specifies the fixed interest rate of If interest rate is fixed fill the field with rate
a condition in percentage. This applies to some LT - For some long term loan accounts
loans; it does not apply to Short term loans.
See Example:
Loan Index
184

condition:
Description for a condition. - Enter a description for For each different condition enter a
the condition to be created. different name to differentiate.
Currency Key - Currency key for amounts in the Currency of the accounts associated
system.
Markup/Markdown Reference Interest - Possible Markups / markdowns used with reference

interest markups/markdowns on the reference interests Euribor + Value
interest rate from the Reference interest rate table.
You must enter the interest mark-up/markdown in See Example:
percentage points (absolute). When you enter a
markdown you must enter a minus sign after the
amount. Enter markups without a +/- sign.
Loan Index
Interest Reference
Interest reference Euribor, Libor
For conditions depending on a reference interest rate
See Example:
you do not enter the percentage rate directly in the
condition but rather a reference to a table in which
the interest rates are saved. Every change made to
the interest rate in the table leads to a change in the Loan Index
interest rate for the account.
The interest calculation should be based on the daily closing position (which can only be calculated after the cash
sweep per DB bank statement. To reduce the administrative burden, the interest should only be capitalised (added to
the loan) monthly. For this (as explained in the setup of the conditions) the Interest calculation method will be daily
and the capitalisation carried out monthly.
The interest rate is fixed for a period of a month on all call accounts (which is when they roll over generally) based on
EURIBOR. It is NOT a fixed rate of interest except in a few loan agreements i.e. VAI VL5Sarl
4.13 Non-invoice driven VOCH call account changes
4.13.1 Cash sweeps
The liquidity structure is designed so that all OpCo EVO cash (recourse only) is automatically swept (end of day) to
the VOCH, from which, in turn, it is swept on to Vodafone Group. These cash sweeps are illustrated with bold green
lines in bank account structure diagram below.
184
As the cash is being swept across legal entity it is critical that the intercompany positions between the entities is
appropriately updated. The EVO solution for the maintenance and settlement of intercompany positions is to use SAP
In House Cash (IHC).
There are two steps involved in the automation of intercompany updates for these physical cash sweeps:
1. Receive and process Deutsche Bank bank statement (updates cash position)
2. Update SAP IHC (updates intercompany position)
The design covering first step is detailed in section 1.1, and the IHC update is covered in 1.2.
Illustration of steps involved:

OpCo 1 does a payment run for 10, assume no other cash movements occur in any entities on this day.
End of day:
1. OpCo 1 receives DB statement showing that final transaction of day was an account sweep (funding the 10
spent settling vendors) :
a. Statement processing - Dr Bank, Cr Sweep Bank Clearing
2. VOCH receives a DB statement showing that 10 was swept from its account to OpCo 1 (IHC account
updated):
a. Statement processing Cr Bank Dr Sweep Bank Clearing
b. IHC updated Opco1 -10
184
3. Final transaction on VOCH statement shows 10 sweep covering the OpCo 1 funding
a. Statement processing Dr Bank Cr Sweep Bank Clearing
b. IHC updated VG +10
4. VG receives DB statement showing 10 was swept from its account to VOCH (Cr Bank Dr Sweep Bank
Clearing)
a. Statement processing Cr Bank Dr Sweep Bank Clearing
b. IHC updated VOCH -10
5. VOCH IHC centre periodic processing executed:

a. Statement sent to Opco1 Dr Sweep Bank clearing Cr VOCH loan
b. GL transfer (step 2 above) Cr Sweep Bank clearing Dr Opco1 loan
c. GL transfer (step 3 above) Dr Sweep Bank clearing Cr VG loan
6. VG IHC centre periodic processing executed:

a. GL transfer Dr Sweep bank clearing Dr VOCH loan
4.13.2 Bank statement configuration OpCo
For updating the G/L accounts in the OpCos ledger, we need to define first how the system will be setup for when the
bank statement is received and the business transaction code for cash sweep identified. There are two steps in the
OpCo configuration for receiving bank statements:
1 - when the OpCo receive the bank statement from D.B. with the transaction code for cash sweep
2 - when the OpCo receives the internal IHC bank statement with transaction code for cash sweep.
The objective is to have all movements related to an OpCo reflected in the same G/L account, being the short term
loan account with VOCH.
4.13.3 Configure the Electronic Bank Statement
This fulfils the requirements for correctly posting all business transactions submitted by the FI-BL module as well as
in-house cash centre by means of electronic bank statement.
This document will only focus on the correct posting of the sweeps when the Bank statement is received by the OpCo
s, both from D.B. and from IHC for when the OpCos receive the bank statement internally.
SAP guidelines:
There are some steps to be carried out:
Create account symbol: Specify G/L accounts (such as bank, cash receipt, outgoing checks) to which
postings are to be made from account statement. You assign account symbols to the G/L account
numbers.
Assign accounts to account symbols: Define postings to be triggered by possible transactions in the
account statement (such as bank transfer, debit memo).
In the posting specifications debit -> credit that you define here, use the account symbols from the first
step, not the G/L account numbers. This prevents similar posting rules being defined several times, the
only difference between them being the accounts to which postings are made.
Create keys for posting rules: The posting rules represent typical posting transactions for the bank
statement. A list of assignments where one external transaction code is assigned to one posting rule is
called a transaction type.
184
Define the posting rules. The account determination takes place via the posting rule. This provides the
information required for posting (posting key, accounts, document type).
Create a transaction type
Assign bank details, for which the account statements are to be imported, to a transaction type:
Assign transaction types to group banks with identical external transaction codes.
Assign the business transactions to these posting rules dependent on the transaction type.
Assign the bank accounts to the transaction types.
Note: Make a note of the chart of accounts assigned to your company code. The company code/chart of accounts
assignment is in the IMG under Financial Accounting General Ledger Accounting G/L Accounts Master Data
Preparations Assign Company Code to Chart of Accounts.
EVO Specifications:
Planned usage:
The bank statement files, provided from interface FI-TCM-IF-1 (EVO Bank statement input interface Deutsche Bank
to SAP) can be imported into the SAP system where they are automatically processed. To do this, you run the
program that imports the files generated into the SAP System or, more specific, into the bank data memory. During
conversion, data in these files is supplied with SAP-specific information, such as the chart of accounts and company
code, for further processing. After the import transaction is completed, the data in the bank data memory is analyzed.
The system tries to identify the individual business transactions and filter out the information necessary for posting
(e.g. document numbers) from the note to payee fields on the bank statement.
If the necessary information can be interpreted, the system will automatically post the transactions using batch input
or a call transaction.
By making configuration settings, you ensure that all business transactions of which your bank informs you (via the
electronic bank statement) are posted correctly in the system. The following steps contain the information you require
to be able to configure the electronic statement.
4.13.4 Create account symbol
Freely definable key for an account symbol. The posting details contain account symbols instead of accounts. The
account symbol is defined by the user when configuring the electronic bank statement.
Role of the Object:
The Account symbol specifies which G/L account is posted to. After any modifications that may exist, the account
symbols lead to one account.
Attribute details:
Technical name V_T033I_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
184
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
EVO Specifications:
Planned usage:
To create account symbols related to the outgoing and incoming cash sweeps. Each account symbol should relate to
one G/L account. We will create an account symbol for cash sweep which we can use when defining the posting
rule to post financial documents to a G/L account. An account symbol is necessary for each G/L account we wish to
post to.
Area FI
Ownership Global
For cash sweep purposes for the GL accounts described below an account symbol will be defined:
Cash sweep clearing account
In the transaction to create account symbols
Select new entry.
Account Text
V_T033I_EBST-KTOSY V_T033I_EBST-LTEXT
Loans due to Group companies Loans due to Group companies
Loans to Grp Cos Loans to Group companies
Pay/Rec clearing Pay/Rec clearing
IHC call account IHC call account
Cash sweep clearing Cash sweeps
4.13.5 Assign accounts to account symbol
Assign the G/L account to the account symbol created above
Role of the Object:
After assigning G/L account to the account number the account symbol leads to G/L accounts. First create account
symbol, then in this step assign account symbol to G/L account.
Attribute details:
184
Technical name V_T033G_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
EVO Specifications:
Planned usage:
In the case of bank accounts, the system allows numbers to be entered in a generic format, using + signs for the
static numbers. The system replaces these plus signs with the G/L account number that is maintained for the house
bank. So, to simplify the maintenance of the configuration, EVO system can be configured by entering the account
number generically by entering a series of + signs. It will simplify procedures when we create/change a new bank
account, the system will automatically recognize the bank accounts if the G/L account number is maintained for the
house bank.
For the bank clearing accounts, they can either be entered with the full G/L account number or part of the account
number and complete the field with + signs - Cash sweep clearing account (+++++++09)
Also VOCH will be considered as an OpCo when receiving the bank statement from
This can be implemented as the clearing accounts will be defined with the same account number logic for all OpCos
- 24XXXX09 Cash sweep clearing account.
Area FI
Ownership Global
Account G/L Account Number

Account Symbol Currency
modification
V_T033G_EBST- V_T033G_EBST- V_T033G_EBST- V_T033G_EBST-
KTOSY KOMO1 KOMO2 KONTO
Loans to Grp Cos + + 48510000
Loans due to Group + + 28510000
companies
Pay/Rec clearing + + 24++++12
Call account VOCH + + 24++++10
Cash sweep clearing + + 24++++09
184
4.13.6 Create Keys for posting rules
This field specifies the rules for posting in the general ledger and sub ledger.
Role of the Object:
Assign posting rules to possible transactions in account statement file. In this activity you enter descriptions for the
necessary posting rules.
Attribute details:
Technical name V_T028D-VGINT
Field type CHAR
Field length 4
SAP level Client
EVO Specifications:
Planned usage:
To post the cash sweep in the cash sweep clearing account we need to create a posting rule key and subsequently a
posting rule.
Area FI
Ownership Local
Create posting rules in Customizing for Bank Accounting. Posting rules are represented in the system by a non-bank-
specific code (Z010 for Cash Sweep IHC and Z011 for Cash Sweep DB ).
Posting Key Text

V_T033G_EBST-KTOSY V_T028D-TXT20
Z010 Cash Sweep in - IHC
Z011 Cash Sweep in - DB
Z012 Cash Sweep out - IHC
Z013 Cash Sweep out - DB
184
Posting Key Text

Z014 Deb. Interest
Z015 Cred. Interest
Z016 Treasury Deals Credit
Z017 Treasury Deals Debit
Z018 Payments Out
Z019 Payments In
Z020 Charges
4.13.7 Define posting rules
Create posting specifications for each posting rule.
Role of the Object:
You use the posting specifications to specify how a certain business transaction is to be posted in the G/L accounts.
Attribute details:
Technical name V_T033F_EBST-EIGR1
Field type CHAR
Field length 10
SAP level Client
EVO Specifications:
Planned usage:
When defining a posting rule, you must specify how each business transaction that is transmitted by electronic
account statement (for cash sweep) is posted in EVO system.
In EVO system posting specifications consists of one or two posting records debit -> credit, where the first posting
record is called posting area 1, and usually represents a G/L account posting (Bank -> clearing account). That is the
posting record that we are going to us.
These posting transactions affects bank accounting only.
Area FI
Ownership Local
184
Enter account symbols rather than the actual account names in posting specifications. Those are already define in
section (Create account symbol)
We will use standard SAP posting area:
posting area 1 (bank accounting or G/L accounting)
Posting Posting Posting Posting Acct Doc. Posting

Rule Area Key (D) Acct (Debit) Key (C) (Credit) Type Type
V_T033 V_T033F V_T033 V_T033F_ V_T033F
V_T033F_E F_EBST _EBST- V_T033F_EBS F_EBST EBST- _EBST- V_T033F_EB
BST-EIGR1 -EIGR2 BSCH1 T-KTOS1 -BSCH2 KTOS2 ATTR1 ST-ATTR2
40 IHC CALL CASH ZW
Z010
1 ACCOUN 50 SWEEP 1
40 IHC CALL CASH ZW
Z011
1 ACCOUN 50 SWEEP 1
40 CASH SWEEP IHC CALL ZW
Z012
1 50 ACCOUN 1
Z013 1 40 CASH SWEEP 50 BANK ZW 1
4.13.8 Define Search String for Electronic Bank statement
Search strings establish rules that increase the possible number of direct clearances when the electronic bank
statement is uploaded.
Role of the Object:
The system will check if search strings exist and based on the rules established will redirect the entry that the original
posting rule may have applied. The item may be cleared directly and reduces the number of instances that post
processing is used. Depending on the note to payee field,, the search string may be used to fill other fields such as
cost centre or posting rule.
SAP Guidelines
Define the search string, then define mapping in order to eliminate characters that may have been added to the
documents or other information in the bank statement. Several strings may be defined per bank account and
interpretation algorithm.
Attribute Details
Technical name V_TPAMA-PANAM
Field type CHAR
Field length 20
Modified:
SAP level 6/16/2017 5:41 PMClient Page 100 of Last modified by: Romo Navarrete, Pablo
184
Statement Define Search String for Electronic Bank Statement
4.13.9 Create transaction type
External transactions (also known as business transaction codes) are bank-specific codes for business transactions,
each of which involves a different type of payment. It will be also used for internal transactions Intercompany
settlements.
Role of the Object:
The external transaction code is issued by banks in the electronic bank statement or using the in house cash
functionality (producing and importing bank statements internally). The SAP system requires this code in order to
identify the business transaction. It converts the bank (also in house bank)-defined codes into its own system-internal
transaction codes (known as posting rules), which in turn trigger certain specific posting transactions in the system.
SAP Guidelines:
Group together the bank accounts which contain the same external transactions in one transaction type. You can
thereby reduce the processing work involved in Customizing for external transactions.
Attribute details:
Technical name V_T028V-VGTYP
Field type CHAR
Field length 8
SAP level Client
EVO Specifications:
Planned usage:
184
EVO global solution is supported by one banking partner. The transaction codes will be defined locally with inputs
from the D.B.. For this create two transaction types. This will allow for future changes and scalability:
MT940
In-House
For clarity it would be better to maintain 2 transaction types. One for D.B. bank statement and one for I.H.C.
statements. The advantage of this grouping is that you do not have to allocate the external transaction codes of the
banks (business transaction codes) to internal SAP posting rules for every individual bank but rather can make this
allocation just once per transaction type. After defining the transaction type it must be allocated each of the house
banks to a transaction type.
Area FI
Ownership Global
Define transaction types (one for DB and other for IHC) in order to group together banks with the same external
transaction codes (all banks of the same type - DB)
Select new entry.
Transaction Type Posting Area

V_T033F_EBST-
V_T028V-VGTYP EIGR2
MT940 SWIFT MT940
IN HOUSE IN HOUSE
4.13.10 Assign external transaction type to posting rules
External (or internal using in house cash) transactions (also known as business transaction codes) are bank-
specific codes for business transactions, each of which involves a different type of payment
Role of the Object:
The external transaction code is issued by banks or in house bank in the electronic bank statement. The SAP system
requires this code in order to identify the business transaction.
SAP Guidelines:
If the bank makes the bank statements available in SWIFT MT940 format, then the external transaction is a business
transaction code. In Customizing you can assign different external transactions to a transaction category. These
transactions are posted according to the same posting rules.
Attribute details:
184
Technical name V_T028G-VGEXT
Field type CHAR
Field length 27
SAP level Client
EVO Specifications:
Planned usage:
For cash sweep from D.B. MT940 will be subject to localizations. For recognizing the reconciliation of cash pooling
items and the references, the system can use GVO codes to reconcile cash sweep transactions. In general, the
system will know that a transaction is a sweep related entry by the internal "GVO" code in the beginning of field 86:
833.
For cross border sweeps, some country specific information will appear in field 86 subfield ?00 but the key
information is usually found in subfield ?20-?29 where the following logic applies:
ECP[Target Name][Source Name]NNNYYMMDD where [Target Name] - name of target account, max 11 char
[Source Name] name of source account, max 11 char NNN - internal DB number YYMMDD - date
The aspect that can be normally controlled is the [Target Name] and [Source Name].
Regarding domestic sweeps (overlay structure in country), the logic is, however, slightly different due to in-country
back end systems (and not done by the cash pool engine which controls the cross border sweeps). In general the
logic for field 86 ?20-?29 are the following:
DB-TRANSFER [target account number] [source account number]
These configuration enable the system to convert the bank-defined codes into its own system-internal transaction
codes (known as posting rules), which in turn trigger certain specific posting transactions in the system. Please see
Business transaction codes used by D.B. below. This will require configuration subject to localizations:
BTC Bank
In this step we define the algorithm used to do, for each business transaction, to do the automatic reconciliation
against the open items. The note to payee fields in the electronic bank statement contains information relevant to
clearing open items.
The interpretation algorithm allows the EVO system to search for incoming and outgoing payments in the bank
statement, based on information supplied by the customers and/or the house bank and entered in the note to payee
lines in the bank statement.
184
For cheques we use the cheque number. For incoming/outgoing payments we use the Document number / Reference
document number
Area FI
Ownership Local
Define transaction types in order to group together banks with the same external transaction codes (all banks of the
same type DB and In House).
Select MT940 transaction type (D.B. Business transaction codes)

Select new entry.
External business +/- sign of the Posting Rule Interpretation

transaction incoming amount algorithm
V_T028G-VGEXT V_T028G-VOZPM V_T028G-VGINT V_T028G-INTAG
833 + Z011 -
833 - Z013 -
For in house cash:
Select IN HOUSE transaction type (IHC Business transaction codes)

Select new entry.
External business +/- sign of the Posting Rule Interpretation

transaction incoming amount algorithm
IHC transaction -
defined Z010 -
IHC transaction -
defined Z012 -
4.13.11 Assign bank accounts to transaction type
Allocate each of the house banks to a transaction type already created
Role of the Object:
Banks are identified by specifying bank keys and external or internal account numbers. To do this, select the step
Allocate banks to transaction types.
184
Attribute details:
Technical name V_T028B-VGTYP
Field type CHAR
Field length 8
SAP level Client
EVO Specifications:
Planned usage:
Banks are identified by specifying bank keys and external account numbers. Evo system configuration will have the
same transaction type (MT940) for all accounts in EVO scope (D.B. accounts) and transaction type (IN HOUSE) for
all the accounts - virtual bank accounts created in In House cash module scope.
Area FI
Ownership Local
To configure, select the step Allocate banks to transaction types.
Select new entry.
Bank key (usually Bank account Transaction type

bank number) number
V_T028B-BANKL V_T028B-KTONR V_T028B-VGTYP

405081 11001242 MT940
300070024 1234567 MT940
Note: The previous table is just be filled with the bank key and account numbers during the build phase when creating
the external bank accounts for each country.
For In House cash:
184

bank number) number
99999999 + IN HOUSE
4.13.12 Bank statement configuration IHC
When IHC receives a bank statement with the sweeps it has to update the IHC accounts. For the system to support
this process the configuration steps are the following.
4.13.13 Central cash receipt / Incoming bank statements IHC
4.13.13.1 Set Up Connection to IHC in FI
In FI, you must set up a link to the In-House Cash interfaces for central incoming payments.
Role of the Object:
Link between IHC and the incoming statements
Attribute details:
SAP transaction FIBF
Technical name TBE22-PRDKT
Field type CHAR
Field length 8
SAP level Cross - Client
Activities
1. In the FI system, start transaction FIBF.
2. Choose Settings -> Identification -> Partners.

Enter IHC as a partner.
3. Choose Settings -> Products -> ... of a partner -> Edit.

Enter IHC as a partner product.
4. Choose Settings -> P/S function modules -> ... of a partner.

For event 00002810 enter the function module BKK_IHB_BASTA_IN_CHECK
5. Choose Settings -> Process function modules -> ... of a partner.

For the process 00002810 enter the function module
BKK_IHB_BASTA_IN_POST.
184
EVO Specifications:
Planned usage:
IHC should be defined in this transaction to be able to process the incoming bank statements
Area FI
Ownership Global
Product Partner
TBE22-PRDKT TBE22-PARTY
IHC IHC
4.13.13.2 IHC Account Determination from External Bank Account
In this IMG activity you define the data that the system requires to find the responsible in-house cash centre for an
incoming account statement and to post the items there.
Role of the Object:
During posting the system uses the account statement date as posting date and the value date of the respective
account statement item as value date.
If the posting date is in the future, the system creates a planned item provided no currency conversion takes
place. If a currency conversion takes place, the account statement date must be in the past or be the same
as the payment transaction date so that the system can process the account statement item.
184
If the posting date is in the past or is the same as the payment transaction date, an item is created in the in-
house cash centre. During the general ledger transfer the system determines the posting period based on the
posting date.
The in-house cash centre manages a separate account at the in-house cash centre bank for each company
connected.
Attribute details:
Technical name V_TBKKIHB6-BANKL
Field type CHAR
Field length 15
SAP level Client
Financial Supply Chain Management In-House Cash Account Management Payment Processes in In-House
Cash Central Cash Receipt / Incoming Bank Statements
EVO Specifications:
Planned usage:
To define the data that the system requires to find the responsible in-house cash centre for an incoming account
statement and to post the items there. We need to link the IHC account with the bank statement that we are receiving.
For that, for each bank partner account we link to an account and bank area in the system.
Area FI
Ownership Global
1. Choose New Entries.
2. For each entry, enter the house bank of the in-house cash centre in the first three columns (bank number -
IHC, bank account - IHC, currency- IHC account currency). You only have to enter the currency of the house
bank account if you have several foreign currency accounts with identical account numbers at the house
bank.
3. In the following two columns, (bank number and partner bank account D.B. account), enter the bank details
of the paying partner.
4. In the following two columns (bank areas - IHCE and account number see master data IHC account) enter
the account of the in-house cash centre that the incoming payments are to be posted to.
184
Save your entries.
The system proceeds as follows for the account determination:
1. It searches for an entry where the first five columns (house bank, house bank account, house bank account
currency, partner bank, partner bank account) agree with the data of the incoming account statement. When
it finds an entry, it creates an item for the account assigned in the in-house cash centre.
2. If it does not find an entry, the system searches for an entry without bank partner details where the first three
columns agree with the data of the incoming account statement. When it finds an entry, it creates an item for
the account assigned in the in-house cash centre.
The system for the bank number that is in the bank statement, it will update the IHC account number defined in the
configuration using fields in the MT940 for the match:
?3030070070010?3110553000000
Example of MT940 with fields completed:
IHC MT940
4.13.13.3 Set Up Account Determination for Incoming Payment
In this IMG activity you specify the FI account and In-House Cash Centre to which you want to post the inbound bank
statement.
Role of the Object:
Specify the FI account and In-House Cash Centre to which you want to post the inbound bank statement. You also
define a header account for payments for which the system was unable to automatically determine a recipient.
Attribute details:
Technical name IHC_DB_CL_XBS-BUKRS
Field type CHAR
Field length 4
SAP level Client
184
EVO Specifications:
Planned usage:
IHC should be defined in this transaction to be able to process the incoming bank statements
Area SPRO
Ownership Global
CoCd House Account Bank FI Acct Header account

Bank ID Area in IHC
House Account IHCE IHC Payments for which the system was not able
bank number accounts to automatically determine a recipient are
short key of OpCo posted to this account VOCH account
Company s see dummy account
codes of the master
OpCos data IHC
accounts
documen
t
4.13.13.4 Define Transaction Types for Incoming Payment
In this IMG activity you determine how incoming bank statements are processed and updated.
Role of the Object:
This involves defining the transaction types dependent on the bank area and different bank statement details. If you
have charge items, the transaction type for charges is used for posting. A requirement is to have defined the
transaction types and set up account determination for incoming payments.
184
Attribute details:
Technical name IHC_DB_CL_XBS-BUKRS
Field type CHAR
Field length 4
SAP level Client
EVO Specifications:
Planned usage:
We have to use the BTC business transaction code that is coming with the bank statement and associate them to
an IHC transaction type already created (standard) for cash sweeps. Also define the Bank area (IHCE VOCH IHC
centre)
Area SPRO
Ownership Global
Bank Area TransTy BTC Cred/De Transact Header account

p b
2210 and 833 Define if EXTPAY This transaction type is used to post payment
7210 cash orders from the charges for an account
cash sweep is statement -leave blank
IHCE sweeps debit or
credit by
transacti
on code
184
4.13.13.5 Conclusion:
Assign Transaction Type for Payment Transaction to GL Operation when this step is done we associate Transaction
Types (e.g. 2210 Cash Concen. Outflow Ext.) to a GL operation.
Also when a GL transfer from IHC accounts is done we define the account for Transfer Postings
Payables/Receivables. We define in this step (see configuration rational) the IHC clearing account and the GL
Account Payables/receivable (defined for the OpCos and with trading partner per item there for reporting purposes
(intercompany) if not define GL Account IHC Payables/receivable for each OpCo.
What will append after these steps have been made is (example of a cash sweep from OpCo A to VOCH):
1. OpCos receive external bank statement Credit by cash sweep business transaction code to D.B. GL bank
account and Debit in Cash sweep clearing account - because of posting rules setup
2. IHC receives bank statement per business transaction code (cash sweep) will post item in IHC account of
correspondent OpCo
3. IHC will debit PAY clearing and debit IHC clearing defined in the configuration Transfer Postings
Payables/Receivables step
4. At the end of the day with the process step balance sheet preparation the IHC clearing account will be
debited and the IHC payables will be credited (showing there in the GL by OpCo the amount that VOCH owns to
the OpCo) IHC clearing account cleared at this moment
5. When bank statement run processed, internal bank statement will be sent to OpCo and processed Debit
Short term loan account (opposite to IHC payables account) and credit in Cash sweep clearing account (account
cleared) because of posting rules setup
6. At the end GL Accounts not cleared
a. OpCo level - Short term loan account with debit amount
b. IHC centre GL Account GL Account Payables/receivable with credit amount
4.14 Treasury (eTC) transactions with loan settlement

In Vodafone, treasury is a centralised function and as such, when required, recourse OpCos executes internal
treasury deals with Group Treasury (eTC is used to capture treasury deal attributes). Sometimes, part or all of the
treasury deal is settled as a book entry (no physical cash flows), where this is the case the intercompany position
needs to be affected.
4.14.1 Payment Items
Payment items are individual posting items on a current account. These can either come from internally initiated
payment transactions (entered directly or during posting of a payment order) or from externally initiated payment
transactions.
Role of the Object:
An item can be posted, parked, or placed in post processing. The status "parked" means that it has already been
assigned to an account but is not yet included in the account balance.
A payment item is a one-sided turnover on a current account, representing either a credit or a debit.
184
A payment item can consist of more than one position,. this can be the case, for example, with account balancing
items. Items created internally and items transferred from the payment transaction system always consist of only one
position/item. It is possible, however, to create one or more additional positions (such as charges, tax or interest
penalty) during posting.
Every payment item comprises information regarding:
The transaction type describing how the item was updated.
The medium via which the item or the payment order belonging to the item was brought to the bank.
The payment method with which the corresponding item was forwarded.
If customer fields were maintained in Customizing for the bank area, they are also available and transferred from the
system to the bank statement.
You can differentiate payment items according to the following criteria:
Status: Depending on whether the item is in post processing or posted, there are various options for
editing the item.
The account to which the item was posted: CpD (suspense), clearing account, other accounts.
Attribute details:
SAP transaction --
Technical name --
Field type --
Field length --
SAP level Client
Steps defined in TCM configuration rationale version 1.6 (Payment item is a transaction in user menu). Authorizations
need to be setup.
EVO Specifications:
Planned usage:
For update the in IHC accounts with internal treasury deals between OpCos and Group Treasury an interface
inbound - FI-TCM-IF-6 - Interface to SAP from eTC - Interface to update SAP with eTC Treasury deals - will be built
update the payment items directly the fields in SAP.
These payment items, when processed, will update the IHC accounts with all of the treasury deal that are settled as a
book entry and the intercompany position needs to be affected
Workaround: If the interface isnt build those treasury deals can be posted manually in the payment item transaction
by a responsible person role.
The interface or manual posting as to process as follow:
1. Process transaction in In House cash - Account Management Payment Item Create.
184
2. Specify the transaction type with which the item is to be updated Treasury transaction type
3. Define bank area IHCE
4. Account number of the respective OpCo involved in the treasury deal see Master data IHC account object
document.
5. On the item entry screen, specify the value date of the posting and the posting amount. It can also be enter
payment notes (description).
6. For further processing we can choose following options (Compliance and Control for SOX):
a. Post the item, depending on the transaction type, the system runs the appropriate checks (such as
account, limit, check (banks only), business partner, locked transaction type). If its defined a minimum
deposit on the account (see Master data IHC account object document) and activated the limit check, the
system also checks the minimum deposit when it checks the limits.
b. It is still possible to first park the item (interface or manually we can setup for a role to process and park
and other person role to review items and post), which can then be processed in post processing. If its
activated the (amount-dependent) principle of dual control for the creation of payment items, the payment
item is parked with the Control status. This must then be released by another user with appropriate
authorization. To post process these items - Account Management Payment Item Release. The
system lists all the items that have not yet been released. Then we re able to review and release a
payment item by choosing Release.
Note1: For Interface from eTC to SAP the field structure, tables affected, length and type of fields will be described for
mapping from eTC information that is sent to SAP.
Note2: For Short term loan account and long term loan accounts conversion purposes this functionality
should be used to update the balances of the IHC accounts when Go-Live
Area FI
Ownership Global
No Values process step
5. Finance FI-BL
The SAP FI-BL component is a solution that can be used to manage the bank master data, cash balance
management and the creation and processing of incoming and outgoing payments. It is possible to freely define all
country-specific characteristics, such as the specifications for manual and electronic payment procedures. The data
relationship with the bank will be made by this component.
The data exchange provided in these files is supplied with SAP-specific information, such as the chart of accounts
and company code, for further processing.
184
One of the key functionalities of this module is importing the bank statement. After the import of the bank statement is
completed, the data is stored in the bank data memory in SAP, where it is then analyzed. The system tries to identify
the individual business transactions and filter out the information necessary for posting in the bank data memory, for
example document numbers, from the note to payee fields or reference field on the account statement (interpretation
of the note to payee).
If the necessary information can be interpreted, the system will automatically post the transactions (using batch input
or a call transaction). All line items are usually posted automatically in line with the posting rules.
Statistics show that up to 95% of customer data can be posted automatically in the SAP R/3 System. The system
offers convenient tools for further processing of line items that are not posted.
The Evo design is to use FI-BL for the relationship with the banks, for external settlements. The decision to use this
module will support:
- Single European Payments Area (SEPA) initiative which will mean that all Euro payments made to other EU
participating states will be charged at a rate close to the local Automated Clearing House (ACH) rates (i.e.
domestic payments)
- Using FI-BL for external settlements instead of IHC will facilitate and solve the legal issues raised in some
countries
- Will provide full visibility to the VF entities over their settlements and reconciling items
- One Bank One system simplification of relationships reducing costs to Vodafone.
Vodafone As Is:
Vendor Customer Vendor Customer Vendor Customer
Cash Cash Cash Cash Cash Cash
Bank A Bank B Bank C
Payment file Bank Statement Payment file Bank Statement Payment file Bank Statement
System A System B System C
184
OpCo A OpCo B OpCo C
Vodafone To-Be:
Vendor Customer
Cash Cash
Deutsche Bank
Payment file Bank Statement
FI-BL
Vodafone
EVO System
OpCo A OpCo B OpCo C OpCo ...
Implementation of the FI-BL component for VF will:
Standardise process for all OpCos

Improve audit trail visibility through the use of the same system for all Vodafone entities in EVO
scope (data control and trail since all the data is based in the same system)
Centralized maintenance lowering cost
Significantly reduce resourcing requirements by simplification of processes
184
Lower Vodafones switching costs through standardisation of payment file formats & processes
Increased process automation in OpCos
Introduce latest banking solutions to enable real time reporting and control
Eliminate manual allocation/ reconciliation
Support, with the data relationship being made by one system one bank, to centralise volumes with
one bank to obtain best pricing
5.1 Set Country-specific checks
For all countries with which your company maintains business relationships, you must include rules for checking the
following data:
Bank data
Postal data
Control data
This data is then checked during master data maintenance to ensure it meets the country specific requirements.
Role of the Object:
To enable all bank master data to be checked during master data maintenance.
Attribute details:
SAP transaction OY17
Technical name V_005_B-LAND1
Field type CHAR
Field length 3
SAP level Client
SAP Netweaver General settings Set countries Set country-specific checks
EVO Specifications:
Planned usage:
Check and maintain table to control creation of bank master data. The check rules will be defined with DB to provide
EVO the control of the master data converted and uploaded in the system. The system enables to check the right
number of digits.
184
Area FI
Ownership Global
Check the configuration table with the data provided by DB.
In country specific settings, bank key will be set to 1 ie. Bank number.
In the formal checks we have to define the checking rule - which determines how the check is to be carried out.
Predefined checks are started using keys 1 to 8. The system checks for numerical entry, length of entry and spaces in
the entry. Using key 9, you can activate a special country-specific check. The entry is checked against a template
defined in the program.
The logic for that check is defined in the table bellow that provide Vodafone the right number of Bank account
numbers throughout Europe .The International Bank Account Number (IBAN) has been developed to identify bank
accounts in a cross-border context. Although the IBAN is an international standard, some elements of the
IBAN are defined at the national level.
Summary of European and non-European domestic account numbers
184
184
184
Non-European Countries
1 *** Indicates that the branch code is included in the bank code.
2 Check digits are specified as follows:
the number indicates how many check digits there are
a or n specifies whether the check digit(s) are alpha or numeric
brackets indicate that the check digit(s) are included in the account number
3 The first digit is an integral part of the account number, the second digit is not.
4 The alphabetic check digit precedes all other digits in the account number structure.
5 The branch code is part of the account number
6 The entry for Serbia and Montenegro has been deleted with the split of the two countries in 2006
7 The check digits are located between the bank/branch code and the actual account number.
8 Please check the Swedish contribution. The domestic situation does not apply to account numbers
used in cross-border transfers.
9 The Type 2 account in Sweden does not include the bank/branch code.
10 This account number structure is used for CHAPS-Euro payments. The branch code (AAA) is
optional.
11 *** Indicates that the branch code is included in the bank code.
12 Check digits are specified as follows:
the number indicates how many check digits there are
a or n specifies whether the check digit(s) are alpha or numeric
brackets indicate that the check digit(s) are included in the account number
Bank standards
For more information see attached document
Regarding other non-European countries bank standards
Account
Country Local clearing code number
INDIA Max. 9 an Max. 19 an
184
Account
Country Local clearing code number
SWIFT code 8
AUSTRALIA (AU) AND NEW ZEALAND or 11 n or max.
(NZ) 17 n local
Max. 10 an clearing code
CHINA MAX - 12 an (used as bank code) Max. 30 an
HONG KONG 12 an (used as bank code) Max. 9 an
INDONESIA Max. 6 an Max. 14 an
Max. 4 an (first 4 positions used
JAPAN as bank code, last 3 positions
used as branch code) Max. 7 n
MALAYSIA Max. 12 an Max. 20 an
SINGAPORE as bank code, last 3 positions 11 an SWIFT
used as branch code) code
TAIWAN Max. 7 an (used as bank code) Max. 14 an
as bank code, last 4 positions
THAILAND used as branch code) Max. 14 an
4 n for Chips participant
USA 6 n for Chips universal ID
9 n for Fedwire / Fed ABA 8 or 12 n
5.2 Define House Banks
by an account ID.
Role of the Object:
example, for automatic payment transactions to determine the bank details for payment.
SAP guidelines:
Several house banks are supplied as examples in the standard system in order to enable configuration of the
payment program.
For domestic banks, you should enter the bank number in the "bank key" field and for foreign banks; you should enter
the SWIFT code in this field.
For Belgium, the first three house bank ID items must be numeric.
Do not forget to create a G/L account for the specified bank account. The G/L account is to be managed in the same
currency as the account at the bank.
Attribute details:
SAP transaction FI12
Technical
Modified: 6/16/2017 5:41 PMV_T012-HBKID
name Page 122 of Last modified by: Romo Navarrete, Pablo
Field type CHAR 184
Field length 5
Financial Accounting Bank Accounting Bank Accounts Define House Banks
EVO Specifications:
Planned usage:
Define Vodafone DB house banks and the corresponding accounts in the system under a bank ID or an account ID.
The Evo system will already have during this activity the bank directory updated. In this case, we only have to create
the banks that were not created in the "Copy bank directory" step to assign to the house bank that Vodafone is using.
We can also add any data that may be required to banks that are already in the bank directory via upload. We need
also to create the GL accounts related to those house banks.
So, when creating the house bank, there some fields that need to be update with the detailed information regarding
each one. The house bank is country dependant the definition of the country defines the rules according to which bank
data, such as the bank and account numbers, is to be validated that means that for one company code we can have one
house bank (D.B) and several accounts in that house bank (different currencies):
Area FI
Ownership Local
Values will be establish with DB and provided during the roll outs in accordance with the strategy and the number of
house banks Vodafone wants to maintain in each country. The strategy of creating an account is defined bellow.
184
Operating Company Foreign Currency Bank Criteria:
To decide whether an Operating Company requires a foreign currency bank account, the following criteria must be
met:
The currency is a major group currency (EUR, USD or GBP) and if there is a sufficient volume of transactions such
that the cost of maintaining a bank account is less than the charges being suffered on cross border payments. Also
the value of transactions is material to require hedging as per TQP01 section 5.1 (as per below)
Treasury policy TQP01 section 5.1 requires the immediate hedging of foreign currency exposures where there
are "External trading transactions (which exclude those with Vodafone Group Plc and its Subsidiaries) in excess of
5m per foreign currency per month and 15m per foreign currency over a 6 month period.
Given that the majority of foreign currency transactions are related to either roaming (which will be settled by the
Roaming Financial Clearing House) or settlement of invoices with stock/hardware suppliers I.e. Siemens, Cisco (to be
negotiated and settled by VPC), it is not anticipated that many Operating Companies will require a foreign currency
bank account.
5.3 Bank Chains
Chain of banks through which payment is carried out.
Example:
Vendor requests payment via an intermediary bank e.g Pay X bank, with further credit to X bank .
5.3.1 Define Scenario
In this activity you define scenarios for determining bank chains.
Role of the Object:
A scenario specifies the way in which a bank chain is to be determined:
generally, i.e. not dependent on certain business partner bank details (general search)
dependent on the business partner (recipient-specific search)
with which fields and in which order
SAP guidelines:
The SAP standard system contains a number of standard procedures (scenarios).
184
You cannot make changes to the standard system. Please note that any change can slow performance considerably,
because secondary indexes have only been created for the relevant database tables for the scenarios provided. If
you want to create indexes, SAP should be contacted.
Attribute details:
Technical name V_TBCH0-CHAINSCEN
Field type CHAR
Field length 4
SAP level Client
Financial Accounting Bank Accounting Bank Accounts Bank Chains
EVO Specifications:
Planned usage:
The bank chains scenarios used will be the provided SAP standards:
Any change can slow performance considerably (create new bank chains) SAP guidelines
The standard scenarios will support the scenarios in Vodafone business.
Standard scenarios:
0001 - NO BANK CHAIN DETERMINATION
0002 - SENDER BANK ORIENTED
0003 - RECEIVER BANK ORIENTED
0004 - RECEIVER ORIENTED
Area FI
Ownership Global
Use bank chain standard scenarios
5.3.2 Activate Bank Chain
184
In this activity you activate the bank chain function. In doing so, you specify that a bank chain is to be determined for
a payment.
Role of the Object:
In the previous activity, Define Scenario, you decided whether to use an existing scenario to determine the bank
chain, or whether to define a new scenario. You specify that scenario here.
SAP guidelines:
Enter the required scenario (such as 0003) for determining the bank chain for the current client.
Attribute details:
Technical name TBCHAINC0-CHAINSCEN
Field type CHAR
Field length 4
SAP level Client
Financial Accounting Bank Accounting Bank Accounts Activate Bank Chain
EVO Specifications:
Planned usage:
The bank chains scenarios used will be the provided SAP standards:
The standard scenarios will support the scenarios in Vodafone business.
Area FI
Ownership Global
Use bank chain standard scenarios. For that we need to activate the 4 scenarios provided:
0001 - NO BANK CHAIN DETERMINATION

0002 - SENDER BANK ORIENTED
0003 - RECEIVER BANK ORIENTED
184
0004 - RECEIVER ORIENTED
5.3.3 Create General Bank Chain
In this activity you define general bank chains.
Role of the Object:
Payments can be processed via a general bank chain and are not dependent on the business partner's bank details.
SAP guidelines:
Define the sequence of banks and the accounts from which payments are to be made.
Select the line containing the data you have entered, and then choose Bank chain. Enter the required data.
Here is defined the bank chain to be used for a predefined combination of the following criteria:
Currency
Sender bank country
Sender bank key
Recipient bank country
Recipient bank key
Payment method supplement
Attribute details:
Technical name V_TBCH2-CHAINID
Field type CHAR
Field length 10
SAP level Client
Financial Accounting Bank Accounting Bank Accounts Create General Bank Chain
EVO Specifications:
Planned usage:
For each
Area FI
184
Ownership Local
BankChn ID No. Typ Corr. ctry BnkKeyCor BankAcct

The bank The Type of bank in Country key for the In this field is the bank key of the This field
chain ID increasing a bank chain country in which the correspondence bank, where the bank contains the
identifies a numbers of (correspondent, correspondent bank data are stored in each country. The number under
chain of a bank in a intermediary) is headquartered. The country-specific meaning of this bank which the
connected bank chain country key key is determined while defining the account at the
banks. A determines determines which country keys. Normally, banks are kept correspondent
payment can the order of rules are used to according to their bank number. The bank is kept.
be made via the banks check the remaining number is used again on the bank's
a certain in the bank bank data (e.g. bank tax data. In certain countries the bank
bank chain. chain number and account account number serves this purpose;
number). there is no bank number. Bank data
are kept according to account number.
When performing a data medium
exchange, it can be useful to create
foreign business partners without bank
numbers, even if bank numbers are
available in that particular country. In
these cases you can then assigned a
bank key internally. If bank data are
kept according to a different key, e.g.
the SWIFT code, you can also assign
numbers externally.
For each case that Vodafone needs a correspondent bank, the values will be defined in the configuration step
5.4 Define Factory Calendar per Currency
SAP specifications:
The factory calendar per currency will contain the public holidays which apply in the country in which the currency is
traded. It is used to determine correct value date based on public holidays which apply in the country in which the
currency is traded. This is used in payments cycle.
Role of the object:
Define the factory calendar for payment currency and bank country.
Attribute details:
SAP transaction F8BC
Technical name V_TBKFK - WAERS
Field type CHAR
Field length 2
SAP level Client
184
SPRO Financial Accounting (New) Bank Accounting Business Transactions Payment Transactions
Payment Handling Value date Define Factory Calendar per Currency
EVO Specifications:
Planned usage:
The factory calendar for payment currency and bank country will be the same as the calendar of the country. For
each country assign the calendars already defined and configured for that country. The corresponding calendars have
already been defined for a series of currencies.
Area FI
Ownership Global
Use the F8BC transaction to display the configuration values.
Currency Bank Country Factory Calendar Text

V_TBKFK-WAERS T043T-PROZS V_TBKFK-FACID V_TBKFK-LTEXT
AUD AU AU Australia
BRL BR BR Brazil
CAD CA CA Canada
CHF CH CH Switzerland
CZK CZ CZ Czech Republic
DKK DK DK Denmark
European Currency Union
EUR EU EU (ECU)
Great Britain (England and
GBP GB GB Wales)
HUF HU HU Hungary
JPY JP JP Japan
MXN MX MX Mexico
NOK NO NO Norway
NZD NZ NZ New Zealand
RUB RU RU Russian Federation
SEK SE SE Sweden
SGD SG SG Singapore
TWD TW TW Taiwan
USD US US USA
VEB VE VE Venezuela
184
ZAR ZA ZA South Africa
5.5 Define Tolerance Groups for users
SAP Specifications

In this activity, you predefine various amount limits for your employees with which you determine:
the maximum document amount the employee is authorized to post
the maximum amount the employee can enter as a line item in a customer or vendor account
the maximum cash discount percentage the employee can grant in a line item
the maximum acceptable tolerance for payment differences for the employee
Role of the object

Payment differences are posted automatically within certain tolerance groups. This way the system can post the
difference by correcting the cash discount or by posting to a separate expense or revenue account.
In this respect you define:
the amounts or percentage rates up to which the system automatically posts to a separate expense or
revenue account if it is not possible to correct the cash discount or
Up to which difference the system corrects the cash discount. In this case the cash discount is automatically
increased or decreased by the difference, using tolerance groups.
Attribute details:
SAP transaction OBA4
Technical name T043T-RFPRO
Field type CHAR
Field length 4
SAP level Client
EVO Specifications
For the roles in TCM, a user has to be able to post a financial document in:
All bank clearing accounts

Bank charges account
All Interest accounts
Loan accounts
FX gains and losses, both realised and unrealised
Small differences account
All hedging accounts, i.e. Forward exchange deal accounts.
184
Any Treasury suspense account

Any related hedging accounts (i.e. mark to market accounts for cash flow hedging)
Planned usage:
Area FI
Ownership Local
The customizing path is: Financial Accounting (New) Financial Accounting Global Settings (New) - Document
Tolerance Group
.
Tol. Group for Financial Company

Acc. Code
T043T-RFPRO T043T-BUKRS
With reference to the key,
tolerances for the entry of
documents and the The company
Granting of cash code is an
discounts can be organizational
determined for all unit within
employees of the group financial
for payment settlement. accounting.
Company
Z001 code
Tol. Group for Financial Company Max. Payment Diff. for

Acc. Code Max. Payment Difference for Rev. Exp.
T043T-RFPRO T043T-BUKRS T043T-BETRS T043T-BETRH
With reference to the key, The company Payment differences to our Payment differences to
tolerances for the entry of code is an advantage are allowed up to our disadvantage are
documents and the organizational the amount entered here. allowed up to the amount
granting of cash discounts unit within The amount always refers to entered here. The
can be determined for all financial the local currency. Payment amount always refers to
employees of the accounting. differences up to the amount the local currency.
Group for payment entered here are posted Payment differences up
settlement. automatically by the system as to the amount entered
increasing the profit. The here are posted
system creates line items to automatically by the
show this. system as reducing the
profit.
Company Payment differences - Payment differences to
Tolerance group created code advantage our disadvantage
Z001 GB06 5 5
Tol. Group for Financial Max Allowable Rev. from Payment Max. Exp. Permitted from Payment Diff.
184
Acc. Diff.
T043T-RFPRO T043T-PROZS T043T-PROZH
With reference to the key, Differences when settling payments
tolerances for the entry of are accepted and posted Differences when settling payments
documents and the automatically by the system up to the are accepted and posted
granting of cash discounts percentage rate entered here. The automatically by the system up to the
can be determined for all percentage rate is only valid if the percentage rate entered here. The
employees of the group difference is posted as a gain. percentage rate is only valid if the
for payment settlement. The percentage rate is used for the difference is posted as an expense.
maximum of the debit and credit The percentage rate is used for the
totals of the items to be cleared. maximum from the debit and the
credit total of the items to be cleared.
Differences when settling payments Differences when settling payments
that are accepted and posted that are accepted and posted
Tolerance group created automatically by the system. automatically by the system.
Z001 0,5 0,5
Tol. Group for Financial Max. Disc. Adjust. for Gain from Payment
Acc. Diff. Max. Discount Adjust. for Loss from Payment Diff.
T043T-RFPRO T043T-SKNTS T043T-SKNTH
With reference to the key, When clearing payments, any payment When clearing payments, any payment
tolerances for the entry of differences up to the amount differences up to the amount specified here are
documents and the specified here are corrected with the cash corrected with the cash discount posting as long
granting of cash discounts discount posting as long as the cash as the cash discount amount is large enough for
can be determined for all discount amount is large enough for the the adjustment. The value you specify here is
employees of the group adjustment. The value you specify here is used for differences that represent a loss.
for payment settlement. used for differences that represent a gain.
Tolerance group created Payment differences up to the amount When clearing payments, any payment
specified here are corrected with the cash differences up to the amount
discount posting - gain specified here are corrected with the cash
discount posting - loss
Z001 1 1
Tol. Group for Max. Amount Posted

Financial Acc. per Doc. Max. Posting Amount per Line Item Max. Cash Discount Percentage Rate
T043T-RFPRO T043T-MAXBT T043T-MAXEB T043T-MAXSK
With reference to the Maximum permitted Maximum posting amount Maximum cash discount percentage
key, tolerances for posting amount per permitted per customer or vendor rate which may be assigned by an
the entry of document for this user item for this user group. employee of the user group.
documents and the group. The posting The percentage rate is checked during
granting of cash amount is the total of the entry, change and clearing of open
discounts can be all debit items or, items.
determined for all similarly, the total of
employees of the all credit items.
group for payment
settlement.
Maximum permitted Maximum posting amount Maximum cash discount percentage
Tolerance group posting amount per permitted per customer or vendor rate which may be assigned by an
created document item employee of the user group.
Z001 9.999.999.999.999,99 9.999.999.999.999,99 5
184
After defining the tolerance groups, in release phase, assign user name (user created in the system for one user) to
a tolerance group:
User Grp
User in the TCM department Tolerance group created
SMITH Z001
5.6 Configure the Electronic Bank Statement
This fulfils the requirements for correctly posting all business transactions submitted by the FI-BL module as well as
in-house cash centre by means of electronic bank statement. This includes the ability to automatically reconcile the
payments/receipts from the bank statements (both in house as well as external banks) with the ledger entries. This
ensures the process is less dependent on manual intervention.
This process enables the automatic reconciliation of the internal settlements as it clears the outstanding invoices,
and incoming receipts in both the creditor/debtor accounts. This process will prevent delays in the manual
reconciliation, which could lead to delays in operating companies being able to close outstanding items.
This process will be done automatically. A job will be created running the transaction FF.5 with fields pre-defined
(bank statement file location) that will upload the bank statements daily.
SAP guidelines:
There are some steps to be carried out:
Create account symbol: Specify G/L accounts (such as bank, cash receipt, outgoing checks) to which
postings are to be made from account statement. You assign account symbols to the G/L account
numbers.
Assign accounts to account symbols: Define postings to be triggered by possible transactions in the
account statement (such as bank transfer, debit memo).
In the posting specifications debit -> credit that you define here, use the account symbols from the first
step, not the G/L account numbers. This prevents similar posting rules being defined several times, the
only difference between them being the accounts to which postings are made.
Create keys for posting rules: The posting rules represent typical posting transactions for the
bank statement. A list of assignments where one external transaction code is assigned to one posting
rule is called a transaction type.
Define the posting rules. The account determination takes place via the posting rule. This
provides the information required for posting (posting key, accounts, document type).
Create a transaction type
Assign bank details, for which the account statements are to be imported, to a transaction type:
Assign transaction types to group banks with identical external transaction codes.
Assign the business transactions to these posting rules dependent on the transaction
type.
Assign the bank accounts to the transaction types.
Note: Make a note of the chart of accounts assigned to your company code. The company code/chart of accounts
assignment is in the IMG under Financial Accounting General Ledger Accounting G/L Accounts Master Data
Preparations Assign Company Code to Chart of Accounts.
EVO Specifications:
Planned usage:
184
The bank statement files, provided from an interface RICEFWS (FI-TCM-IF-1) (EVO Bank statement input
interface between Deutsche Bank to SAP) - can be imported into the SAP System where they are then automatically
processed. To do this, you run the program that imports the files generated into the SAP System or, more specific,
into the bank data memory. During conversion, data in these files is supplied with SAP-specific information, such as
the chart of accounts and company code, for further processing. After the import transaction is completed, the data in
the bank data memory is analyzed. The system tries to identify the individual business transactions and filter out the
information necessary for posting, for example document numbers, from the note to payee fields on the bank
statement (interpretation of the note to payee).
If the necessary information can be interpreted, the system will automatically post the transactions (using batch input
or a call transaction). All line items are usually posted automatically against open items in clearing accounts based on
reference fieldreconciliation with invoice no., amount, or with SAP document no.
By making configuration settings, you ensure that all business transactions of which your bank informs you via the
electronic bank statement are posted correctly in the system. The following steps contain the information you require
to be able to configure the electronic statement.
Postings can be done with clearing or just posted in a GL account (bank charges). Posting automatically cleared will
be done against clearing account.
5.6.1 Create account symbol
Freely definable key for an account symbol. The posting details contain account symbols instead of accounts. The
account symbol is defined by the user when configuring the electronic bank statement. It specifies which G/L account
is posted to.
Role of the Object:
After any modifications that may exist, the account symbols lead to one account.
Attribute details:
Technical name V_T033I_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic
Bank Statement Make Global Settings for Electronic Bank Statement
EVO Specifications:
Planned usage:
Create account symbols related to the outgoing and incoming payment methods. After the modifications, the account
symbol leads to one account. The symbols that are linked with G/L accounts should be easy to understand, with
184
meaning. That is for the end user and for the maintenance it will be easier to relate those accounts with types of
payments/receivables.
Here you maintain the bank details and the accounts that you have at the house bank. It must be created a G/L
account in EVO system for each of these accounts. In the master record of each of these G/L accounts you enter a
currency key. The currency key must be the same as the currency in which you run the respective account at the
house bank. The account symbol is used when defining the posting rules and not the GL accounts. So, for each GL
account used to post financial documents from the import of the bank statement we will define an account symbol.
This account symbol will be used to define posting rules in a configuration step detailed below.
Area FI
Ownership Global
When specifying bank account data in the house bank table on the accounts at the house bank, it must be created a
G/L account for each account. If this is not done EVO system cannot make any postings when it receives the
electronic bank statement.
For each GL account described below an account symbol will be defined

:
Bank account
bank clearing accounts
Bank charges account
FX gains and losses, both realised and unrealised
Small differences account
Costumer and vendor accounts that we define to post with clearing when uploading the bank statement
In the transaction to create account symbols
Select new entry.
Account Text
V_T033I_EBST-KTOSY V_T033I_EBST-LTEXT
Bank Bank
Bank Charges Bank Charges
Outgoing EFT Outgoing EFT
Incoming EFT Incoming EFT
Outgoing CHQ Outgoing CHQ
Incoming CHQ Incoming CHQ
Funds Funds
Direct Debit Direct Debit
Note: The previous table is just an example. The final one will contain the details specified during roll out.
184
5.6.2 Assign accounts to account symbol
Assign the G/L account to the account symbol.
Role of the Object:
After assigning G/L account to the account number the account symbol leads to G/L accounts.
Attribute details:
Technical name V_T033G_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client

EVO Specifications:
Planned usage:
In EVO system, the Bank accounts and the clearing accounts configuration will be maintained with the values
provided after the definition of the final G/L accounts during the build phase.
In the case of bank accounts, the system allows numbers to be entered in a generic format, using + signs for the
static numbers. The system replaces these plus signs with the G/L account number that is maintained for the house
bank. So, to simplify the maintenance of the configuration, EVO system can be configured by entering the account
number generically by entering a series of + signs. It will simplify procedures when we create/change a new bank
account, the system will automatically recognize the bank accounts if the G/L account number is maintained for the
house bank.
For the bank clearing accounts, they can either be entered with the full G/L account number or part of the account
number and complete the field with + signs. E.g. Account symbol - Outgoing EFT G/L account (+++++++01)
This allows the simplification of maintenance and configuration as only part of the G/L account number is used. This
can be implemented as the clearing accounts will be defined with the same account number logic for all OpCos E.g.
24XXXX01 Outgoing EFT / 24XXXX02 Incoming EFT. In this case the system replaces these plus signs with the
G/L account number maintained for your house bank, but the non-generic part of your entry remains in the field.
Taking the example of an account 24005000 Bank account (as defined in the house bank master), the two end
digits of the number are replaced by 10. This entry would trigger a posting to account 24005001 Outgoing EFT.
The clearing accounts will be created based on the payment methods in each country. There will be a one to one
relationship between payment method and clearing account
In case of usage of P&L account, use the complete G/L account number in the assignment.
184
Area FI
Ownership Global
Note that, when making generic entries (i.e. using + signs), the system expects a 10-character entry for an account.
If you are using account numbers shorter than 10 characters, you must make your entries right-justified.
The account symbol used reflects the payment methods in place for each company code plus if its an outgoing or
incoming transaction e.g.- cheques+out or cheques+in. Also for the texts in the posting keys created.
In the transaction to create account symbols. Select new entry.
Account Symbol Account modification Currency G/L Account Number

V_T033G_EBST- V_T033G_EBST-KOMO1 V_T033G_EBST-KOMO2 V_T033G_EBST-KONTO
KTOSY
Bank + + ++++++++++
+ + 69320000 (See appendix A
Bank Charges
for logic of accounts)
+ + ++++++++01 (See
Bank Account -
appendix A for logic of
Cheques Out
accounts)
+ + ++++++++02 (See
Bank Account - SEPA
Out
accounts)
+ + ++++++++03 (See
Bank Account - Local
ACH Out
accounts)
+ + ++++++++04 (See
Bank Account - SDP
Out
accounts)
+ + ++++++++05 (See
Bank Account - DD
Out
accounts)
+ + ++++++++06 (See
Bank Account -
Cheques In
accounts)
+ + ++++++++07 (See
Bank Account - SEPA
In
accounts)
+ + ++++++++08 (See
Bank Account - Local
ACH In
accounts)
+ + ++++++++09 (See
Bank Account - SDP
In
accounts)
+ + ++++++++10 (See
Bank Account - DD In appendix A for logic of
accounts)
Bank Account - + + ++++++++11 (See
184

Treasury Transfers
accounts)
+ + ++++++++12 (See
Bank Account - Other appendix A for logic of
accounts)
Note: The previous table is just an example. The final one will contain the details specified during build phase.
The clearing accounts will be created based on the payment methods in each country. There will be a one to one
relationship between payment method and clearing account
5.6.3 Create Keys for posting rules
This field specifies the rules for posting in the general ledger and sub ledger.
Role of the Object:
Assign posting rules to possible transactions in account statement file. In this activity you enter descriptions for the
necessary posting rules.
Attribute details:
Technical name V_T028D-VGINT
Field type CHAR
Field length 4
SAP level Client

EVO Specifications:
Planned usage:
In EVO system for each posting rule created its needed to define a posting key. A posting key must be created for
each posting rule defined. E.g. - To post bank charges in a P&L account we need to create a posting rule key and
subsequently a posting rule.
Area FI
Ownership Local
184
Create posting rules in Customizing for Bank Accounting. Posting rules are represented in the system by a non-bank-
specific code (for example, Z001for Outgoing Payment). A posting key will be defined for each different financial
movement posting rule. The posting keys will be used to create a posting rule. For example a bank charge will
have a posting key. This posting key is linked to a posting rule that is defined in the system. Each time that a bank
charge item is in the bank statement, the system will associate this movement to a posting key linked with a posting
rule that will define the automatic posting in the bank charge account.
Select new entry.
Posting Key Text

Z001 Bank Charges
Z002 Cheques Out
Z003 SEPA Out
Z004 Local ACH Out
Z005 SDP Out
Z006 DD Out
Z007 Cheques In
Z008 Local ACH In
Z009 SDP In
Z010 DD In
Z011 Treasury Transfers
Also to allow the bank statement upload without error with GVO codes a posting key has to be defined for
Unallocated:
With the external transaction to match this posting key:
5.6.4 Define posting rules
Create posting specifications for each posting rule.
184
Role of the Object:
You use the posting specifications to specify how a certain business transaction is to be posted in the G/L accounts.
Attribute details:
Technical name V_T033F_EBST-EIGR1
Field type CHAR
Field length 10
SAP level Client

EVO Specifications:
Planned usage:
When defining a posting rule, you must specify how each business transaction that is transmitted by electronic
account statement (for example, bank charges) is posted in EVO system.
In EVO system posting specifications consists of one or two posting records debit -> credit, where the first posting
record is called posting area 1, and usually represents a G/L account posting (Bank -> clearing account). The optional
second posting record is called posting area 2 (clearing account -> Customer).
Depending on whether a posting transaction affects bank accounting only, or also affects sub ledger accounting,
define the posting rules either for the first posting area only, or for both the first and the second posting areas.
Document types will be created for reporting purposes to support bank reconciliation report needed - FI-TCM-RP-17 -
Bank Rec Auto-allocation
Area FI
Ownership Local
Enter account symbols rather than the actual account names in posting specifications. Those are already define in
section (Create account symbol)
Posting specifications consist of a posting key and account symbol for one or two line items (debit and credit
postings). The system uses the account symbol to determine the G/L account to which to make the posting.
184
Select new entry.
The posting area will define if the postings will be in G/L or bank accounts (posting area 1) and sub ledger postings
(posting area 2). Depending on the external transaction code and your Customizing settings, a single line item from
an electronic account statement can automatically trigger up to two posting transactions: A posting in posting area 1
(bank accounting or G/L accounting) and a further posting to posting area 2 (sub ledger accounting). We will use
standard SAP posting areas:
posting area 1 (bank accounting or G/L accounting)
posting area 2 (sub ledger accounting)
For each posting rule a Posting type will be choose for each set of posting specifications. The posting type must be
entered for each posting specification you define in customizing (clear sub ledger accounts in debit for example).
The posting types used (SAP standard) can be chosen from the following posting types:
Key Meaning
1 Post to G/L account
2 Debit posting to sub ledger account
3 Credit posting to sub ledger account
4 Clear debit entry from G/L account
5 Clear credit entry from G/L account
7 Clear debit entry from sub ledger account
8 Clear credit entry from sub ledger account
Posting Posting Posting Posting Acct Doc. Posting

Rule Area Key (D) Acct (Debit) Key (C) (Credit) Type Type
V_T033 V_T033F V_T033 V_T033F_ V_T033F
V_T033F_E F_EBST _EBST- V_T033F_EBS F_EBST EBST- _EBST- V_T033F_EB
BST-EIGR1 -EIGR2 BSCH1 T-KTOS1 -BSCH2 KTOS2 ATTR1 ST-ATTR2
OUTGOING
Z001
1 EFT 50 BANK ZW 4
40 INCOMING
Z002
1 BANK 50 EFT ZW 1
40 INCOMING
Z002
2 EFT DZ 8
40 BANK
Z003
1 CHARGES 50 BANK SB 1
OUTGOING
Z004
1 CHQ 50 BANK ZW 4
184
Note1: The previous table is just an example. The final one will contain the details specified during build phase.
Note: Document splitting is currently under discussion and is a SAP recommendation. Splitting documents from a
organized.
5.6.5 Create transaction type
External transactions (also known as business transaction codes) are bank-specific codes for business transactions,
each of which involves a different type of payment. It will be also used for internal transactions Intercompany
settlements.
Role of the Object:
The external transaction code is issued by banks in the electronic bank statement or using the in house cash
functionality (producing and importing bank statements internally). The SAP system requires this code in order to
identify the business transaction. It converts the bank (also in house bank)-defined codes into its own system-internal
transaction codes (known as posting rules), which in turn trigger certain specific posting transactions in the system.
SAP Guidelines:
Group together the bank accounts which contain the same external transactions in one transaction type. You can
thereby reduce the processing work involved in Customizing for external transactions.
Attribute details:
Technical name V_T028V-VGTYP
Field type CHAR
Field length 8
SAP level Client

EVO Specifications:
184
Planned usage:
EVO global solution is supported by one banking partner - Deutsche Bank. The transaction codes will be defined
locally with inputs from the D.B.. For this create two transaction types. This will allow for future changes and
scalability:
MT940
In-House
For clarity it would be better to maintain 2 transaction types. One for D.B. bank statement and one for I.H.C.
statements. The advantage of this grouping is that you do not have to allocate the external transaction codes of the
banks (business transaction codes) to internal SAP posting rules for every individual bank but rather can make this
allocation just once per transaction type. After defining the transaction type it must be allocated each of the house
banks to a transaction type.
Area FI
Ownership Global
Define transaction types (one for DB and other for IHC) in order to group together banks with the same external
transaction codes (all banks of the same type - DB)
Select new entry.
Transaction Type Posting Area

V_T033F_EBST-
V_T028V-VGTYP EIGR2
MT940 SWIFT MT940
IN HOUSE IN HOUSE
5.6.6 Assign external transaction type to posting rules
External (or internal using in house cash) transactions (also known as business transaction codes) are bank-
specific codes for business transactions, each of which involves a different type of payment
Role of the Object:
The external transaction code is issued by banks or in house bank in the electronic bank statement. The SAP system
requires this code in order to identify the business transaction.
SAP Guidelines:
184
If the bank makes the bank statements available in SWIFT MT940 format, then the external transaction is a business
transaction code. In Customizing you can assign different external transactions to a transaction category. These
transactions are posted according to the same posting rules.
Attribute details:
Technical name V_T028G-VGEXT
Field type CHAR
Field length 27
SAP level Client

EVO Specifications:
Planned usage:
MT940 will be subject to localizations. These configuration enable the system to convert the bank-defined codes into
its own system-internal transaction codes (known as posting rules), which in turn trigger certain specific posting
transactions in the system. Please see Business transaction codes used by D.B. below. This will require configuration
subject to localizations:
BTC Bank
In this step we define the algorithm used to do, for each business transaction, to do the automatic reconciliation
against the open items. The note to payee fields in the electronic bank statement contains information relevant to
clearing open items.
The interpretation algorithm allows the EVO system to search for incoming and outgoing payments in the bank
statement, based on information supplied by the customers and/or the house bank and entered in the note to payee
lines in the bank statement.
For cheques we use the cheque number. For incoming/outgoing payments we use the Document number / Reference
document number
Area FI
Ownership Local
184
Define transaction types in order to group together banks with the same external transaction codes (all banks of the
same type DB and In House).
Select MT940 transaction type (D.B. Business transaction codes)

Select new entry.
+/- sign of the Posting Rule

External business incoming amount Interpretation
transaction algorithm
- 011: Outgoing Check:
001 Check No. Different
Z004 from Pymt Doc. No.
+ 001: Standard
020
Z002 algorithm
- 001: Standard
020
Z001 algorithm
- 001: Standard
802
Z003 algorithm
Note: The previous table is just an example. The final one will contain the details specified during build phase. Also
we will define an External business transaction for transaction codes that will not have a right or maintained code.
These transaction codes will have a posting rule associated posting with clearing that will be post processed
correctly with FEBA transaction.
For in house cash:
Select IN HOUSE transaction type (IHC Business transaction codes)

Select new entry.

- 001: Standard
020
Z002 algorithm
+ 001: Standard
051 Z001 algorithm
5.6.7 Assign bank accounts to transaction type
Allocate each of the house banks to a transaction type already created
184
Role of the Object:
Banks are identified by specifying bank keys and external or internal account numbers. To do this, select the step
Allocate banks to transaction types.
Attribute details:
Technical name V_T028B-VGTYP
Field type CHAR
Field length 8
SAP level Client

EVO Specifications:
Planned usage:
Banks are identified by specifying bank keys and external account numbers. Evo system configuration will have the
same transaction type (MT940) for all accounts in EVO scope (D.B. accounts) and transaction type (IN HOUSE) for
all the accounts - virtual bank accounts created in In House cash module scope.
Area FI
Ownership Local
To configure, select the step Allocate banks to transaction types.
Select new entry.

bank number) number

405081 11001242 MT940
300070024 1234567 MT940
Note: The previous table is just be filled with the bank key and account numbers during the build phase when
creating the external bank accounts for each country.
184
For In House cash:

bank number) number

99999999 + IN HOUSE
Define Search String for Electronic Bank Statement
An interpretation algorithm enables you to find separate outgoing payments using the reference information returned
by the bank.
Role of the Object:
The following algorithms are available:
000 (No interpretation)
You use this algorithm if you do not want to use the standard algorithms supplied by SAP. If this is the case,
the system calls up the algorithms you defined yourself, in conjunction with functional enhancements (user
exits).
001 (Standard algorithm)
Algorithm 001 interprets the values in the note to payee fields of the electronic account statement as either
document numbers or reference document numbers. In the process, it checks whether the values are in the
document/reference document number ranges you entered when importing the account statement. If (and
only if) they are, it then tries to find the items to be cleared in the system.
Note that you must prescribe the possible intervals for documents/reference documents using the
values "BELNR number range" and "XBLNR number range" in the selection screen for importing the
electronic account statement.
If the reference document was stored with leading zeroes in the system, the system can find a line
item only if the reference document number in the account statement is imported with these leading
zeroes. If, on the account statement import selection screen, you were to enter 00100 - 00200 as the
interval, the system does not find the value if the reference document number is simply 100.
011 (Outgoing check: Check number not identical to document number)
This algorithm is used for payments by check if the bank uses pre-numbered checks. Your house bank
supplies the check number in the account statement. The algorithm uses the check number to find the
appropriate document number.
012 (Outgoing check: Check number identical to document number)
You use this algorithm for payments by check if checks are printed using forms that do not yet contain a
check number. The SAP document number is then printed on the check as the check number. Your house
184
bank confirms this check number on the account statement. The algorithm finds the check number (which in
this case is the same as the document number) in the note to payee lines in the statement.
On the selection screen for importing electronic account statements, you must specify the possible number
ranges for the document number search (see algorithm 001).
013 (Outgoing check: Check number identical/not identical to document number)
This algorithm finds the check number in the note to payee lines either per algorithm 11 or per algorithm 12.
015 (Clearing transaction: Selection per assignment number)
This algorithm enables you to clear open items according to the assignment number:
If the posting rule in question permits clearing, the system selects the items for clearing according to the
assignment number.
If the posting rule in question does not permit clearing, the system writes the bank reference (check number
for example) as the assignment number in the line item of the posting on account.
Then, at a later date, you can use report SAPF123W to clear the item automatically via the
assignment number.
These algorithms have the following limitations:
The system can only clear an item by means of the assignment number if it can
locate the account to be cleared (the bank data in the case of customers/vendors or
the posting rule in the case of G/L accounts).
To select items using the assignment number, the system uses the Bank reference
or Check number field from the account statement. (If there is no entry in this field, it
uses the start of the Note to payee field.) Check whether these fields contain the
information that the system requires to be able to find open items in the relevant
account.
Since the assignment number is a text field, the information in the account
statement may not be correctly formatted. If you want selection to take place using
the assignment number even though the information in the account statement is
missing or not in the correct format, you can use the customer exit to enter data in
the Check number field FEBEP-CHECT).
019 (DME administration reference number)
You use this algorithm to import those account statement line items that relate to a previous payment run. All
the items for a payment medium generated by the payment program are summarized by means of a DME
(data medium exchange) reference number. Your house bank confirms the overall total for the line items,
together with the DME reference number. The algorithm finds the DME reference number in the note to
payee lines in the account statement. The reference number is used to find and clear all the line items in the
system.
020 (Document number search)
Algorithm 020 functions in the same way as algorithm 001, except that it interprets the contents of the note to
payee fields only as a document number.
021 (Reference document number search)
184
Algorithm 020 functions in the same way as algorithm 001, except that it interprets the contents of the note to
payee fields as a reference document number only.
022 (BZ bank transfer method (Germany only) with document number)
Algorithm 022 refers to the BZ procedure (payment form transfer without documents). Under this procedure,
a billing system creates a transfer form that contains a thirteen digit number in the coding line. This number
normally consists of the document number and a check digit and is returned by your house bank. This
algorithm cuts off the check digit and interprets the number (right-aligned) as document number.
023 (BZ bank transfer method (Germany only) with reference document number)
This algorithm also refers to the BZ procedure (payment form transfer without documents). Under this
procedure, a billing system creates a transfer form that contains a thirteen digit number in the coding line.
This number normally consists of the reference document number and a check digit and is returned by your
house bank. This algorithm interprets the number (including the check digit) in the note to payee fields of the
electronic account statement as a reference document number.
You define the interpretation algorithm under the Customizing activities for the electronic account statement. In
Customizing for Bank Accounting, choose Business Transactions Payment Transactions Electronic Account
Statement Make Global Settings for Electronic Bank Statement Assign External Transaction Codes to Posting
Rules. For each external transaction, you then define which interpretation algorithm is to apply.
If the standard algorithms supplied by SAP for interpreting note to payee fields do not meet your
requirements, customer exits can be programmed which do so. These exits do not involve any
modification to the standard system.
026 (Search for reference document number with leading zeros, if < 10).
You can use this algorithm if the ten digit reference number in the account statement does not contain leading
zeros (if for example the reference document number in the statement is 100 and not 0000000100). This
algorithm works in three stages:
a. As with algorithm 021, algorithm 026 reads the Note to payee field searching for possible reference
document numbers. (Number range XBELNR on the selection screen following import of the account
statement).
b. In contrast to algorithm 21, algorithm 026 enters ten digits by adding leading zeros.
c. Finally, it compares the reference document numbers from the account statement with the reference
document numbers in the system.
027 (Reference number TITO)
This algorithm searches for the Payment reference supplied by the Finnish TITO account statement format.
028 (Reference number per MULTICASH conversion programs)
This algorithm is the same as algorithm 027. The account statement files are imported in MULTICASH format.
The algorithm uses number range BELNR.
029 (Payment order number)
This algorithm searches using the payment order number. The algorithm uses number range XBELNR.
184
030 (Brazil)
Applies where the electronic account statement is implemented in Brazil. It searches for the document
number, the fiscal year, and the number of the line item within the accounting document.
031 (Document number search (customer number in line item))
This algorithm functions in the same way as algorithm 020 (document number search). Here are some
exceptions:
o If the system can identify the business partner from a document number entered in the Note to payee
field, then you have the system add the bank details to the master data. This facility also exists with
algorithm 021. Since the account statement normally contains the bank details, these details can be
used to supplement the master data. You can use report RFEBKA80 to generate a file containing
customers bank details and add this data to the master records using report RFBIDE00. For more
information, see the documentation for these programs.
Where an alternative payer is specified, the bank details contained in the account statement are not
those of the business partner to which the document number previously found in the note to payee
refers. The bank details in question are not added to the correct business partner.
o This algorithm is used automatically to create payment advice notes when importing account
statements. The system creates a payment advice note if, when importing the account statement
data, it could not clear every open item right away (for example because it could not find every
document number contained in the Note to payee field). The payment advice note contains the
document numbers the system found, and can be used to post the account statement items if you
enter the missing document numbers yourself.
It is possible that the individual document number or payment advice note items relate to different
business partners. If this is the case, these items are only automatically assigned to the correct
business partner if you use algorithm 031. If you use algorithm 21, you need to add the correct
business partner information to each individual payment advice note items.
040 (Treasury (TR): Standard search followed by loan search)
You can use this algorithm if you implement the Treasury Management (TR-TM) application component. The
system first runs algorithm 001 (document and reference number search). If this search is unsuccessful, it
then searches for Treasury documents. A Treasury customer exit is used here.
041 (Treasury: Search for loan, then standard search)
As for algorithm 040 above, except that the search is carried out in the reverse order.
When importing an electronic bank statement, the system identifies the business transactions and uses the settings
you have already made to determine how each should be recorded. In most cases, the system uses the document
number entered in the "note to payee" lines of the bank statement to determine the appropriate clearing transaction.
For example, a cash receipt clears customer open items.
The information in the note to payee may be incomplete - for example, the first characters in the document number
may be cut off or new characters may be added. The interpretation algorithm then reaches the limits and cannot find
the appropriate document numbers. This means the document cannot be cleared and you must post- process the
transactions manually.
In addition to the search for clearing information, you can use the search string to fill other fields (such as the cost
center or posting rule, depending on the content of the note to payee.
184
It is the "Target Field" which determined which field is filled in each case. The target field in the bank data store
indicates to where the result of the search is written. The target field must always be the note to payee when you are
searching for clearing information (document number, reference document number. (Unlike other fields, it is not
necessary to repeatedly change the note to payee field - the information in it is temporarily "enriched" while the
interpretation algorithm is running.) The explanations and examples that follow all refer to the search for clearing
information (meaning that the note to payee is the target field), but they can also be applied to most other fields.
To increase the number of hits in the document number search, you can use this step to define strings for the search.
The system uses this string to conduct the search before the interpretation algorithm comes into effect.
Step one is to define the search string. The end of this section gives definitions of some special characters.
Having defined the search string, you must then define "mapping". Mapping is used, for example, to eliminate
characters that customers have added to document numbers.
To illustrate which sign in the search string is assigned to which character in mapping; the example which follows
gives vertical representations of the search strings and associated mapping. See the end of this section for definitions
of some special characters. These characters cannot be entered in mapping.
In the example, the symbol "#" means any figure between 0 and 9. A blank in mapping causes the system to delete
the respective item.
SAP Guidelines:
If no standard string is useful to separate outgoing payments using the reference information returned by the bank we
need to define and Simulating Strings
Define string
1. Double click in the tree Search string definition.

2. Choose "New entries".
3. Enter a search string name (example: STRING1), a description ("Five digit document number") and a search string
(example: (^| )###.##( |$)),then choose Enter.
4. In the Mapping area, assign a character to each character in your string.
The system proposes the unchanged search string as initial mapping. Change the characters as you want.
Test the string
5. In the Test area, enter a text under Input text. The text must include the document number as it would appear in the
electronic bank statement. Then choose Test.
You then see the document number the system uses to find document so that it can post the business transaction in
the system. (Any mapping basis you may have entered in addition is ignored in this test.)
Assign Search String to Interpretation Algorithm
6. Go back and double click in the tree Note-to-payee search string

7. Choose new entries.
8. Enter the company code, house bank, account, interpretation algorithm, and a name for the string.
If you leave all or one of the fields Company code, House bank, or Account , the system uses the specified search
string to search in all company codes, house banks, and/or accounts.
9. If you want to use the string in the document number search, select Active and "Note to Payee" as the target field.
10. Enter a mapping basis if required. Select the ID indicator if required.
Attribute details:
Technical name V_TPAMA-APPLI
Field type CHAR
Field length 4
SAP
Modified: 6/16/2017 5:41 PMClient
level Page 151 of Last modified by: Romo Navarrete, Pablo
184

Bank Statement Define Search String for Electronic Bank Statement
EVO Specifications:
Planned usage:
MT940 will be subject to localizations. For each release/country D.B. is going to provide different information in the
bank statement. With that, we define the search string needed to process automatic allocation.
Area FI
Ownership Global
Standard Interpretation algorithms:

- 011: Outgoing Check:
NCHQ Check No. Different
Z004 from Pymt Doc. No.
+ 001: Standard
NMSC
Z002 algorithm
- 001: Standard
NMSC
Z001 algorithm
- 001: Standard
NPBC
Z003 algorithm
5.7 Define Accounts for Exchange Rate Differences
SAP specifications:
184
With this object, you define the account numbers to which realized exchange rate differences are posted
automatically when clearing open items. When clearing open items, the system posts realized gains or losses
(realized exchange rate differences). You therefore define expense accounts and revenue accounts.
Role of the object:
The system automatically posts to the Revenue/Expense accounts defined for exchange rate differences in
configuration, thus eliminating the possibility of incorrect entries. The realized difference is stored in the cleared line
item.
Exchange rate differences are also posted when open items are valuated for the balance sheet. These exchange rate
differences from valuation are posted to the unrealised exchange rate difference account and to a balance sheet
adjustment account.
When clearing an open item that has already been valuated, the system reverses the balance sheet correction
account and posts the remaining exchange rate difference to the account for realized exchange rate differences.
SAP guidelines:
You can also define the accounts for valuating open items in this step. You can, however, also still set these accounts
when making the specifications for the closing procedures.
You can differentiate the accounts by currency. Exchange rate gains and exchange rate losses are then posted to
separate accounts for the individual currencies. You may no longer change your accounts for the valuation posting
after the first valuation run. Otherwise valuation postings can no longer be cancelled.
Attribute details:
SAP transaction OB09
Technical name T030H
Field type -
Field length -
SAP level Client Dependent
Select the impacted chart of accounts,

Enter the New Entries screen and:
Define a G/L account/Currency/Currency Type,
Define expense accounts and revenue accounts for gains and losses and,
If necessary, define the accounts for valuating open items
EVO specifications:
Additional Details:
184
Area FI
Ownership Global
6. Finance TR CM
Cash forecasting impacts the ability to make decisions around cash optimisation, risk, investment, etc., and
requires a comprehensive integration of corporate planning, systems integration and appropriate analysis. The
module used for the Forecast and positioning is the TR-CM. Integrating all the OpCos data in the module will
support the CBM process design, improving cash management by providing Treasury with accurate information
on short and long term cash needs and sources, leading to lower funding costs, higher return on investments,
and fewer un-invested funds. Obtaining accurate and reliable cash forecasts is imperative to cash management
operations. For that, the decision of using TR-CM to enable the creation of forecast with the appropriate level of
detail while trying to minimize work efforts and to support a complete cash flow forecast integrating all OpCo data
in the same system. The TR-CM module will support the CBM process design being used to:
To measure cash position and 90 day forecast

Fully integrating relevant data across OpCos to allow treasury access to a single pool of consolidated
Output
Vodafone Vodafone
System / Module Cash position and
Organization Organization
Liquidity Forecasting
Vodafone SAP
EVO
Group
OpCo A
Treasury
Short Term
Medium Term
Long Term
Forecast
Module
OpCo B Decision
TR-CM Making
90 day forecast
Modified: 6/16/2017 5:41 PM Page 154 of Last
Daily modified
cash position by: Romo Navarrete, Pablo
184
OpCo C
Implementation of the TR-CM component for VF will:
Hedging - mitigate FX risk

Control increase control
Inter-company funding - decrease overall companys funding costs by improving accuracy of forecasts
Debt management -secure lowest cost funds to meet future cash needs
Investment management - secure the highest yielding/lowest risk investments given future cash needs.
Operational improvements - based on problem areas uncovered in forecasts. Ability to analyse forecasts to
identify areas where forecast accuracy can be improved.
6.1 Define Planning Levels
Planning Levels
Planning levels Source
AB Payment advice (confirmed) Bank Accounting
B1 Outgoing checks Bank Accounting
B2 Outgoing transfer, domestic Bank Accounting

Source Cash Position
B3 Outgoing transfer, foreign Bank Accounting
Bank Accounting
B4 Bank collection Bank Accounting
B8 Incoming checks Bank Accounting

GL Accounts
B9 Customer cash receipt Bank Accounting
master data
M1 Purchase requisition Materials Management
Source Liquidity Forecast
M2 Purchase order Materials Management
Materials Management
M3 Scheduling agreement Materials Management
Sales and Distribution
S1 Sales Orders Sales and Distribution
F0 Posting to bank account Bank Accounting
184
SAP specifications:

In this step, you specify a planning level for each cash account and allocate this planning level to the cash position by
using the appropriate source symbol.
Role of the object:

Financial transactions in Cash Management are displayed using planning levels in order to explain beginning and
ending account balances.
In the standard R/3 System, levels starting with "F" or "B" are reserved for automatically updating data during posting
so that you can easily analyze the cash position. Manually created payment advice notes or planned items, however,
are allocated to different level (liquidity forecast). Detailing by planning level provides information on the causes of
bank or account transactions for bank accounts and planning groups. For example, you can identify how a piece of
information came into the system (posting or payment advices/plan item) and how probable it is that a cash inflow or
outflow will take place on the day planned.
Typical planning levels include outgoing checks, outgoing bank transfers, check receipts, FI postings, purchase
orders, orders, and confirmed or unconfirmed payment advices. For structuring purposes, planning levels are divided
by where they came from, and assigned to either the cash position or liquidity forecast.
The table below gives a summary of planning sources that affect the liquidity analyses.
Cash Position Liquidity Forecast
Bank balances Receivables as expected incoming payments
Checks posted to the bank clearing account Payables as expected outgoing payments
Outgoing bank transfer posted to the bank Planned wage and salary payments for an as yet
clearing account unspecified account
SAP guidelines:
SAP recommends using the following levels:
Level F0 for bank accounts

Level F1 for customers and vendors
Levels B1 to Bn for bank clearing accounts
Level CP, for example, for confirmed payment advice notes
Level UP, for example, for unconfirmed payment advice notes
Level NI, for example, for noted items
The levels defined will be unique - meaning that it will not be defined the same level for more than one application or
activity as this may affect the clarity of the display in the cash position or liquidity forecast.
It might also adversely affect the function for jumping from these transactions to the correct application or line item
display. In addition, you will reserve levels, for example, all levels beginning with X, to represent postings with
184
payment blocking indicators in the liquidity forecast. When displaying the liquidity forecast, you can then see because
of these levels that the displayed amounts are postings with payment blocking indicators.
Attribute details:
Technical name EBENE
Field type Char
Field length 2
SAP level Client
IMG: Financial Supply Chain Management Cash and Liquidity Management Cash Management Master Data
G/L Accounts Define Planning Levels
EVO Specifications:
Planned usage:
When displaying the cash position, you can then see because of level F0 assigned to the G/L accounts that the
amounts are posted to bank accounts. The other levels reflect planned bank account transactions, which include
postings to bank clearing accounts or entered payment advice notes. Therefore, you can use the display to compare
planned data with actual data. The master data that has to be updated for the display of the right daily cash position is
the GL accounts. This is essential touch point with finance and cash management. In the cbmMDA_AP363 Business
Object Definitions_CoA Data Definition document is defined that the field Planning level will be filled when a GL
Account from the Cash account group of accounts is created:
ZCAC Cash account (CBM)
The basic information needed for this account group is the following:
Data for the EVO Chart of accounts

o General Data Basic account information
Account group This field determines the screen layout for the accounts within the group.
This field is mandatory
P&L account This field determines that the account is a P&L account. This field is not
used.
Balance Sheet account This field determines that the account is a BS account. This field is
mandatory
Short text Short description for the account. This field is mandatory
Long text Long description for the account. This field is mandatory
o Control Data Control account information
Account currency Determines the currency for the account. This field is mandatory
Tax category Determines that the account is tax relevant. This field is optional
Posting without tax Te account is relevant but it can be posted without tax. This field is
optional
Alternative account number By this field the EVO accounts and the Local accounts are
linked This field is mandatory for the OpCos that have local accounts
Open Item management This means that the account is managing Open Items. This field
is optional
184
Line item display the postings will be showed individually. This field is mandatory
Sort key Sort criteria used in the account. This field is mandatory
o Bank/Interest Bank information
Field status group This field determines the fields that will be mandatory in the postings
when using the account. This field is mandatory
Planning level This field is used in Bank accounts for the cash position. This field is
mandatory.
House Bank Link with treasury for the real Bank. This field is optional
Account ID Link with treasury for the real Account number. This field is optional
o Key Word / translation In this tab the user introduce the account description in the local language
Language key This key identifies the language for the description. This field is optional
Short text Short description for the account. This field is optional
Long text Long description for the account. This field is optional
To improve the display of the cash position and liquidity forecast, the levels that start with "F" or "B" will be reserved
for automatically updating data during posting. F levels should be used for bank accounts, customers, and vendors,
and B levels for bank clearing accounts.
Examples:
F0: bank accounts
F1: purchasing/sales (customers/vendors)
B1: bank clearing accounts, outgoing checks
B2: bank clearing accounts, outgoing bank transfers (domestic)
EVO global design model, to reflect the amounts, the configuration of the planning level will be done as followed:
Area FI
Ownership Global
The short text will be displayed in the report and the length of field is 10 Char.
Planning level Source Short text Planning level long

text
V_T036-EBENE V_T036-ORIGN V_T036-KTEXT V_T036-LTEXT
The planning level is The source symbol Planning level short Planning level long text
used to control divides the planning text used and
displays in Cash levels according to the displayed in the report
Management. sources that supply
them with data. You
184
Planning level Source Short text Planning level long

text
V_T036-EBENE V_T036-ORIGN V_T036-KTEXT V_T036-LTEXT
can freely define the
source symbol and
allocate it to either the
cash position or the
liquidity forecast.
BNK Advice, c. Payment advice
AB
(confirmed) -
B1 BNK Out. check Outgoing checks
BNK Dom trans Outgoing transfer,
B2
domestic
BNK For. trans Outgoing transfer,
B3
foreign
B4 BNK Bank coll. Bank collection
B8 BNK Inc checks Incoming checks
B9 BNK Cash rec Customer cash receipt
M1 MMF Purch.Req. Purchase requisition
M2 MMF Pur. Order Purchase order
M3 MMF SchedAgree Scheduling agreement
S1 SDF Order Sales Orders
BNK FI Banks Posting to bank
F0
account
Note: this will be used to post the memo of non-Evo billing receipt expected, urgent payments, physical presence
payments, roaming payments and receipts
6.2 Define Source Symbols
SAP specifications:
In this step source symbols are defined and its needed to allocate them either to the liquidity forecast or to the cash
position.
Role of the object:

The source symbol divides the planning levels according to the sources that supply them with data:
Bank accounting
Sub ledger accounting
Materials management
Sales and distribution
SAP guidelines:
Create a symbol for data from bank-related accounting.
Create a symbol for data from sub ledger accounting.
184
Create a symbol for data from Materials Management and a symbol for data from Sales and Distribution.
Attribute details:
Technical name V_T039-ORIGN
Field type Char
Field length 3
SAP level Client
IMG: Financial Supply Chain Management Cash and Liquidity Management Cash Management Basic
Settings Define Source Symbols
EVO Specifications:
Planned usage:
Select the "CM posit." field for bank data in order to assign this data to the cash position. Do not select this field for
the other sources, since they supply the liquidity forecast with data. The cash position then will reflect bank
accounting and liquidity forecast will reflect sub ledger accounting, materials management and sales and distribution-
the impact that the expected incoming outgoing payments could have in Vodafone and each OpCo.
Area FI
Ownership Global
We will use the standard source from SAP
Source Cash pos. Short text Description
BNK X Bank acctg Bank Accounting
MMF MM Materials Management
PSK Sub. Acctg Sub ledger Accounting
SDF Sales Sales and Distribution
6.3 Define Planning Groups

Planning Groups
Invoices
Planning group
Cash position and liquidity
Z1 Non6/16/2017
Recourse forecast
Modified: 5:41 PM Page
Customer / Vendor 160
Sales of Last modified by: Romo Navarrete, Pablo
Orders
184
Z2 Recourse Master Data Values divided by planning
groups defined
Z3 Third Party
P.O.
SAP specifications:
In this step, you define the planning groups for customers and vendors. A planning group represents particular
characteristics, behaviour or risk of the customer or vendor group. In Cash Management, customers and vendors are
assigned to the planning groups by means of master data entries.
Role of the object:

Therefore, you can break down incoming and outgoing payments according to the amount, the probability of the cash
inflow or outflow, and the type of business relationship. Customers and vendors are assigned to a planning group by
making an entry in the master record.
In addition, planning groups are allocated to a planning level.
Attribute details:
Technical name V_T035-GRUPP
Field type Char
Field length 10
SAP level Client
IMG: Financial Supply Chain Management Cash and Liquidity Management Cash Management Master Data
Sub ledger Accounts Define Planning Groups
EVO Specifications:
Planned usage:
EVO CBM design decision was use planning groups to break down incoming and outgoing payments according to the
amount and the type of business relationship.
For that the planning groups to create are 3:
Third party
Intercompany Recourse
Intercompany non recourse
184
So, this will provide a high level view with summarized groups by these three groups, forecasting the incoming and
outgoing amounts by Third party / Intercompany Recourse / Intercompany non recourse.
This has impact on the creation of the costumer and vendor master record. This field, Planning group (cash
management group) will be mandatory for all account groups. See cbmMDA_AP363_Data Definition Vendor Master
Record Table and cbmMDA_AP363 Business Object Definition Customer_Data_Table.
Area FI
Ownership Global
Plan. grp Level SCn DaCo Short text Description

V_T035- V_T035- V_T035- V_T035- V_T035-TEXTK V_T035-TEXTL
GRUPP EBENE BILD1 DATYP
Z1 F1 Non Reco. Non Recourse
Z2 F1 Recourse Recourse
Z3 F1 Third Part Third Party
6.4 Define Cash Management Account Name
SAP specifications:
In this step, you assign a mnemonic name as the cash management account name to each bank account and bank
clearing account.
Role of the object:

This mnemonic name is used with all functions and reports in Cash Management instead of the account number. This
will not change the master data GL account object but is just used for reporting purposes and memo posting (cash
management functions).
The name is unique within a company code.
Attribute details:
SAP transaction Spro
Technical name DISKB
Field type Char
Field length 10
SAP level Client
184
IMG: Financial Supply Chain Management Cash and Liquidity Management Cash Management structuring
Define Cash Management Account Name
EVO Specifications:
Planned usage:
For each bank account and bank clearing account will be defined a name using logic used in the table of the
configuration values. This is made company code level. So for each company code created, the bank and bank
clearing accounts will be named. This will help to the final user to understand, when he is posting a memo to an
account or seeing the cash positing report, it will appear in these functionalities the name of the account and not the
number.
Choose a cash management account name for each bank account and bank clearing account.
Specify the G/L account number for each of these accounts.
Enter a name for each account.
If necessary, indicate any internal, cash management accounts.
The system automatically displays the external bank account number for a bank account.
Area FI
Ownership Global
CoCd CM acct Bank acct Description

GB07 DB GBP 24002000 GBP account
GB07 DB USD 24006000 USD account
GB07 INC CHEQUE 24002001 Inc. Cheques account
Example:
Note: these GL accounts and related symbols will be created per company code using the accounts/clearing
accounts defined
GL accounts
Grouping and Structure
0024002000
6.5 Define Groupings and Maintain Headers
0024002001
0024002002
Cash position and
Planning group liquidity forecast
Planning levels Grouping
Z1 Non Recourse Planning groups Values from Planning
GL accounts Vodafone levels
Z2 Recourse taken in Planning groups
account when GL accounts defined in
Z3 Third Party extracting grouping
the reports selecting
Planning levels
Vodafone grouping
AB Payment advice (confirmed)
B1 Outgoing checks
B2 Outgoing transfer, domestic
B3 Outgoing transfer, foreign

M1 Purchase requisition
184
M2 Purchase order
M3 Scheduling agreement
S1 Sales Orders
F0 Posting to bank account

SAP specifications:

In this step you define the groupings, and stipulate the main headings and the line headings that the system displays
in the cash position or liquidity forecast.
Role of the object:
Specify a planning level for each cash account and allocate this planning level to the cash position by using the
appropriate source symbol. The planning level is used to control displays in Cash Management.
SAP guidelines:
Check the standard planning levels and change them if necessary.
Attribute details:
SAP transaction OT12
Technical name V_T036-EBENE
Field type CHAR
Field length 2
SAP level
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
Structuring Groupings Define Groupings and Maintain Headers
EVO Specifications:
184
Planned usage:
Here we define which the header for each group that we define is in the next step. Can be created several groupings,
depending on the display of the report defined. For EVO, it will be one, globally standardizing the report for all OpCos
so just one grouping will be define.
Area FI
Ownership Global
Grouping Heading Line heading
V_T038P-GLIED V_T038P-TEXTU V_T036-KTEXT

VODAFONE Vodafone EVO Vodafone EVO
6.6 Maintain Structure
SAP specifications:

In this step, you specify grouping structures. These structures enable to group together bank and sub ledger
accounts in the cash position or the liquidity forecast. The planning level reflects typical financial transactions, for
example:
FI posting to a bank account
FI posting to a clearing account
Confirmed or unconfirmed payment notes
Role of the object:

These structures enable to group together bank and sub ledger accounts in the cash position or the liquidity forecast.
For the cash position and the liquidity forecast, you specify:
o The accounts you want to see in the grouping and those you want to exclude
o The summarization term under which you want to group together the lines for levels and the lines for
groups in the display
o The line type, whereby "E" stands for level and "G" for the account or planning group.
For cash concentration, you specify
o The account in which clearing account balances are summarized during cash concentration.
184
You use groupings to stipulate the format for your display. You specify the setup of the cash position and liquidity
forecast by using groupings. The grouping determines which levels and accounts will be displayed in the cash
position and liquidity forecast. Groupings select and structure the required dataset and are responsible for compiling
the cash position.
You want to see the activity within various bank accounts. By entering the grouping on the request screen, you
specify the accounts and balance the system selects and displays.
By specifying a summarization term, such as the name of a bank, you can have the system group together individual
lines in the display. For example, if you do not want to see all clearing accounts individually, assign them to a
summarization term such as FIRST or CITI. On the first display screen, you then see the clearing accounts grouped
together under these summarization terms rather than individual clearing accounts.
To display the cash position and liquidity forecast according to different criteria, you can use the line selection function
to group according to levels.
SAP guidelines:
Create your grouping structures.

Select the following for each grouping structure
o All levels and
o The corresponding accounts according to your requirements.
Enter a summarization term for each grouping and, if necessary, a summarization account.
Attribute details:
Technical name V_T038-GLIED
Field type CHAR
Field length 10
SAP level
structuring Groupings maintain Structure
EVO Specifications:
Planned usage:
Can be created several groupings, depending on the display of the report defined. For EVO, it will be one, globally
standardizing the report for all OpCos. For EVO objectives, and for liquidity forecast there will be defined planning
groups to be able to distinguish in the report amounts forecasted from 3 different groups 3 rd party and intercompany
(recourse and non recourse).
For cash position the records, items, on the clearing and bank accounts, will be taken into account.
184
Area FI
Ownership Global
Grouping Ty. Selection CoCd ChAc Sum. term

VODAFONE E ++ EVO DB
VODAFONE E AB EVO FX
VODAFONE E CL EVO CL
VODAFONE E F0 EVO BANK
VODAFONE E F1 EVO AP/AR
VODAFONE E M1 EVO PURC REQ
VODAFONE E M2 EVO PURC ORD
VODAFONE E S1 EVO SALES
VODAFONE G 0024002000 GB07 EVO DB GBP
VODAFONE G 0024002001 GB07 EVO DB CLEARIN
VODAFONE G 0024006000 GB07 EVO DB USD
VODAFONE G Z1 EVO N-RECOURSE
VODAFONE G Z2 EVO RECOURSE
VODAFONE G Z3 EVO THIRD
For each company code create the selected red letter with the GL accounts created
6.7 Define Planning Types
Planning types and Memo's
FX Memos
Liquidity Forecast
Planning Level Planning type Post FX memo
DI Z1
Non EVO billing

Post Cash Position
Planning Level Planning type Non EVO billing
AB Z2 memo
Linking a planning level to a planning type will define if the memo posted will appear in the
cash position or liquidity report
184
SAP specifications:
Using the planning type, you control the manual entry of planned memo records. For each planning type, you specify
the level to which the planning type is allocated
the archiving category in which a memo record is stored after it becomes invalid
whether memo records expire automatically
the number range to which the planning type is allocated
Which fields are displayed for the respective planning type, and whether an entry is required or optional in the
fields.
In addition, you specify a mnemonic name that is also displayed when memo records are created.
Role of the object:

Define the respective planning types for manual planning. This object also processes the field status definition.
A planning type is a customized view on the planning table. You might have one view for sales planning
and one for production planning.
A planning type is based on an information structure. This can be either a standard information
structure or a self-defined information structure. You therefore have almost infinite possibilities with
regard to the information you can plan. In other words, planning types provide a flexible tool for the
planning, storage, and analysis of any logistics data. In consistent planning, the information structure
on which a planning type is based is always self-defined.
Information structures are maintained in Customizing for the Logistics Information System (in Maintain
self-defined information structures). If you intend to use the consistent planning method, it must be
created an own information structure.
A planning type defines the content and layout of the lines in the planning table as well as the
mathematical operations, in the form of macros, which can be performed on these lines.
SAP guidelines:
Create your planning types with a two-digit key.

Define each planning type according to your requirements.
Specify the field status (--> Break down field status) for each planning type.
You must make these specifications for two field status groups:
o general data
o additional details
Attribute details:
Technical name V_T037_1-DSART
Field type CHAR
Field length 2
SAP level Client
184
Structuring Manual Planning Define Planning Types
EVO Specifications:
Planned usage:
The EVO solution defines that the system need to different planning types: Non EVO billing, FX memos urgent
payments and physical presence payments.
Non Evo billing memos will reflect in the daily cash position the amounts of the netted amount from the Non Evo
billing costumers outside Evo scope. For that and for urgent and physical payments we will create a planning type to
reflect that in the daily cash position. We can create this using one planning type associated with the new planning
type created non Evo billing. The planning type assigned is the AB. Also we need to activate the check box auto
expire. to set the date that the memo will expire.
For the planning type FX memo, we want that these amounts to be reflected in the liquidity forecast. So for that we
assign the planning level DI to the planning type FX memo. Both urgent payments and physical presence
payments the amounts posted in memos will be reflected in the cash position report.
Area FI
Ownership Global
Plg Plg Archive Auto Planning type

Type Level Cat. Exp. NR text
AB AB A X 01 Confirmed advices
Z1 DI A X 01 FX Memos
Z2 AB A X 01 Non EVO billing
Z3 AB A X 01 Urgent Payments
Z4 AB A X 01 Physical presence
Depending in the eTC upload of information in EVO system, TCM may need a planning level to reflect in the liquidity
forecast movements using
6.8 Define planning levels for Logistics
SAP specifications:
184
In this step, allocation of the transactions from Materials Management (MM) and Sales and Distribution (SD) to the
planning levels that have defined for updating this data.
This allocation is necessary since the system cannot determine the planning level by using the master record fields,
as it does to access data from Financial Accounting (FI).
Role of the object:
In FI, the planning level for G/L accounts is specified in the master record. The specification for sub ledger accounts is
made using the planning group with which the level for FI postings can be determined. However, a business
transaction in Logistics is represented by an internal ID:
1 = purchase requisition
2 = purchase order
3 = scheduling agreement
101 = order
SAP guidelines:
You must assign these transactions to a planning level so that you can distinguish them in Cash Management.
Allocate a planning level you defined before for MM and SD to each of these business transactions.
Attribute details:
Technical name V_T036O-INTEB
Field type NUMC
Field length 3
SAP level Client
Structuring Define planning levels for Logistics
EVO Specifications:
Planned usage:
The EVO solution defines that the system needs to assign planning levels to logistic business transactions.
This to capture the business transactions started in MM and SD (logistic modules) and that could impact in the future
cash movements (expected). So, for forecast accuracy, we need to capture the impact that purchase requisitions,
purchase orders and scheduled agreements and sales orders could have in Vodafone cash forecast and positioning.
Area FI
Ownership Global
184

Int code Level Plan. grp Long text Text

001 M1 Z3 Purchase requisition Purchase Requisition
002 M2 Z3 Purchase order Purchase Order
003 M3 Z3 Scheduling agreement Scheduling Agreement
101 S1 Z3 Sales Orders Order
6.9 Maintain Blocked Levels
SAP specifications:

In this step, blocked levels are allocated for the levels of the liquidity forecast. When a payment is posted with a
blocking indicator, the system then takes the blocked level instead of the standard level of the corresponding planning
group.
Role of the object:
When displaying the liquidity forecast, it can be seen because of the blocked level that the displayed amounts are
postings with payment blocking indicators.
SAP guidelines:
Create an appropriate key for the liquidity forecast levels.
Attribute details:
Technical name V_T036S-GESEB
Field type CHAR
Field length 2
SAP level Client
Structuring Maintain Blocked Levels
EVO Specifications:
Planned usage:
The EVO solution will provide information about what is blocked in the liquidity forecast splitting them from the other
items. These items will be taken in account in the liquidity forecast (in the future can be unblocked and impact the
cash position of the OpCo) but will also be shown in the repost has different items from the others.
184
For that we create the blocking levels showed below in the configuration values.
Area FI
Ownership Global
Level Block ind. Blocked lv Short text Description

F1 XX FI C/V Free for payment
F1 A XA FI C/V Locked for payment
F1 R XR FI C/V Invoice verification
6.10 Define Number Ranges

SAP specifications:

In the "Number ranges" step, you specify one or more number ranges for manual planning.
Role of the object:

The system allocates a number from the appropriate interval to each memo record entered manually.
Enter a two-character ID.
The following fixed number range assignments apply to the application component Cash management:
Memo assignment:
Enter the value 01 to create a number range with internal number assignment.
Attribute details:
Field type CHAR
Field length 2
SAP level Company
Structuring Manual Planning Define Number ranges
EVO Specifications:
184
Planned usage:
One number range will be defined for all the memos. Reporting needs dont require the creation of different number
ranges to different memo types. So we need to create a number range for each company code in the system since
this activity is at company code level definition.
Area FI
Ownership Global
184
7. Exchange Rates Table

Based on the decision document about exchange rates there is some configuration needed in the system to provide
and support the decisions being made in that decision paper
7.1 Types
Planning Rate Average Rate

- Requirement: Inception - Requirement: Inception
- Frequency: Forecast periods - Frequency: Monthly (working day + 1)
- Notes: Rates calculated by Group - Notes: Used for monthly interest accruals
Treasury
Intra-group Settlement Document Rate

Rate (ECM) - Requirement: Inception
- Requirement: Transition
- Frequency: Monthly (approx
Exchange - Frequency: Daily
- Notes: Applying daily exchange rates
23rd of the month)
- Notes: Rate ensures that internal
Rate to documents is best practice and
ensures accurate FX gains/losses.
settlements are booked clearing at
same rates across group.
Types
Central Bank Reporting Central Bank Reporting
Document Rate/s Revaluation Rate/s
- Requirement: Country specific
- Frequency: Daily Group Revaluation Rate - Frequency: Monthly (working day +1)
- Notes: Multiple rates needed as rate will be
- Notes: Multiple rates needed as rate - Requirement: Inception
Opco/country specific. Rate ensures that
will be Opco/country specific. Applying - Frequency: Monthly (working day +1) balance sheet is revalued at central bank
daily exchange rates to documents is exchange rate per legal requirement.
- Notes: Rate is same as Hyperion and so
best practice and ensures accurate FX
ensures no false FX when re-translating
gains/losses.
foreign currency transactions in non-GBP
Opcos.
SAP Specifications
Exchange rates for different purposes for the same date are defined in the system as exchange rate types (cannot
delete existing entries).
Role of the object:
You can define different exchange rates for each currency pair. You then differentiate between these exchange rates
using the exchange rate type.
You need different exchange rates for the following purposes, for example:
Valuation
Conversion
Translation
184
Planning
Attribute details:
Technical name V_TCURV-KURST
Field type CHAR
Field length 4
SAP level Client
General Settings Currencies Check Exchange Rate Types.
EVO Specifications:
Planned usage:
Because of several requirements, we need to use several exchange rate types:
1. Central Bank Reporting Revaluation Rate/s

- Exchange rate type: To Define
- Frequency of updating exchange rate type values using transaction TBEX: Monthly (working day +1)
- Notes: Multiple rates needed as rate will be OpCo/country specific. Rate ensures that balance sheet is
revalued at central bank exchange rate per legal requirement.
2. Group Revaluation Rate
- Requirement: Inception
- Exchange rate type: 100* - Reference value = group value
- Frequency of updating exchange rate type values using transaction TBEX: Monthly (working day +1)
- Notes: Rate is same as Hyperion and so ensures no false FX when re-translating foreign currency
transactions in non-GBP OpCos.
3. Document Rate
- Exchange rate type: M - For posting and clearing, the system uses the exchange rate type M (average rate).
This exchange rate type must be entered in the system and you must also enter the exchange rates for this
type. SAP guideline
- Frequency of updating exchange rate type values using transaction TBEX: Daily
- Notes: Applying daily exchange rates to documents is best practice and ensures accurate FX gains/losses.
4. Central Bank Reporting Document Rate/s

- Exchange rate type: BDXX
- Frequency of updating exchange rate type values using transaction TBEX: Daily
- Notes: Multiple rates needed as rate will be OpCo/country specific. Applying daily exchange rates to
documents is best practice and ensures accurate FX gains/losses.
184
5. Intra-group Settlement Rate (ECM)
- Requirement: Transition
- Exchange rate type: To define
- Frequency of updating exchange rate type values using transaction TBEX: Monthly (approx 23rd of the
month)
- Notes: Rate ensures that internal settlements are booked clearing at same rates across group.
6. Planning Rate
- Exchange rate type: P (Multiple) - The standard system includes exchange rate type P (standard translation
for cost centre accounting).
- Frequency of updating exchange rate type values using transaction TBEX : Forecast periods
- Notes: Rates calculated by Group Treasury
7. Average Rate
- Exchange rate type: 2002 - The standard system includes exchange rate type 2002 (Average exchange rate).
- Frequency: Monthly (working day + 1)
- Notes: Used for monthly interest accruals
After creating this exchange rate types we need to add the necessary exchange rate types when defining Valuation
Methods and defining currencies of leading ledger
Area FI
Ownership Local
ExRt Inv Usage Ref.crcy BCR Buy.rt.at Sell.rt.at Fix EMU

100* Reference value = group value
Central Bank Reporting Revaluation
CBXX Rate Hungary
Central Bank Reporting Document Rate
BDXX Hungary
IGSR Intra-group Settlement Rate (ECM)
M Standard translation at average rate
2002 - Average exchange rate - - - - - -
PX Standard translation for cost planning
X = to enable multiple P rates for each plan plan type
XX=ISO country code
Note1: Both Exchange rate types CBHU - Central Bank Reporting Revaluation Rate Hungary and BDHU - Central
Bank Reporting Document Rate Hungary will be created in the release phase in all countries that have this specific
184
requirement. E.g. - Central Bank Reporting Revaluation Rate Portugal create CBPT using the last to digits the
ISO country code. The maintenance daily or monthly of these rates will be done by the countries.
Note2: For configuration purposes follow also the exchange rate paper configuration document
Exchange rate
configuration paper
7.2 Application
The rates will be applied to translate foreign currency amounts when posting or clearing or to check an exchange rate entered
manually, determine the gain and loss from exchange rate differences and evaluate open items in foreign currency and the foreign
currency balance sheet accounts
The exchange rates are defined by period ("valid from"). When recording an exchange rate we define the date as of which the
exchange rate is effective. When GL accounts are revaluated or posting are made with these exchange rate types defined, the
date used in these actions will pick, for each transaction type, the latest exchange rate maintained using that date (field
V_TCURR-GDATU - Date as of which the exchange rate is effective)
7.3 Rates
The exchange rate types will be maintained in the system using TBEX transaction. The rates that should be
maintained are the following:
Description Rate
Lek ALL
Australian Dollar AUD
Real BRL
Canadian Dollar CAD
Czech Krona CZK
Renminbi CNY
XPF XPF
Kuna HRK
Cyprus Pound CYP
Danish Krone DKK
Egyptian Pound EGP
Krooni EEK
Fiji Dollar FJD
Pound Sterling GBP
Hong Kong Dollar HKD
Forint HUF
Icelandic Krona ISK
Rupee INR
Rupiah IDR
Shekel SHK
Yen JPY
Kenyan Shillling KES
184
Description Rate
Korean Won
South KPW
Kuwait Dinar KWD
Macau Patacas MOP
Maltese Lira MTL
Mexican Peso MXN
Dirham MAD
New Zealand
Dollar NZD
Norwegian Krona NOK
Zloty PLN
Romanian Leu RON
Saudi Riyal SAR
Singapore Dollar SGD
Tolar SIT
South African
Rand ZAR
Slovak Koruna SKK
Swedish Krona SEK
Swiss Franc CHF
Dollar TWD
Baht THB
Turkish Lira TRY
Uganda Shilling UGX
US Dollar USD
ECU / EURO EUR
7.4 Exchange rate triangulation
Reference currency for currency translation - Currency key which should be used for all foreign currency translation for the
exchange rate type in question. Being discussed what is the currency used to be the reference (base) one GBP
SAP specifications:

Currency key which should be used for all foreign currency translation.
Role of the object:

If foreign currency translation is necessary between many different currencies, you can simplify the maintenance of
the exchange rates by specifying a reference currency. You then only have to specify for this exchange rate type the
rates of all currencies in relation to the reference currency. All foreign currency translation is then carried out in two
stages via the reference currency.
184
Attribute details:
SAP transaction IMG
Technical name V_TCURV-BWAER
Field type CUKY
Field length 5
SAP level Client
General Settings Currencies Check Exchange Rate Types.
EVO Specifications:
Planned usage:
For maintaining all exchanges rates against just one currency (for process efficiency) we will maintain all exchange
rates against one rate GBP
Area FI
Ownership Global
Procedure
If you want to use this simplified form of exchange rate maintenance, simply enter the key here for the currency you want to use as
a reference currency.
ExRt Inv Usage Ref.crcy BCR Buy.rt.at Sell.rt.at Fix EMU

M Standard translation at average rate GBP
Example:
Your reference currency is USD. You want to translate 100.00 FRF into DEM. DEM is the local currency of the company code. The
exchange rate table contains the following entries:
GBP USD 0.63000
EUR USD 0.22000
These values give the following (simulated) exchange rate:
EUR GBP 0.34921
184
The currency is then translated as if this were the exchange rate entered in the table.
7.5 FX rounding rules
For the company code/currency combination for which payments are to be made not in the smallest denomination, but in a
multiple of it, enter the currency unit (rounding unit) to which amounts are to be rounded. This ensures that the amounts in this
currency are always rounded to this unit (providing the amounts you enter manually are also rounded in line with your entry). The
payment program evaluates your entries to determine the cash discount and rounds off the amount accordingly.
These rules should be applied using standards defined by each country and the legal / business requirements
8. Appendix A FIMA configuration rational alignment

The accounts used and provided in this document are not definitive. The bank accounts, bank clearing accounts and
other accounts used to support the CBM process design are waiting for some inputs to be definitively established and
the logic maintained in each roll out. This is explained in each step of this document in which the GL accounts are
referenced. The logic and ranges of the accounts were already defined by FIMA below is the approach by FIMA to
TCM requirements:
Treasury and Cash Management

8.1.1 Treatment of exchange rate differences
Guidance from a Group perspective (IFRS leading ledger) is provided by VGIAP 12 from which the following text has
been extracted.
Foreign currency transactions
Foreign currency transactions should be translated into a company's functional currency using the spot rate
on the transaction date. Where exchange rates are stable and do not fluctuate significantly during a period
the following approximations may be used:
- The invoice date may be taken as transaction date provided foreign currency transactions are
promptly invoiced and recorded (normally within one month).
- An approximate exchange rate, such as the average rate for the month or the month end rate may
be used as an alternative exchange rate to the spot rate.
Where a contract or forward exchange rate is applicable, please refer to VGIAP 13a Financial Instruments:
Derivatives and Hedge Accounting.
Translation of foreign currency balances
Monetary assets and liabilities denominated in foreign currency should be retranslated into functional
currency at the end of each period using the closing mid-market rates for the last working day of the period as
advised by Group Finance.
Non-monetary assets and liabilities should not be retranslated but should be carried at their original cost,
typically translated into functional currency at the spot rate effective on the transaction date.
Non-monetary items that are measured at fair value in a foreign currency shall be translated using the
exchange rates at the date when the value was determined.
184
Intercompany balances should be agreed in the functional currency applicable to the transaction (see VGRP
008 paragraph 3.1.1) and retranslated into the functional currency of the reporting entity at the applicable
period end rate.
Exchange gains and losses
Exchange gains and losses will arise where a foreign currency monetary asset or liability is settled, or
translated at the end of a period, at an exchange rate which is different to the exchange rate applicable at the
transaction date.
These exchange gains and losses should be separately identified and reported within the business profit or
loss from ordinary activities as follows:
- Include within operating profit or loss exchange gains and losses arising from trading transactions.
- Include within interest payable or receivable exchange gains and losses arising from financing
arrangements.
8.1.2 Accounts for Exchange rate differences
At the moment we have accounts for the following exchange rate differences in the P&L.
EVO Account V3.1 EVO Account Description Hyperion

8.20.10.000 Forex Gain - Intercompany loans FX - OP5400.FX100
Realised
8.20.11.000 Forex Gain - Intercompany loans FX - OP5400.FX100
Unrealised
8.20.15.000 Forex Loss - Intercompany loans FX - OP5400.FX100
Realised
8.20.16.000 Forex Loss - Intercompany loans FX - OP5400.FX100
Unrealised
8.20.20.000 Forex Gain - Intercompany balances OP5400.FX200
-Realised
8.20.21.000 Forex Gain - Intercompany balances - OP5400.FX200
Unrealised
8.20.25.000 Forex Loss - Intercompany balances - OP5400.FX200
Realised
8.20.26.000 Forex Loss - Intercompany balances - OP5400.FX200
Unrealised
8.20.30.000 Forex Gain - Trade balances FX - realised OP5400.FX300
8.20.31.000 Forex Gain - Trade balances FX - unrealised OP5400.FX300
8.20.35.000 Forex Loss - Trade balances FX - realised OP5400.FX300
8.20.36.000 Forex Loss - Trade balances FX - unrealised OP5400.FX300
8.20.50.000 Forex Gain - Other FX - realised OP5400.FX500
8.20.51.000 Forex Gain - Other FX - unrealised OP5400.FX500
184
8.20.55.000 Forex Loss - Other FX - realised OP5400.FX500

8.20.56.000 Forex Loss - Other FX - unrealised OP5400.FX500
The relationship between payables and receivable accounts and forex gain/loss accounts should be as follows based
on Hyperion logic:
Intercompany loans balance sheet accounts -> FX100
Intercompany payables and receivables -> FX200
Trade payables (TRCxx) and receivables (TRDxxx) -> FX300
Other payables and receivables -> FX500
Most of the inter-company loans are denominated in the local currency of the OpCo foreign exchange differences on
inter-company loans normally reside with the holding companies.
8.1.3 Account for bank charges
6.93.20.000 Bank charges: Hyperion relationship OCS1200
Definition based on Hyperion:
Charges levied by banks for the ongoing management of company bank accounts and transaction charges (e.g. bank
transfers, returned cheques).
Direct debits / cost of collecting customer money should be treated as direct costs and reported in OCS1200. Other
bank charges that are not linked to customer revenues (e.g. foreign exchange settlements), should be treated as
overheads and reported in other overheads - other (OH1800).
8.1.4 Bank clearing accounts and bank accounts
Response: EVO GL will support the following approach outlined at the FIMA CRP.
D:\Profiles\fwilkinson\
FIMEVO Bank account GLs.ppt
8.1.5 Potential extra accounts that will be requested by TCM
Request: There are some accounts that we probably need in order to have the information of treasury (VF Group
treasury) in terms of financial instruments (bonds, swaps) but they are not yet defined. When do we have to give this
information? Because I think this can be treated as localization (VF group treasury).
FIMA Response: The EVO GL is currently based around Group reporting requirements (principally Hyperion), and
has a high degree of flexibility to support the EVO roll-out.
As such, detailed Treasury accounts can be accommodated later as localization. However, you may wish to review
version 3.0 of the EVO GL to ensure that requirements can be logically accommodated.
184
9. Appendix B Steps involved in new OpCo setup in IHC and Test

script
The steps required when a new OpCo is used in IHC are described below. Each time a new OpCo is added to IHC
via release or if a new company is bought by Vodafone these steps as to be followed. All the steps have specific and
detailed settings described or in this configuration rational or in master data documents. Also the majority of the steps
are when its created an IHC centre and not the subsidiary new OpCo. Nevertheless the steps involved are
described in this section:
After a company code is created in the system the steps are the following:
Create business partner follow instructions described in document cbmMDA_AP363 Business Object
Definitions_Business Partners Data Definition v1 4
Process Partner Profiles for Business Partners Manually in this document
Process Partner Profiles Manually for Logical Systems in this document
Set up payment methods per country for payment transactions - in this document
Set up Payment methods per Company code for payment transactions - in this document
Define House Banks intercompany settlements - in this document
Bank determination - in this document
Create Customer / Vendor account Intercompany - in this document
Create IHC GL bank account and bank clearing account - in this document
Create IHC ST accounts in each transactional currency VOCH bank area - Create IHC LT accounts in each
transactional currency LT bank areas - follow instructions described in document cbmMDA_AP363
Business Object Definitions_IHC account creation_v0 3
Create interests if needed - follow instructions described in document cbmMDA_AP363 Business Object
Definitions_Conditions_v0 3 and Interest V0 3
Update Hierarchies for cash concentration purposes - follow instructions described in document
cbmMDA_AP363 Business Object Definitions_AccountsHierarchy
Update variants for end of day processing for each report - in this document
Setup for uploading bank statements and reflecting that in the IHC call accounts - Non-invoice driven VOCH
call account changes V0 3
Setup for cash concentration between ST call accounts and long term call accounts - Reassignment of short
term IHC call account positions to long term call accounts V0 3
Also the steps for master data creation are defined in ARIS for Business partners, IHC Account creation, Interests and
account hierarchy (Cash concentration)
Creating a new IHC centre:
184
ALE - Application Link Enabling - Customizing in the SAP In-House Cash System - section 3.2.1 of this
document
Define In-House Cash Centre as Bank section 3.2.1.7 of this document
Follow steps in section - 3.4.2 Customizing the In-House Cash Centre
Testing script data and expected output in intercompany settlements process using In House Cash (see
below)
Test Script
184

Documents - Tips - Configrationale FSCM Ihc

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Documents - Tips - Configrationale FSCM Ihc

Hochgeladen von

Copyright:

Verfügbare Formate

Project

4.8.2.4 Account Management...................................................................................................................... 60

5.3.2 Activate Bank Chain.......................................................................................................................... 127

1.2.1 Target audience

1.2.2 Document lifecycle

2. Configuration rationale details

For each key parameter the following information are reported:

3. Principles guiding design and configuration

Improve control Consolidate presence

Eliminate current manual interfaces

Reduce cost structure

4. SAP In House Cash

4.1 Key decisions regarding In House Cash

4.2 Benefits of In House cash

Implementation of the IHC component for recourse intercompany settlements will:

Eliminate need to manually populate Excel spreadsheets

4.3 Internal Payments

Task Department Description

4.4 Periodic Processing JOB CHAIN and Closing cockpit

Cash concentration (reassignment of short term balances to LT balances) Detailed in document

1. Choose new entries.

2. Enter the report name and the description.

Create report to be run at end of the day:

1. Choose the processing sequence.

3. Choose individual steps

4.4.1 End of day processing

In terms of configuration this are the reports to support this activities

4.4.2 Month end processing

RFBKPDT2: Set Payment Transaction Posting Date

Posting Date for Payment Transactions

Posting Date for Account Balancing

Dispatch of internal Bank Statements

The dispatch of bank statements will be executed on a daily basis

The postings that are generated are the following:

o clearing of open items on customer accounts at recipient of internal payment

o clearing of open items on bank clearing accounts at sender of internal payment

o postings of payment transactions, charges, interest

The General Ledger Transfer in IHC

IHC = sub ledger

Balance Sheet Preparation

Transfer to the final account

Transfer of trading partner number

Implemented Notes for In House Cash

SAP Note Title of SAP Note Usage

all trading partner

4.5 Organizational Units

4.5.1 Company Codes

For configuration purposes and more detail - cbmFI_AP326_Configuration_Rationale_R2R

4.6 Integration of Systems

This section contains information about integrating system landscape.

1 Defining and configuring logical systems

In House Cash Centre

Same system landscape for all entities

4.6.1.1 Define Logical System

Meaning of the object:

Role of the object:

This is the planned usage for the object:

To create a logical system, choose Edit -> New Entries.

4.6.1.2 Assign Logical System to Client

Meaning and role of the object:

This is the planned usage for the object:

Field name Description User Action and Values

4.6.1.3 Define Target Systems for RFC Calls