Tags
calculation schema, Condition Records, MM, P2P, PortSAP, pricing procedure, Ray Hornbrook, SAP, SAP MM
If you want SAP to calculate PO prices the same way every time base price first, then discounts, then freight, then taxes you need a pricing procedure (a.k.a. calculation schema). Done well, it removes manual math, enforces negotiated terms, and keeps AP, audit, and suppliers happy.
What a Pricing Procedure Does (in plain English)
A pricing procedure is the recipe SAP follows to compute a PO price. It tells SAP:
- Which price components to consider (base price, discounts/surcharges, freight, taxes, etc.)
- In what order to apply them
- Whether each is mandatory, manual, or automatic
- Whether a component is statistical (informational only) or changes the net price
- Where to look up each value (condition records) and how specific those records should be
Outcome: consistent, auditable net prices with minimal user input.
Why it matters
- Standardization: One pricing logic across plants, buyers, and vendors
- Fewer errors: Less keying, less arithmetic, fewer invoice mismatches
- Compliance: Enforces negotiated terms and freight/tax rules every time
- Speed: Buyers focus on content (quantity, dates, approvals), not price math
The building blocks (and how they fit)
1) Condition Tables
Think of these as the index keys for price records. A table defines which fields identify a unique price:
- Examples: Vendor + Material, Vendor + Material + Purchasing Org, Material Group, Plant, etc.
- The more fields, the more specific the record.
2) Condition Records
These are the actual values—your prices, discounts, freight amounts, scales—stored against the keys above.
- Maintained in Purchasing Info Records, Contracts, Scheduling Agreements, or via condition maintenance (MEK1/MEK2/MEK3).
- Can be scales (e.g., 1–999 units = $10.00, 1,000+ units = $9.50).
- Can be time-bound with validity dates.
3) Condition Types
Each price component has a condition type that controls how it behaves:
- Base price (commonly PB00 in purchasing; some templates use PR00—both are fine if configured)
- Discounts/Surcharges (e.g., RA01 discount, ZFI1 fuel surcharge)
- Freight (e.g., FRB1 header freight, FRA1 item freight)
- Taxes (typically driven by tax codes; you may still see condition lines for visibility/statistics)
Key attributes: calculation type (amount vs. %), manual/automatic entry, header vs. item, statistical or not.
4) Access Sequences
A search strategy that tells SAP where to look for a condition record, from most specific to most general.
Example for base price:
- Vendor + Material + Purchasing Org
- Vendor + Material
- Vendor only
- Material Group
- (Fallback) Plant or general
SAP stops at the first hit.
5) Calculation Schema (Pricing Procedure)
The heart of the setup—the ordered list of condition types with rules:
- Sequence (base price → discounts → surcharges → freight → taxes)
- Subtotals (e.g., net before freight, net after freight)
- Mandatory vs. optional
- Manual vs. automatic
- Statistical flags (informational lines not impacting net)
- Condition bases/formulas if you use advanced routines
6) Schema Groups (Vendor & Purchasing Org)
Schema groups are labels that drive which calculation schema applies:
- Schema Group – Vendor: assigned in the vendor’s purchasing view (lets you differentiate domestic vs. import vendors, consignment partners, etc.)
- Schema Group – Purchasing Organization: assigned to the purchasing org (so different orgs can use different schemas)
7) Schema Determination
Configuration that maps (Vendor Schema Group + Purchasing Org Schema Group) → Calculation Schema.
This is how SAP decides which procedure to use in your PO.
How SAP picks the price in a PO (the flow)
When you create a PO:
- SAP reads the vendor and purchasing org.
- From those, it derives schema groups.
- Schema determination picks the correct calculation schema (pricing procedure).
- For each condition type in that schema, SAP runs the access sequence to find the best matching condition record.
- SAP calculates subtotals and net price, then applies tax based on the tax code and country rules.
- The PO shows the full breakdown: base, discounts/surcharges, freight, taxes, and the net.
A worked example (with math)
Scenario
- Quantity: 100 units
- Base price (PB00/PR00): $10.00 each
- Discount (RA01): 5%
- Freight (FRB1): $20.00 (header)
- Tax: ignored in the math below to keep it simple (assume a recoverable input tax)
Calculation
| Component | Amount |
|---|---|
| Base price | $1,000.00 |
| Discount 5% | –$50.00 |
| Freight (header) | +$20.00 |
| Total PO value | $970.00 |
Behind the scenes, each line came from the schema in order: base price, then discount, then freight, with the access sequence finding the right records.
Configuration: the end-to-end steps (SPRO path included)
SPRO → IMG → Materials Management → Purchasing → Conditions → Define Price Determination Process
- Create Condition Tables (if you need any beyond standard)
- Pick fields (Vendor, Material, Plant, PurOrg, Material Group, etc.).
- Create/Adjust Access Sequences
- Order tables from most specific to most general.
- Create/Adjust Condition Types
- Base price, discounts, freight, surcharges, taxes; set calculation type, manual/automatic, header/item, statistical flag.
- Define Calculation Schema (Pricing Procedure)
- Sequence your condition types; set subtotals, mandatory flags, routines as needed.
- Define Schema Group – Vendor
- Create groups like DOM (domestic), IMP (import), SERV (service suppliers).
- Define Schema Group – Purchasing Organization
- Group purchasing orgs with similar pricing needs (e.g., NA vs. EU).
- Determine Calculation Schema
- Map (Schema Group Vendor + Schema Group Pur Org) → Calculation Schema.
- Assign Schema Group to Vendor Master
- In vendor purchasing data (per purchasing org).
- Assign Schema Group to Purchasing Organization
- In purchasing org configuration.
- Maintain Condition Records
- In Info Records (ME11/ME12) for base price and vendor-specific terms;
- In Contracts/Scheduling Agreements for agreed terms;
- Via MEK1/MEK2/MEK3 for general conditions (e.g., freight by region, material group discounts).
- Test in QA
- Create POs for different vendors/orgs and verify the full price breakdown.
Header vs. Item, Manual vs. Automatic, Statistical—what to use when
- Header conditions (e.g., FRB1 freight as a single amount per PO) are great when the charge doesn’t scale per item.
- Item conditions (e.g., FRA1) work when freight or discounts apply per line/quantity.
- Manual conditions let buyers key a value when there’s no predictable rule (e.g., an ad-hoc expedite fee). Use sparingly and require reasons/approval.
- Statistical conditions show for information only (e.g., not included in net). Handy for landed-cost visibility or audit notes without changing payables.
Tips that prevent invoice headaches
- Lead with master data. Keep Info Records current (prices, scales, validity dates). Price gaps cause red traffic lights in POs and IR/GR mismatches later.
- Be intentional with access sequences. Put your most specific tables first (Vendor + Material + PurOrg), then relax to Vendor + Material, then Vendor, then Material Group. Sloppy sequences = surprising prices.
- Use schema groups to separate realities. Domestic freight vs. import surcharges, or CAPEX vs. OPEX vendors—different rules deserve different schemas.
- Decide freight strategy. Header freight for simple “per shipment” charges; item freight when the cost must follow the line for inventory valuation/landed cost.
- Align with tax. In many countries, tax code drives purchasing tax. Keep pricing condition taxes as statistical unless your process requires otherwise.
- Train for manual lines. If you allow manual conditions, document when and how to use them—and how they impact invoice verification.
- Reconcile regularly. Compare PO price conditions to invoice variances (MIRO). Persistent deltas usually trace back to missing/expired condition records or wrong access keys.
FAQ (quick answers)
What is a pricing procedure in SAP MM?
A structured list of condition types and rules that SAP uses to calculate a PO’s net price.
What is an access sequence?
A prioritized search order over condition tables—SAP looks for the most specific matching price record first.
Can we have multiple pricing procedures?
Yes. Use schema groups for vendors and purchasing orgs to drive which procedure applies where.
What is a calculation schema?
Another name for the pricing procedure itself—the ordered condition list with controls.
Where do we maintain condition records?
In Info Records, Contracts, Scheduling Agreements, and via MEK1/MEK2/MEK3 for general conditions.
Can condition types be manual?
Yes. Mark them manual in customizing when buyers must key an amount/percent. Use approvals to control risk.
Bottom line
The pricing procedure is SAP MM’s way of turning your commercial playbook into system logic. With smart access sequences, clean condition records, and clear schema determination, you get accurate, repeatable PO prices—no spreadsheet side-math, no surprises at MIRO, and far fewer “why did this cost that?” emails.
If you want, paste a couple of your live condition types and access sequences here, and I’ll tailor this to match your exact naming (PB00 vs. PR00, FRB1 vs. custom Z-freight, etc.) and add a step-by-step test script for your QA system.
If you have question on this or any other PortSAP Consulting blog please feel free to contact us at Blog@PortSAP.com. Or if you are looking for Top Quality SAP Consultants please feel free to contact us.
The author, Ray Hornbrook, has over 19 years of SAP functional and technical experience. Ray started his career in SAP as a MM/PP Subject Matter Expert (SME) for a SAP implementation in 1998 and is now a Senior Level SAP Consultant. Since Ray has worked both sides of SAP, business end user and IT professional, he is able to communicate effectively with both IT and Business team members. Having a background as an SAP business end user has helped Ray greatly in his consulting career. The business background helps him better communicate with the business members of the team. As well as helping bridge gaps in communication between the IT and Business team members.
To find out more about Ray Hornbrook please check out his LinkedIn profile by clicking HERE.
End of document – www.portsap.com
PortSAP Blogging 