Partner Function in SAP MM | Detailed Explanation with end to end Configuration

Main ideas / concepts covered

• What “partner functions / partner roles” mean in SAP MM (especially for vendor/PO processing) Procurement activities in a procure-to-pay flow involve different parties:

  • Buyer side: RFQ → quotation → PO → PO copy to vendor → Goods receipt → Invoice processing
  • Seller (vendor) side: receive RFQ → finalize terms → submit quotation → receive PO copy → dispatch goods → submit invoice

A vendor may perform these activities through different internal offices/locations (partners). To manage this in SAP, the PO must record which vendor plays which role (partner function), so SAP can automatically route/configure processes correctly.

• Why partner functions matter (end-to-end role in MM) In a PO, the header vendor (main vendor) represents the contract party, but other roles determine:

  • Where PO copies are sent (ordering address / OA)
  • From where goods are delivered/returned (goods supplier / GS)
  • Which vendor is used for invoice/liability (invoicing party / PI)
  • From where output is printed/configured (ordering address)
  • Which vendor is used by IRO invoice processing (invoicing party)

• Standard partner roles referenced

  • VN = main vendor (vendor entered in PO header)
  • OA = ordering address
  • GS = goods supplier
  • PI = invoicing party
  • AZ = alternate payment recipient (mentioned as another role in the mapping diagram)

---

Methodology / configuration approach (as instructed in the video)

A) Configuration building blocks (SAP customizing concept)

1. Define partner roles

   • Create partner role keys (used in vendor master maintenance)
   • Assign each partner role to a partner type (for vendors, partner type is LI)
   • Set rules such as:
     • Uniqueness per organizational level (whether only one partner can be entered per role/org level)
     • Hierarchy relationship (higher-level partner mapping if roles are hierarchical)

2. Assign permissible partner roles to vendor account groups

   • Decide which partner roles are allowed for vendors belonging to a given account group
   • This controls what roles can be used in partner data in vendor master

3. Define partner schema in the supplier (vendor) master

   • Create a filtered list of partner roles that are valid for that vendor account group

   • Control role behavior via flags:

     • No change indicator Prevents changing the partner value (but may still allow deletion)

     • Mandatory indicator Forces entry of that partner role for vendor master to be saved

4. Assign the vendor partner schema to account groups

   • Vendor partner roles are supported at multiple organizational levels:
     • purchase organization level
     • purchase organization + vendor subrange
     • purchase organization + plant
     • purchase organization + vendor subrange + plant
   • The highest relevant level drives system selection.

5. Define partner schema for purchasing documents

   • Create a filtered list of partner roles allowed for specific PO document types

   • Also controlled with indicators:

     • No change indicator Can prevent changing and deleting partner role entries in the PO

     • Mandatory indicator Forces entry of that partner role in PO

     • Higher level indicator If partner role was maintained at lower level (subrange/plant) but not found for the PO’s org combination, system can fall back to higher level (purchase organization)

     • End indicator Controls when determination happens:

       • at check/save time vs. immediately after entering header vendor + purchase organization

6. Assign purchasing partner schema to document types

   • Example used: assign a partner schema to standard purchase order document type (e.g., NB in the example)

---

B) End-to-end setup workflow demonstrated (create “from scratch”)

• Step 1: Create a vendor account group Example: create SU1

• Step 2: Allow specific partner roles for that account group Example: allow VN, OA, PI, GS for SU1

• Step 3: Create vendor master partner schema Example: create L5 and include the partner roles (VN, OA, PI, GS) Set flags (no change / mandatory) for certain roles in the schema. Assign schema L5 to account group SU1 at purchase organization level.

• Step 4: Create purchasing document partner schema Example: create Z02 Include (or later remove) partner roles to see how PO defaults behave. Assign purchasing partner schema to PO document type NB.

• Step 5: Prepare business partner/vendor integration

  • Create number range for the vendor account group
  • Create BP grouping and align number assignment between BP and vendor

• Step 6: Create master data for partner vendors

  • Create vendors for each role (ordering address vendor, goods supplier vendor, invoicing party vendor)
  • Maintain the partner vendors inside the main vendor’s purchasing partner functions

• Step 7: Create a purchase order and validate partner determination Check the Partners tab and how each partner role defaults.

---

Key lessons shown through demos

• Partner roles default from vendor master → into PO

  • PO partners are determined using: 1) vendor master’s partner schema constraints 2) purchasing document partner schema constraints (per PO document type)

• Two-level filtering concept

  • A partner role must exist in both:
    • vendor master schema (for the main vendor/account group)
    • purchasing document schema (for the PO document type)
  • If a role is missing from either schema, it won’t default in the PO.

• Uniqueness rule example

  • Role OA configured as unique → system blocks adding multiple ordering addresses.
  • Role PI not unique → system allows multiple invoicing parties in vendor master.

• Default checkbox behavior (in vendor master)

  • When multiple values exist for a partner role (e.g., multiple PI vendors):
    • system may show selection pop-up in PO creation
    • “default” partner is preselected/highlighted in the PO

• Company code extension requirement

  • If a partner vendor role (e.g., PI) is not extended to the PO’s company code:
    • the PI may not default into the PO partners/header selection
  • After extending PI vendor to the company code, the PI defaults properly.

• Removing roles from purchasing partner schema affects PO defaults

  • If OA is removed from the purchasing partner schema assigned to the PO document type:
    • PO will not default ordering address from vendor master
    • manual entry of that role in PO is also restricted (system rejects invalid partner role)

---

Speakers / sources featured

• Primary speaker: The video creator/instructor (no specific name provided in subtitles).
• Source content referenced: SAP MM/IMG configuration paths and standard SAP customizing concepts (no external person/source beyond the instructor).