Many SAP customers are moving to SAP S/4HANA as part of their digital transformation journey. Generally, the first step of the journey involves moving their Financial Reporting to the new and much improved S/4HANA platform by implementing the module called Central Finance or CFIN. While SAP CFIN implementation is about bringing the financial transactions from the legacy environment(s) to the new S/4 environment and their consolidation, these transactions can’t exist on their own in the new system and must be supported by bringing over the associated Master Data as well as the Reference Data.
While there are many master data objects such as Profit Centre, Cost Centre, G/L Accounts, Materials, Vendors & Customers that must be migrated to the new S/4 environment for a CFIN implementation, the one object that plays arguably the most critical role is the Business Partner given the wide range of key attributes it holds. These attributes play a crucial role when it comes to correctly reporting the organization’s financial health. These attributes include but are not necessarily limited to the Bank data, Co code data, Withholding Data, Tax information, Address Data etc.
This blog Series is an attempt to highlight the key considerations while migrating the BP Master data for a SAP CFIN implementation. This is a 5-part blog series emphasizing on the key considerations related to the concept of ONE Business Partner object and the it’s common attributes, approach around the initial load and the post migration data sync and finally the options to re-boot, if needed.
The first part focuses on Business Partner being ONE master data object in S/4
Part 1: Business Partner – It’s ONE object in S/4 and not TWO (Vendors & Customers)
While the concept of business partners in the SAP world has been there for a long time, the merger of SAP customers and SAP vendors into one master data object called BP is relatively new. The merger is achieved through CVI (Customer Vendor Integration). SAP has moved away from the concept of maintaining the same attribute multiple times for the same business entity under different master data objects that earlier caused possibly duplicate attributes at the end of the day.
For example, if a business entity supplies materials to a business organization and plays a dual role of being a customer and purchasing services from the same organization, it makes sense to maintain that business entity under one common master data object. That’s where the concept of Business Partner comes into play. In the new S/4 world, only a single BP needs to be created for the business entity with two different roles i.e. vendor and customer.
What it means from the migration standpoint is that two different objects having two different numbers in the legacy systems will be created as one common number in the S/4 system (Linked BPs scenario). Another scenario variation possible is that the business entities that are only doing business either as customers or as vendors will be created as BPs with either a customer role or a vendor role (Unique BPs scenarios).
To implement the concept of ONE master data object in S/4 for Business Partners, following considerations play important role.
In essence, the business partner master data is one of the pivotal elements for a CFIN implementation on SAP S/4HANA. Customers and vendors migration from legacy system to S/4HANA should be mapped to ONE master data object in S/4 that’s BP. BP master data has common attributes that serve both to customers and vendors and hence pose additional complexities / considerations from data migration standpoint and demands a holistic design between the three master data objects i.e. vendors, customers and BP.
For general SAP Business Partner concepts, please follow the link below.
https://help.sap.com/viewer/5a1b852d92f6427c92b045409b8f1680/1709%20002/en-US
The next part of the series will focus on the handling of the common attributes for Business Partner migration, link to which you can find here
While there are many master data objects such as Profit Centre, Cost Centre, G/L Accounts, Materials, Vendors & Customers that must be migrated to the new S/4 environment for a CFIN implementation, the one object that plays arguably the most critical role is the Business Partner given the wide range of key attributes it holds. These attributes play a crucial role when it comes to correctly reporting the organization’s financial health. These attributes include but are not necessarily limited to the Bank data, Co code data, Withholding Data, Tax information, Address Data etc.
This blog Series is an attempt to highlight the key considerations while migrating the BP Master data for a SAP CFIN implementation. This is a 5-part blog series emphasizing on the key considerations related to the concept of ONE Business Partner object and the it’s common attributes, approach around the initial load and the post migration data sync and finally the options to re-boot, if needed.
- Business Partner – It’s ONE object in S/4 and not TWO (Vendors & Customers)
- Business Partner Migration - Approach for Common Attributes
- Business Partner Migration - Initial Load Approach
- Business Partner - Post Migration Data Sync between legacy systems and S/4
- Business Partner Migration Errors - Options for re-boot
The first part focuses on Business Partner being ONE master data object in S/4
Part 1: Business Partner – It’s ONE object in S/4 and not TWO (Vendors & Customers)
While the concept of business partners in the SAP world has been there for a long time, the merger of SAP customers and SAP vendors into one master data object called BP is relatively new. The merger is achieved through CVI (Customer Vendor Integration). SAP has moved away from the concept of maintaining the same attribute multiple times for the same business entity under different master data objects that earlier caused possibly duplicate attributes at the end of the day.
For example, if a business entity supplies materials to a business organization and plays a dual role of being a customer and purchasing services from the same organization, it makes sense to maintain that business entity under one common master data object. That’s where the concept of Business Partner comes into play. In the new S/4 world, only a single BP needs to be created for the business entity with two different roles i.e. vendor and customer.
What it means from the migration standpoint is that two different objects having two different numbers in the legacy systems will be created as one common number in the S/4 system (Linked BPs scenario). Another scenario variation possible is that the business entities that are only doing business either as customers or as vendors will be created as BPs with either a customer role or a vendor role (Unique BPs scenarios).
To implement the concept of ONE master data object in S/4 for Business Partners, following considerations play important role.
- BP Creation Scenarios: BPs in S/4 can be created as Unique or Linked BPs.
- Unique BP: Refers to a scenario where one customer from legacy is linked to one BP in S/4 or one vendor from legacy is linked to one BP in S/4
- Linked BP: Refers to a scenario where two master data object instances (one customer plus one vendor) from legacy are both linked to one BP in S/4. Usually in these scenarios, the BP is created first with one role (customer of vendor), followed by the second role also known as BP extension
- BP Roles: BPs in S/4 will always have the BP General role. In addition to the BP General role, it will either have vendor role or customer role or both the roles based on whether it’s a unique or linked BP
- BP ID:
- For BPs, there will always be a BP no
- If the BP has a vendor role, there will be a vendor no same as the BP no (available under vendor role of the BP)
- If the BP has a customer role, there will be a customer no same as the BP no (available under customer role of the BP)
- BP ID mapping between Legacy and S/4:
- For Unique BP:
- If the number ranges from the legacy systems are retained, then the legacy customer no (or legacy vendor no) will map to themselves to determine the BP no as well as the customer (vendor no) in S/4
- If the number ranges from the legacy systems are not retained, then the legacy customer no (or legacy vendor no) will map one to one with the BP no as well as the customer no (vendor no) in S/4
- For Linked BP:
- As there will be two number ranges in legacy (i.e. one for customer and one for vendor) and as there will be only one number range in S/4, hence it's a good idea to define a new number range in S/4 that is different from both the legacy customer and vendor number ranges to get a clean break
- The mapping between the legacy customer no and the new BP as well as the legacy vendor no and the new BP must be maintained in the MDG table in S/4. The same mapping can also be maintained in the field previous account no that is available at the co code level in the BP
- BP Common Attributes: For the Linked BPs, the BP General role contains some common attributes that serve for both the vendor and the customer entity such as Names, Address details, Telephones, Emails, Tax Numbers and more importantly Banking information
- Always define the business / transformation rules pertaining to the common attributes considering both objects i.e. customers and vendors. For example, if a certain rule is built to determine the tax number category field in S/4HANA for vendors, the same rule must also be applied to the corresponding customer as well.
In essence, the business partner master data is one of the pivotal elements for a CFIN implementation on SAP S/4HANA. Customers and vendors migration from legacy system to S/4HANA should be mapped to ONE master data object in S/4 that’s BP. BP master data has common attributes that serve both to customers and vendors and hence pose additional complexities / considerations from data migration standpoint and demands a holistic design between the three master data objects i.e. vendors, customers and BP.
For general SAP Business Partner concepts, please follow the link below.
https://help.sap.com/viewer/5a1b852d92f6427c92b045409b8f1680/1709%20002/en-US
The next part of the series will focus on the handling of the common attributes for Business Partner migration, link to which you can find here
- SAP Managed Tags:
4 Comments
