In Part 1, we learnt that the Business Partner is ONE master data object in S/4 and looked at what were the key consideration before implementing the object in S/4. Part 2 digs deeper and looks at the common attributes of the object and how they should be handled. Data structures for some of these common attributes have also changed in S/4 and hence needs closer inspection during design.
Part 2 - Business Partner Migration - Approach for Common Attributes
BP General data role broadly has following set of attributes that are common for a BP from vendor and customer standpoint
In simple terms what common attribute means is while in ECC (legacy system), it was possible to maintain one attributes at two places, in S/4, it’s permitted only once. For example, in ECC, for one business entity playing dual role of customer and vendor, bank records could be maintained separately under different master data objects i.e. one as receivable bank for a vendor (LFBK) and as a payee bank for a customer (KNBK), in S/4 both these bank accounts must be maintained under one object BP (BUT0BK). Although just to call out that S/4 still maintains the data in the vendor and customer specific bank tables i.e. LFBK and KNBK but without any identification of which bank account is for which entity (customer / vendor).
Another example of common attributes is address data. While in ECC it was likely that master data team might maintain two different versions of the same address for customers and vendors i.e. 110, 4th Street, Northwest for customer and House No 110, Fourth Street, NW, Near City center for the corresponding linked vendor, in S/4 it must be one version. Over a period, the old master data structures resulted in organizations ending up with either duplicate or datasets that were different across customer and vendors.
To ensure that these common attributes are merged correctly in S/4, it is imperative to profile the source data and build the transformation rules before the migration so that BP on S/4 has one version of these common attributes going forward. Some of these attributes such as Bank Id in banking data, if not loaded correctly may directly impact some of the payment related functionalities further down the road.
Let’s get back to the example of Bank data to understand what I mean by one version. In S/4 we have a new field called Bank Id (BKVID), that along with the Bank country, Bank No, Bank Account No and Control key determine whether the given bank record is unique or not. This field for example can be used to assign a unique Id to every bank record and help determine by just looking at it whether the bank account was previously used by a vendor, a customer or both.
Let’s say, Vendor V has two bank records VB1 and VB2 (where VB1 and VB2 are going to be the Bank Ids for these records in S/4) in ECC while customer C has 3 bank records CB1, CB2 and CB3 in ECC out of which CB1 is the same bank account as VB1 given both vendor V and customer C is one business entity. From migration standpoint in S/4 the BP should have only 4 bank accounts loaded and not 5. These must have unique Bank Ids in S/4 i.e. VB1 (or CB1), VB2, CB2 and CB3.
As you would have noted, For the first account (VB1 or CB1), it must be merged into one bank record in S/4 and can have only one Bank Id. Depending on whichever entity (customer or vendor) gets loaded first, can determine whether the Bank Id will be VB1 or CB1. But as it’s a common bank account, there is no way for someone to determine whether it was a bank account used by both customer and the vendor. This can be tricky for requirements to process the inter-company payments. One option can be to assign a common prefix, say X, while loading the bank accounts that would denote that the bank account was common to both vendors and customers, so the Bank id for the first account can be assigned as XB1 instead of VB1 or CB1.
Bank Ids with separate prefixes for bank accounts for customers, vendors and business entities playing dual role
The numbering of the Bank Id can be flexible per the client requirement. For example, it can be reset for each prefix as shown in the screenshot below. This will allow to maintain more than 10 Bank accounts for a BP although a BP having more than 10 accounts may be a little rare for a number of clients.
Bank Ids with separate numbering for bank accounts for customers, vendors and business entities playing dual role
Another variation with numberings can be if the BP maintains bank accounts in more than one country, then in the scenario, country can be incorporated in the Bank Id itself to make it easier for reading.
Bank Ids with separate numbering for customers & vendors maintaining international bank accounts
Another important consideration while dealing with the common attributes is the sequence in which they are loaded. For bank records example, if customers are loaded first with the customer bank records, then while extending those customer BPs in S/4 for the vendors role, the common bank accounts don’t need to be re-loaded though the additional bank records (VB2 in our example) must be loaded. Similarly, for the address data, if customers are loaded first with the address details, vendors addresses don’t need to be reloaded unless there is an additional second address maintained for the vendors. For the tax numbers, generally, they remain the same for one business entity, so they don’t need to be reloaded.
Common attributes for BP are tricky because two sets of data from legacy now needs to be merged into one in S/4 and hence needs to be designed / implemented carefully. Some of the common attributes are very critical from further finance processes standpoint and can impact adversely if not loaded correctly.
Part 3 of the series will focus on the Initial Load Approach for the Business Partner Data the link to which can be found here.
Part 2 - Business Partner Migration - Approach for Common Attributes
BP General data role broadly has following set of attributes that are common for a BP from vendor and customer standpoint
- Name & Address details including emails, phones and faxes
- Tax numbers
- Banking data
- Status data such as archiving flags, central blocks etc.
In simple terms what common attribute means is while in ECC (legacy system), it was possible to maintain one attributes at two places, in S/4, it’s permitted only once. For example, in ECC, for one business entity playing dual role of customer and vendor, bank records could be maintained separately under different master data objects i.e. one as receivable bank for a vendor (LFBK) and as a payee bank for a customer (KNBK), in S/4 both these bank accounts must be maintained under one object BP (BUT0BK). Although just to call out that S/4 still maintains the data in the vendor and customer specific bank tables i.e. LFBK and KNBK but without any identification of which bank account is for which entity (customer / vendor).
Another example of common attributes is address data. While in ECC it was likely that master data team might maintain two different versions of the same address for customers and vendors i.e. 110, 4th Street, Northwest for customer and House No 110, Fourth Street, NW, Near City center for the corresponding linked vendor, in S/4 it must be one version. Over a period, the old master data structures resulted in organizations ending up with either duplicate or datasets that were different across customer and vendors.
To ensure that these common attributes are merged correctly in S/4, it is imperative to profile the source data and build the transformation rules before the migration so that BP on S/4 has one version of these common attributes going forward. Some of these attributes such as Bank Id in banking data, if not loaded correctly may directly impact some of the payment related functionalities further down the road.
Let’s get back to the example of Bank data to understand what I mean by one version. In S/4 we have a new field called Bank Id (BKVID), that along with the Bank country, Bank No, Bank Account No and Control key determine whether the given bank record is unique or not. This field for example can be used to assign a unique Id to every bank record and help determine by just looking at it whether the bank account was previously used by a vendor, a customer or both.
Let’s say, Vendor V has two bank records VB1 and VB2 (where VB1 and VB2 are going to be the Bank Ids for these records in S/4) in ECC while customer C has 3 bank records CB1, CB2 and CB3 in ECC out of which CB1 is the same bank account as VB1 given both vendor V and customer C is one business entity. From migration standpoint in S/4 the BP should have only 4 bank accounts loaded and not 5. These must have unique Bank Ids in S/4 i.e. VB1 (or CB1), VB2, CB2 and CB3.
As you would have noted, For the first account (VB1 or CB1), it must be merged into one bank record in S/4 and can have only one Bank Id. Depending on whichever entity (customer or vendor) gets loaded first, can determine whether the Bank Id will be VB1 or CB1. But as it’s a common bank account, there is no way for someone to determine whether it was a bank account used by both customer and the vendor. This can be tricky for requirements to process the inter-company payments. One option can be to assign a common prefix, say X, while loading the bank accounts that would denote that the bank account was common to both vendors and customers, so the Bank id for the first account can be assigned as XB1 instead of VB1 or CB1.
Bank Ids with separate prefixes for bank accounts for customers, vendors and business entities playing dual role
The numbering of the Bank Id can be flexible per the client requirement. For example, it can be reset for each prefix as shown in the screenshot below. This will allow to maintain more than 10 Bank accounts for a BP although a BP having more than 10 accounts may be a little rare for a number of clients.
Bank Ids with separate numbering for bank accounts for customers, vendors and business entities playing dual role
Another variation with numberings can be if the BP maintains bank accounts in more than one country, then in the scenario, country can be incorporated in the Bank Id itself to make it easier for reading.
Bank Ids with separate numbering for customers & vendors maintaining international bank accounts
Another important consideration while dealing with the common attributes is the sequence in which they are loaded. For bank records example, if customers are loaded first with the customer bank records, then while extending those customer BPs in S/4 for the vendors role, the common bank accounts don’t need to be re-loaded though the additional bank records (VB2 in our example) must be loaded. Similarly, for the address data, if customers are loaded first with the address details, vendors addresses don’t need to be reloaded unless there is an additional second address maintained for the vendors. For the tax numbers, generally, they remain the same for one business entity, so they don’t need to be reloaded.
Common attributes for BP are tricky because two sets of data from legacy now needs to be merged into one in S/4 and hence needs to be designed / implemented carefully. Some of the common attributes are very critical from further finance processes standpoint and can impact adversely if not loaded correctly.
Part 3 of the series will focus on the Initial Load Approach for the Business Partner Data the link to which can be found here.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
