The traditional SAP system has various inconsistent and duplicate objects for master data for common information, such as customer, supplier, or employees, making it difficult to maintain it on an ongoing basis and causing the waste of an organization’s resources. It can result in erroneous correspondence with your customers or suppliers, leading to their lack of confidence in your organization’s accounting system and increased mailing costs for any corrections. There are also limitations when the details for customers or suppliers are changed from a particular validity date, which sometimes results in more duplicate master data creation rather than reuse of the same objects.

SAP S/4HANA has largely tackled these issues with the concept of a business partner by making it mandatory and a single point to handle master data for customers or suppliers. Business partner itself is not a new element in the SAP system. It was used earlier in applications related to Financial Supply Chain Management (FSCM), but now it has been extended extensively in other applications involving customers or suppliers.

SAP ran with a customer or supplier approach for decades. An organization created its customer and supplier in a siloed manner with both being distinct master data objects even if they belonged to same legal entity or group. Organizations started using the SAP core product Financial Accounting (FI). Later on they shifted to newer dimensions, such as SAP Treasury and Risk Management and Loans Management, that needed a business partner setup. Now SAP has also brought the business partner concept to the logistics and core finance areas by making it mandatory in the latest SAP S/4HANA versions. A business partner can take on different business partner roles that allow you to have different views on customer or supplier master data depending on the business function being performed.

So why do you need to move to a business partner for SAP S/4HANA? Let’s first consider the main limitations in the previous customer and supplier model:

• The customer or supplier might belong to same legal entity as they can be affiliated companies in one group and may be dealing with your organization in different capacities (e.g., one unit procuring some finished products from you and another unit supplying some raw materials). However, they have to be created in the classical SAP system as separate objects. This leads to data duplication for common information, such as general data and bank accounts.
• The customer or supplier can have only one address in one master record, so it poses a practical difficulty when the entity has different addresses and then needs to have various multiple master data.
• The customer or supplier can’t be created or maintained based on validity dates. So if a change is made, that change affects all the transactions and correspondences that read the data from master data dynamically.

With SAP S/4HANA, SAP has extended the business partner concept to cover suppliers and customers from the SAP ERP Central Component (ECC). Business partner roles are integrated to various components, including logistics and finance, for various business transactions. However, in the future SAP S/4HANA direction the classical tables, such as LFA1 and KNA1, will also be unnecessary, leading to a unified back-end data structure without any duplication. There is only one transaction code (BP) in SAP S/4HANA to create, edit, or display a customer, supplier, or business partner. For now, SAP has kept the back-end tables for customer and suppliers intact (for example, LFA1 and KNA1). These tables are filled from the business partner transaction code BP. Figure 1 shows the main benefits of the business partner approach.

Figure 1

Key features of the business partner object

First, I show a glimpse of the business partner master data maintenance screens to link with features listed in Figure 1. You can see in Figure 2 that the same business partner has multiple roles such as customer, supplier, or credit management data. All common data such as address is maintained in a single place and is consistently available in various roles for different business transactions, such as role FCLU00 for company code data (FI customer), FCLU01 for sales area data (sales and distribution [SD] customer), FLVN00 for company code data (FI supplier), and FLVN01 for supplier area data (materials management [MM] supplier).

Figure 2

A business partner having multiple roles

In Figure 3 each role can have a different validity period, providing flexibility so that you can maintain only the needed information.

Figure 3

A business partner’s roles with a validity range

A business partner can also have multiple addresses, and the default one can be assigned to different usages, as shown in Figure 4.

Figure 4

A business partner having multiple addresses with a validity range and an assignment to usage

Figure 5 shows the maintenance of a business partner using an SAP Fiori application independent of an SAP GUI application.

Figure 5

An SAP Fiori application to maintain a business partner

Now let’s go in detail through the various things to consider while implementing a business partner approach.

When Do You Adopt Business Partner? Is It Mandatory?

SAP has selected business partner as a strategic master data object in SAP S/4HANA and allows you to adopt this in your legacy SAP Business Suite system even before converting to SAP S/4HANA. You are not required to be on SAP S/4HANA to adopt the business partner approach. For new SAP S/4HANA installations under a greenfield approach, the need of a business partner object is based on the target SAP S/4HANA version. The requirements for a business partner are listed in Table 1 for companies with legacy systems on SAP Business Suite.

For SAP S/4HANA Finance on-premise editions 1503 and 1605, the old way of working with a customer or supplier can continue. Because SAP S/4HANA 1503 and 1605 was for finance simplifications only, organizations may not want to change their way of processing in the logistics area that would be running on their legacy SAP systems using the customer or supplier approach.

Customer/Supplier Integration (CVI, formerly known as Customer-Vendor Integration) is a tool to adopt the business partner approach in a consistent way.

It is mandatory to have CVI in place in a legacy system if you want to convert the system to SAP S/4HANA Enterprise Management On-premise edition 1610. SAP will also perform a pre-check on a legacy system for CVI existence before allowing the conversion to the 1610 version. This is also the direction for future SAP S/4HANA releases.

If a business partner is mandatory for a target SAP S/4HANA state, then the conversion of existing customers or suppliers to business partners should be started way before the actual SAP S/4HANA conversion. This avoids downtime during system conversion and any last-minute issues.

Is Business Partner Adoption a Complex Task? What Expertise Is Needed?

As stated earlier, business partner is not a new concept and was used by SAP in earlier applications such as FSCM. So in SAP S/4HANA, it is important that the converted data is well integrated in various applications. It needs careful planning and execution, and can even be taken as a parallel project along with the SAP S/4HANA conversion journey. However, it has to be completed before you start using the new SAP S/4HANA system.

Hence, business partner adoption needs specific expertise in the following areas:

• Understanding of SAP S/4HANA architecture, specifically the principle of one, whereby SAP S/4HANA offers a single solution for supplier and customer master data across various solution components.
• Understanding the SAP S/4HANA simplification list overall and specifically the items related to business partners, such as the ones in Table 2.
• Understanding the CVI tool, data services tools, or migration cockpit for handling data
• Expertise should also be there to see the impact of various fields in master data, what to migrate, and how to have data cleaned.
• Technical know-how for setting up system integration, CVI setup, and migration activities in the correct sequence as per SAP guides.

Check that your project team is well equipped with the above competencies to avoid technical glitches in this crucial activity of business partner activation or conversion. A simplification list is a good start to understanding the business partner changes and related know-how, such as the simplification item Business Partner Approach listed in SAP Note 2265093, which contains a detailed document on activities for business partner conversion. After successful implementation of a business partner, you have harmonized master data that can be sustained in the long term following good data governance procedures.

How Can Business Partner Adoption Be Simplified?

You can consider the following points in source SAP Business Suite systems to make the business partner adoption process simpler:

• Mark all the redundant customer or supplier master data with the deletion flag.
• Archive all the customer or supplier master data with the deletion flag.
• For incomplete customer or supplier data, correct the missing information (e.g., missing the @ sign in an email address) and enrich the data for various attributes to be used in SAP S/4HANA processes (e.g., if you are targeting intercompany matching in SAP S/4HANA, then look for the trading partner field in the customer or supplier master).
• Correct all the customization inconsistencies (e.g., postal code check or country-specific checks). Various configuration elements, such as tax type, and tax number, used in customer or supplier master data should exist in customization. (There might be inconsistencies due to long-running historical systems that have gone through various mergers, acquisitions, or carve outs [i.e., deleting a company code along with its relevant data from the system].) You can check these customization inconsistencies via a program provided in SAP Note 2344034 (link to SAP Note: https://launchpad.support.sap.com/#/notes/2344034).

• If you need to gather certain information from customers or suppliers to fill in business partner master data and the data collection process is time-consuming, then you can suppress the mandatory fields. This enables you to proceed with the business partner transition and then that piece of information can be filled in at a later stage in the project. Refer to SAP Note 2336018 for the function module to be implemented to enable this suppression. (https://launchpad.support.sap.com/#/notes/2336018). Also SAP Note 2344034 (https://launchpad.support.sap.com/#/notes/2344034) provides the Business Add-In (BAdI) CVI_CUSTOM_MAPPER to enable the bypass of the following checks: postal code check, address regional check, mandatory fields checks, and country-specific checks.

All mandatory fields checks are stored in the CVI synchronization logs and should be resolved before you do the actual production synchronization. However, if the data is in the wrong format or there are some missing references or links, then this data must be cleaned up before CVI synchronization (e.g., a date in the wrong format or an email address not containing an @ sign).

How Do You Handle the Mass Volume of Customer or Supplier Data to Convert to SAP S/4HANA Business Partner?

Your legacy SAP Business Suite may have voluminous customer and supplier data. So you would need some mass tool to manage this system’s transformation to the new SAP S/4HANA environment. This is more relevant when you are going with a greenfield approach and you have to perform a data migration.

Here are some points to consider:

• Legacy System Migration Workbench (LSMW) is not a recommended way for data migration to SAP S/4HANA as the usage would be at the customer’s own risk. LSMW technology has not been updated since 2004 as it is a non-strategic function from SAP’s point of view. It can’t work for transaction recording for the new SAP Fiori screens. Also the old interfaces such as those to customer/supplier master data do not work with changed interfaces for business partner master data. Standard Batch Data Communication (BDC) programs in LSMW may also not work if there are changes in SAP S/4HANA in transactions used in BDC. LSMW can still work in SAP S/4HANA using workarounds, but a careful testing should be done for each object being migrated using LSMW. SAP has given a workaround (at the customer’s own risk to handle the interface to SAP S/4HANA architecture) for business partner objects in SAP Note 2287723. (https://launchpad.support.sap.com/#/notes/2287723.) This refers to the detailed documentation for such LSMW objects as mentioned in link https://blogs.sap.com/2016/03/10/uploading-business-partner-data-using-lsmw/.

• The data can also be migrated using SAP Data Services, which extracts data from legacy systems, hosts the data in a staging area, and transforms and loads data into SAP S/4HANA leveraging the Rapid Data Migration (RDS) solution. This solution is a useful approach when there is a need to do direct data connection from the source to the target system.

• Another approach for data migration is the use of the SAP S/4HANA Migration Cockpit (available from SAP S/4HANA Enterprise Management on-premise 1610). Data extracts are provided and arranged in an SAP S/4HANA input template (format) by legacy system owners. Transformation is performed manually and data is arranged in an xml load file format. The data load to SAP S/4HANA EM happens with the SAP S/4HANA Migration Cockpit. This approach is easy to use due to ready-made templates.

For a conversion scenario, I recommend the SAP synchronization cockpit (transaction code MDS_LOAD_COCKPIT) under CVI to handle large-scale creation of business partners from customers and suppliers.

How Does Moving to Business Partner Affect the Satellite Systems Interfacing for a Customer or Supplier?

If any connected system has to update or maintain the business partner, then it can continue to work via:

• Calling function module BUP_PARTNER_MAINTAIN
• Calling the Remote Function Call (RFC) RFC_CVI_EI_INBOUND_MAIN (or a custom one based on this RFC)
• Calling web service BusinessPartnerSUITEBulkReplicateRequest or BusinessPartnerRelationshipSUITEBulkReplicateRequest

The Core Interface (CIF) for data exchange between SAP S/4HANA and the connected Supply Chain Management (SCM) system (such as SCM Extended Warehouse Management) will continue to be supported for the business partner. Similarly, business partner synchronization via middleware will also be continued.

Regarding reporting systems that have the reports based on customers or suppliers, such as SAP Business Warehouse (SAP BW), will continue to generate the reports without adjusting to a business partner. SAP is still continuing with tables such as LFA1 and KNA1 in the back end of the business partner. Also note that in case the legacy SAP Business Suite has overlapping customers or suppliers and thus, after conversion, the business partner number is different than the customer or supplier number, then financial reports are run based on the customer or supplier numbers known to the customers or suppliers.

How to Do You Handle Number Ranges Overlapping in a Source System?

SAP has recommended (it is not mandatory) that you have a customer or supplier number that is the same as the business partner number during conversion for SAP S/4HANA.

However, there might be situations in which customers or suppliers in legacy SAP Business Suite systems have overlapping numbers and thus are unable to link one to one to the business partner. In such cases, it is necessary to find a way so that such overlapping customers or suppliers have unique target business partner numbers.

You can handle this by linking customers to a separate number range of business partners. Suppliers can be linked to a separate number range of business partners. However, this results in situations in which the target business partner number is not the same as the customer or supplier number for the converted customers or suppliers from the legacy system. To reiterate again, the financial reporting continues to run based on customer or supplier numbers in such inconsistent cases.

The organization has to make a call on how to handle such overlapping cases. You can also develop an enhancement in a BAdI for having some alphanumeric identifier in the target business partner, which provides more consistency in such overlapping cases.

Or if you want to keep if the things simple, then you can also evaluate the option to create such overlapping customers or suppliers as new ones with consistent business partner numbers. That creates some extra work and communications to customer or suppliers, but results in a clean system for reporting and transactions.

Can a One-Time Customer or Supplier in a Traditional SAP System Continue?

Yes, it can continue. However, as with other suppliers or customers, it also requires linking to the business partner in SAP S/4HANA. One-time customers or suppliers are also not yet handled via CVI for replication from customer or supplier to the business partner. Before converting one-time customers or suppliers, you need to ensure that the business partner grouping used is the one linked to the customer or supplier group of the one-time master data. (Check customization in transaction codes TBD001 and TBC001 for this account group to business partner grouping linking.)

Do You Also Need to Convert Employees to Business Partners?

The SAP S/4HANA data model is based on a business partner and thus employees also need to have a business partner linked. Conversion of an employee to a business partner is not covered in the CVI approach, and should be converted separately. (If you have to mark those business partners as people, then you need to implement BAdI CVI_MAP_BP_CATEGORY.)

Also the conversion changes only the existing data in the employee master to the business partner. There might be data that exists in the employee master for a future validity date range. To reflect that you need to run report /SHCM/RH_SYNC_BUPA_FROM_EMPL after technical downtime and before productive use of production system. Refer to SAP Note 2340095 (https://launchpad.support.sap.com/#/notes/2340095) for more details with a guide for employee conversion if this scenario applies to you.

When Do You Switch Off Legacy Transaction Codes and When Do You Switch on Business Partner Transaction Codes?

If a company is not using business partners in a legacy SAP Business Suite, then the company can lock transaction code BP for users until the ECC system is converted into SAP S/4HANA. There is not any side impact, as at this point of time direction for replication in CVI is from the customer or supplier to the business partner. The CVI process keeps doing business partner replication in the background based on customers or suppliers created by users using old ECC transaction codes (e.g., XD01 or FD01). If it is already using transaction BP for other purposes such as FSCM, then it has to keep a tight control over its usage to avoid duplicate creation by users of a customer/supplier as a business/partner that would already be created in the background by CVI.

After a legacy SAP Business Suite is converted to SAP S/4HANA and business has activated the direction from BP to customer/supplier, then the BP transaction can be widely opened for relevant users. In SAP S/4HANA, the old customer/supplier maintenance diverts to transaction BP automatically.

What Is the Impact on Central Finance?

Central Finance will also be on SAP S/4HANA. It is just a deployment approach to quickly realize the benefits of SAP S/4HANA reporting, especially in a multisystem ERP landscape. So the customers or suppliers have to be replicated as business partners in the SAP S/4HANA Central Finance system. If Central Finance is using the SAP-recommended mapping tool Master Data Governance (MDG), then note that the MDG-BP/C/S (business partner, customer, or supplier) data model does not support all fields of legacy SAP Business Suite and SAP S/4HANA. Refer to SAP Note 2221398 (https://launchpad.support.sap.com/#/notes/2221398) to see which fields are supported and which ones are not. If there is any field not supported by MDG that is critical for your business processes, then you need to make a custom enhancement in the MDG mapping.