SD / O2Cadvanced

SD Pricing Part 8: Manual Pricing, Price Updates and Change Governance

Key takeaway

Control manual price changes and repricing: which condition types may be changed and within which limits, manual-only conditions, the Update Prices function and pricing types in documents, pricing date control, condition update (cumulative limits), authorizations and approval flows for price overrides.

Explanation

📌 KEY POINTS
✅ Condition type settings decide whether users may change or delete a condition and whether manual entry has priority over automatic determination.
✅ Upper and lower limits on records restrict how far manual values may deviate.
✅ "Update Prices" in the document reprices with a chosen pricing type (e.g. B new pricing, C keep manual changes).
✅ Pricing date (header/item) decides which validity period is used — often order date, sometimes delivery or billing date by copy control.
⚠️ Unrestricted manual price changes are a major margin and compliance risk — control them through configuration, authorization and monitoring.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 7 covered routines. Now the human side of pricing.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MANUAL CHANGES

V/06: manual entries (priority), amount/percent changeable, value changeable, delete allowed.
Procedure: manual-only lines (e.g. special discount entered by sales).
Records: upper/lower limits for manual values.

━━━━━━━━━━━━━━━━━━━━
▶ 2. REPRICING

Update Prices button: select pricing type (B, C, G…).
Automatic repricing on changes (e.g. quantity change triggers new pricing of scales).
Copy control pricing types for follow-on documents (Copy Control topic).

━━━━━━━━━━━━━━━━━━━━
▶ 3. PRICING DATE

Proposed from order date; can be changed.
Different pricing date per item possible.
Billing may reprice with billing date if pricing type in VTFL says so.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CONDITION UPDATE (LIMITS)

Condition update flag in condition type: track cumulative value, quantity or number of orders against limits on the record.
Used for promotions with a maximum budget or quantity.

━━━━━━━━━━━━━━━━━━━━
▶ 5. GOVERNANCE

Authorizations for changing conditions (by condition type) and for maintaining records.
Approval flows: billing block/delivery block or user status for orders with manual discounts beyond thresholds.
Monitoring: reports on manual changes (condition origin "manual") and margin below target.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Decide per condition type: changeable, limits, manual-only.
Configure V/06 and record limits.
Define approval rule (block + release) for overrides.
Report manual changes monthly.

✅ CHECKPOINT: a discount above the limit is rejected, and approved overrides are visible in a monitoring report.

Code example

ABAP Code

===== STEP 1: condition type control (V/06) =====ZPR0 price     : manual entries D (not possible to process manually)  → price cannot be overwrittenZD01 discount  : manual entries C (manual priority), amount changeable X, delete allowed –ZSPD special   : manual-only line in pricing procedure (Man = X) ===== STEP 2: limits on records (VK11 > Details) =====ZD01 customer 1000: 5% | lower limit 0% | upper limit 10%   → manual value above 10% rejected ===== STEP 3: repricing =====VA02 > item > Conditions > Update → pricing type B (new) / C (keep manual) / G (unchanged, redetermine tax) ===== STEP 4: condition update (budgeted promotion) =====V/06 ZPRM: Condition update X  | record: max. condition value 50,000 EUR ===== STEP 5: governance =====Authorization per condition type for manual changes | billing block for overrides > thresholdReport manual condition changes (condition origin/manual flag in document conditions)

Real project scenario

A distributor allowed sales reps to overwrite the price condition freely. Year-end analysis showed 11% of order lines with manual prices, many below cost. The company redesigned: price not manually changeable, a separate manual discount with upper limit per customer segment, a billing block for discounts above 10% released by sales management, and a monthly manual-pricing report. Manual discounts fell to 3% of lines with documented approvals.

Common mistakes

Allowing manual changes of the main price.
No upper/lower limits on discount records.
Repricing with B in documents that contain negotiated manual prices.
No approval or monitoring of manual changes.
Unclear pricing date rules between order and billing.

Best practices

Separate price (not changeable) from manual discount (controlled).
Use record limits and authorizations.
Add approval steps for large overrides.
Monitor manual pricing and margins regularly.
Document pricing date and repricing rules per flow.

Interview angle

Questions: "How do you control manual price changes?", "What does Update Prices do?", "What is condition update?"
Strong answer: V/06 manual entry and changeability settings, manual-only procedure lines, record limits, authorizations, approval via blocks, monitoring; Update Prices with pricing types; pricing date; condition update for cumulative limits on records.

Practice this lesson

Quick check

1. A promotion discount must stop once the total discount granted reaches 50,000 EUR. Which function supports this?

2. Sales reps overwrite negotiated contract prices freely, causing margin losses. Which control is most effective?

3. Which setting prevents users from entering a manual discount above 10% for a customer?

Interview questions

1. In a make-to-order scenario, how does customer expected price functionality reconcile a customer's anticipated price with the system-calculated pricing during ATP and requirements transfer, and what are the risks if this is misconfigured?

Answer it in your own words first, then compare.

2. What is the purpose of the 'Expected Price' field on a sales order item, and how does it differ from the actual pricing determined by the pricing procedure?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.