Professional Documents
Culture Documents
Documents - Tips - Configrationale FSCM Ihc
Documents - Tips - Configrationale FSCM Ihc
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
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:40 PM Page 3 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Modified: 6/16/2017 5:40 PM Page 4 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Modified: 6/16/2017 5:40 PM Page 5 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Modified: 6/16/2017 5:40 PM Page 6 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
From these project goals, the TCM workstream identified the micro-principles to drive the design:
Modified: 6/16/2017 5:40 PM Page 7 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Modified: 6/16/2017 5:40 PM Page 8 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Modified: 6/16/2017 5:40 PM Page 9 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Modified: 6/16/2017 5:40 PM Page 10 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
This is the description off all the process of internal payments. The responsibility of TCM is only after step 2.
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
Modified: 6/16/2017 5:41 PM Page 11 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
Modified: 6/16/2017 5:41 PM Page 12 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
2. Create the processing sequence. Issue the key and appropriate names for the processing sequence. You can
freely choose the key.
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.
Modified: 6/16/2017 5:41 PM Page 13 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 14 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
RFBKCLEB: Set Balancing Posting Date (only when Acct Balancing is scheduled)
RFBKGLBSPREP: Balance Sheet Preparation
RFBKGL01: General Ledger Transfer
The following reports should be included within the month end processing in this sequence the difference is the
cash concentration only done monthly:
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
Modified: 6/16/2017 5:41 PM Page 15 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
The posting date for all account balancing items must be the last day of the month.
Modified: 6/16/2017 5:41 PM Page 16 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
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
Modified: 6/16/2017 5:41 PM Page 17 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
SSC
VOCH
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
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
Modified: 6/16/2017 5:41 PM Page 18 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
SAP specifications:
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 19 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
Here you assign a client to the system for SAP In-House Cash.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name T000-MANDT
Field type CLNT
Field length 3
SAP level Client
Configuration steps:
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
For this customizing process the values that should be already there for this step are
Modified: 6/16/2017 5:41 PM Page 20 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
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:
Attribute Description
SAP transaction SM59
Technical name -
Field type -
Field length -
SAP level -
Configuration steps:
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling
(ALE) Communication Create RFC Connections
Modified: 6/16/2017 5:41 PM Page 21 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
N/A
SAP specifications:
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.
Configuration steps:
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
Configuration values:
Carry the following activity because SAP In-House Cash and the OpCos are in the same client.
Modified: 6/16/2017 5:41 PM Page 22 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
Attribute details:
Attribute Description
SAP transaction WE20
Technical name VEDI_TDPP1-PARNUM
Field type CHAR
Field length 10
SAP level
Configuration steps:
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Modified: 6/16/2017 5:41 PM Page 23 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
You have to make entries for each OpCo. You can copy the entries as follows:
Select the partner.
Choose Create Copy.
Attribute Description
SAP transaction WE20
Technical name VEDI_TDPP1-PARNUM
Field type CHAR
Field length 10
SAP level Company code
Configuration steps:
SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and
EDI Basis Administration Partner profile
Modified: 6/16/2017 5:41 PM Page 24 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Choose Create.
Modified: 6/16/2017 5:41 PM Page 25 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
- FI of head office is
in the same client as
IHC
Receiver port Receiver port The port you generated
Process code Basic type PEXR
Syntax check Syntax check Select
Processing by function Processing by function
Trigger immediately
module module
SAP specifications:
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:
Attribute Description
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Modified: 6/16/2017 5:41 PM Page 26 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration Values:
SAP specifications:
In this IMG activity, you can define one function per country for creating a BBAN (Basic Bank Account Number)
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:
Attribute Description
SAP transaction SM30
Technical name V_TBKK06 - FBNAME
Field type CHAR
Field length 30
SAP level Company code
EVO Specifications:
Planned usage:
Modified: 6/16/2017 5:41 PM Page 27 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration Values:
In transaction SM30 on the Maintain table view: Initial Screen, enter V_TBKK06 in Table/View field, and then
choose the Maintain button.
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
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.
Modified: 6/16/2017 5:41 PM Page 28 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCVAR-GLVAR
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash periodic tasks Maintain GL variant
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
The transfer of the values in the IHC account and the IHC G/L account will be done daily
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 29 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
SAP specifications:
Here you define the system for the OpCo and the system for SAP In-House Cash.
Attribute details:
Attribute Description
Technical name V_TBDLS-LOGSYS
Field type CHAR
Field length 10
SAP level
Configuration steps:
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling
(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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Modified: 6/16/2017 5:41 PM Page 30 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
Attribute details:
Attribute Description
SAP transaction
Technical name T000-MANDT
Field type CLNT
Field length 3
SAP level
Configuration steps:
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration Values:
Modified: 6/16/2017 5:41 PM Page 31 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
4.6.2.3 Configure Systems in Network, Define Target Systems for RFC Calls
SAP specifications:
Here you define the SAP In-House Cash system as your target system.
Attribute details:
Attribute Description
SAP transaction SM59
Technical name -
Field type -
Field length -
SAP level Client
Configuration steps:
SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling
(ALE) Communication Create RFC Connections
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Modified: 6/16/2017 5:41 PM Page 32 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration Values:
Here you create the in-house cash centre as your house bank in partner type B.
Attribute details:
Attribute Description
SAP transaction WE20
Technical name VEDI_TDPP1-PARNUM
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and
EDI Basis Administration Partner profile
EVO specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration Values:
Modified: 6/16/2017 5:41 PM Page 33 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
SAP specifications:
Attribute details:
Attribute Description
SAP transaction WE 20
Technical name -
Field type -
Field length -
SAP level Client
Configuration steps:
SAP Easy Access Tools ALE ALE Administration Runtime Settings Port Maintenance Partner
Profiles
Modified: 6/16/2017 5:41 PM Page 34 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration Values:
SAP specifications:
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.
Modified: 6/16/2017 5:41 PM Page 35 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction Transaction: FBZP
Technical name V_T042ZL-ZLSCH
Field type CHAR
Field length 1
SAP level Company Code
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Core
Modified: 6/16/2017 5:41 PM Page 36 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Coding rule:
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
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 37 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 38 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
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:
Attribute Description
Modified: 6/16/2017 5:41 PM Page 39 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
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 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.
Attribute Description
Area FI
Ownership Op but following Global methodology
Expected activity Core
Change management CTS
Coding rule:
Not applicable because for each company code and payment method several fields will be filled.
Configuration values:
The combination between company codes and payment transaction will be defined during localization.
Modified: 6/16/2017 5:41 PM Page 40 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 41 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
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.
Modified: 6/16/2017 5:41 PM Page 42 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
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.
Modified: 6/16/2017 5:41 PM Page 43 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction Transaction: FBZP
Technical name V_T042BD-ZBUKR
Field type CHAR
Field length 4
SAP level Company code
Configuration steps:
Financial Accounting -> Accounts Receivable and Accounts Payable -> Business Transactions -> Outgoing Payments
-> 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.
Attribute Description
Area FI
Ownership Op Co
Expected activity Core
Change management CTS
Coding rule:
Not applicable because for each paying company code several fields will be filled.
Modified: 6/16/2017 5:41 PM Page 44 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
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.
This is the planned usage for the object:
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.
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.
Modified: 6/16/2017 5:41 PM Page 45 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Note: The previous tables are just an example. The final ones should contain the details specified by company code.
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.
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.
SAP guidelines:
Several house banks are supplied as examples in the standard system in order to enable configuration of the
payment program.
Attribute details:
Attribute Description
SAP transaction FI12
Technical name V_T012-HBKID
Field type CHAR
Field length 5
SAP level Company Code
Configuration steps:
SAP Netweaver General settings Set countries Set country-specific checks
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Modified: 6/16/2017 5:41 PM Page 46 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
EDI partner:
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.
SAP specifications:
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
Modified: 6/16/2017 5:41 PM Page 47 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction Transaction: FBZP
Technical name V_T042BD-ZBUKR
Field type CHAR
Field length 4
SAP level Company code
Configuration steps:
Financial Accounting -> Accounts Receivable and Accounts Payable -> Business Transactions -> Outgoing Payments
-> 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.
Modified: 6/16/2017 5:41 PM Page 48 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
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.:
Note: The previous tables are just an example. The final ones will contain the details specified by company code.
SAP specifications:
Modified: 6/16/2017 5:41 PM Page 49 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name IHC_V_BANK_AREA-BKKRS
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Enter a bank area and the global settings. Take account the meaning and the values for the following fields:
Modified: 6/16/2017 5:41 PM Page 50 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
SAP specifications:
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:
Attribute Description
SAP transaction IHCN1
Technical name INRDP-NRRANGENR
Field type CHAR
Field length 2
SAP level Client
Configuration steps:
Financial Supply Chain Management In-House Cash Basic Settings Set Up Number Ranges for Log
EVO Specifications:
Planned usage:
Modified: 6/16/2017 5:41 PM Page 51 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
To Log the payment orders regarding technical reasons it must be defined a number log.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
Attribute details:
Attribute Description
SAP transaction IHCN3
Technical name INRDP-NRRANGENR
Field type CHAR
Field length 2
SAP level Client
SAP guidelines:
Modified: 6/16/2017 5:41 PM Page 52 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
SAP specifications:
Set how the transfer of the general ledger data to financial accounting is to take place.
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.
Modified: 6/16/2017 5:41 PM Page 53 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name TBKK00-GL_TRANSFERTYPE
Field type CHAR
Field length 1
SAP level Bank area
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Basic Settings Basic Settings - Postings
Set +/- Sign Postings/GL Transfer/Name Check
EVO Specifications:
Planned usage:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 54 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
SAP specifications:
The business transaction event (BTE) interface can be used to transfer created or changed material master data to
customer-defined processes.
Attribute details:
Attribute Description
SAP transaction BF11
Technical name
Field type
Field length 1
SAP level Client
Configuration steps:
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.
Modified: 6/16/2017 5:41 PM Page 55 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
SAP specifications:
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:
Attribute Description
SAP transaction F9MBP
Technical name V_TBKKH1-PRODEXT
Field type CHAR
Field length 10
SAP level Bank Area
Configuration steps:
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.
Modified: 6/16/2017 5:41 PM Page 56 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
4.8.2.2.1.1 Conditions
SAP specifications:
Attribute details:
Attribute Description
SAP transaction F98E
Technical name BKK83-CONDAREA
Field type CHAR
Field length 4
SAP level Bank Area
Configuration steps:
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.
Attribute Description
Area FI
Modified: 6/16/2017 5:41 PM Page 57 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Ownership Global
Expected activity Release
Change management CTS
SAP specifications:
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKM9-BKST_FORMAT
Field type CHAR
Field length 6
SAP level Bank Area
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Master Data Account Maintain
Formats for Bank Statements
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
1 FINSTA
Modified: 6/16/2017 5:41 PM Page 58 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
Clearing account: Bank-internal account on which transaction charges and transaction interest are stored.
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.
Attribute Description
SAP transaction SPRO
Technical name V_TBKK01D-CHARGE_ACT
Field type CHAR
Field length 35
SAP level
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Account Management Maintain
Accounts for Payment Transactions
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 59 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCVAR-GLVAR
Field type CHAR
Field length 4
SAP level
Modified: 6/16/2017 5:41 PM Page 60 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
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.
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:
Modified: 6/16/2017 5:41 PM Page 61 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP supplies example settings for general ledger accounts. Review these and adapt them to suit the chart of
accounts you use.
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCCLR-GLACCT_CLR
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
Transfer Postings Payables/Receivables
EVO Specifications:
Planned usage:
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
Select GL variant defined and enter a receivables and a payables account for every clearing account.
*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
Modified: 6/16/2017 5:41 PM Page 62 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCACT-GLACT
Field type CHAR
Field length 6
SAP level Client
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
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.
Attribute Description
Modified: 6/16/2017 5:41 PM Page 63 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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:
For the general ledger transfer, assign a general ledger transaction type to each transaction type in
the current account system.
Modified: 6/16/2017 5:41 PM Page 64 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP guidelines:
You can assign several payment transaction types to one general ledger transaction type.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCTTP-TRNSTYPE
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
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.
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
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
In-House Cash Center
IHCE 1010 EVO Debit interest 8010 Deb. Interest (Customer)
In-House Cash Center
IHCE 1020 EVO Plus Debit Interest 8010 Deb. Interest (Customer)
In-House Cash Center
IHCE 1100 EVO Overdraft Interest 8010 Deb. Interest (Customer)
In-House Cash Center
IHCE 1150 EVO Minus Credit Interest 4010 Cred. Interest (Customer)
In-House Cash Center
IHCE 1300 EVO Direct Charges 8020 Charges
IHCE 2015 In-House Cash Center Treasury Deal - Debit 2015 Treasury Deals Debit
Modified: 6/16/2017 5:41 PM Page 65 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
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:
Attribute Description
SAP transaction SPRO
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
Configuration rationale 358155987.doc 2.4
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
SAP specifications:
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
Modified: 6/16/2017 5:41 PM Page 67 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKCGRP-GLGRP
Field type CHAR
Field length 4
SAP level
Configuration steps:
SPRO Financial Supply Chain Management In-House Cash Periodic Tasks General Ledger Transfer
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:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 68 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
*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).
Modified: 6/16/2017 5:41 PM Page 69 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
**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.
SAP guidelines
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:
Attribute Description
SAP transaction BP
Technical name BUS_JOEL_MAIN-CHANGE_NUMBER
Field type CHAR
Field length 10
SAP level
Configuration steps:
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
Modified: 6/16/2017 5:41 PM Page 70 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
SAP guidelines
SAP guidelines:
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:
Attribute Description
SAP transaction F9K1
Technical name IBKK50-ACNUM_EXT
Field type CHAR
Field length 35
SAP level
Configuration steps:
SAP Easy Access In-House Cash Account Create
EVO Specifications:
The account is the central object of the current IHC account system.
Modified: 6/16/2017 5:41 PM Page 71 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
SAP guidelines
SAP guidelines:
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:
Attribute Description
SAP transaction FD01 / FK01
Technical name RF02D-KUNNR / RF02K-LIFNR
Field type CHAR
Field length 16
SAP level
Configuration steps:
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
Modified: 6/16/2017 5:41 PM Page 72 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
This is the planned usage for the object:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management
Configuration values:
Create Costumer:
Activate flag Payment Advice by EDI in the Payments tab of the company code details
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 type the payment program will pay the vendor via the previously predefined bank (IHC house
bank)
Modified: 6/16/2017 5:41 PM Page 73 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
SAP guidelines
Modified: 6/16/2017 5:41 PM Page 74 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_T015L-LZBKZ
Field type CHAR
Field length 3
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
SAP specifications:
Modified: 6/16/2017 5:41 PM Page 75 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP guidelines:
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.
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:
Attribute Description
SAP transaction F9B1
Technical name PDAT_NEW
Field type DATS
Field length 4
SAP level
Configuration steps:
Sap Easy Access Accounting Financial Supply Chain Management In-House Cash Periodic
Processing Posting Date Payment Transactions
SAP specifications:
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:
Attribute Description
Modified: 6/16/2017 5:41 PM Page 76 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
Sap Easy Access Accounting Financial Supply Chain Management In-House Cash Periodic
Processing Posting Date Closing
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:
Modified: 6/16/2017 5:41 PM Page 77 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
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.
Modified: 6/16/2017 5:41 PM Page 78 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name IHC_V_BANK_AREA-BKKRS
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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
Modified: 6/16/2017 5:41 PM Page 79 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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:
Modified: 6/16/2017 5:41 PM Page 80 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
The maximum balance, amounts above which are transferred to a superior account.
Attribute details:
Attribute Description
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Transition phase Values should be setup in IHC accounts and Account Hierarchy based on the Master Data Object
definition for these two objects.
End Game Values should be setup following IHC accounts and Account Hierarchy based on the Master Data
Object definition for these two objects.
Modified: 6/16/2017 5:41 PM Page 81 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Then download the results to an excel spreadsheet and send to Vodafone Group Treasury
Modified: 6/16/2017 5:41 PM Page 82 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
Modified: 6/16/2017 5:41 PM Page 83 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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)
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
Modified: 6/16/2017 5:41 PM Page 84 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 85 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Modified: 6/16/2017 5:41 PM Page 86 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Modified: 6/16/2017 5:41 PM Page 87 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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 -
Modified: 6/16/2017 5:41 PM Page 88 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 89 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
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.
Modified: 6/16/2017 5:41 PM Page 90 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Scaled calculation
Interval calculation
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
Modified: 6/16/2017 5:41 PM Page 91 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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
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.
Modified: 6/16/2017 5:41 PM Page 92 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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
Modified: 6/16/2017 5:41 PM Page 93 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
Modified: 6/16/2017 5:41 PM Page 94 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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:
Attribute Description
SAP transaction SPRO
Technical name V_T033I_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
Configuration steps:
Modified: 6/16/2017 5:41 PM Page 95 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
For cash sweep purposes for the GL accounts described below an account symbol will be defined:
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
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:
Modified: 6/16/2017 5:41 PM Page 96 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
SAP transaction SPRO
Technical name V_T033G_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 97 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
This field specifies the rules for posting in the general ledger and sub ledger.
Assign posting rules to possible transactions in account statement file. In this activity you enter descriptions for the
necessary posting rules.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T028D-VGINT
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
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.
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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 ).
Modified: 6/16/2017 5:41 PM Page 98 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
You use the posting specifications to specify how a certain business transaction is to be posted in the G/L accounts.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T033F_EBST-EIGR1
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
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.
Attribute Description
Area FI
Ownership Local
Expected activity Release
Modified: 6/16/2017 5:41 PM Page 99 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
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)
Search strings establish rules that increase the possible number of direct clearances when the electronic bank
statement is uploaded.
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
Attribute Description
SAP transaction SPRO
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
Configuration rationale 358155987.doc 2.4
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Define Search String for Electronic Bank Statement
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.
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:
Attribute Description
SAP transaction SPRO
Technical name V_T028V-VGTYP
Field type CHAR
Field length 8
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
EVO Specifications:
Planned usage:
Modified: 6/16/2017 5:41 PM Page 101 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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)
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
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:
Modified: 6/16/2017 5:41 PM Page 102 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
SAP transaction SPRO
Technical name V_T028G-VGEXT
Field type CHAR
Field length 27
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
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:
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.
Modified: 6/16/2017 5:41 PM Page 103 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
For cheques we use the cheque number. For incoming/outgoing payments we use the Document number / Reference
document number
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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).
Banks are identified by specifying bank keys and external or internal account numbers. To do this, select the step
Allocate banks to transaction types.
Modified: 6/16/2017 5:41 PM Page 104 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T028B-VGTYP
Field type CHAR
Field length 8
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Business Transactions Payment Transactions Electronic Bank
Statement Make Global Settings for Electronic Bank Statement
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.
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 105 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute details:
Attribute Description
SAP transaction FIBF
Technical name TBE22-PRDKT
Field type CHAR
Field length 8
SAP level Cross - Client
Configuration steps:
Activities
Modified: 6/16/2017 5:41 PM Page 106 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
EVO Specifications:
Planned usage:
IHC should be defined in this transaction to be able to process the incoming bank statements
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Product Partner
TBE22-PRDKT TBE22-PARTY
IHC IHC
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.
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.
Modified: 6/16/2017 5:41 PM Page 107 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_TBKKIHB6-BANKL
Field type CHAR
Field length 15
SAP level Client
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 108 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
IHC MT940
In this IMG activity you specify the FI account and In-House Cash Centre to which you want to post the inbound bank
statement.
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:
Attribute Description
SAP transaction SPRO
Technical name IHC_DB_CL_XBS-BUKRS
Field type CHAR
Field length 4
SAP level Client
Modified: 6/16/2017 5:41 PM Page 109 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
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:
IHC should be defined in this transaction to be able to process the incoming bank statements
Attribute Description
Area SPRO
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
In this IMG activity you determine how incoming bank statements are processed and updated.
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.
Modified: 6/16/2017 5:41 PM Page 110 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name IHC_DB_CL_XBS-BUKRS
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
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:
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)
Attribute Description
Area SPRO
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 111 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
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.
Modified: 6/16/2017 5:41 PM Page 112 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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:
Attribute Description
SAP transaction --
Technical name --
Field type --
Field length --
SAP level Client
Configuration steps:
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.
Modified: 6/16/2017 5:41 PM Page 113 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 114 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Payment file Bank Statement Payment file Bank Statement Payment file Bank Statement
Modified: 6/16/2017 5:41 PM Page 115 of Last modified by: Romo Navarrete, Pablo
System A System B System C
184
OpCo A OpCo B OpCo C
Configuration rationale 358155987.doc 2.4
Vodafone To-Be:
Vendor Customer
Cash Cash
Deutsche Bank
FI-BL
Vodafone
EVO System
Modified: 6/16/2017 5:41 PM Page 116 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
To enable all bank master data to be checked during master data maintenance.
Attribute details:
Attribute Description
SAP transaction OY17
Technical name V_005_B-LAND1
Field type CHAR
Field length 3
SAP level Client
Configuration steps:
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.
Modified: 6/16/2017 5:41 PM Page 117 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 118 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Modified: 6/16/2017 5:41 PM Page 119 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Modified: 6/16/2017 5:41 PM Page 120 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Account
Country Local clearing code number
INDIA Max. 9 an Max. 19 an
Modified: 6/16/2017 5:41 PM Page 121 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Max. 7 an (first 4 positions used
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
Max. 7 an (first 3 positions used
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
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.
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.
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:
Attribute Description
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
SAP level Company Code
Configuration rationale 358155987.doc 2.4
Configuration steps:
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):
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 123 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Example:
Vendor requests payment via an intermediary bank e.g Pay X bank, with further credit to X bank .
generally, i.e. not dependent on certain business partner bank details (general search)
SAP guidelines:
Modified: 6/16/2017 5:41 PM Page 124 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_TBCH0-CHAINSCEN
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 125 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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:
Attribute Description
SAP transaction SPRO
Technical name TBCHAINC0-CHAINSCEN
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Bank Accounts Activate Bank Chain
EVO Specifications:
Planned usage:
The bank chains scenarios used will be the provided SAP standards:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Use bank chain standard scenarios. For that we need to activate the 4 scenarios provided:
Modified: 6/16/2017 5:41 PM Page 126 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_TBCH2-CHAINID
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
Financial Accounting Bank Accounting Bank Accounts Create General Bank Chain
EVO Specifications:
Planned usage:
For each
Attribute Description
Area FI
Modified: 6/16/2017 5:41 PM Page 127 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
For each case that Vodafone needs a correspondent bank, the values will be defined in the configuration step
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.
Define the factory calendar for payment currency and bank country.
Attribute details:
Attribute Description
SAP transaction F8BC
Technical name V_TBKFK - WAERS
Field type CHAR
Field length 2
SAP level Client
Modified: 6/16/2017 5:41 PM Page 128 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Use the F8BC transaction to display the configuration values.
Modified: 6/16/2017 5:41 PM Page 129 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP Specifications
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
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:
Attribute Description
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:
Modified: 6/16/2017 5:41 PM Page 130 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Planned usage:
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
The customizing path is: Financial Accounting (New) Financial Accounting Global Settings (New) - Document
Tolerance Group
.
Tol. Group for Financial Max Allowable Rev. from Payment Max. Exp. Permitted from Payment Diff.
Modified: 6/16/2017 5:41 PM Page 131 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 132 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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:
Modified: 6/16/2017 5:41 PM Page 133 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
After any modifications that may exist, the account symbols lead to one account.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T033I_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
Configuration steps:
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
Modified: 6/16/2017 5:41 PM Page 134 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
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
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.
Modified: 6/16/2017 5:41 PM Page 135 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
After assigning G/L account to the account number the account symbol leads to G/L accounts.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T033G_EBST-KTOSY
Field type CHAR
Field length 15
SAP level Client
Configuration steps:
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.
Modified: 6/16/2017 5:41 PM Page 136 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 137 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
This field specifies the rules for posting in the general ledger and sub ledger.
Assign posting rules to possible transactions in account statement file. In this activity you enter descriptions for the
necessary posting rules.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T028D-VGINT
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
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.
Attribute Description
Area FI
Ownership Local
Expected activity Release
Modified: 6/16/2017 5:41 PM Page 138 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
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.
Note: The previous table is just an example. The final one will contain the details specified during build phase.
Also to allow the bank statement upload without error with GVO codes a posting key has to be defined for
Unallocated:
Modified: 6/16/2017 5:41 PM Page 139 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
You use the posting specifications to specify how a certain business transaction is to be posted in the G/L accounts.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T033F_EBST-EIGR1
Field type CHAR
Field length 10
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 140 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 141 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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.
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.
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:
Attribute Description
SAP transaction SPRO
Technical name V_T028V-VGTYP
Field type CHAR
Field length 8
SAP level Client
Configuration steps:
EVO Specifications:
Modified: 6/16/2017 5:41 PM Page 142 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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)
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
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:
Modified: 6/16/2017 5:41 PM Page 143 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_T028G-VGEXT
Field type CHAR
Field length 27
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Modified: 6/16/2017 5:41 PM Page 144 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
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).
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.
Modified: 6/16/2017 5:41 PM Page 145 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name V_T028B-VGTYP
Field type CHAR
Field length 8
SAP level Client
Configuration steps:
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.
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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.
Modified: 6/16/2017 5:41 PM Page 146 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
An interpretation algorithm enables you to find separate outgoing payments using the reference information returned
by the bank.
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).
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.
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.
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
Modified: 6/16/2017 5:41 PM Page 147 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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).
This algorithm finds the check number in the note to payee lines either per algorithm 11 or per algorithm 12.
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.
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).
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.
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.
Modified: 6/16/2017 5:41 PM Page 148 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
This algorithm searches for the Payment reference supplied by the Finnish TITO account statement format.
This algorithm is the same as algorithm 027. The account statement files are imported in MULTICASH format.
The algorithm uses number range BELNR.
This algorithm searches using the payment order number. The algorithm uses number range XBELNR.
Modified: 6/16/2017 5:41 PM Page 149 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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.
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.
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.
Modified: 6/16/2017 5:41 PM Page 150 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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
Attribute details:
Attribute Description
SAP transaction SPRO
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
Configuration rationale 358155987.doc 2.4
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Note: The previous table is just an example. The final one will contain the details specified during build phase.
SAP specifications:
Modified: 6/16/2017 5:41 PM Page 152 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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:
Attribute Description
SAP transaction OB09
Technical name T030H
Field type -
Field length -
SAP level Client Dependent
Configuration steps:
EVO specifications:
Additional Details:
Modified: 6/16/2017 5:41 PM Page 153 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
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:
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
Configuration rationale 358155987.doc 2.4
Planning Levels
Modified: 6/16/2017 5:41 PM Page 155 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
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.
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:
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
Modified: 6/16/2017 5:41 PM Page 156 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute Description
SAP transaction SPRO
Technical name EBENE
Field type Char
Field length 2
SAP level Client
Configuration steps:
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:
The basic information needed for this account group is the following:
Modified: 6/16/2017 5:41 PM Page 157 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
EVO global design model, to reflect the amounts, the configuration of the planning level will be done as followed:
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
The short text will be displayed in the report and the length of field is 10 Char.
Modified: 6/16/2017 5:41 PM Page 158 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Note: this will be used to post the memo of non-Evo billing receipt expected, urgent payments, physical presence
payments, roaming payments and receipts
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.
Bank accounting
Sub ledger accounting
Materials management
Sales and distribution
SAP guidelines:
Modified: 6/16/2017 5:41 PM Page 159 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Create a symbol for data from Materials Management and a symbol for data from Sales and Distribution.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T039-ORIGN
Field type Char
Field length 3
SAP level Client
Configuration steps:
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.
Attribute Description
Area FI
Ownership Global
Expected activity Core
Change management CTS
Configuration values:
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
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.
Configuration rationale 358155987.doc 2.4
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.
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T035-GRUPP
Field type Char
Field length 10
SAP level Client
Configuration steps:
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
Modified: 6/16/2017 5:41 PM Page 161 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
SAP specifications:
In this step, you assign a mnemonic name as the cash management account name to each bank account and bank
clearing account.
Attribute details:
Attribute Description
SAP transaction Spro
Technical name DISKB
Field type Char
Field length 10
SAP level Client
Configuration steps:
Modified: 6/16/2017 5:41 PM Page 162 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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
M3 Scheduling agreement
S1 Sales Orders
SAP specifications:
SAP guidelines:
Check the standard planning levels and change them if necessary.
Attribute details:
Attribute Description
SAP transaction OT12
Technical name V_T036-EBENE
Field type CHAR
Field length 2
SAP level
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
Structuring Groupings Define Groupings and Maintain Headers
EVO Specifications:
Modified: 6/16/2017 5:41 PM Page 164 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
SAP specifications:
Modified: 6/16/2017 5:41 PM Page 165 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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:
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T038-GLIED
Field type CHAR
Field length 10
SAP level
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
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.
Modified: 6/16/2017 5:41 PM Page 166 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
For each company code create the selected red letter with the GL accounts created
FX Memos
Liquidity Forecast
Planning Level Planning type Post FX memo
DI Z1
Linking a planning level to a planning type will define if the memo posted will appear in the
cash position or liquidity report
Modified: 6/16/2017 5:41 PM Page 167 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
SAP specifications:
Meaning of the object:
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.
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:
Attribute details:
Attribute Description
SAP transaction OT21
Technical name V_T037_1-DSART
Field type CHAR
Field length 2
SAP level Client
Modified: 6/16/2017 5:41 PM Page 168 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Depending in the eTC upload of information in EVO system, TCM may need a planning level to reflect in the liquidity
forecast movements using
SAP specifications:
Modified: 6/16/2017 5:41 PM Page 169 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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).
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:
Attribute Description
SAP transaction SPRO
Technical name V_T036O-INTEB
Field type NUMC
Field length 3
SAP level Client
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
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.
Attribute Description
Area FI
Ownership Global
Modified: 6/16/2017 5:41 PM Page 170 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Configuration values:
SAP specifications:
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:
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_T036S-GESEB
Field type CHAR
Field length 2
SAP level Client
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
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.
Modified: 6/16/2017 5:41 PM Page 171 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
For that we create the blocking levels showed below in the configuration values.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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:
Attribute Description
SAP transaction OT21
Technical name INRDP-NRRANGENR
Field type CHAR
Field length 2
SAP level Company
Configuration steps:
SPRO Financial Supply change Management Cash and Liquidity Management Cash Management
Structuring Manual Planning Define Number ranges
EVO Specifications:
Modified: 6/16/2017 5:41 PM Page 172 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
Modified: 6/16/2017 5:41 PM Page 173 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
7.1 Types
SAP Specifications
Exchange rates for different purposes for the same date are defined in the system as exchange rate types (cannot
delete existing entries).
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
Modified: 6/16/2017 5:41 PM Page 174 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Planning
Attribute details:
Attribute Description
SAP transaction SPRO
Technical name V_TCURV-KURST
Field type CHAR
Field length 4
SAP level Client
Configuration steps:
General Settings Currencies Check Exchange Rate Types.
EVO Specifications:
Planned usage:
- 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
- Requirement: Inception
- 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.
Modified: 6/16/2017 5:41 PM Page 175 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
- 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
- Requirement: Inception
- 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
- Requirement: Inception
- 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
Attribute Description
Area FI
Ownership Local
Expected activity Release
Change management CTS
Configuration values:
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
Modified: 6/16/2017 5:41 PM Page 176 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 177 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
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:
Modified: 6/16/2017 5:41 PM Page 178 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
Attribute details:
Attribute Description
SAP transaction IMG
Technical name V_TCURV-BWAER
Field type CUKY
Field length 5
SAP level Client
Configuration steps:
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
Attribute Description
Area FI
Ownership Global
Expected activity Release
Change management CTS
Configuration values:
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.
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:
Modified: 6/16/2017 5:41 PM Page 179 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
The currency is then translated as if this were the exchange rate entered in the table.
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
Guidance from a Group perspective (IFRS leading ledger) is provided by VGIAP 12 from which the following text has
been extracted.
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.
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.
Modified: 6/16/2017 5:41 PM Page 180 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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 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.
At the moment we have accounts for the following exchange rate differences in the P&L.
Modified: 6/16/2017 5:41 PM Page 181 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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.
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).
Response: EVO GL will support the following approach outlined at the FIMA CRP.
D:\Profiles\fwilkinson\
FIMEVO Bank account GLs.ppt
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.
Modified: 6/16/2017 5:41 PM Page 182 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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)
Modified: 6/16/2017 5:41 PM Page 183 of Last modified by: Romo Navarrete, Pablo
184
Configuration rationale 358155987.doc 2.4
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
Modified: 6/16/2017 5:41 PM Page 184 of Last modified by: Romo Navarrete, Pablo
184