SAP MM Pricing

Purchasing uses the condition technique: a calculation schema (pricing procedure) combines condition types (gross price, discounts, freight, tax) to compute the net price on a PO. Condition records (e.g. a vendor’s agreed price for a material) supply the values automatically.

• Condition types: price, discount, surcharge, freight.
• Calculation schema: how conditions combine.
• Condition records: the actual values (info records, contracts).
• Purchasing info records: vendor-material price relationships.

Two fields on a condition record decide more than their size suggests. Validity dates mean a price applies from a date, so a record that expired last night is the most common cause of a price that worked yesterday. And the condition scale allows the price to vary by quantity, which is how a volume discount is expressed without a record per quantity.

People are surprised that a purchase order arrives priced, and the order of preference is worth knowing because it decides whether spend is controlled.

A contract or scheduling agreement wins. It is a negotiated commitment, and an order released against it takes its terms.

Failing that, the purchasing info record supplies the price for that material from that vendor for that purchasing organisation.

Failing that, the system may propose the last purchase order for the same combination, which sounds helpful and perpetuates whatever was typed last time.

Failing all of it, somebody types a number, and that is where uncontrolled spend begins. The invoice will then be matched against a price nobody negotiated.

On top of whichever base price is found, the pricing procedure applies the other condition types: discounts, surcharges, freight, duty. Some of those are delivery costs, and they behave differently: they are expected at goods receipt and settled at invoice, which is how a freight charge from a third party gets onto the material's value.

The practical instruction: when a buyer says prices keep drifting, the answer is almost always missing info records or contracts rather than anything in the pricing configuration.

Twenty minutes, and it shows the hierarchy in action.

1. Create a purchase order for a material and vendor with no info record. Note that you had to type the price.
2. Create an info record with ME11 for that combination, with a price and a planned delivery time.
3. Create a second order. The price is proposed, and so is the delivery time, which feeds planning.
4. Open the conditions tab and run the analysis. It shows which condition type found which record and at what level.
5. Add a discount condition record and create a third order. The net value changes and the analysis shows both conditions.
6. Now create a contract and order against it. The contract terms take precedence over the info record.

Pricing drives the value posted at goods receipt and invoice verification, so errors flow straight into inventory value and payables. The condition technique is shared conceptually with SD pricing, so learning it here transfers. Getting condition records and the schema right ensures POs cost what they should.

It matters beyond the order because the price determines the value posted at goods receipt, and on a moving average material that value changes the price of everything in stock. A wrong purchase order price therefore misstates inventory rather than only the payable, and correcting it after receipt means a revaluation rather than an edit. See SD pricing for the same machinery on the selling side.

• Info records maintained deliberately or created automatically. Automatic creation records whatever was typed; deliberate creation records what was negotiated.
• Contracts for repeated buying. Anything bought regularly from one supplier belongs on an agreement rather than on repeated standalone orders.
• Which delivery costs are planned. Planned costs are expected and accrued at receipt; unplanned ones arrive with the invoice and have to be assigned somewhere.
• Whether buyers may change the price. Convenient, and it removes the reason for having condition records at all.

Both use the condition technique and the differences are the part worth knowing, because knowledge of one transfers with caveats.

The procedure is determined differently. In sales it comes from the sales area, the customer's pricing procedure and the document type. In purchasing it comes from the schema group on the vendor and on the purchasing organisation, which is a smaller and simpler determination.

Delivery costs are a purchasing concept. Freight, duty and insurance conditions can be marked as delivery costs, which means they are accrued at goods receipt and settled separately at invoice. Sales has no equivalent, and it is the largest structural difference.

The consequence of a wrong price differs. In sales, a wrong price is invoiced and disputed. In purchasing, it becomes the value of stock at goods receipt, which on a moving average material changes the valuation of everything on hand.

Condition records live at different levels. Purchasing leans heavily on the info record and on contracts as the source of the base price, where sales uses condition records throughout.

What does transfer is the machinery: condition types, access sequences, condition tables and the analysis function all work identically, which is why an SD consultant can read an MM pricing problem and usually solve it.

A purchasing pricing procedure carries a set of condition types, and the common ones behave in ways worth knowing by name.

The gross price is the base, usually from an info record or a contract.

Discounts and surcharges adjust it, as a percentage or an absolute amount, and they can be per unit or per document.

Freight conditions are typically marked as delivery costs, which changes their behaviour entirely: they are accrued at goods receipt against a provision and settled when the carrier invoices, possibly weeks later and from a different vendor.

Duty and customs work the same way for imported goods.

Cash discount is usually handled through payment terms rather than as a pricing condition, which is why it does not appear in the order value.

Statistical conditions are shown and not added, which is how an expected market price or a comparison value can be carried on the document for reporting without affecting what is paid.

The one to check first when a value looks wrong is whether a condition is statistical, because a statistical condition that should have been active is invisible in the total and obvious in the analysis.

• Missing/wrong condition records, incorrect PO price.
• Misconfigured calculation schema.
• Ignoring info records that supply prices automatically.

• Reading the conditions tab instead of the analysis. The tab shows what happened; the analysis shows why.
• Expired validity on a condition record. The most common cause of a price that worked last week.
• Unplanned delivery costs treated as a surprise. See MM configuration and MM examples for the settings and worked cases.

• Info records created automatically from every order. They then record what was typed rather than what was negotiated, which is the appearance of control without any.

Maintaining a condition record is the easy half, and designing the procedure and the source data so prices are controlled rather than typed is the part you do in the course.

The instinct to build: when a price is wrong, open the analysis before forming a theory. It lists every condition type, every access attempted and why each one missed, and the answer is in there rather than in the configuration.