Central Finance – Lessons Learned Master Data objects (Part3 – Business Partner/non-financial master data)

Introduction

Having been involved in various SAP project implementations we all know how critical the learnings from a project are and how they can help us if we face the similar situation again.

We are a group of consultants at SAP dedicated to gather valuable lessons learned during CFIN projects and share within the external community. Our main objective is to elaborate on lessons learned in regards to harmonization and mapping guidelines for financial and non-financial master data objects.

This is the first blog of its nature to be followed by additional blogs in the future in regards to a variety of topics where valuable lessons could be gathered.

The following blogs will be published separately broken into 3 parts:

• Part 1 – General Ledger Accounts
• Part 2 – Controlling master data object
• Part 3 – Business Partner/non-financial master data (current blog)

Overview

Previous blogs focused on lessons learned in regards to General Ledger Account and Controlling master data objects. The current blog will provide an overview, harmonization & mapping guidelines as well as lessons learned focusing on the Business Partner/nonfinancial master data

Non-Financial Master Data

Customers/Vendors (Business partners)

Overview

In SAP S/4 HANA, Business Partner is the leading object and single point of entry to create, edit, and display master data for business partners, customers, and vendors.

• A legal entity is represented with one Business Partner
• Different Business Partner categories – Organization, Person, Group
• Maximal data sharing and reuse of data which leads to an easier data consolidation
• General Data available for all different business partner roles, specific data is stored for each role
• Several Addresses possible with a default Address
• Flexible Business Partner Relationships possible like contact, married etc.
• Time dependency on different sub entities e.g. roles, address, bank data etc.
• Core Component of Credit Management, Collections Management, Dispute Management etc.
• Fiori User Interface with a specific Customer and Supplier Partner App

Options how to create in CFIN:

• Centralized creation of customer/vendor in MDM and distribute customer/vendor to source and CFIN for creation of BP with or without consolidation
• Centralized creation of Business partner in MDG and distribute customer/vendor to source and CFIN for creation of BP with or without consolidation
• Decentralized creation of Customer/vendor/BP in individual source system and distribute to Central Finance with or without consolidation

Lessons Learned

• When consolidating customer/vendors across systems, check the availability of critical fields when determining system priority.
• Business involvement from early on is advisable to help determine the criteria to identify duplicate customer/vendors between source systems.
• One-time accounts should be consolidated with one-time accounts. One-time accounts should only be mapped to one-time accounts.
• In case company codes are merged with withholding tax scenario: mapping of withholding tax type and code needs to be considered so that the same code is not added twice per company code.
• CFIN system within the reporting scenario duplicates might be acceptable. In the central processing scenario duplicates should be avoided
• If conversion to BP has not been performed in source and customer is being made aware of the concept for the first time, customer IT team should receive training on BP concepts
• It is advisable to keep Business Partner number and customer/vendor number as the same number. However, there are no restrictions otherwise
• When multiple account groups are to be merged to one account group/role grouping, number range needs to be setup to allow all source account group numbering
• Based on critical fields decided, if any fields that have customizing or domain value setup, this needs to be harmonized as well
• CVI can be carried out in source system if BP conversion has not been done already prior to start of CFIN implementation.
• Data steward can be used to compare and decide on golden reference customer
• Identify the fields which can be used to identify uniqueness of a record
• Any branch/head office relationship for vendor master must be consistent between source and target. E.g. Invoice was received at branch and payment was made by head office. Vendor was different between invoice & payment. In the source system the relationship between branch & head office was maintained, however, in CFIN it failed as this was missing. Subsequently, this relationship between BP is required in CFIN as well.

Hopefully the above concepts, valuable experiences as well as lessons learned which were gathered from various projects and teams across our organization will help you to overcome similar challenges which you might face during your projects.

We invite you to post any feedback, ideas, or tell us how this content was helpful for your project.

Please also look out for lessons learned blogs Part 1 (G/L Account) and Part 2 (Controlling) as well.

Best wishes.