Config.rationale FSCM IHC

Documentation Standards

Configuration rationalecbmFIN_TCM_AP326_Configuration_Rationale_FSCM-IHC.doc2.4

AP326 Configuration rationaleTCM area

Version: 2.420 June 2013

Document Control

Location: https://teamrooms-vista.vodafone.com/eRoom/Global43/EVOTeamRoom/0_4c238

Document Owner

Owning TeamAuthor

FINuno Ferreira

Document History

AuthorDateVersionComment

Nuno Ferreira18/07/2007V1 0First version

SAP Arch Team24/07/2007V1 0Review and comments from SAP Arch Team

Nuno Ferreira26/07/2007V1 1Changes based on review from SAP Arch Team

Soobrayen Adacen 03/08/2007V1 1Review

Nuno Ferreira13/08/2007V1 2Changes based on review from SAP

Tanveer Yaqoob17/08/2007V1 2Review

Nuno Ferreira20/08/2007V1 3Changes based on review from Tanveer

Robert Hawker17/08/2007V1 2Review

Nuno Ferreira 20/08/2007V1 4Changes based on review from Tanveer

Matt Parlour15/08/2007V1 2Review

Nuno Ferreira20/08/2007V1 4Changes based on review from Matt Parlour

Tom Light15/08/2007V1 2Review

Nuno Ferreira20/08/2007V1 4Changes based on review from Tom Light

Belinda22/08/2007V1 4Review from Belinda / June Chandler / Steve Pierce / Thomas Light / Matt Parlour

Nuno Ferreira31/08/2007V1 5Changes based on review

Soobrayen / Jos Fernandes / Matt Parlour / June31/08/2007V1 6Last reviews received from June and inputs from meeting with Soobrayen / Jos Fernandes / Matt Parlour )

Nuno Ferreira31/08/2007V1 6Changes based on review

Nuno Ferreira30/10/2007V1.6Exchange rate triangulation and minor changes

Nuno Ferreira30/12/2007V1 7Changes based on presentation of IHC

Nuno Ferreira07/01/2008V1 8Changes based on Review from Thomas

Nuno Ferreira13/02/2008V1 9Update with IHC pieces and ER config. paper

Nuno Ferreira20/02/2008V2 0Changes based on Review from Thomas

Nuno Ferreira22/02/2008V2 1Changes based on points raised (R2R alignment)

Nuno Ferreira27/02/2008V2 2Changes based on points raised by Soobi

Nuno Ferreira11/04/2008V2 3Changes based on review by Soobi

Marta Gonzalez25/03/2009V2.4Include with DE configuration

Related Documents

TitleComment / Link

cbmSAPArch_AP326_Configuration_Rationale_V0.1.dochttps://teamrooms-vista.vodafone.com/eRoom/Global43/EVOTeamRoom/0_3635a

Document Review & Signoff

NamePositionActionApproved

Thomas LightTeam LeadS

Adacen SoobrayenSAPQA

Andrea AleottiSAP ArchFRApproved 26/07/07

S = Signed Approval Required, QA= Quality Assurance Review Required, FR = Formal Review Required, IR = Informal Review, I = For Information.

Table of Contents:

81.Introduction

81.1Purpose

81.2Overview

81.2.1Target audience

81.2.2Document lifecycle

92.Configuration rationale details

93.Principles guiding design and configuration

114.SAP In House Cash

114.1Key decisions regarding In House Cash

124.2Benefits of In House cash

134.3Internal Payments

134.4Periodic Processing JOB CHAIN and Closing cockpit

164.4.1End of day processing

174.4.2Month end processing

204.5Organizational Units

204.5.1Company Codes

204.6Integration of Systems

204.6.1ALE - Application Link Enabling - Customizing in the SAP In-House Cash System

214.6.1.1Define Logical System

224.6.1.2Assign Logical System to Client

234.6.1.3Define Target Systems for RFC Calls

244.6.1.4Create Transactional RFC Port

254.6.1.5Process Partner Profiles for Business Partners Manually

264.6.1.6Process Partner Profiles Manually for Logical Systems

284.6.1.7Define In-House Cash Centre as Bank

294.6.1.8Function module for IBAN

304.6.1.9GL Variant maintenance

314.6.2ALE - Application Link Enabling - Customizing in the Subsidiary Company System

314.6.2.1Define Logical System

324.6.2.2Assign Logical System to Client

344.6.2.3Configure Systems in Network, Define Target Systems for RFC Calls

354.6.2.4Process Partner Profiles Manually

364.6.2.5Process Partner Profiles Manually for Logical Systems

374.6.3Business Customizing

374.6.3.1Customizing Financial Accounting for Subsidiary Companies

374.6.3.2Set up payment methods per country for payment transactions

414.7Set up Payment methods per Company code for payment transactions

444.8Set up Bank determination for payment transactions

474.8.1.1Define House Banks intercompany settlements

494.8.1.2Bank determination

514.8.2Customizing the In-House Cash Centre

514.8.2.1Define In-House Cash Centre as Bank Area

524.8.2.1.1Set Up Number Ranges for Log

534.8.2.1.2Set Up Number Ranges for IHC Payment Orders

554.8.2.1.3Define how in House cash data is transferred to Financial accounting

564.8.2.1.4Activate SAP Component SAP In-House Cash

574.8.2.2Master Data

574.8.2.2.1Process Products

584.8.2.2.1.1Conditions

594.8.2.3Maintain Formats for Bank Statements

604.8.2.4Account Management

604.8.2.4.1Maintain Accounts for Payment Transactions

614.8.2.4.2Define Account Determination

614.8.2.5Periodic Tasks (General Ledger Transfer)

624.8.2.5.1Maintain GL Variants

634.8.2.5.2Transfer Postings Payables/Receivables

644.8.2.6Maintain General Ledger Transaction for General Ledger Transfer

664.8.2.7Assign Payment Transaction Type to General Ledger Transaction

684.8.2.8Maintain General Ledger Group

694.8.2.9Define GL Account Assignment: Current Accounts

714.9Configuring Component-Specific Master Data

724.9.1Create Business Partner Roles in SAP In-House Cash

724.9.2Master Data: account creation in IHC

734.9.3Create Customer / Vendor account - Intercompany

764.9.4Central bank reporting

774.10Ongoing Setting Process steps

774.10.1Current setting for updating the posting date for payment transaction and closing

774.10.1.1Update Posting Date for Payment Transactions

784.10.1.2Update Posting Date for closing manually

794.11Reassignment of short term IHC call account positions to long term call accounts

794.11.1Define In-House Cash Centre as Bank Area

814.11.2Cash concentration Short term to long term call account - Transition and End game

824.11.3Cash Concentration

854.11.4Reassignment of short term IHC call account other currencies to functional currency short term call accounts positions

854.11.5Cash concentration Short term different currencies to functional currency call accounts - Transition and End game

894.12Interest

944.13Non-invoice driven VOCH call account changes

944.13.1Cash sweeps

964.13.2Bank statement configuration OpCo

964.13.3Configure the Electronic Bank Statement

974.13.4Create account symbol

984.13.5Assign accounts to account symbol

994.13.6Create Keys for posting rules

1014.13.7Define posting rules

1024.13.8Define Search String for Electronic Bank statement

1034.13.9Create transaction type

1044.13.10Assign external transaction type to posting rules

1064.13.11Assign bank accounts to transaction type

1074.13.12Bank statement configuration IHC

1084.13.13Central cash receipt / Incoming bank statements IHC

1084.13.13.1Set Up Connection to IHC in FI

1094.13.13.2IHC Account Determination from External Bank Account

1114.13.13.3Set Up Account Determination for Incoming Payment

1124.13.13.4Define Transaction Types for Incoming Payment

1134.13.13.5Conclusion:

1144.14Treasury (eTC) transactions with loan settlement

1144.14.1Payment Items

1165.Finance FI-BL

1195.1Set Country-specific checks

1245.2Define House Banks

1265.3Bank Chains

1265.3.1Define Scenario

1275.3.2Activate Bank Chain

1295.3.3Create General Bank Chain

1305.4Define Factory Calendar per Currency

1325.5Define Tolerance Groups for users

1355.6Configure the Electronic Bank Statement

1365.6.1Create account symbol

1385.6.2Assign accounts to account symbol

1405.6.3Create Keys for posting rules

1425.6.4Define posting rules

1445.6.5Create transaction type

1465.6.6Assign external transaction type to posting rules

1485.6.7Assign bank accounts to transaction type

1555.7Define Accounts for Exchange Rate Differences

1566.Finance TR CM

1576.1Define Planning Levels

1626.2Define Source Symbols

1636.3Define Planning Groups

1656.4Define Cash Management Account Name

1666.5Define Groupings and Maintain Headers

1676.6Maintain Structure

1706.7Define Planning Types

1726.8Define planning levels for Logistics

1736.9Maintain Blocked Levels

1746.10Define Number Ranges

1777.Exchange Rates Table

1777.1Types

1807.2Application

1807.3Rates

1817.4Exchange rate triangulation

1837.5FX rounding rules

1838.Appendix A FIMA configuration rational alignment

1838.1.1Treatment of exchange rate differences

1848.1.2Accounts for Exchange rate differences

1858.1.3Account for bank charges

1858.1.4Bank clearing accounts and bank accounts

1858.1.5Potential extra accounts that will be requested by TCM

1869.Appendix B Steps involved in new OpCo setup in IHC and Test script

EDI1. 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 OverviewThis document is part of the configuration rationale composite deliverable. The composite deliverable is articulated in the following documents:

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

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.)

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)

Configuration rationale HR area: owned by the HR team, describes the configuration rationale for the HR related application components (e.g. ECC-PA, eRecruiting, eLearning)To enable an easier navigation across the content, the configuration shall be articulated following the application breakdown of SAP and the IMG flow.

1.2.1 Target audience

The target audience of the document are:

DDP team/release management team: they have to configure the solution following the configuration rationale

Other functional teams (FIN, SCM, HR) responsible for the detailed configuration of the system.

CoEx will use this document to maintain a consistent design of the solution during the implementation1.2.2 Document lifecycle

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

2. Configuration rationale details

This chapter contains the configuration rationale specifications, articulated by application components/module.

For each key parameter the following information are reported:

SAP specifications: it contain a brief explanation of:

the standard meaning of the object

the role of the object inside the SAP solution

the SAP guidelines (when available) in configuring the parameter

SAP technical specification: contain the reference on how reach the parameter (SAP transaction), technical name of the parameter (field/table), field features (e.g. alpha 10 Char) and dependency inside SAP (e.g. client dependent, company code dependent)

When appropriate (complex to manage) the configuration steps required to configure the object

EVO specifications: it contains:

The planned usage of the parameter in EVO

The coding rule to be applied to the parameter

When meaningful (at core level and stable), the configuration values considered for the configurations (e.g. for the vendor master account group)

The planned management of the parameter in EVO in term of:

Area: Cross, FIN, SCM, HR

Ownership: Global, OpCo Expected activity: Standard (mainly no config. planned), Core (Template/core set of values), Release (mainly implemented during the release implementation), OnGoing (requires activities after the release)

Change mgm: CTS (correction and Transport), Production (activity performed directly in production (applicable only to some data as posting periods, etc.)

Detailed specification about the configuration of the specific parameter (e.g. attributes of the parameter) shall be included in the more detailed configuration design.

Intercompany configuration requirements within this document should be referenced back to the FI-Intercompany Configuration Rationale. Where there is a conflict in the requirements or configuration details relating to Intercompany, the FI-Intercompany Configuration Rationale takes precedence over this document.

3. Principles guiding design and configuration

The purpose of EVO is to deliver standard common processes, a common language for products and terminology, independent of OpCos or geography, to identify the best commercial solutions and to apply a single source of the truth for information across all of our functions.

From these project goals, the TCM workstream identified the micro-principles to drive the design:

4. SAP In House Cash

The SAP In-House Cash (IHC) component is a solution that can be used to manage the settlement of both intercompany and external commitments. Through the use of internal bank accounts it eliminates the need for cash transfers between recourse VF entities. IHC can also be configured so that it channels external commitments from a number of VF entities through one bank account, adjusting internal bank accounts appropriately.

4.1 Key decisions regarding In House Cash

The Evo design is to use IHC for recourse intercompany settlements, but not for external settlements. The decision to not use IHC for external settlements was taken for following reasons:

- Single European Payments Initiative (SEPA) initiative will mean that all Euro payments made to other EU participating states will be charged at a rate close to local Automated Clearing House (ACH) rates (i.e. domestic payments)

- To benefit from local ACH pricing on cross boarder payments, IHC would be configured so that VOCH would make payments on behalf of other VF entities (with a VOCH account in each country). However, in order to do this there would need to be a significant local ACH data collection exercise (currently OpCos would only hold international banking details of cross boarder suppliers)

- Using IHC on behalf of model there would be some know your customer legal complications in some countries - Lack of visibility of a VF entities settlements and reconciling items

- Solution would require more bank accounts (given OpCos will need an overlay account regardless of solution for EVO settlements)

IHC is part of the EVO design for intercompany settlements. In the below illustration, steps 1-3 are the same as the steps taken for an external payment run. The IHC centre acts as a bank, changing the payee and beneficiary internal bank accounts upon receipt of payment instruction. The IHC centre then sends a bank statement to both internal companies. As with the receipt of external bank statements, the statement drives the clearing of related items in the OpCos GL. The internal bank account adjustment itself drives the update of the VOCH to OpCo call (loan) account.

4.2 Benefits of In House cash

Implementation of the IHC component for recourse intercompany settlements will:

Eliminate need to manually populate Excel spreadsheets

Eliminate need to manually aggregate Excel spreadsheets

Eliminate risk of re-keying errors

Significantly reduce resourcing requirements

Improve flexibility of process (currently monthly process, proposal is to make daily)

Eliminate manual allocation/ reconciliation (and risk of this process being duplicated for same transactions in different VF entities.

The IHC component will sit within the VOCH and replace the existing Intragroup settlement process. Therefore, the internal short term loans will move from being held with VDG to the VOCH. These short term positions will be cleared down to the existing long term positions held with VG/VFL. Until all VF entities are on EVO SAP we will need to maintain the ability to settle through existing Intragroup settlement process a consideration which is reflected in following documentation.

Intercompany transactions with VF defined non-recourse entities will continue to be settled cash and are therefore out of scope for above detailed IHC process.

4.3 Internal Payments

This is the description off all the process of internal payments. The responsibility of TCM is only after step 2.TaskDepartmentDescription

Execute payment run - post automatic payment program (F110)P2P Run and post automatic payments for all participating subsidiaries using payment method Z Intercompany payments;

Clear intercompany vendor items

Generate IDOC = PAYEXT

Current account postingsCentral Treasury Dep.Postings in the respective bank accounts are generated via the IDOC (PAYEXT). Monitor IDOC creation.

Bank statementsCentral Treasury Dep.Generate internal bank statements (IDOC=FINSTA) and delivered to the respective subsidiaries

Posting of the internal bank statementsCentral Treasury Dep. Clears clearing accts in the paying subsidiary

Clears customer accounts in receiving subsidiary. Adjust VOCH-OpCo call accounts

IHC payment reports Central Treasury Dep.Check accounts, posting and balances

4.4 Periodic Processing JOB CHAIN and Closing cockpitThe 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 Cash concentration (reassignment of short term balances to LT balances) Detailed in document Reassignment of short term IHC call account positions to long term call accounts V0 4 and included in Job chain eTC treasury data import detailed in document FI-TCM-IF-6 - Interface to SAP from eTC Posting cut-off for payment transactions described in this document and included in Job chain

Interest calculation and capitalisation - Account balancing : Calculates and posts interest and charges for accounts that are due - and included in Job chain

Send out IHC statements to OpCos - Generate bank statements: Mass run for transferring the bank statement data to the relevant interface. Bank statements can be generated periodically or upon request. included in the Job Chain

All the external steps to IHC are - DB bank statement import (funding/depositing sweeps), Cross currency loan cleardown and eTC treasury data import. For them to be included in the Job Chain they will need to have a report to be attached to the job chain. To include those in the processing chain they must be entered when chosen - Specify the Sequence of Mass Processing. Activities

1. Choose new entries.

2. Enter the report name and the description.

3. Set the indicator continue, showing if the end of day processing chain continues directly after the start of the next report ('X') or not (' '). If the indicator is set, it is possible that (in the case of direct continuation) several reports run at the same time (in parallel) after being called up / scheduled ('X'). If the indicator is not set, the customer-own report must start the next report in the processing chain. For this, there are two prerequisites:

- The two parameters P_LAUFD and P_LAUFI are mandatory report parameters.

- At the end of processing the report must call up the function module BKK_CHAIN_START_NEXT_STEP, with which the next report is started as a job.

It is also possible to set a return code using module BKK_CHAIN_DB_SET_RETURNCODE. The constants G_CON_REPRETURN_OP (no errors), G_CONREPRETURN_WARNING (warnings), G_CON_REPRETURN_ERROR (single error) and G_CON_REPRETURN_ABORTED (termination) are available for this. In the case of termination, it is advisable not to start the next step.

Create report to be run at end of the day:

For the organization of your mass runs, for example, for end of day processing, you have the option of establishing end of day processing chains (as alternative to scheduling batch jobs). In this section you define these chains.

Activities

1. Choose the processing sequence.

2. Create the processing sequence. Issue the key and appropriate names for the processing sequence. You can freely choose the key.

3. Choose individual steps

4. Define the corresponding reports for each processing sequence. You define the order with the sequential number. For each report enter a variant with which this report is to be called up as a matter of standard.

4.4.1 End of day processing

The following reports should be included within the end-of-day processing in this sequence:

Posting cut-off for payment transactions: Once the posting cut-off time is set, all subsequent postings take the date of the next working day. This means that while account balancing is running, you cannot make any more postings in the period that is being closed (back-dated postings are still possible). The account balancing postings themselves are not affected by the cut-off, and therefore still fall within the account balancing period.

Account balancing: Calculates and posts interest and charges for accounts that are due.

Generate bank statements: Mass run for transferring the bank statement data to the relevant interface. Bank statements can be generated periodically or upon request.

Set Balancing Posting Date - Set next posting date for account balancing: This date should be incremented on a daily basis, even ifno account balancing run takes place. This ensures that the posting date for account balancing activities is always at the end of the period you want to close.

Balance sheet preparation - Balance sheet preparation (division into payables / receivables) for BCA accounts. The transfer postings for the FI general ledger are prepared, but no FI documents are posted.

Transfer to general ledger: Independent of the other periodic activities. The interest accrual/deferral run and G/L transfer would usually be run daily after end-of-day processing

In terms of configuration this are the reports to support this activities RFBKPDT2: Set Payment Transaction Posting Date

RFBKCONC: Account Balancing RFBKBSST: Bank Statement

RFBKCLEB: Set Balancing Posting Date (only when Acct Balancing is scheduled)

RFBKGLBSPREP: Balance Sheet Preparation

RFBKGL01: General Ledger Transfer4.4.2 Month end processing

The following reports should be included within the month end processing in this sequence the difference is the cash concentration only done monthly: RFBKPDT2: Set Payment Transaction Posting Date

RFBKCONC: Account Balancing RFBKKC20: Cash Concentration Generates carry-forwards from accounts that are organised in the cash concentration hierarchy type.

RFBKBSST: Bank Statement

RFBKCLEB: Set Balancing Posting Date (only when Acct Balancing is scheduled)

RFBKGLBSPREP: Balance Sheet Preparation

RFBKGL01: General Ledger TransferAssumption: 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

Posting Date for Payment Transactions

The posting date of the internal payments in IHC must correspond to the posting date of the payment generated by the payment program. The posting date of the clearing entry in the receiving subsidiary must also be the same.

Account Balancing

During the account balancing operation all interests and charges defined will be calculated and posted in the individual current accounts.

Posting Date for Account Balancing

The posting date for all account balancing items must be the last day of the month.

Dispatch of internal Bank Statements

Message type that dispatches and posts the items is FINSTA

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

The postings that are generated are the following:

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

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

postings of payment transactions, charges, interest

The General Ledger Transfer in IHC

IHC = sub ledger balance sheet preparation this step must be executed before the G/L transfer, even though it does not make any postings in the system.

G/L transfer

Balance Sheet Preparation

Aggregation and preparation of balances, checks

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

Creation of FI documents1. post transactions between IHC tech. clearing account and respective offsetting account2. transfer to the final bank account

Transfer of trading partner numberImplemented Notes for In House CashSAP NoteTitle of SAP NoteUsage

OSS Note 522747 For general ledger transfer trading partner not filledDuring the general ledger transfer in 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 extensionsApplication menu update for In-House Cash

OSS note 376180 Change IHC bank BNKAINif 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 all trading partner

4.5 Organizational Units

4.5.1 Company Codes All the company codes that are to participate in the IHC must be created in the SAP system during the release phases. The company codes are assigned then to an internal house bank In house cash centre and the accounting.For configuration purposes and more detail - cbmFI_AP326_Configuration_Rationale_R2R4.6 Integration of Systems

This section contains information about integrating system landscape.

This includes, for example:

Defining and configuring logical systems

Generating and editing partner profiles

Completing the configuration settings and carrying out additional activities required

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 manages the In House cash centre (VOCH) are run. For payment orders from companies affiliated with the in-house cash centre, use message type PAYEXT with basic type PEXR2002 and transaction code PEXR as the inbound parameter. For bank statements from the in-house cash centre to affiliated companies, use message type FINSTA with basic type FINSTA01 and the transaction code FINS as the inbound parameter. EVO OpCo accounting, IHC accounting and IHC bank are all on same box in the system landscape since the OpCos and the in House cash centre will work in the same system.4.6.1.1 Define Logical System

SAP specifications:

Meaning of the object:

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

Define the logical systems in your distributed system. SAP guidelines:

You store system names here for the logical systems for SAP In-House Cash, the OpCos and Financial Accounting of the head officeAttribute details:

AttributeDescription

SAP transactionSPRO

Technical nameV_TBDLS-LOGSYS

Field typeCHAR

Field length10

SAP levelClient

Configuration steps:

SPRO SAP Net Weaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) IDoc Interface / Application Link Enabling (ALE) Basic Settings Logical Systems Define Logical System

EVO Specifications

Financial Accounting of the head office in house cash centre is in the same client as SAP In-House Cash, you will make an entry here to show that an RFC - Remote Function Call - connection is not used, for example, LOCAL. Planned usage:

This is the planned usage for the object:


AreaFI

OwnershipGlobal

Expected activityRelease

Change managementCTS

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

Enter a name for the logical system that you want to create.

Enter a description of the logical system.

If you want to change this entry:

a) Select the appropriate line.

b) Choose Edit -> Change field contents.

c) Enter the new text.

d) Choose Replace.

Save your entries.

4.6.1.2 Assign Logical System to Client

SAP specifications:

Meaning and role of the object:Here you assign a client to the system for SAP In-House Cash. Attribute details:


SAP transactionSPRO

Technical nameT000-MANDT

Field typeCLNT

Field length3

SAP levelClient

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:



AreaFI

OwnershipGlobal



Configuration values:For this customizing process the values that should be already there for this step are

Field nameDescriptionUser Action and Values

ClientClientTo be defined

CityCityBlank value

Logical SystemLogical systemTo be defined

Std currencyStandard currencyBlank value

Changes and transports for client - specific objectsChanges and transports for client - specific objectsIndicator Changes without automatic recording

Cross client object changesCross client object changesChanges to repository and cross-client Customizing allowed

Protection: Client copier and comparison toolProtection regarding client copy program and comparison toolsProtection Level 0: no restriction

RestrictionsRestrictionsIndicator that starting CATT processes is permitted

4.6.1.3 Define Target Systems for RFC Calls

SAP specifications:


RFC: Remote Function Call (RFC) . RFC is an SAP interface protocol based on CPI-C.Role of the object:

It is used to simplify the programming of communication processes between systems. RFCs enable call and execute predefined functions in a remote system - or in the same system. They manage the communication process, parameter transfer, and error handling.

SAP guidelines:

Here you define the subsidiary system as the target system and a technical user; this means that the system is still accessible even if the personal user is deleted. Attribute details:


SAP transactionSM59

Technical name-

Field type-

Field length-

SAP level-


SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Communication Create RFC Connections

Choose R/3 connections and Edit -> create

Enter the parameters required for that type (connection type: 3) Save and click on Test Connection to test the connection. (Here you can define a technical user. This means that the system is still accessible even if the personal user is deleted)

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:



AreaFI

OwnershipGlobal



Configuration values:N/A4.6.1.4 Create Transactional RFC Port

SAP specifications:

Meaning and role of the object:

Ports are a fundamental requirement for communicating by means of the IDoc Interface. At least one port must exist for each external system. The process flow depends on the port type, in our case, a Transactional RFC port has to be created.

EVO Specifications:

The SAP In-House Cash and the subsidiary companies are in the same client. So the configuration steps will be done as followed.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.

Choose Create to create a transactional RFC port.

Field NameDescriptionUse Action and Values

PortPortLet the system generate a port name or assign your own port name

DescriptionDescriptionSend IDocs to self

RFC destinationRFC destinationNONE

Choose Save to create a transactional RFC port.

Carry out the following activity (SAP In-House Cash and Financial Accounting of the head office are in the same client.)

Choose Create to create a transactional RFC port.


PortPortLet the system generate a port name or assign your own port name

DescriptionDescriptionLoopback to local system

RFC destinationRFC destinationNONE

4.6.1.5 Process Partner Profiles for Business Partners Manually

SAP specifications:

Meaning and role of the object:

Partners with whom you communicate via IDocs in the partner profiles: choose the message to be sent to the partner and define the path to be used, as well as how inbound messages are processed.

Attribute details:


SAP transactionWE20

Technical nameVEDI_TDPP1-PARNUM

Field typeCHAR

Field length10

SAP level


Accounting Financial Supply Chain Management In-house Cash Environment Idoc and EDI Basis Administration Partner profileEVO 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:



AreaFI

OwnershipGlobal



Configuration values:

Select Partner Type GP.

Choose Create.

Choose Outbound Parameters.


Message TypeMessage TypeFINSTA

Receiver portReceiver portThe port you generated

Output modeOutput modeIndicator: Transfer IDoc immediately

Basic typeBasic typeFINSTA01

Syntax checkSyntax checkSelect

Choose Inbound Parameter. Field NameDescriptionUse Action and ValuesNote

Message TypeMessage TypePAYEXT

Process codeProcess codePEXNProcessing of incoming payments

Syntax checkSyntax checkSelect

Processing by function module Processing by function moduleTrigger immediatelyOnly in test phase, otherwise Trigger by background program

You have to make entries for each OpCo. You can copy the entries as follows: Select the partner.

Choose Create Copy.

4.6.1.6 Process Partner Profiles Manually for Logical Systems

Role of the object:

Here you process the clearing partners in partner type LS Logical Systems.

Attribute details:


SAP transactionWE20


Field typeCHAR

Field length10

SAP levelCompany code


SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and EDI Basis Administration Partner profile

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:



AreaFI

OwnershipGlobal




Choose Create. Field NameDescriptionUse Action and Values

Partner no.Partner numberLogical system of Financial Accounting

Partn. TypePartner TypeLS

AgentAgentUser ID

Lang. Language

Choose Outbound Parameters.

Field NameDescriptionUse Action and ValuesNote


Message CodeMessage codeConfiguration values - FI of head office is in the same client as IHC

Message function Message functionConfiguration values - FI of head office is in the same client as IHC

Receiver port Receiver portThe port you generated

Basic typeBasic typePEXR2002

Syntax check Syntax checkSelect

Choose Inbound Parameters



Message CodeMessage codeConfiguration values - FI of head office is in the same client as IHC

Message function Message functionConfiguration values - FI of head office is in the same client as IHC

Receiver port Receiver portThe port you generated

Process codeBasic typePEXR

Syntax check Syntax checkSelect

Processing by function module Processing by function moduleTrigger immediately

4.6.1.7 Define In-House Cash Centre as Bank

SAP specifications:

Meaning of the object

Each house bank of a company code is represented by a bank ID in the SAP system, every account at a house bank by an account ID.

Role of the object:

In the SAP system, you use the bank ID and the account ID to specify bank details. These specifications are used, for example, for automatic payment transactions to determine the bank details for payment. Define the in-house cash centre as your house bank and choose EDI partner profiles. SAP guidelines:

Work out the specifications you have to enter in the system for your house banks.

Define your house banks and the corresponding accounts in the system under a bank ID or an account ID.

Note: To avoid problems when checking the length of the bank key or the bank number, use transaction code FIHC.

Attribute details:


SAP transactionFIHC

Technical nameV_T012-HBKID

Field typeCHAR

Field length5

SAP levelClient

EVO Specifications:

The company that manage the in-house cash centre activities will be defined as the bank country.

Planned usage:



AreaFI

OwnershipGlobal



Configuration Values: Field NameDescriptionUse Action and ValuesNote

Bank CountryBank CountryHUCountry of the in house cash centre

Bank KeyBank Key99999999Configuration values to differentiate from the other banks

Bank Name Bank NameIn House Cash Centre Bank

4.6.1.8 Function module for IBAN

SAP specifications:

Meaning of the object

In this IMG activity, you can define one function per country for creating a BBAN (Basic Bank Account Number)

Role of the object:

The BBAN is a conventional bank and account identification consisting IID (institute identification) and BAN (bank account number), all together max. 30 alphanumeric characters. It is used to create an IBAN (International Bank Account Number).

IID: Institute ID (Institute label): fixed length per country, any number of characters in the context of BBAN (in practice 4 to 12 characters); corresponds to the current BC number (5 characters)

BAN: Customer account number: fixed length per country, any number of characters in the context of BBAN (in practice 8 to 20 characters)

SAP guidelines:

Its needed to define the function module.Attribute details:


SAP transactionSM30

Technical nameV_TBKK06 - FBNAME

Field typeCHAR

Field length30


EVO Specifications:

This is required when creating the call/current accounts in the IHC.Planned usage:



AreaFI

OwnershipGlobal



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.


Country (CTY)CountryAll OpCos and IHC centre

Countries with companies in IHC scopeBBAN conversion functionBKK_IBAN_CREATE_BBAN_DEConfiguration values equal to all OpCos

Note: This value will be done for all countries that have companies in IHC scope.4.6.1.9 GL Variant maintenance

SAP specifications:


General ledger variants serve as model for transfer to the general ledger

Role of the object:

Allocate general ledger transactions and general ledger groups to a general ledger variant. The general ledger variant defines how the transfer from BCA to the FI general ledger takes place.

All settings are made in relation to a general ledger variant. Especially the general ledger accounts are defined. To this end, an account plan, among other things, is assigned to the general ledger variant.

The Clearing accounts to identify are technical clearing account for the purpose of splitting high volume line items in IHC company code.SAP guidelines:

SAP supplies sample customizing that relates to the standard account framework supplied by SAP. To make things clearer, additional general ledger accounts have been created. Create these too in accordance with the pre-settings on the general ledger.


SAP transactionSPRO

Technical nameV_TBKKCVAR-GLVAR

Field typeCHAR

Field length4

SAP levelClient


SPRO Financial Supply Chain Management In-House Cash periodic tasks Maintain GL variantEVO Specifications:

Planned usage:


AreaFI

OwnershipGlobal



The transfer of the values in the IHC account and the IHC G/L account will be done dailyConfiguration values:

Bank Area

Description GL Variant

ChAcClearing Account Transfer FI General LedgerDoc. TypePosting Key Debit Transfer FI General Ledger

Posting Key Credit Transfer FI General Ledger

V_TBKK01D-BKKRSV_TBKKCVAR-T_GLVARV_TBKKCVAR-KTOPLV_TBKK01D-CHARGE_ACTV_TBKKCVAR-BLARTV_TBKKCVAR-BSCHL_SV_TBKKCVAR-BSCHL_H

IHCEIn-House Cash Centre EVO0EVO48520000SI4050

Note: Document splitting is currently under discussion and is a SAP recommendation. Splitting documents from a Profit Centre perspective is not a requirement, but following SAP recommendations and taking into account that it can be necessary in the future, it will be configured in such a way that the documents are zero balanced at profit centre level, and the partner field is the profit centre.

Every business transaction that is entered is analyzed during the document splitting process. In this process, the system determines which splitting rule is applied to the document. In order that the system can determine the splitting rule to each document type. With the document types delivered in the standard system, SAP delivers a classification for document splitting. This classification is a proposal that needs to check against how the document types are organized.

Reference for configuration: cbmFIN_R2R_AP326_Configuration_rationale

4.6.2 ALE - Application Link Enabling - Customizing in the Subsidiary Company System

Here you make the ALE Customizing settings required for the SAP In-House Cash component from the view of the OpCos.

For payment orders from companies affiliated with SAP In-House Cash, use message type PAYEXT with basic type PEXR2002 as the outbound parameter. For bank statements from the in-house cash centre to affiliated companies, use message type FINSTA with basic type FINSTA01 and process code FINS as the inbound parameter.

When you create PAYEXT, EUPEXR is created automatically. 4.6.2.1 Define Logical System

SAP specifications:


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

Role of the object:

Here you define the system for the OpCo and the system for SAP In-House Cash. Attribute details:


Technical nameV_TBDLS-LOGSYS

Field typeCHAR

Field length10

SAP level


SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Basic Settings Logical Systems Define Logical SystemEVO 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:



AreaFI

OwnershipGlobal



4.6.2.2 Assign Logical System to Client

SAP specifications:

Role of the object:

Here you assign a client to the OpCo system. Attribute details:


SAP transaction

Technical nameT000-MANDT

Field typeCLNT

Field length3

SAP level


SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Basic Settings Logical Systems Assign Logical System to Client

EVO Specifications:

These settings will be already created in the system configuration. Nevertheless check if these values the configuration values are there.

Planned usage:



AreaFI

OwnershipGlobal



Configuration Values:

Select one line.

Choose: Goto -> Details.

The 'Client Details' screen appears and the following fields must be filled:


ClientClientClient used in the system

City City

Logical systemLogical system

Std currencyStandard currency

Changes and transports for client specific objectsChanges and transports for client specific objectsSelect indicator: automatic recording of changes

Cross-client object changesCross client object changesNo changes to Repository and cross client

Protection: client copier and comparison toolProtection regarding client copy program and comparison toolsProtection level 0: No restriction

RestrictionsRestrictionsIndicator that starting CATT processes is permitted

.

Note: In the field Logical system, enter the name of the logical system to which you want to assign the selected client.

4.6.2.3 Configure Systems in Network, Define Target Systems for RFC Calls

SAP specifications:

Role of the object:

Here you define the SAP In-House Cash system as your target system.

Attribute details:


SAP transactionSM59

Technical name-

Field type-

Field length-

SAP levelClient


SPRO SAP NetWeaver SAP Web Application Server IDoc Interface / Application Link Enabling (ALE) Communication Create RFC ConnectionsEVO Specifications:

Check if the customizing settings are already created in the system

Planned usage:



AreaFI

OwnershipGlobal




Choose R/3 connections and Edit -> create

Enter the parameters required for that type (connection type: 3)Field NameDescriptionUse Action and Values

RFC destinationRFC destination

Connection type Connection type 3

DescriptionDescription

Logon/SecurityLogon/Security

4.6.2.4 Process Partner Profiles Manually

Role of the object:

Here you create the in-house cash centre as your house bank in partner type B.

Attribute details:


SAP transactionWE20


Field typeCHAR

Field length10

SAP levelClient


SAP easy access Accounting Financial Supply Chain Management In-house Cash Environment Idoc and EDI Basis Administration Partner profileEVO specifications:Planned usage:



AreaFI

OwnershipGlobal




Select Partner Type B

Choose Create.


Partner no.Partner number99999999 Bank key defined for in house bank

TypeUS

AgentAgentUser ID

Lang. Language

Choose Outbound Parameters. You have to create two messages types: PAYEXT and EUPEXR. The values to introduce are the followings:

Field NameUse Action and ValuesUse Action and Values

Message TypePAYEXT EUPEXR

Receiver portThe port you generated

Output mode Indicator: Transfer IDoc immediatelyIndicator: Transfer IDoc immediately

Basic typePEXR2002IDCREF01

Syntax check Select Select

Choose Inbound Parameters

Field NameUse Action and Values

Message TypeFINSTA

Process codeFINS

Syntax checkSelect

Processing by function moduleTrigger immediately

4.6.2.5 Process Partner Profiles Manually for Logical Systems

SAP specifications:

Role of the object:

Here you process the clearing partners in partner type LS.

Attribute details:


SAP transactionWE 20

Technical name-

Field type-

Field length-

SAP levelClient


SAP Easy Access Tools ALE ALE Administration Runtime Settings Port Maintenance Partner ProfilesEVO 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:



AreaFI

OwnershipGlobal




Select Partner Type LS.

Choose your logical system.

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

4.6.3 Business Customizing

4.6.3.1 Customizing Financial Accounting for Subsidiary Companies

In this section you make the settings required for the payment program of the subsidiary companies: You define the in-house cash centre as new house bank. You define a new payment method for payments via the in-house cash centre. You carry out the Customizing for the incoming electronic account statement from the in-house cash centre. These settings are required for internal payments.

4.6.3.2 Set up payment methods per country for payment transactionsSAP specifications:


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

Role of the object:

To identify one of the several payments methods used in each country. The country key contains information which the system uses to check entries such as the length of the postal code or bank account number.

Before every payment run the payment methods need to be specified. If a payment method is specified in open items or in the master record of the vendor and if that payment method is permitted for that payment run, the payment program selects this payment method. The payment method in the open items takes precedence over any payment method defined in the master record.

SAP guidelines:

You have to specify which payment methods are to be used in each country. Enter the following details for the payment method:

Payment method either for incoming or outgoing payments.

Characteristics for classifying payment method.

Required entries in master record.

Posting specifications.

Which procedure is to be used to issue the accompanying payment form.

Attribute details:


SAP transactionTransaction: FBZP

Technical nameV_T042ZL-ZLSCH

Field typeCHAR

Field length1

SAP levelCompany Code


Financial Accounting -> Accounts Receivable and Accounts Payable -> Business Transactions -> Outgoing Payments -> Automatic Outgoing Payments -> Payment Method/Bank Selection for Payment Program->Set Up Payment Methods per Country for Payment Transactions

If its a new entry select a country code and a key for the payment method. Add a description for it;

Set the payment method as an outgoing payment;

Set the classification of the payment method (bank transfer, cheque, Bill/ex, Cheque/bill/ex.);

Set the master data required address/bank data;

Select the payment medium required for the payment method as an output for the payments,

Enter the currencies allowed screen, and enter those currencies that are permitted for this payment method. Note: Leaving this table empty will mean that all currencies are permitted.

EVO specifications:

Planned usage:

Some of the outgoing payment methods which are going to be created in some OpCos are already identified, such as bank transfers, cheque, and direct debit. However, specific payment methods are going to be evaluated during Rollout phase.Payment methods will be identified based on the specific country key. Currently 18 countries are in scope of EVO (considering also VPC located in Luxemburg).For intercompany settlement the payment method Z is used which is valid for all countries and all currencies.The table below provides additional details:


AreaFI

OwnershipGlobal

Expected activityCore


Coding rule:

To identify the country:

Use the general coding rule Country ISO code.The countries in scope have the following standards:

CountryCountry

ISO CODE

AlbaniaAL

AustraliaAU

Czech RepublicCZ

EgyptEG

GermanyDE

GreeceGR

HungaryHU

IrelandIE

ItalyIT

LuxemburgLU

MaltaMT

NetherlandsNL

New ZealandNZ

PortugalPT

RomaniaRO

SpainES

TurkeyTR

United KingdomGB

Each payment method is assigned with one alphanumeric identification code.

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.Payment method classificationPosting detailsRequired Master data SpecificsPayment Medium

Payment MethodOutgoing paymentBank transferCheckBill/exCheck/bil/exDocument type for paymentClearing document typeBank DetailsA/C No ReqdIBAN ReqdSWIFT code ReqdUse payment medium workbenchUse Classical paymnt medium program

ACHXXZPZVXXX

SEPAXXZPZVXXXX

SDPXXZPZVXXX

Direct DebitZPZVXXX

CheckXXZPZVX

TTXXZPZVXXXXX

ZXXZPZVXXX

YXXZPZVX

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 methodNameUsage

CChequesPaper Payments

EACH 3 day payment

GSDP InternationalSame day payment to US

HSDP EurozoneSame day payment IBAN & BIC required

S SEPA 3 day payment inside Europe. IBAN & BIC required

No external IDOC will be required.

PMT methodNameUsage

DDirect DebitFinancial postings only - no bank files to be produced

YIntercompany Legacy settlementFinancial postings only - no bank files to be produced

OStanding OrdersFinancial postings only - no bank files to be produced

TTelegraphic TransferFor BCP use

ZInter.In house cash paymentUsed to settle incompany payments for EVO opco;s

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 willbe 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 transactionsSAP specifications:


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

Specified which payment methods can be used in each company code and determine the conditions under which a payment method should be used.

Amount limits for payments within which the payment program can select the payment method.

Specifications for grouping items for payment.

Specifications for foreign/foreign currency payments

Specifications for optimizing bank selection.

Specifications for the form to be used for the payment medium.

Specifications for issuing payment advice notes.

SAP guidelines:

The payment method per company code can be optimized either by bank groups or by postal codes. If you optimize by bank groups, money is transferred from the house bank to the business partner's bank in the shortest possible time. For this to be possible, you assign all banks in the master records to a bank group defined by you (in alignment with Treasury settings).

If you specify that the payment method can also be used for foreign currencies, all currencies are permitted. In the previous configuration object described, you can also specify certain currencies per payment method and country. Only payments in these specified currencies are then made using this payment method.

Attribute details:



Technical nameV_T042E-ZLSCH

Field typeCHAR

Field length1



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.The table below provides additional details:


AreaFI

OwnershipOp but following Global methodology



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.

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 GBPForeign currency will be allowed for all payment methods except cheque + Automated clearing house.

Company codeNameCity

V_T042E-ZBUKRV_T042E-BUTXTV_T042E-ORT01

DE04Vodafone D2 GMBHDsseldorf

DE05Vodafone Services GMBHDsseldorf

GB06Peoples Phone LimitedLondon

GB07Vodafone LimitedLondon

GB11Vodafone UK Services Ltd.London

GB34Vodafone UK LimitedLondon

GB85Vodafone Group Serv. Ltd.London

GR02Vodafone Panafon HellenicAthens

LU07Vodafone Procurement Sarl Luxembourg

LU99Dummy VPCLuxembourg

HU00Vodafone Magyarorszg zrtBudapest

Payment method per company code

Pmt methodNameMinimum amountMaximum amountForeign businesspartner allowedForeign currency allowedcust/vendor bank abroad allowed

V_T042E-ZLSCHV_T042E-TEXT1V_T042E-VONBTV_T042E-BISBTV_T042E-XAUSLV_T042E-XFWAEV_T042E-XAUSB

EACH5,0200.000.000,00xx

SSEPA5,0200.000.000,00xxx

HSDP5,0200.000.000,00xxx

DDirect Debit5,0200.000.000,00xxx

CCheque5,0200.000.000,00

TTT5,0200.000.000,00xxx

ZIntercompany settlements5,0200.000.000,00xxx

YIntercompany legacy settlement5,0200.000.000,00xxx

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.

Reference for configuration: cbmFIN_R2R_AP326_Configuration_rationale

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.

Regarding the payment medium program, it will be maintained the RFF0EDI1

4.8 Set up Bank determination for payment transactionsSAP specifications:


Specified settings that the payment program uses to select the banks or bank accounts from which payment is to be made.

For payment transactions you need house banks and possibly the bank details of your vendors. House banks are banks with which your company code maintains accounts.

Role of the object:

This object allows you to define the following:

Ranking order of banks: you specify which house banks are permitted and rank them in a list.

Bank accounts: for each house bank and payment method (and currency, if required), you specify which bank account is to be used for payments.

Available amounts: for each account at a house bank, you enter the amounts that are available for the payment run. You enter separate amounts for incoming and outgoing payments. Specifying available amounts enables you to control which bank account is to be used for payments. You can specify the amounts depending on the value date at the bank. Value date: You specify how many days elapse between the posting date of the payment run and the value date at the bank, dependent on the payment method, bank account, payment amount, and currency.

.

SAP guidelines:

Ensure that payment methods have defined both in country and company code as described in the previous steps. Also ensure that all house banks and bank accounts required have been created on these company codes.

Depending on the payment method used, you may/may not require the bank details of your vendor. For example, you require the bank details of your vendor for transfers, but not for clearing cheques. Enter vendor bank details in master records.

You can enter as many sets of bank details in master records as you want, both for your company codes and for your vendors. You can determine the bank that is selected by:

An explicit specification in the master record of the customer/vendor or in the open items. The specification in the item has higher priority.

The payment program, which determines according to specified rules, the most suitable house bank or the optimal combination of house bank and customer/vendor's bank.

.Attribute details:



Technical nameV_T042BD-ZBUKR

Field typeCHAR

Field length4



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. The table below provides additional details:


AreaFI

OwnershipOp Co



Coding rule:

Not applicable because for each paying company code several fields will be filled.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.


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 thepayment 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 aVF UK$ account we would not set up a cheque clearing account.

Paying company codeHouse BankPayment MethodCurrencyAccount IDBank Sub account

GB061C125424003020

GB061TT125724003021

GB062C128724003022

GB062TT198224003023

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.

Company CodeHouse BankAccount IDDaysCurrencyAvailable for outgoing paymentScheduled incoming payment

GB06000011254999GBP9.999.999.999.999,009.999.999.999.999,00

Note: The previous tables are just an example. The final ones should contain the details specified by company code.4.8.1.1 Define House Banks intercompany settlements Meaning of the object:

Each house bank of a company code is represented by a bank ID in the SAP system, every account at a house bank by an account ID.

Role of the Object:

In the SAP system, you use the bank ID and the account ID to specify bank details. These specifications are used, for example, for automatic payment transactions to determine the bank details for payment.

SAP guidelines:

Several house banks are supplied as examples in the standard system in order to enable configuration of the payment program.

Attribute details:


SAP transactionFI12

Technical nameV_T012-HBKID

Field typeCHAR

Field length5

SAP levelCompany Code


SAP Netweaver General settings Set countries Set country-specific checks EVO Specifications:

Planned usage:


AreaFI

OwnershipLocal




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

EDI partner:

EDI payment methods:

Payment MethodsName

ZIntercompany clearing

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

Payment MethodsName

YIntercompany legacy settlement

4.8.1.2 Bank determination

SAP specifications:


Specified settings that the payment program uses to select the banks or bank accounts from which payment is to be made.

For payment transactions you need house banks and possibly the bank details of your vendors. House banks are banks with which your company code maintains accounts.

Role of the object:

This object allows you to define the following:

Ranking order of banks: you specify which house banks are permitted and rank them in a list.

Bank accounts: for each house bank and payment method (and currency, if required), you specify which bank account is to be used for payments.

Available amounts: for each account at a house bank, you enter the amounts that are available for the payment run. You enter separate amounts for incoming and outgoing payments. Specifying available amounts enables you to control which bank account is to be used for payments. You can specify the amounts depending on the value date at the bank. Value date: You specify how many days elapse between the posting date of the payment run and the value date at the bank, dependent on the payment method, bank account, payment amount, and currency..

SAP guidelines:

Ensure that payment methods have defined both in country and company code as described in the previous steps. Also ensure that all house banks and bank accounts required have been created on these company codes.

You can enter as many sets of bank details in master records as you want, both for your company codes and for your vendors. You can determine the bank that is selected by:

An explicit specification in the master record of the customer/vendor or in the open items. The specification in the item has higher priority.

The payment program, which determines according to specified rules, the most suitable house bank or the optimal combination of house bank and customer/vendor's bank.

.Attribute details:



Technical nameV_T042BD-ZBUKR

Field typeCHAR

Field length4



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.AttributeDescription

AreaFI

OwnershipGlobal




Intercompany payment method in the company code, enter in the ranking position the in-house bank (IHC house bank);

Bank Accounts, for intercompany combination house bank/payment method/currency, enter an account ID of the house bank (IHC house bank) Value date for accurate cash position reporting define value date same day value date - Probable number of days before a debit and/or a credit memo is carried out to the bank account. The number of days is added to the posting date and results in the date relevant for cash management and forecast on which the debit and/or credit memo is to be expected on the bank account. These dates will be provided by D.B. or correspondence banks in order to have an accurate cash position. This will depend in the country, so will be define in the release phase.Assumptions:

1. Bank Accounts:

For each company code several Bank accounts will be defined to the different currencies.

The Clearing account will be defined by payment method and House Bank. Each bank account will have separate GL account, and each bank will have its own set of clearing accounts (defined by types of payment that can be made from that account)2. Available Amounts:

SAP Standard functionality will be used to calculate value dates (based on payment method and currency)

For all EVO the amount available for outgoing payments will be 9.999.999.999.999,00. E.g.:Company CodeHouse BankAccount IDDaysCurrencyAvailable for outgoing paymentScheduled incoming payment

GB06000019999999GBP9.999.999.999.999,009.999.999.999.999,00

Note: The previous tables are just an example. The final ones will contain the details specified by company code.

4.8.2 Customizing the In-House Cash Centre As a virtual house bank, the in-house cash centre receives payment orders from subsidiary companies in the form of PAYEXT IDocs and posts them to the corresponding current accounts. The in-house cash centre creates and sends account-statement-relevant data in the form of a FINSTA IDoc.

4.8.2.1 Define In-House Cash Centre as Bank Area

SAP specifications:

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

Role of the object:

Define the bank area that you require for your organization and determine certain defaults which will or can affect all accounts within the bank area. Within a bank area, complete and independent account management and account processing takes place. This means there must be clear and unmistakable account numbers within a bank area. A bank key (for example, in Germany the bank identification number) is assigned to each bank area. You normally create an own bank area for every banking organization for which a bank key exists. You create accounts and conditions specifically for a bank area. Note that within a bank area there must be clear and unmistakable account numbers.

SAP guidelines:

SAP recommends that you create a bank area for each organization managed in the system which has its own bank key. Generally, you will only need one bank area. The bank country to be entered (where the institute is located) controls how the bank key is treated and which underlying control mechanisms apply. The bank country also determines the maximum length of account numbers that the system uses in this bank area. Attribute details:


SAP transactionSPRO

Technical nameIHC_V_BANK_AREA-BKKRS

Field typeCHAR

Field length4

SAP levelClient


Financial Supply Chain Management In-House Cash Basic Settings Bank Area Define Bank AreaEVO 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.AttributeDescription

AreaFI

OwnershipGlobal




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 definedBank Area

Description Bank AreaBank country keyBank KeysExchange Rate TypeCompany code

GL Variants

IHC_V_BANK_AREA-BKKRSIHC_V_BANK_AREA-T_BKKRSIHC_V_BANK_AREA-BANKSIHC_V_BANK_AREA-BANKLIHC_V_BANK_AREA-RATETYPEIHC_V_BANK_AREA-BUKRSIHC_V_BANK_AREA-GLVAR

IHCEEVO IHC BankHU99999999MHU01 (Vodafone Op.Centre Hungary)IHCE

Activate LOG and IHC active4.8.2.1.1 Set Up Number Ranges for Log

SAP specifications:

Meaning and Role of the object:A payment order originated from OpCo accounting and integrates seamlessly into IHC. In the event that an error occurs, a log is created and referenced by a unique error log number. This configuration is required to specify the number range which the error log references will use. The number range is year dependent allowing for adequate value range.Attribute details:


SAP transactionIHCN1

Technical nameINRDP-NRRANGENR

Field typeCHAR

Field length2

SAP levelClient


Financial Supply Chain Management In-House Cash Basic Settings Set Up Number Ranges for LogEVO Specifications:

Planned usage:

To Log the payment orders regarding technical reasons it must be defined a number log.AttributeDescription

AreaFI

OwnershipGlobal




Enter 01 as the Number range number.

Create only one number range.

Define an interval of your choice with at least 100000 numbers.

Do not set the indicator for external numbering.

4.8.2.1.2 Set Up Number Ranges for IHC Payment Orders

SAP specifications:

Meaning of the object:IHC payment orders are numbered automatically. A payment item is created in IHC as a result of the payments generated by OPCO payments. This number range is used for assigning a unique reference to each payment item. The number range is year dependent allowing for adequate value range. This is used to enter a payment transaction. An IHC payment order documents a payment from a bank account to a recipient account and contains a payer and a recipient position. The IHC payment order holds these payment items together but strictly speaking it does not post anything.

Role of the object:

In this activity, you process the number range intervals. Attribute details:


SAP transactionIHCN3

Technical nameINRDP-NRRANGENR

Field typeCHAR

Field length2

SAP levelClient

SAP guidelines:

Create the number range interval 01 with internal number assignment for each bank area and year.

Create a separate number range interval for each year.


You can execute this function introducing the transaction code IHCN3 or following the path:

Financial Supply Chain Management In-House Cash Basic Settings Bank Area Set Up Number Ranges for IHC Payment OrdersEVO Specifications:

Planned usage:

For the IHCE bank area create a number range interval for IHC payment orders.


AreaFI

OwnershipGlobal




4.8.2.1.3 Define how in House cash data is transferred to Financial accountingSAP specifications:


Set how the transfer of the general ledger data to financial accounting is to take place.

Role of the object:In this section you can set the +/- sign with which postings are to be displayed by the system.

You have the op