2.2 Business Partner (BP) Approach, Customer Roles, and Partner Functions

Business Partner (BP) Approach, Customer Roles, and Partner Functions

The Strategic Shift to the Business Partner Data Model in SAP S/4HANA

In legacy SAP ERP Central Component (ECC 6.0), customer and vendor master records operated in independent, siloed database architectures. Customer master data was created and maintained through transaction codes such as XD01 (central customer creation across company code and sales area), VD01 (sales area customer creation), and FD01 (accounting customer creation). Vendor master records were managed separately via XK01, MK01, and FK01. This legacy architecture suffered from inherent structural limitations:

• A single legal entity acting simultaneously as both a customer and a vendor required duplicate master records with redundant address, tax, and banking details.
• Maintaining multiple addresses or time-dependent relationships for a single business entity was impossible without custom developments or complex workarounds.
• Data inconsistency frequently arose when financial and sales departments updated distinct master record segments independently.

SAP S/4HANA eliminates these redundancies by establishing the Business Partner (BP) data model as the mandatory, single point of entry for all master data maintenance. In SAP S/4HANA, executing legacy transactions such as XD01, VD01, FD01, XK01, or MK01 triggers an automatic system redirection to transaction BP. The Business Partner concept represents an entity once as a central object and manages its diverse commercial interactions through assigned BP Roles.

Customer-Vendor Integration (CVI) Architecture

The technical foundation enabling the Business Partner model in SAP S/4HANA is Customer-Vendor Integration (CVI). CVI serves as the bidirectional synchronization engine linking the modern Business Partner tables with the traditional customer and vendor tables retained in the SAP database for backward compatibility.

When a consultant creates or updates a Business Partner in transaction BP, CVI automatically updates the corresponding tables in the background:

• Central BP Data (BUT000): Stores general entity information common across all functions, including legal name, primary address, tax identification numbers, banking details, and contact persons.
• Customer General Data (KNA1): Synchronized from BUT000 to maintain legacy reporting and SD compatibility.
• Company Code Customer Data (KNB1): Stores financial accounting parameters such as reconciliation accounts, payment methods, dunning procedures, and withholding tax data.
• Sales Area Customer Data (KNVV): Stores Sales and Distribution parameters segmented by the enterprise sales area (Sales Organization + Distribution Channel + Division).

Prior to system conversion or productive operation, organizations run the CVI Synchronization Cockpit (transaction MDS_LOAD_COCKPIT) to ensure complete synchronization between BUT000 and KNA1/KNB1/KNVV. Any missing customizing, incomplete mandatory fields, or number range discrepancies will halt synchronization and generate error logs in the Post-Processing Office (PPO).

Key Business Partner Roles for Sales and Distribution

In transaction BP, a single Business Partner entity is extended to distinct roles to support specific business operations. For sales consultants preparing for certification, understanding the three foundational BP roles is essential:

Other roles are added only when a process needs them. For example, SAP Credit Management stores credit profiles and credit segment limits in role UKM000, and a supplier relationship uses the supplier roles. Because the general data is shared, adding a role never duplicates the name, address, or bank data.

Business Partner Category, Grouping, and Role

When you create a business partner, you make three decisions in a fixed order:

To use a business partner in a sales document, the partner needs the customer role. When that role is maintained, the system creates the four mandatory sales partner functions (sold-to, ship-to, bill-to, payer) in the background. This works because the customer role is linked to a customer account group through customer-vendor integration (CVI).

Customizing Customer-Vendor Integration (CVI)

CVI keeps the business partner and the customer master synchronized. The official configuration sequence in the S46050 course is:

1. Align field control. Every field that is a required entry in the customer account group must also be a required entry in the field selection of the corresponding BP role, otherwise CVI cannot create the customer record.
2. Prepare numbering. Define BP groupings with their number ranges, and define customer account groups with their number ranges in Financial Accounting customizing.
3. Map grouping to account group. In Master Data Synchronization → Business Partner Settings → Settings for Customer Integration → Field Assignment for Customer Integration → Define Number Assignment for Direction BP to Customer, assign each BP grouping to a customer account group. Here you decide whether the customer number is assigned internally, externally, or as the same number as the business partner.

Effects of Changing Customer Master Data

Changes to a business partner do not automatically flow into sales documents that already exist. If you change the payment terms or Incoterms of a customer, open orders keep their old values until someone changes them in the document. The address is the exception: an address change in the business partner is reflected in all documents at once. If the move happens at a known future date, maintain a time-dependent address so the new address applies only from that date.

Grouping and Number Assignment Configuration

A critical architectural decision during SAP S/4HANA implementation is configuring the relationship between the Business Partner Number and the Customer Number. This linkage is defined through CVI customizing under: SPRO -> Cross-Application Components -> Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Customer Integration -> Field Assignment for Customer Integration -> Assign Keys -> Define Number Assignment for Direction BP to Customer

BP Grouping vs. Customer Account Group

Every Business Partner is assigned a BP Grouping at the time of creation. The BP Grouping determines:

• The number range interval (internal system-generated or external user-specified).
• The field status behavior for central fields.

Simultaneously, the traditional Customer Account Group (e.g., 0001 for Sold-to Party, 0002 for Ship-to Party, 0003 for Payer, 0004 for Bill-to Party) controls:

• The customer master number range interval.
• The field status specification (suppressed, required, optional, display) for sales area and company code fields.
• The default partner determination procedure.

The Same-Number Rule (Implementation Nuance)

In enterprise implementations, business stakeholders overwhelmingly prefer same-number alignment, where a customer's Business Partner number (BUT000-PARTNER) exactly matches their Customer number (KNA1-KUNNR). Achieving same-number alignment requires precise SPRO configuration:

1. The BP Grouping is configured with an Internal Number Range (for example, range 01 spanning 0001000000 to 0001999999).
2. The corresponding Customer Account Group is configured with an External Number Range covering the exact same numerical interval (0001000000 to 0001999999).
3. In CVI Key Assignment, the "Same Numbers" checkbox is selected for the pair.

When a user creates a new Business Partner, the system assigns the next sequential number from the internal BP range (e.g., 1000452). When CVI synchronizes the record to the customer tables, it passes 1000452 to the customer creation routine. Because the customer account group uses an external range covering that value, the customer master is created with ID 1000452. A frequent exam trap is assuming that both groups must be set to "Internal"; setting the customer account group to internal will cause CVI synchronization to fail when same-number assignment is active.

Core Partner Functions in Sales and Distribution

Once an SD Customer master record is created within a sales area, it participates in sales transactions through Partner Functions. Sales orders require four core partner functions to execute the Order-to-Cash life cycle:

1. Sold-to Party (SP / German: AG)

• Role: The entity that places the commercial purchase order and enters into a legally binding contract.
• Operational Authority: The Sold-to Party determines the valid sales area of the transaction, proposes the document currency and the customer pricing procedure, supplies the shipping condition used in shipping point and route determination, and proposes the complete delivery and partial delivery agreements.
• Restriction: The Sold-to Party cannot be changed at the sales document header once downstream documents (such as outbound deliveries or billing documents) have been generated.

2. Ship-to Party (SH / German: WE)

• Role: The physical site or warehouse facility that receives the delivered goods.
• Operational Authority: The Ship-to Party supplies the delivering plant proposal (if no CMIR plant exists), the Transportation Zone used in Route Determination, and the unloading points and goods receiving hours. The Shipping Condition used in shipping point determination is not taken from the ship-to party: it comes from the sold-to party (or from the sales document type, if one is maintained there).

3. Bill-to Party (BP / German: RE)

• Role: The commercial recipient of the billing document (invoice).
• Operational Authority: The Bill-to Party determines the address to which the invoice is sent and is the usual recipient of billing output (print, email, or EDI). Tax classification is not simply a bill-to attribute: depending on the sales organization's rule, the VAT registration number and customer tax classification are taken from the payer, the ship-to party, or the sold-to party.

4. Payer (PY / German: RG)

• Role: The financial entity responsible for settling the accounts receivable balance.
• Operational Authority: The Payer determines the payment terms, payment methods (e.g., direct debit, wire transfer), cash discount terms, and the credit limit account maintained in SAP Credit Management.

Partner Relationships and Multi-Tier Corporate Structuring

In simple sales scenarios, a single Business Partner entity fulfills all four core partner functions. For example, a local retailer ordering goods acts simultaneously as Sold-to, Ship-to, Bill-to, and Payer. The system automatically populates all four roles with the same customer number.

In complex enterprise environments, these roles are frequently distributed across distinct Business Partners:

• Central Headquarters: Configured as Sold-to Party (SP) and Payer (PY).
• Regional Distribution Centers: Configured as distinct Ship-to Parties (SH), each with unique delivery addresses, receiving dock schedules, and transportation zones.
• Shared Financial Services Office: Configured as Bill-to Party (BP) to receive centralized electronic invoices.

These relationships are maintained in the Sales Area view of the Sold-to Party under the Partner Functions tab. Partner Determination Procedures assigned to customer account groups and sales document types govern which partner functions are mandatory, which can be modified during order processing, and whether multiple partners of the same function (e.g., multiple Ship-tos) can be assigned.