9.1 Partner Determination Procedures and Account Group Linkage

Partner Determination Procedures and Account Group Linkage

In SAP S/4HANA Sales, business transactions rarely occur between monolithic commercial entities. A single corporate client frequently operates separate purchasing departments, regional distribution centers, centralized accounts payable offices, and independent legal entities. The Partner Determination architecture provides the structural framework that identifies, validates, and manages these distinct business relationships across the entire Order-to-Cash (O2C) life cycle.

Configuring partner determination correctly is vital: partner functions govern tax jurisdiction, delivery routing, credit checks, billing output routing, and legal liability. A misconfiguration at the partner level cascades into downstream delivery failures, incorrect invoicing, or blocked accounting documents.

---

The Core Partner Functions in Sales and Distribution

Every standard sales transaction requires four mandatory partner functions. Each represents a distinct legal or operational role in fulfilling a commercial contract:

                  ┌───────────────────────────────┐
                  │   Sold-to Party (SP / AG)     │
                  │   • Places the order          │
                  │   • Legal contract partner    │
                  └──────────────┬────────────────┘
                                 │
         ┌───────────────────────┼───────────────────────┐
         ▼                       ▼                       ▼
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Ship-to Party   │     │  Bill-to Party  │     │      Payer      │
│    (SH / WE)    │     │    (BP / RE)    │     │    (PY / RG)    │
│ • Receives goods│     │ • Receives bill │     │ • Settles debt  │
│ • Plant & Route │     │ • Output target │     │ • Credit limit  │
└─────────────────┘     └─────────────────┘     └─────────────────┘

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

• Operational Role: The customer entity that places the order and enters into the contractual agreement with the selling organization.
• Master Data Level: Defined under Business Partner Role FLCU01 (Customer Sales) and Account Group 0001 (or enterprise custom equivalent).
• Downstream Impact: Anchors sales area eligibility, base customer pricing groups, sales currency, customer purchase order validation, and general document eligibility.

2. Ship-to Party (SH / German: WE — Warenempfänger)

• Operational Role: The physical recipient of the goods or services.
• Master Data Level: Account Group 0002 (Ship-to Party).
• Downstream Impact: Supplies the delivering plant proposal (after the CMIR), the transportation zone for route determination, unloading points, and goods receiving hours. The shipping condition comes from the sold-to party, not from the ship-to party.

3. Bill-to Party (BP / German: RE — Rechnungsempfänger)

• Operational Role: The commercial recipient of the invoice document.
• Master Data Level: Account Group 0004 (Bill-to Party).
• Downstream Impact: Determines the address to which the invoice is sent and is the usual recipient of billing output.

4. Payer (PY / German: RG — Regulierer)

• Operational Role: The legal debtor responsible for settling the financial invoice.
• Master Data Level: Account Group 0003 (Payer).
• Downstream Impact: Drives the credit limit check (SAP Credit Management / FSCM credit segment), payment terms, payment methods (direct debit, wire, check), cash discounts, and automatic dunning procedures in Financial Accounting (FI-AR).

Partner Types and Further Partner Functions

SAP distinguishes partner types from partner functions. The partner type says what kind of master record stands behind the partner; the partner function says which role it plays in the transaction. The official course lists four partner types in sales partner processing:

• KU (Customer): sold-to party, ship-to party, bill-to party, payer, and other customer functions.
• AP (Contact person): for example, the purchaser at the customer's company or an external consultant. Contact persons can be entered in the customer master and are then assigned to that customer.
• LI (Vendor): for example, the forwarding agent.
• PE (Personnel): employees of your own company, such as the responsible employee (partner function ER) or a sales employee.

One business partner can take on several functions. In the simplest case, the same customer is sold-to party, ship-to party, bill-to party, and payer.

---

Multi-Language Partner Function Technical Keys

In standard SAP customizing, partner functions possess internal two-character language-independent codes as well as localized display codes maintained in table TPAUM:

---

Partner Determination Customizing Architecture (Transaction VOPAN)

The central configuration cockpit for partner determination is transaction VOPAN (or SPRO $\rightarrow$ Sales and Distribution $\rightarrow$ Basic Functions $\rightarrow$ Partner Determination). Customizing is organized around distinct Partner Objects:

                               Transaction VOPAN
                                       │
         ┌─────────────────────────────┼─────────────────────────────┐
         ▼                             ▼                             ▼
┌─────────────────┐           ┌─────────────────┐           ┌─────────────────┐
│ Customer Master │           │ Sales Document  │           │ Billing Header  │
│ (Account Groups)│           │ (Header & Item) │           │ (Billing Types) │
└─────────────────┘           └─────────────────┘           └─────────────────┘
         │                             │                             │
         ▼                             ▼                             ▼
┌─────────────────┐           ┌─────────────────┐           ┌─────────────────┐
│ Delivery Header │           │  Sales Activity │           │  Shipment / TM  │
│ (Delivery Types)│           │      (CAS)      │           │    (Freight)    │
└─────────────────┘           └─────────────────┘           └─────────────────┘

Configuration Steps within a Partner Object

Within each partner object, customizing follows a rigorous 4-step sequence:

Step 1: Define Partner Functions

Ensure the required partner functions exist (table TPAR) and are assigned a valid partner type (KU customer, AP contact person, LI vendor, PE personnel). Unique business rules—such as whether a partner function is unique within a document—are maintained here.

Step 2: Define Partner Determination Procedures

A Partner Determination Procedure is an ordered list of partner functions permitted to appear together in a document or master record. For example, procedure TA is commonly configured for standard sales orders, while procedure AG is used for Sold-to customer master records.

Step 3: Configure Partner Functions in Procedure

Within the procedure, each partner function is governed by customizing settings:

• Mandatory (Mandat.): If activated, the partner function must be present; if it is missing, the document is incomplete and the partner appears in the incompletion log (section 9.2).
• Not Modifiable: If activated, once the partner is populated (either derived from customer master or entered manually), the end user cannot change or overwrite the partner number in the sales document.
• Source and Sequence: Defines where the partner is determined from, for example the sold-to party's customer master (KNVP), another partner's master record, the customer hierarchy (KNVH), or contact persons (KNVK). An analysis function in the document traces how each partner was found.

Step 4: Assign Partner Determination Procedure to Objects

The completed procedure is assigned to business entities:

• Customer Master: Assigned to Account Groups (e.g. Account Group 0001 $\rightarrow$ Procedure AG).
• Sales Document Header: Assigned to Sales Document Types (e.g. Order Type OR/TA $\rightarrow$ Procedure TA).
• Sales Document Item: Assigned to Item Categories in sales, so that items can have their own partners (for example, a different ship-to party). Partners defined only at header level cannot be changed at item level.
• Delivery Document: Assigned to Delivery Types (e.g. LF $\rightarrow$ Procedure LF).
• Shipment: Assigned to Shipment Types.
• Billing Document Header and Item: Assigned to Billing Types (e.g. F2 $\rightarrow$ Procedure F2).

---

Account Group Linkage and Permitted Partners

In SAP Business Partner / Customer Master customizing, an Account Group controls field status (suppressed, mandatory, optional, display) and number ranges. However, within transaction VOPAN, Account Groups serve a secondary, vital security function:

1. Assign Procedure to Account Group: Directs which partner procedure applies when creating a customer in that account group.
2. Assign Partner Functions to Account Group: Restricts which partner functions can be assigned to a customer master. For instance, customer master records created under Account Group 0002 (Ship-to Party) can be restricted so that they cannot be assigned the role of Payer (PY) or Sold-to (SP).

---

Partner Function Copying Rules and Derivation Mechanics

When a sales representative enters a Sold-to Party in transaction VA01, the system initiates automated partner derivation:

                                 User inputs Sold-to Party (SP)
                                               │
                                               ▼
                                  Query Table KNVP in Sales Area
                                               │
                   ┌───────────────────────────┼───────────────────────────┐
                   ▼                           ▼                           ▼
        Single Ship-to found        Multiple Ship-tos found         No Ship-to found
                   │                           │                           │
                   ▼                           ▼                           ▼
          Auto-populated in           Interactive Selection       Incompletion Log Flagged
             Sales Order                   Popup Raised             (Mandatory Missing)

Step-by-Step Derivation Flow

1. Query Customer Master (KNVP): The system accesses table KNVP using the entered Sold-to Party and the current Sales Area (Sales Org / Dist Channel / Division).
2. Evaluate Default Partners: If exactly one Ship-to, Bill-to, and Payer are maintained, the system automatically populates them in sales document table VBPA.
3. Multiple Partner Dialog: If the customer master contains several partners for one function (for example, three regional warehouses as SH), a selection list appears when the order is entered. In sales documents, only one partner can be assigned to each partner function; the exception is outline agreements, where several partners authorized to release (AA) and alternative ship-to parties (AW) are allowed.
4. Header-to-Item Inheritance: By default, items take the partners of the header (POSNR = 000000). If the item category has an item partner procedure, individual items can have different partners, for example another ship-to party. A user can also change a partner's address manually in the document; this does not change the master record.
5. Copying to Downstream Documents:
   • Order to Delivery: The delivery header (LIKP) carries the ship-to party and, if determined, the forwarding agent, according to the delivery type's partner procedure.
   • Order/Delivery to Billing: The billing document header (VBRK) requires the Payer (PY) and Bill-to (BP). The Payer determines the accounting customer account in BSEG / ACDOCA.

---

Indirect Partner Determination

Partners do not have to come from the sold-to party's record. The determination sequence can read another partner's master record. Example from the official course: you have regular forwarding agents in different regions, so the forwarding agent should depend on the ship-to party. The procedure first reads the sold-to party's record to find the ship-to party, then reads the ship-to party's record to find its forwarding agent.

Multiple Address Handling

A classic customer master record holds one address, so a company with a goods receiving branch and a separate billing address needed one customer record per address, which duplicated the same legal entity N times. The SAP Business Partner can store several addresses with time-dependent validity. To use them in sales, two business functions must be activated in this order:

1. BPCUSTOMER_MULTIPLE_ADDRESSES (Multiple Address Handling for Customer Master Data in Business Partner)
2. Q2C_MULTIPLE_BP_ADDRESSES (Multiple Address Handling for Business Partners in Sales and Distribution)

SAP Note 3067314 contains the configuration guide. With the functions active, one customer number can represent the legal entity, and sales documents and deliveries take address-dependent data from that single record.

Address determination runs when a partner is added or changed in an SD document. It can be configured at two levels:

It can be set for partner functions of partner type KU, except the payer. The system first takes valid addresses from the configured address usage (for example, address determination attribute BBP003 Send goods, mapped to the delivery address usage); if that does not cover the period from today until 31 December 9999, it adds addresses from the address overview. If no field is configured, addresses come from the address overview. A document can use several addresses of one customer, but only one per partner function. In new sales documents and in deliveries without order reference, the user selects the address if several exist; the partner tabs offer an address selection button. If the user edits an address manually, it is saved as a document-specific address and the master address is kept as the BP reference address.

Summary of Customizing Tables in Partner Determination