To-Be Process Design:

MDM-010 Business Partner and

Contract Account Creation
Document Control Information

Document Review/Approval History

Date Name Organization/Title Comments
01/2016 Nathalie Boeykens Deloitte SAP consultant Initial draft
05/02/2016 Stefanie Fauconnier Colruyt Functional analyst Added:
 High-level
overview of FinRel
and SAP
datamodels
 Which data will be
synchronized
 Process overview:
FinRel use cases
09/02/2016 Sophie Castanié Team Lead Review
16/02/2016 Nathalie Boeykens Deloitte SAP consultant Final version before
validation together with
Stefanie
07/04/2016 Nathalie Boeykens Deloitte SAP consultant Final version after
validation + integration
PTP
13/07/2016 Pieter Van Dyck Process Responsible Approval
com138.524.090

Distribution of Final Document

The following people are designated recipients of the final version of this document:

Name Organization/Title
Pieter Van Dyck Process responsible

Reference to external files (SharePoint)

Provide an overview of existing materials used to create this BPD

A reference matrix that indicates what source of information has been used to establish this
documentation set

Filename Link SharePoint

Requirement Traceability Matrix https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Template/
Working%20Documents/OTC/RTM_RequirementsTraceMatri

Document Control Information Page ii Document1

19-Mar-18
 Filename
Enterprise Structure
Tobe Master Data Design
Posting scheme
Change impact assessment
Document Control Information
19-Mar-18
Link SharePoint
x%20OTC.xlsm
https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Integration
/Working%20Documents/accounting%20treatments%20-
%20O2C%20review.xlsm?Web=1
https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Template/
Working%20Documents/OTC/C2.0_VIE_O2C_Change%20I
mpact%20Assessment.xlsx
Page iii Document1
Table of Contents

1 INTRODUCTION............................................................................................................................................ 5
DOCUMENT OBJECTIVE .............................................................................................................................................. 5
DOCUMENT PROCESS SCOPE.................................................................................................................................... 5
1.1.1 Mapping to Industry Print .................................................................................................................. 9
PROCESS VARIANTS ................................................................................................................................................... 9
PROCESS OVERVIEW ................................................................................................................................................ 10
1.1.2 Process Diagram ............................................................................................................................... 10
1.1.3 Process Overview .............................................................................................................................. 10
1.1.4 Process Activity Description ............................................................................................................. 11
1.1.5 Overview of Transactions ................................................................................................................. 28
2 BUSINESS REQUIREMENTS .................................................................................................................... 29
PROCESS .................................................................................................................................................................. 29
PROCESS CONTROLS ............................................................................................................................................... 32
METRICS / REPORTING ............................................................................................................................................. 33
LEGAL ....................................................................................................................................................................... 33
CHANGE IMPACTS ..................................................................................................................................................... 33
FUNCTIONAL INTEGRATION TOPICS ......................................................................................................................... 34
2.1.1 Functional integration ........................................................................................................................ 34
3 SAP FUNCTIONALITY GAPS.................................................................................................................... 35
DEVELOPMENT REQUIREMENTS (WRICEF) ........................................................................................................... 35
1.1.1 Workflow .............................................................................................................................................. 35
4 ROLES & AUTHORIZATIONS ................................................................................................................... 36
ROLES....................................................................................................................................................................... 36
5 ANNEX ......................................................................................................................................................... 37
OVERVIEW OF REPORTS ........................................................................................................................................... 37
6 ABBREVIATIONS ....................................................................................................................................... 39

Table of Contents Page iv Document1

19-Mar-18
1 Introduction

Document Objective
This business blueprint document provides a high-level overview of the following Sub-process:

 Create and maintain customer master data

Document Process Scope

Customer master data will be maintained in the existing Colruyt Group application FinRel. FinRel contains
Financial Relations (= FinRels). A FinRel is a person or organization who is relevant to Colruyt Group
Finance. A FinRel can be in contact with Colruyt Group in the role of Customer or of Supplier.

These data will be synchronized from FinRel (master) to SAP FICA (slave). This implies that:

- Customers will not be created, modified or deleted directly in SAP.

- Customer master data will as a rule not be updated directly in SAP. Information coming from
the business partner/contract account can be overwritten manually at document level by an
end user (interest rates and interest locks, payment methods, payment locks). SAP FICA is a
subledger accounting for processing large document volumes and realizes the typical
accounts receivable functions. In FICA master data is maintained on two levels: the business
partner level and the contract account. Which information is stored on which level is
described further in the document

SAP high level model:

- In SAP, a person or organization is present as a business partner. On the level of the
business partner, generic information about this person or organization can be stored, for
instance: addresses, names, bank details etc.
- One business partner can have multiple contract accounts. A contract account contains
information about the customer in a specific company. This information can include: mandate
information, payment terms, …When a sales transaction is registered in SAP, a document
will be posted with a link to the relevant contract account.
- One business partner can be created in multiple roles. The business partner will always be
created in the general role. Depending on whether the business partner is a customer and/or
vendor, we will add the OTC and/or PTP specific role. For OTC processes we will use the
FICA role. For PTP processes the business partners will be created in another role.

Introduction Page 5 of 39 Document1

19-Mar-18
 Finrel high level model:
- Finrel contains Financial Relations. A FinRel is a person or an organization who is relevant
for Colruyt Group Finance. A FinRel can be in contact with the Colruyt Group in the role of
customer or of supplier. Relevant data objects stored for FinRels with the role customer are:
LinkedFirm, address, financial contact, mnemonic, payment conditions, bank account details
and mandate.

One FinRel will map to one business partner and one linked firm will map to one contract account.

Introduction Page 6 of 39 Document1

19-Mar-18
Finrel high level model

Introduction Page 7 of 39 Document1

19-Mar-18
SAP High level model

Introduction Page 8 of 39 Document1

19-Mar-18
1.1.1 Mapping to Industry Print

Process Variants
The following variants have been identified during Business Blueprint and will be in scope for realization:

 Creation of business partner and contract account (customer master data)

 Changes to business partner and contract account

 Block/Archive business partner and contract account

 Display customer master data

Introduction Page 9 of 39 Document1

19-Mar-18
Process overview

1.1.2 Process Diagram

Figure 1 Colruyt Process MDM-010 Create and Maintain Customer Master Data

1.1.3 Process Overview

The process MDM-010 Create and Maintain Customer Master Data includes the following activities:

 MDM-010-010 Validate request in Finrel

 MDM-010-020 Send to SAP
 MDM-010-030 Create Business Partner
 MDM-010-100 Add customer role to the existing business partner
 MDM-010-060 Create Contract Account
 MDM-010-070 Update information
 MDM-010-080 Block business partner: central block flag
 MDM-010-090 Archiving flag for business partner
 MDM-010-040 Lock outgoing payment on contract account level

Introduction Page 10 of 39 Document1

19-Mar-18
1.1.4 Process Activity Description

Activity MDM-010-010 Validate request in Finrel

Creation, changes, blocking and deletion of customer master data always happens in Finrel. In FinRel
there is a validation process for certain actions (e.g. creation of a new customer). Data will only be
synchronized to SAP after validation if validation is needed (according to the image below). As long as a
business partner/contract account is not validated and available in SAP, no documents can be posted.
The SLE for validation is determined as followed :

VELDEN TE VALIDEREN SLA

NIEUWE TOEGEVOEGDE
RELATIES 1 dag
Alle velden
TOEGEVOEGDE
HERKENNINGSCODE 3 dag
BRCK (Colruyt-kaart klant)
CDCU (Symeta klant)
CDSU (Symeta Leverancier)
CPCU (Premedia klant)
DAKL (Dats24)
DDER (Dreamland)
DKLA (Dreamland)
EBAS (Eoly-klant)
EB2B (Collishop prof)
PROF (Colruyt prof)
PROM (Promesse klant)
PSSU (Leverancier) 1 dag
ZACH (FR) (Zakencheque)
PSCU (Factuurklant) 1 dag
WIJZ FINANCIELE RELATIES
VANUIT CBH 3 dag
CLASSIFICATIE
TYPE RELATIE
NAAM (VOORNAAM)
TAAL
GEBOORTEDATUM
STRAAT
STAD
LAND
BTW/ONDERNR

Introduction Page 11 of 39 Document1

19-Mar-18
WIJZ FINANCIELE RELATIES
VANUIT FINREL 3 dag
CLASSIFICATIE
TYPE RELATIE
NAAM (VOORNAAM)
TAAL
GEBOORTEDATUM
STRAAT
STAD
LAND
BTW/ONDERNR
NEW SEPA DD MANDATES 1 dag
REKENINGNUMMER
NAAM
DATUM GETEKEND OP
HANDTEKENING OP
DOCUMENT
NIEUWE
BANKREKENINGNUMMER 1 dag
NAAM
REKENINGNUMMER
DOCUMENT
Extra :
Het verhangen van een mnemonic na validatie mag niet meer mogelijk zijn. OK PIDYC
Automatisatie mogelijk door het linken van een BTW-bestand (KBO/Creditsafe)
WD4 : alle nieuwe finrels, 1x klant en/of 1x lev moeten op dag zelf gevalideerd zijn. BELANGRIJKE CHANGE

The two figures displayed below, illustrate when validation of creation/changes to customer master data
in Finrel is needed. Creation of a new financial relation, always needs to be validated. Changes regarding
bank account details also needs to be validated before the necessary changes can be send to SAP. The
type of relationships and relationship address changes will be send immediately.

Other changes do not need to be validated and will be sent from Finrel to SAP online (real time). Deletion
of customers also never needs to be validated.

Introduction Page 12 of 39 Document1

19-Mar-18
Introduction Page 13 of 39 Document1
19-Mar-18
Introduction Page 14 of 39 Document1
19-Mar-18
Activity MDM-010-020 Send information regarding the changes to/creation of business partners to
SAP

After validation in Finrel, the information can be sent to SAP to make the necessary changes. This will
happen in real time. The initial load of data however will be uploaded in batch.

The validated information will go through the sustainable interface, where the data will be translated to
SAP language. The sustainable interface will also add some information that is needed in SAP but cannot
be delivered by Finrel (described later in this BPD).

In SAP the customer master data will be stored in two places: the business partner and the contract
account. The business partner contains general information of the customer (name, address, bank
details…) whereas the contract account contains information that is specific for the customer in each firm
of the Colruyt Group.

The updates in SAP will happen automatically, so no manual intervention is needed. We will not maintain
any customer master data directly within SAP. All updates will either come from Finrel or via the interface.
The possible updates:

- Create a business partner and create contract accounts for all the linked firms of the customer.
- Change business partner/contract account data
- Block or archive business partner/ lock outgoing payment on contract account

The customer master data will only be available in SAP in display mode. End users can display this data
via the display transaction codes FPP3 for business partner and CAA3 for contract accounts. Customer
master data is created or changed within FinRel and interfaced towards SAP.

Manually changing data in SAP will be impossible. In case of errors in the flow from information between
the interface and SAP, we will update Finrel. Other errors can lead to a required change in the interface.
In this case a change request is needed to do the necessary changes in the interface

Create
For the creation of business partners in SAP two possibilities exist. The regular case is MDM-010-030
when a completely new business partner is created. It is however also possible that the business partner
already exists in a vendor (see PTP processes). In this case we will add the customer role to the existing
business partner.

Activity MDM-010-030 Create Business Partner

The validated data in Finrel will lead to the automatic creation of a business partner in SAP. No manual
creation of business partners will be possible in SAP. For one time vendor we will need to do the
necessary configuration manually in SAP. This will only need to be done one time. This one time vendor
will be used for customer reimbursements and for employee as vendor.
All fields will be filled out by the interface. No data will be transferred back from SAP to the legacy
system. Some data that is SAP specific and that is not maintained in the legacy system (e.g. Withholding
tax codes for the Cobonet process) will be derived in SAP or in the Sustainable inferface.

Introduction Page 15 of 39 Document1

19-Mar-18
When a business partner is created automatically, all data fields that are used need to be filled in when
accessing the interface (see functional interface specification FSI-053). This means that:
- No data will be added in SAP
- All meaningful data will come from FinRel. If necessary, FinRel will be expanded with new fields.
- Data that cannot come from FinRel will be supplied by the sustainable interface (enrichment)
Some data fields will not be synchronized from FinRel to SAP because it is not necessary to store them in
two places (eg marital status, legal form etc). When consulting the SAP screen, these fields will be
invisible when possible.

One financial relation in Finrel will map to one business partner in SAP. When a new financial relation is
created in Finrel, we will always create the business partner in at least two roles. Always the general role
and then depending on the kind of business partner we will add the vendor and/or the customer role. The
general role will contain general information on the business partner that is ‘role independent’. The
general business partner role will contain the following data:
 Business Partner Role: Via the business partner role, different uses of business partners can be
defined. Each business partner needs to be created in a certain role. The role of the business
partner will determine which information is required, optional or hidden. For example, when the
business partner role is contract partner, information on payment details is important while if the
business partner is only used for dunning purposes, contact information such as addresses and
phone numbers is more important. By using two different roles for those two purposes, you can
define which fields need to be filled in for each role. However, field modification will not happen in
SAP. In Finrel we will determine which fields are mandatory, optional, hidden or displayed and
this will be sent to SAP. Assigning a role is mandatory when creating a business partner. For
Colruyt Group, three possible business partner roles will exist: the general role, the
contractpartner role for OTC processes and the FI vendor role for PTP processes. Finrel will
provide this information. Business partners that are both vendors and customers will be stored in
SAP as one business partner with three roles: general, contractpartner and vendor. Every
business partner will always be created in the general role.
 Business Partner Category: the business partner category is the first selection that needs to be
made when creating a business partner. The business partner category determines the available
fields in the following steps of business partner creation. The possible business partner
categories are person, organization and group. In Finrel, two categories exist: person and
organization. In Finrel it is possible to change the classification of a customer and it occurs quite
often that a person becomes an organization. Since the business partner category cannot be
changed in SAP once it was determined, we will only use the category ‘organization’ in SAP. The
only practical difference is that the person has a name and not an ‘organization name’. This is
easily solved by mapping the name field in Finrel for a person, to the ‘name of organization’ field
in SAP. In SAP a third category ‘group’ exists but we will also not use this since it does not even
exist in Finrel and because there is currently no need for this business partner category. The
category group contains business partners that consist of multiple persons. One business partner
number can contain two people (e.g. husband and wife). If we later decide to use other business
partner categories, then these can easily be added via configuration in SAP and a change in the
interface but the classification of existing customer will no longer be able to change.
 Grouping: By defining business partner groups, business partners can be classified. The grouping
determines the number range. For Colruyt Group, the business partner number will come through
the interface (= Finrel number) and will therefore be determined externally. The Finrel number
exists of a unique identification number and a prefix. These prefixes are used to identify whether
the customer is an internal or an external customer. The business partner number will be the
Finrel number but without the prefixes. The prefixes will be stored at business partner type level.

Introduction Page 16 of 39 Document1

19-Mar-18
 Only one grouping of business partners will be used: Finrel. This value will also need to come via
the interface.
 Business Partner number: The numeric part of the Finrel number (without relation number R/I) will
be the business partner number in SAP (valid for Vendor and Customer roles). This number will
be used across all entities of the Colruyt group that will use SAP. Similar to master records in the
legacy, the business partner in SAP will only be activated for the entities in which the vendor
exists in the Legacy. This means that the interface will be able to either create a brand new
business partner with activation in one or more entities or to only activate the business partner in
an entity.
 Address data: In Finrel four types of addresses are stored for each business partner: relation,
invoice, dunning and VAT address. Only the relation address will be synchronized to SAP, where
it will be listed as the standard address and as the bank statement address since these are the
types of addresses we want to maintain in SAP. The bank statement address needs to be
defined to be able to do a payment run in SAP (for direct debit and refunds). For PTP processes
only the address of the social seat needs to be maintained but this is the same address as the
relation address.The other addresses will not be used in the beginning. The dunning address is
not needed because dunning will still happen in OnGuard and the invoice and VAT address is not
needed because invoicing will not happen in SAP. However, Finrel needs to be able to also send
these addresses to SAP in case we decide in the future to use SAP also for dunning purposes for
example. An address consists of a number of fields: Street, House number, postal code, city and
country. In SAP the field Postal code can contain a check on the legal format (eg 4 numeric
characters in Belgium, 5 numeric characters for France). However the correctness of the data
needs to be assured in FinRel. Therefore this check will not be activated in SAP.
 In the address tab also general information on the business partner is stored such as:
o Name: The name field can consist of 4 lines of 40 characters. For Colruyt Group entities
only the first line will be used. We will use the organization name of the business partner.
o Language: the language key is used to determine the language in which correspondence
to the vendor will be issued. All correspondence that needs to be generated in SAP will
be sent to the vendor by BCOM. Communication (e.g. payment advice) will be prepared
in SAP, therefore the language key from SAP will be used.
o Email address: For OTC we will not need an email address. For PTP an email address
will be used, for sending the payment advices to vendors. This communication will not be
sent directly from SAP but will be sent centrally by BCOM. The email address will be
determined from the SAP vendor master record. In SAP there is only one field to store
an email address. Currently that is enough but if we want to maintain multiple email
addresses in the future, there needs to be a destinction between email addresses so that
the correct address is used. Therefore we will use the field ‘Notes’ to make this
destinction. The email address that is to be used for Accounts Payable communication is
stored in Finrel as the email address for payment data (‘e-mail betaalgegevens’) and will
be indicated in SAP with the key ‘PAY’ in the field ‘Notes’. The field ‘Notes’ is a free text
field to maintain further information about an email address. The field will be used by
interface FSI-055 (see BPD DC-030) to identify the email address that needs to be used
for the payment correspondence towards the vendor.If we want to store extra email
addresses in the future, we can just create an extra key in the field ‘Notes’.
o The following information is not needed for Colruyt Group: telephone, name affix, suffix,
academic titles, occupation, marital status, industries, legal forms and legal entities.
These fields will be hidden in SAP.
 Search terms: In SAP two fields are available to store search terms in order to restrict the search
for a business partner. These two fields will not be used as all information will already be stored in
different places

Introduction Page 17 of 39 Document1

19-Mar-18
  Identification: In this tab in SAP, different identification categories can be maintained. In the
configuration we can determine the needed ID categories and the corresponding specifications.
Also some personal information can be stored here such as sex, birth and death date. For Colruyt
Group these ID categories will be used to maintain the mnemonics for a business partner. This
information will be stored because the customers will use this number as payment reference for
payments. We will also use the external BP number field to store the personnel number in case
the business partner is an employee of the Colruyt Group.
The mnemonics that will be maintained are DAKL,PSCU, HAUL and SPAR. These are the only
systems that will be generating documents that are going to customers.

IDType Description
DAKL DATS klant
HAUL Haulogy
PSCU Peoplesoft customer
SPAR SPAR klant

o VAT information is also stored in the identification tab: both VAT and enterprise numbers can be
maintained in the business partner. These tax numbers are all maintained in a table within the
Business Partner master record. Each country can have its own tax number types and
numbering conventions and they are all supported by SAP. The Tax number needs to be
accompanied by a Tax Number Category that identifies the country and tax number type. Some
of the common categories are
BE0 Belgium: VAT Registration Number
BE1 Belgium: Enterprise Number
DE0 Germany: VAT Registration Number
FR0 France: VAT Registration Number
FR1 France: SIRET Number
FR2 France: SIREN Number
ES1 Spain: NIF Number
Currenctly a key that identifies the type of VAT number is not available in FinRel but it is foreseen
to be added.
More information regarding the VAT information and natural person can be found in the BPD
Monitor local close
https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Template/Content%20Deliverables/BPD_IP
%20level%202%20-%20Monitor%20local%20close.docx
In the topic 2.2.13.1 DC-100-120-010 Extract financial reports under bullet point Withholding Tax
 Control: In this tab the following information is maintained:
o Business Partner Types: Via business partner type, business partners can be grouped
according to own set criteria in customizing. In customizing you can show or hide fields
for data entry, depending on the requirements of the relevant business partner type. The
business partner types will be used to differentiate between intercompany (I) , external
(R), dummy (D), joined (J), related party (P) and One time (O) customers. These are the
different possibilities in Finrel. For the business partner types I and J an extra field for the
company code is necessary this will be ‘Trading Partner’. Other fields are equal for all
business partner types. For vendor only the business partner types I and R will be used.

Introduction Page 18 of 39 Document1

19-Mar-18
  Internal customer: a customer/vendor that belongs to the Colruyt Group
(example: Colruyt, Dreamland)
 External customer: customers/vendors that do not belong to the Colruyt Group
 Dummy customer: unknown customers
 Joined: boekhouding op afstand (vb. Codi-France)
 Related party: example Jef Colruyt, Dim, Him
o In this tab there is also the possibility to put a note via correspondence note, accounting
note, marketing note or credit management note. These are all text fields.
o Payment transactions: Contrary to Legacy, bank details are not maintained at company level.
They are part of general data, which means that they can be used by all companies for which the
business partner is created. As a consequence it will not be possible in SAP to derive the
preferred bank account in SAP. OCR and ventilation will still use ‘locatie’ for the allocation of
invoices. At the moment of the final posting in SAP this ‘locatie’ will be used to select the
preferred bank account from FinRel and this bank account will be transferred to the SAP posting.
Bank data in SAP consists of the following elements:
o Bank Details ID (= partner bank type at document level): a business partner can have
multiple bank accounts and he can specify a preference to which bank account invoices
should be paid to. The bank details ID gives a unique identification to each of the bank
accounts. Bank accounts are also sorted on the Bank Details ID in ascending order. The
bank account that takes the first place in the list of bank accounts is the preferred bank.
Bank Details ID is the indicator that is used in invoices and payment requests to identify
the vendor/customer bank. If no value is specified in the invoice or payment request,
then the preferred bank is used. For OTC processes the bank details ID is also very
important because it is used to link the bank data on business partner level with the
mandate on contract account level. The bank details ID does not exist in Finrel but will be
the same as the unique identification of the bank account in the legacy system.
o Bank Country: identifies the country in which the bank is based. The Bank Country can
be different than the home country of the business partner or the country of the VAT
number. Fraudechecks have to be forseen in FinRel.
o Bank Key: unique number identifying the bank (eg 001 for BNP, 400 for KBC) . This key
must be defined in advance and contains data like bank name, address and BIC code.
The Bank key needs to be available in SAP prior to the upload of the bankdata of a
vendor. The key contains the name of the bank and (more important) the BIC code of
the bank. All Bank keys will be loaded in the system as a conversion task and will be
available for use at the moment the vendor/customer accounts are being transferred.
o Bank account Number: the number under which the account is managed at the
bank.This information will come from Finrel.
o Bank control key: for some countries (eg France), a control key contains a check key for
the combination bank key and bank account number.
o IBAN: A uniform standardized ID number for representing bank details that is in
accordance with the ECBS (European Committee for Banking Standards).This
information will come from Finrel.
o For Colruyt Group payment card information will not be used.
o The master data interface between Legacy and SAP will not transfer all bank account
information listed above. Only the IBAN code and the bank details ID will be uploaded in
SAP. The IBAN code will be converted by an standard SAP function into Bank country,

Introduction Page 19 of 39 Document1

19-Mar-18
 Bank key, and eventually Control key.The BIC code will be derived in SAP based on the
Bank Key that is predefined in the system.
 Status: In this tab the only fields that will be used are the central block flag and the archiving flag
in case a customer is blocked/archived in Finrel (see activities MDM-010-080 and MDM-010-
090). Other information stored here is irrelevant for Colruyt Group.
 Relationships: business partners can be linked with each other in relationships. Relationships are
maintained in Finrel and will not be needed in SAP so this field will not be used.

Activity MDM-010-100 Add customer role to the existing business partner

In case the business partner already exists in SAP in the role of vendor (and thus also in the general
role), then we only need to add the customer role and update some fields if needed (for example add
bank account).

Activity MDM-010-060 Create Contract Account (for customer only)

In FICA a business partner always has attached contract accounts with firm specific information for the
business partner. One contract account is created for each legal entity where the business partner is a
customer.
One contract account in SAP maps to a linked firm in Finrel. The linked firm contains data which is
specific to the relation between one FinRel and one Colruyt firm. A FinRel can be linked with multiple
Colruyt firms.

When a business partner is created in Finrel, at least one contract account is created immediately since a
business partner is always created for at least one linked firm. For every linked firm, a contract account is
created. Because the information flows from Finrel to SAP in only one way, it is not possible to create
multiple contract accounts, within the same company code, for the same business partner since Finrel will
never know to which contract account the information should be sent.

It is also possible that a business partner who already has a contract account in Dreamland for example,
later also becomes a customer in Colruyt for example. This means that now a new contract account will
need to be created for this business partner at the moment of the sales transaction in this firm. This will
be done by adding a linked firm in Finrel first and then sending the information for the creation of a
contract account to SAP. This should happen online (real time) because as long as the contract account
does not exist, no documents can be posted.

Each contract account has a unique number that can be determined internally or externally by another
system. For Colruyt Group the numbering of contract accounts will happen externally. The interface will
send the contract account number to SAP. This number will be the Finrel number followed by the
company code. This numbering is not possible by using internal numbering in SAP. A contract account
number can consist of up to 12 characters.

In SAP a contract account is always created attached to a certain business partner. A single contract
account can only be assigned to one business partner. Before creation of a contract account, a contract
account category needs to be defined. This is a grouping attribute for accounts which have the same
control features. The contract account category defines the field determination for the contract accounts
that are created in this category. Field determination is used to identify which fields of a certain
transaction code are required to fill in, optional, displayed or hidden. For Colruyt Group, a single contract

Introduction Page 20 of 39 Document1

19-Mar-18
account category will be used for all contracts since field determination will happen mostly in Finrel and it
will be the same for all contract accounts. The contract account category does not exist in Finrel and will
need to be delivered by the interface. When Finrel determines the field status, than the fields will be
optional in SAP since this has the lowest priority. For some fields, the field status will be determined in
SAP as well. This is the case for mandate information because we need to guarantee that all required
information is filled in when creating a mandate to avoid that payments will not be offered due to
incomplete mandate data. Fields that we will not use in SAP (fields that will not be filled in by the interface
and that are not needed) will be hidden. Information that is maintained at contract account level:
 Authorization groups: authorization groups enable us to protect access to certain objects.
Different authorization groups can be created to give specific users access to certain information,
to give them permission to change certain data etc. For all objects no authorization groups are
needed since the information will come either from Finrel or from the interface and will not be
adaptable in SAP.
 Relationship of business partner to the contract account: in SAP this is a mandatory field. For
Colruyt Group only one possible relation will be defined: account holder. This will come from the
interface.
 Tolerance groups: tolerance groups are used to determine the tolerance values for payment
differences. For Colruyt one tolerance group is currently used: tolerance of 10 % with a maximum
amount of 5 EUR. End-users will not be able to choose another tolerance group or to change the
parameters of this tolerance group. This tolerance group can either be left blank in SAP and
customized to the needed value (customize: blank = 10% with a maximum amount of 5 EUR). Or
if we want to see in SAP that the tolerance group is 10% with a maximum amount of 5 EUR
(instead of a blank field), than the information will need to be sent to SAP. Since we prefer to see
the value of the tolerance group in SAP and because in the future we might want to add extra
tolerance groups, the last option was selected. The tolerance group currently does not exist in
Finrel, but this will be added in Finrel.
 Clearing category: defines the clearing rules for postings. We will use only one clearing category
which will always be used. The clearing category is not maintained in Finrel, the same options
exist as for the tolerance group: using a default value for a blank field or send information to SAP.
It has been decided that we will send the information on the clearing category via the sustainable
interface.
 Interest key and interest lock reason: In SAP an interest key needs to be determined for each line
item on which interest is to be calculated (needed for RPCG). The interest key contains the
interest rates to be used. These will be either 0%, 8% or 12%. Since 12% will be the most used
percentage, we will always put this on contract account level. In case the interest rate should be
8% than this will be overwritten manually in SAP at document level. This is possible when the BA
of RPCG makes an agreement with the customer that interest can be lowered to 8%. The manual
update in SAP will happen by the department ‘debiteurenbeheer’ from RPCG. The interest lock
reason is used to define a reason for excluding a specific item or a contract account for interest
calculation. This can be used for example when for a certain business partner an agreement has
been made to exclude a certain item from interest calculations. The interest lock can be put
manually in SAP on document level. If we decide that a certain business partner does not need to
pay interest for a certain period of time (on all his documents) then we will change the interest key
on the contract account to 0%. The interest key needs to be filled in in SAP and can currently not
be maintained in Finrel. We will expand Finrel to make it possible to manage this information
there. From Finrel it can then be synchronized to SAP. We have the possibility to create a report
on the list of customers with an interest lock which can then be reviewed and approved by an
authorized person. This report can be consulted via transaction code FPO4.
 Account Determination ID: together with the main and subtransaction that are defined at
document level, the account determination ID determines the GL account to which the documents
are posted. The different business partner types will be linked to different reconciliation accounts.

Introduction Page 21 of 39 Document1

19-Mar-18
 Four reconciliation accounts will be used for Colruyt Group, one for internal customers (IN), one
for external customers (EX), one for the dummy customers (DU) (for freezer, Colruyt Group
Academy, Primeurwijn etc) and one for guarantees. The reconciliation account for linked party
and joint customers is the same as the reconciliation account for external customers. This
information cannot come from Finrel so the interface will need to add this information.
 Payment terms: this is the key used to define the rules for determining the due dates for incoming
payments and the due dates for outgoing payments in the legacy system, payment terms are
used to define the net due date of a document, since the information related to the net due date
comes across via Finrel, there is no need to maintain payment terms at contract account level.
 The company code and company group code: the company code is required at contract account
level to identify to which company the contract is created. For Colruyt Group, each company code
will be assigned to a company code group of the same name so that a contract always belongs to
a unique company code.
 Payment methods: both for incoming and outgoing payments, a payment method can be defined.
This is not mandatory. Payment methods defined at contract account level can be overwritten at
document level. For Colruyt Group, the incoming payment method will not be specified on
contract account level. Documents created via the interfaces for OTC will always hold a payment
method at line item level. For OTC the possible payment methods that we will define on
document level are O for overschrijving and D for direct debit. If the payment method (defined at
document level) is direct debit, than the needed information needs to be foreseen in the contract
account, so bank details ID (the link with the bank account that was determined at BP level) and
mandate information will need to be filled in even though the payment method will be left blank.
The other fields in the incoming payment method tab do not need to be filled in. For outgoing
payment method, we will always mention ‘O’ for overschrijving. This is needed in case a refund
would need to be made. A bank details ID also needs to be filled in. Other fields can be left blank.
 Mandate information: a mandate is stored at business partner level with eventually a reference on
the contract account level, one contract account can contain multiple (active) mandates. In the
legacy systems, each payment card is linked to a certain bank account in DAKL/BRCK. In Finrel
this bank account contains the mandate information which is also stored at business partner level
(each mandate is assigned to a certain bank account in Finrel). This means that the card is
sufficient to identify the bank account and the mandate in the legacy before passing the
information to SAP. This also means that one customer can have multiple payment cards that are
linked to different bank accounts; the assembly will still be able to always identify the correct
mandate and to transfer the mandate information to the document. Creation of mandates will
happen in Finrel. Mandate number ranges will come through the interface. In SAP we will
indicate external numbering for mandates. In SAP mandates are stored at contract account level
but the bank account to which the mandate is linked is situated at business partner level. In the
mandate information, the bank details ID field is used to make the link between the mandate and
the correct bank account in the business partner information.

Introduction Page 22 of 39 Document1

19-Mar-18
  Dunning procedure: this will not be maintained in SAP but in Onguard. This field will not be used
in SAP (but still visible). The sustainable interface however needs to be foreseen to send the
necessary data to SAP in the future.

Introduction Page 23 of 39 Document1

19-Mar-18
Delete

Activity MDM-010-080/090 Block/Archive business partners

In FinRel, a customer can be logically deleted. This implies that the customer is not visible in the
application, but the data is not erased from the databank. Archiving of customers in Finrel happens when
no mnemonics exist for the customer. This means that the customer is no longer used in the different
companies.

In SAP, archiving business partners is not that easy. A business partner can only be archived when no
contract accounts are attached. This means that we would first have to delete/archive the contract
accounts, which is only possible when no documents are attached to the contract account. Therefore we
will not archive business partners often. Instead we will use either a central block flag or an archiving flag
to indicate that the customer was either blocked or archived in Finrel. These indicators will only have an
informational purpose, no actions will result from setting this flag.

In Finrel customers can be blocked, archived or deleted (“schrappen”):

 Block: a problem with the customer exists, but we do not want to delete the data from the system.
The customer needs to stay present in the system. Example: customer is bankrupt. Remark: a
block will not trigger archiving of customers automatically.
 Archive: The customer is no longer necessary in the system. Its data is still present on the
database. Example: the customer is no longer used, no more mnemonics exist for this customer.
 Delete (“schrappen”): This only happens in case of an error or a double registration of a certain
customer. This information will normally be deleted before it comes to SAP so in most cases, no
action is required in SAP. To do: permanent deletion double check.
Required actions in SAP
 Central block: a central block is an indicator that can be selected at business partner level. This
will not have any consequences but it is purely informative. A central block will be put
automatically in SAP when a customer was blocked in Finrel.
 Archiving flag: The archiving flag is also purely informative and will not lead to any further actions.
The business partner can theoretically still be used in transactions and is still visible in reports.
However, since the business partner was archived in Finrel, and SAP is slave to Finrel, no more
transactions will happen with that business partner. It will be put on business partner level when a
customer was archived in Finrel. A report will need to be available to check if there are still
archived business partners in SAP that are still used in transactions.
 Deletion flag on contract account: This is an indicator that the corresponding Finrel data was
archived. The deletion flag will have no consequences in SAP it will be flagged automatically
when a customer was deleted or archived in Finrel. In Finrel two things can happen, either the
entire business partner is archived or the business partner is archived in one company code.
When the entire business partner is archived, then automatically a deletion flag will be put on all
the contract accounts of that business partner. When the business partner is only archived in one
company, then only on that contract account a deletion flag will be put.

Later, an archiving program can be executed in SAP to archive all the business partners for which the
archiving indicator is flagged. Business partners can only be deleted when no contract accounts are

Introduction Page 24 of 39 Document1

19-Mar-18
attached and contract accounts can only be deleted when no transactions are attached. To decide the
frequency and the conditions of archiving, we first have to know the legal requirements regarding the
deletion of documents.

Activity MDM-010-040 Lock outgoing payment on contract account of a blocked business partner
When a business partner is blocked in Finrel, than we need to put a lock for outgoing payments at
contract account level, after setting a central block flag on business partner level:
o Lock outgoing payment: This lock is used to prevent outgoing payments relating to the
contract partner from being initiated by the payment program for this contract account. This
for instance in case of repayment. This block is put in Finrel and is then sent to SAP where
the lock will be put automatically. A lock for invoices and incoming payments will not be used.
This outgoing payment lock will only be put in case of a block in Finrel. In case of archiving
the customer in Finrel, this lock will not be put. A report can be consulted via transaction code
FPO4 to see all documents with a lock for outgoing payments.

Update
Update of information will always happen via Finrel or via the interface. The data will be created/changed
in Finrel and then SAP will be updated. Preferably, these changes will be synchronized real time. Two
options exist for the transfer of the changed data. Either we only send the changed data from Finrel to
SAP or we send the entire business partner information again (snapshot). The last option is preferred
since this is easier and it will avoid possible errors that can result from only sending changed data.

MDM-010-070 Update information on business partner level

When data of a customer changes in Finrel, these changes also need to be visible in SAP. Changes to a
business partner are usually made via transaction code FPP2 but for Colruyt Group, data will never be
changed directly in SAP. The data will be adapted in Finrel and then after validation (if needed) it will be
sent to SAP where the changes will be done automatically.

Once the business partner was created, the following data can no longer be changed:
 Authorization groups
 Business partner number
 Business partner role
 Grouping
 Category: in Finrel this is linked with the ‘classification’ which can be changed. In Finrel it is
possible to change the customer classification from person to organization. The fact that this
change can be made in Finrel but not in SAP is a problem. This problem will be solved by only
using the business partner category Organization (also for persons). The only difference is the
name field which is name and surname for persons and name of organisation for organisations.
This can easily be handled by mapping the name and surname fields in Finrel to the name of
organisation field in SAP. The PTP stream will also only use this category.
Updates can be made to the following data:
 Address: In this tab the standard address can be updated. Also communication methods such as
telephone number, mobile phone number and email addresses can be changed here, this will be
stored in the Address-Independent communication box. In SAP two addresses will be maintained:

Introduction Page 25 of 39 Document1

19-Mar-18
 standard address and bank statement address. The standard address is the company address
and the bank statement address will be the same as the standard address but this needs to be
maintained for direct debit purposes. Changes made to the standard address need to be
validated first in Finrel.
 Address Overview: add extra addresses and assign them to a certain use. From Finrel, only one
address (relation address) will be sent to SAP and this address needs to be allocated to two
different uses: standard address and bank statement address. This will happen via the interface,
and will not be done manually.
 Identification: here we can add/remove certain identification categories and update the
corresponding identification numbers and validity dates, the responsible institution. The
information regarding tax numbers can also be adapted in this tab: no tax categories can be
added but tax numbers can be changed.
 Control: In this tab, the business partner type can be modified via the interface. This is also the
place where notes can be added.
 Payment Transactions: Here bank details of customers can be added/deleted. In case a bank
account to which a mandate is attached, is deleted then SAP will display error messages and
payment runs will no longer be executed.
 Status: in this tab no information will be changed.

In Finrel the following changes need to be validated before they can be sent to SAP:
 Changes to the classification of customers: when a natural person becomes an organization. In
SAP this is not possible. Once the business partner category has been selected (person or
organization) no changes can be made to this.
 Changes to the type of the relationship: when a standard relationship changes to an
intercompany relationship. This change is also possible in SAP: the business partner type can be
changed.
 Changes to the relation address, name, bank accounts, VAT number

Activity MDM-010-080 Update contract account

Updates to the contract account are transferred in the same way as changes to the business partner: the
changes are made in Finrel or in the sustainable interface and then sent to SAP where the updates will
happen automatically. Changes can be made to almost every field in the contract account. Information
that cannot be changed after creation of the contract account is the contract account number, the
business partner number to which the contract account is attached, the contract account category (for
Colruyt Group only one CA category) and the validity start date (the date that the contract account was
created in SAP).

Possible changes to payment/taxes data:

 Incoming payment method information: The incoming payment method will not be specified at
contract account level. However, when a customer wants to pay via direct debit then mandate
information will need to be added here (mandate reference, status, etc.) before the first document
with payment method direct debit can be posted. Once this information is entered for a certain
customer than this will not be deleted later in time. On document level various payment methods
can be selected.
 Mandates: when a mandate is disactivated in Finrel, its status in SAP will change to non active.

Introduction Page 26 of 39 Document1

19-Mar-18
  Company code and company group code
 Outgoing payment data: in case of a bankruptcy, the business partner will be blocked in Finrel
and will receive a central block indicator in SAP. In this case, an outgoing payment lock needs to
be put on the CA level to prevent outgoing payments to the business partner.
Possible changes to general data:
 Trading partner
 Deletion flag
 Authorization group (for Colruyt Group we will not maintain different authorization groups since
master data will not be changeable directly in SAP)
 Tolerance group: currently we will only use one tolerance group. If we would add possible entries
for tolerance groups in the future, then it is possible to change this.
 Clearing category: we will also maintain only one clearing category for Colruyt Group.
 Planning level (for cash management purposes), will be mentioned on G/L account
 Interest key/Interest lock
 Account determination ID: the account determination ID will be used to use different GL accounts
for postings for external, dummy,internal, joined customers and related parties. A change in the
account determination ID is thus possible when an external customer becomes an internal
customer.

Possible changes to dunning/correspondence data

 Grouping for dunning notices: not applicable for now because we will not use dunning in SAP
 Dunning procedure: not applicable for now because we will not use dunning in SAP
 Correspondence variant: this is a key under which correspondence types are grouped for
controlling the periodic correspondence. We will not use the correspondence variant.

Introduction Page 27 of 39 Document1

19-Mar-18
1.1.5 Overview of Transactions
Transaction Transaction Code
Task code Task Description Code description
MDM-010-
030 Create Business Partner FPP1 Create Business Partner
MDM-010-
040 Lock outgoing payments CAA2 Change Contract Account
MDM-010-
070 Update the info on BP level FPP2 Change Business Partner
MDM-010-
Update Contract Account
090 CAA2 Change Contract Account
MDM-010-
060 Create Contract Account CAA1 Create Contract Account
Display Business Partner FPP3 Display Business Partner
Display Contract Account CAA3 Display Contract Account

Introduction Page 28 of 39 Document1

19-Mar-18
2 Business Requirements

Process

Business Business Detailed Detailed

Requirement Requirement Requirement Requirement
Requirement
ID* Name* ID* Name* Description / Desire*
Type*
(Level 1 (Level 1 (Level 2 (Level 2
Requirement) Requirement) Requirement) Requirement)
OTC-001 Creation of OTC-001-001 Create and Decentrale creation and Business
customers maintain modification of customers
customer
master data
OTC-001 Creation of OTC-001-002 Create and The business partner is created in Functional
customers maintain Finrel, all fields in SAP are
customer protected for update.
master data
OTC-001 Creation of OTC-001-003 Create and The business partner is available Functional
customers maintain in SAP via interface from Finrel to
customer SAP.
master data We want an upload to SAP at least
once a day.
OTC-001 Creation of OTC-001-004 Create and Number range will be determined Functional
customers maintain in Finrel. SAP number will be
customer identical to the finrel number.
master data
OTC-001 Creation of OTC-001-005 Create and We need 5 different BP types : R, Business
customers maintain I, J, P, D.
customer For BP type I and J an extra field
master data for company code is necessary.
OTC-001 Creation of OTC-001-006 Create and 2 BP categories : organisation and Business
customers maintain person, Only organization is
customer needed
master data We don't need group as BP
category..
OTC-001 Creation of OTC-001-007 Create and All modifications to the business Functional
customers maintain partner will be done in Finrel. All
customer fields in SAP must be protected.
master data
OTC-001 Creation of OTC-001-008 Create and The modifications of the business Functional
customers maintain partner will be available in SAP via
customer interface van Finrel to SAP.
master data Upload to SAP of these
modifications at least once a day..
OTC-001 Creation of OTC-001-009 Create and The specification of de mandatory Functional
customers maintain fields are defined in Finrel. No
customer determination of the fields in SAP.
master data
OTC-001 Creation of OTC-001-010 Create and We will have only one BP role in Business
customers maintain OTC.
customer
master data

Business Requirements Page 29 of 39 Document1

19-Mar-18
 Business Business Detailed Detailed
Requirement Requirement Requirement Requirement
Requirement
ID* Name* ID* Name* Description / Desire*
Type*
(Level 1 (Level 1 (Level 2 (Level 2
Requirement) Requirement) Requirement) Requirement)
OTC-001 Creation of OTC-001-011 Create and There is no need to send Functional
customers maintain information from SAP to Finrel
customer
master data
OTC-001 Creation of OTC-001-012 Create and It must be possible te have Business
customers maintain multiple BP's with the same VAT-
customer nr
master data
OTC-001 Creation of OTC-001-013 Create and Name affix, suffix, academic title is Business
customers maintain not required.
customer
master data
OTC-001 Creation of OTC-001-014 Create and Occupation and marital status is Business
customers maintain not required
customer
master data
OTC-001 Creation of OTC-001-015 Create and Legal forms en legal entities is not Business
customers maintain needed.
customer The legal form is mentioned in the
master data name of the BP.
OTC-001 Creation of OTC-001-016 Create and Industries are not required Business
customers maintain
customer
master data
OTC-001 Creation of OTC-001-017 Create and Relationships will only be Business
customers maintain maintained in Finrel and will not be
customer sent to SAP.
master data
OTC-001 Creation of OTC-001-018 Create and Each BP needs a contract account Business
customers maintain for each company where he will
customer have transactions.
master data In case a mandate is required (
BRCK, DAKL en SPAR) the
contract account will be created
immediately with the BP.
OTC-001 Creation of OTC-001-020 Create and A BP can have several contract Business
customers maintain accounts, but only one per
customer company code
master data
OTC-001 Creation of OTC-001-021 Create and Number range for the contract
customers maintain account Business Partner number
customer + company code.
master data

OTC-002 Customer is OTC-002-000 Create and Assurance that a customer is only Business
only once maintain once present in our system and
present in the customer that his data is accurate and
system master data complete.

Business Requirements Page 30 of 39 Document1

19-Mar-18
 Business Business Detailed Detailed
Requirement Requirement Requirement Requirement
Requirement
ID* Name* ID* Name* Description / Desire*
Type*
(Level 1 (Level 1 (Level 2 (Level 2
Requirement) Requirement) Requirement) Requirement)
OTC-002 Customer is OTC-002-001 Create and All customers must be valildated Business
only once maintain before they are sent to SAP :
present in the customer check doubles
system master data check VAT
check document or comment
check accountnumbers
This will be done in Finrel.

OTC-003 Validation of OTC-003-000 Create and Availability of validated data in Business

master data in maintain SAP for
SAP customer New customers.
master data Modified customers.
OTC-003 Validation of OTC-003-001 Create and All creations and modifications in Business
master data in maintain finrel must be validated within x-
SAP customer days (as determined in the SLA),
master data so that all postings can be done in
SAP before end month close.
An automated validation proces is
required
OTC-003 Validation of OTC-003-002 Create and Only validated Business
master data in maintain bankaccountnumbers are available
SAP customer in SAP, they are linked to the BP.
master data Fields concerning bankaccount are
protected in SAP.
OTC-004 Customer OTC-004-000 Create and Need of specific address/contact Business
address/contact maintain points for 1 customer linked to the
points customer process which occurs.
master data
OTC-004 Customer OTC-004-001 Create and Address cat : only the relation Business
address/contact maintain address will be sent to SAP.
points customer
master data
OTC-005 Link customer OTC-005-000 Create and Link a customer with the supplier Business
with supplier maintain
customer
master data
OTC-005 Link customer OTC-005-001 Create and Automatic netting between Business
with supplier maintain customer en supplier if required.
customer
master data
OTC-006 Mandate OTC-006-000 Create and Mandate Management : Document Business
management maintain registration, archivation and
customer validation will happen in Finrel
master data
OTC-006 Mandate OTC-006-001 Create and Creation of mandates will happen Functional
management maintain in FinRel, and send to SAP, after
customer validation in FinRel.
master data

Business Requirements Page 31 of 39 Document1

19-Mar-18
 Business Business Detailed Detailed
Requirement Requirement Requirement Requirement
Requirement
ID* Name* ID* Name* Description / Desire*
Type*
(Level 1 (Level 1 (Level 2 (Level 2
Requirement) Requirement) Requirement) Requirement)
OTC-006 Mandate OTC-006-002 Create and For Spar the schema is B2B, the Business
management maintain contract must be printed during
customer creation with the maatschappelijk
master data zetel, bank account,
mandatereference.
OTC-006 Mandate OTC-006-003 Create and Mandate numberrange will be Business
management maintain managed in Finrel :
customer Colruyt-card : BRCK-reknr(12k)-
master data schema (5/6)-volgnr(1)
Dats : DAKL-volgnnr(12k)-
schema(5/6)-volgnr(1)
Spar : volgnr (12k)
OTC-006 Mandate OTC-006-004 Create and All mandate fields will be Functional
management maintain managed in FinRel. All fields are
customer protected in SAP
master data
OTC-006 Mandate OTC-006-005 Create and We have different mandates Business
management maintain active for one BP within one
customer company code/ CA
master data
OTC-006 Mandate OTC-006-006 Create and There is only one active mandate Business
management maintain within the same range for a CA.
customer (identieke mandaatreferte maar
master data verschillend volgnummer)
OTC-007 Encoding OTC-007-000 Create and Encoding customer concerning his Business
customer maintain financial status
concerning his customer
financial status master data

Process Controls

Business Detailed Detailed Requirement

REQ Requirement Name* Requirement ID* Name*
Description / Desire*
ID*

(Level 2
(Level 1 Requirement) (Level 2 Requirement)
Requirement)
MDM010 Maintain Process control Restrict master data Access to master data
2.1.3 Customer Master Data requirement access is restricted
Reconciliation account
per customer per
MDM010 Maintain Process control Restrict use of company code is a
2.1.4 Customer Master Data requirement reconciliation account restricted data field

Business Requirements Page 32 of 39 Document1

19-Mar-18
 REQ Business Detailed Detailed Requirement
Description / Desire*
ID* Requirement Name* Requirement ID* Name*

Procedures are in
place for master data
Restrict creation, creation, approval,
MDM010 Maintain Process control modification and deletion modification, deletion
2.1.11 Customer Master Data requirement of master data and review
Master data records
with open transactions
cannot be deleted (for
instance
MDM010 Maintain Process control Restrict deletion of vendor/customer with
2.1.14 Customer Master Data requirement master data sales/orders)
Restrict possibilities Master data records
MDM010 Maintain Process control regarding deletion of with open transactions
2.12.8 Customer Master Data requirement master records cannot be deleted.

Metrics / Reporting
Repor
To-
Repor t BE
Report type Usage / Rationale
t Nr Report Title NL Status OTC
RAP1 Alle info van een Finrel BO controle who changed what in
4393 zonder validatie_ info Active Yes As-is Managerial finrel
RAP1 Finrels aantallen nieuw en BO
4953 gevalideerd Active Yes As-is Managerial controle validationteam
RAP1 Klanten btwnummer in BO
960 aanvraag Active yes As-is Operational controle VAT-number masterdata
RAP6 Aantal relaties obv BO
943 herkenningscode Finrel Active yes As-is Operational Finrel rapport
nieu
w com133.058.714 Yes Treasury

Legal

 Invoices need to be stored for three years (cleared invoices)

Change impacts

Change impacts identified for this process are:

Change Impact Assessment

Business Requirements Page 33 of 39 Document1

19-Mar-18
 Solution
Level 3 or 4 Impacted Org &
Level 2 Change Implications Overall Process &
process Stakeholder People
process (from As Is to To Be) Rating Rating System
(Optional) Group Rating
Rating
MDM-010- FIN Dienst
Decentrale creations of
Create and Retail Partners
customers will be done in
Maintain Colruyt Group Medium Medium Medium High
Finrel, no longer in SAP for
Business (SPAR) (incl
RPCG
Partner chef)
MDM-010-
FIN Dienst Finrels will only be
Create and
Accounts available in SAP after
Maintain High High Medium Low
Receivable (incl validation if validation is
Business
chef) necessary
Partner
MDM-010-
FIN Dienst Postings on BP will only be
Create and
Accounts possible from the moment
Maintain High High Medium Low
Receivable (incl the finrel is available in
Business
chef) SAP
Partner
MDM-010- In SAP we will see every
FIN Dienst
Create and company where the
Accounts
Maintain business partner is a Low Low Low Low
Receivable (incl
Business customer (via the different
chef)
Partner contract accounts)
MDM-010-
FIN Dienst Updates in Finrel that need
Create and
Accounts to be validated, will only be
Maintain Medium High Medium Low
Receivable (incl visible in SAP after
Business
chef) validation
Partner

Functional Integration Topics

2.1.1 Functional integration

Please describe based on the process flow diagram (chapter 2.1) the functional integration points towards
other functional teams.

Leading Integrating
IP-Code Activity Name Integration Topic Description
stream stream
MDM010- Integration business OTC PTP The business partner will always be created in
MDM030 partner OTC/PTP at least one role (general) which contains
information that is equal for a BP in the
customer and the vendor role. The description
of this general information can be found in this
BPD.

Business Requirements Page 34 of 39 Document1

19-Mar-18
3 SAP Functionality GAPs

Development Requirements (WRICEF)

1.1.1 Workflow
None identified
1.1.2 Reports
None identified
1.1.3 Interfaces
WRICEF Object Functional
ID Title Description type Team Complexity Status
Registration of master data customer.
On different levels : Business Partner and
Synchronize ContractAccount
customers Synchronize customers master with Finrel.
master with Including bankaccounts and sepa mandates
FSI-037 Finrel. Interface MDM High FS prep started

1.1.4 Conversion
None identified
1.1.5 Enhancements
None identified

SAP Functionality GAPs Page 35 of 39 Document1

19-Mar-18
4 Roles & Authorizations

Roles

Description/Defini
Role Names Team Task Access Remarks
tion
Klantenboekhouding Display customer CAA3
master data FPP3
Treasury FPO4

Collection team retail

partners

BP&S
Interface user Create customer FPP1
master data CAA1

Roles & Authorizations Page 36 of 39 Document1

19-Mar-18
5 Annex

Overview of reports

https://extranet-
sp.colruytgroup.com/projects/2013/doc360570/Template/Working%20Documents/Forms/List%20Mode.as
px?RootFolder=%2Fprojects%2F2013%2Fdoc360570%2FTemplate%2FWorking%20Documents%2FAll
&FolderCTID=0x0120005E4140C57B9FA34CA2A2B04979CADC37&View=%7BC71D15D2%2D4603%2
D4F21%2DBE4C%2DCC5A9E78B4BD%7D

Annex Page 37 of 39 Document1

19-Mar-18
 Page 38 of 39 Document1
19-Mar-18
6 Abbreviations

Abbreviations Description

SAP System Application and Products

BP Business Partner
CA Contract Account
DPV Diepvriezer
CGA Colruyt Group Academy
MDM Master Data Management

Abbreviations Page 39 of 39 Document1

19-Mar-18