Data that drives processes

Business partner data is not just a contact record. Many fields directly control what happens in sales, purchasing and finance. Knowing which fields matter, and where they live, lets you predict process behavior and design master data tests that catch real problems.

Where each kind of data lives

General data (all roles)Name, address, tax numbers, bank details, language, communication

Company code data (FI roles)Reconciliation account, payment terms, payment methods, dunning procedure, payment and posting blocks

Sales area data (customer role)Customer pricing procedure, currency, shipping conditions, delivering plant, incoterms, billing payment terms, tax classification, partner functions

Purchasing data (supplier role)Order currency, purchasing payment terms, incoterms, GR-based invoice verification, order acknowledgment requirement

Credit data (credit role)Credit limit, risk class, check rules

Process-driving data by level.

The Sign-Off Table · thesignofftable.com/academy/sap-xpr-101

Sales

For Great Lakes Fleet Services in sales area 1710 / 10 / 00, the sales area data decides how an order behaves. The customer pricing procedure helps determine which pricing procedure the order uses. Shipping conditions and the delivering plant influence the shipping point and route. Incoterms and payment terms are copied into the order. Partner functions define sold-to, ship-to, bill-to and payer; if the fleet company wants invoices sent to its head office but goods to each depot, that is modeled here.

Purchasing

For Lakeside Components in purchasing organization 1710, the supplier data supplies the default order currency, payment terms and incoterms for purchase orders. The GR-based invoice verification indicator decides whether invoices are matched to individual goods receipts, which changes how the three-way match behaves.

Finance

In company code 1710, the reconciliation account decides which general ledger account receivables or payables post to. Payment methods and bank details decide whether the payment program can pay a supplier, and how. The dunning procedure decides when overdue customers get reminders. Blocks stop posting or payment entirely.

BP field	Where	Process effect	Typical defect if wrong
Reconciliation account	FI customer / FI supplier, company code	G/L account for receivables or payables	Balances in the wrong account; reconciliation breaks
Payment terms	Company code, sales area, purchasing org	Due dates and cash discount	Wrong due dates; disputes about discounts
Bank details and payment method	General / company code	Whether and how the payment program pays	Supplier not paid or paid to the wrong account
Customer pricing procedure	Customer role, sales area	Pricing procedure in sales documents	Wrong prices, discounts or surcharges
Partner functions	Customer role, sales area	Ship-to, bill-to, payer in orders	Goods or invoices sent to the wrong place
GR-based invoice verification	Supplier role, purchasing org	How invoices match receipts	Unexpected invoice blocks or wrong matching
Credit limit and risk class	Credit role	Credit checks on orders and deliveries	Orders blocked or not blocked as intended

Business partner fields that drive process behavior.

The Sign-Off Table · thesignofftable.com/academy/sap-xpr-101

Designing master data test cases

Turn the table above into tests. For each field that drives a process, write one positive case (the process picks up the expected value) and, where the risk is high, one negative case (a blocked supplier is not paid; a customer over its credit limit is blocked). Name the business partner, role and organizational unit in the test precondition, for example "Great Lakes Fleet Services, customer role, sales area 1710 / 10 / 00, payment terms 30 days net". When the master data changes later, the precondition tells everyone which tests to rerun.

What would you do?

A Contoso UAT order for Great Lakes Fleet Services gets 60-day payment terms instead of the agreed 30. Pricing and billing configuration have not changed. Where should the tester look first?

Key points

General data is shared; company code, sales area and purchasing data are maintained per role and organizational unit.
Sales area data drives pricing, shipping, partner functions and payment terms in orders.
Supplier purchasing data drives order currency, terms, incoterms and invoice matching.
Company code data drives reconciliation accounts, payment methods, dunning and blocks.
Test master data by running a short process with it and checking the result.