SD / O2Cadvanced

SD Pricing Part 9: Troubleshooting Pricing — Missing, Inactive and Wrong Conditions

Key takeaway

A repeatable method for pricing incidents: reading pricing analysis, why conditions are missing (no record, requirement failed, access not reached), why they are inactive (exclusion, subsequent price, error), wrong values from scales, validity or pricing date, pricing errors blocking billing, and repricing documents safely.

Explanation

📌 KEY POINTS
✅ Pricing analysis (item > Conditions > Analysis) shows, per condition type, each access, whether a record was found and why a condition was skipped.
✅ "Missing" = no record for the keys, requirement not met, or wrong procedure; "inactive" = excluded, superseded or in error.
✅ Wrong values usually come from validity/pricing date, scales, field mapping in accesses, or manual changes.
✅ Required conditions missing = pricing error → document incomplete for billing.
⚠️ Repricing to "fix" a document can remove manual agreements — choose the pricing type deliberately.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–8 built pricing. Now how to fix it when it goes wrong.

━━━━━━━━━━━━━━━━━━━━
▶ 1. START WITH ANALYSIS

Identify pricing procedure (header) and the condition type in question.
Read accesses: record found / not found / requirement not fulfilled.
Check field values used for the access (customer, material, price list…).

━━━━━━━━━━━━━━━━━━━━
▶ 2. MISSING CONDITIONS

No record for keys or validity at pricing date.
Requirement routine rejected (e.g. item not relevant, customer group).
Condition type not in procedure / wrong procedure determined (OVKK, customer pricing procedure).

━━━━━━━━━━━━━━━━━━━━
▶ 3. INACTIVE CONDITIONS

Lost in condition exclusion.
Superseded (e.g. subsequent price / later condition of same type).
Error in calculation (missing unit conversion, currency).

━━━━━━━━━━━━━━━━━━━━
▶ 4. WRONG VALUES

Pricing date vs validity.
Scale basis and group condition behavior.
Access field mapping (sold-to vs ship-to).
Manual changes (condition origin).

━━━━━━━━━━━━━━━━━━━━
▶ 5. PRICING ERRORS AND BILLING

Required condition missing → incompletion "pricing", billing blocked.
Fix data, then Update Prices with suitable pricing type; check copy control pricing type into billing.

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

Open analysis for the item and condition type.
Check each access and the field values.
Check records (VK13) with the same keys and dates.
Check procedure determination and requirements.
Fix data/config, reprice with the right pricing type, verify billing.

✅ CHECKPOINT: every pricing incident ticket states the exact cause category (record, requirement, procedure, exclusion, date, manual).

Code example

ABAP Code

===== STEP 1: analysis path =====VA03 > item > Conditions > Analysis  Condition type ZPR0    Access 10 (table 501) : message "Condition record is missing"    Access 20 (table 502) : "Condition record has been found"   → price from price list ===== STEP 2: cause checklist =====Record missing       → VK13 same keys/dates, validity vs pricing dateRequirement failed   → V/08 Reqt column → VOFM routine logicWrong procedure      → OVKK: sales area + DocPP + CuPP (customer master)Inactive             → exclusion groups (OV31–OV33), subsequent/duplicate condition, calculation errorWrong value          → scales, group condition, access field mapping, manual change ===== STEP 3: fix and reprice =====VA02 > Conditions > Update → pricing type (B / C / G) chosen per caseV.02 / incompletion log: pricing errors   VF04 billing due list: check blocked items

Real project scenario

A support team received 30 pricing tickets a week and repriced documents case by case. After introducing a cause-category field in the ticket and a standard analysis checklist, patterns showed: 60% missing records for new customer-material combinations, 20% customers with the wrong customer pricing procedure, 20% other. Master data workflows were fixed at source (price record request at customer onboarding, CuPP validation), and tickets dropped to five a week.

Common mistakes

Repricing with B and wiping manual agreements.
Guessing instead of reading pricing analysis.
Ignoring the pricing date.
Fixing documents one by one without fixing root causes.
Forgetting that the wrong procedure can be a customer master issue.

Best practices

Always start with pricing analysis.
Categorize causes in tickets and fix at source.
Choose pricing types deliberately when repricing.
Keep a troubleshooting checklist in the runbook.
Monitor pricing errors blocking billing daily.

Interview angle

Questions: "A price is missing in an order — how do you analyse?", "Why can a condition be inactive?", "How do you reprice without losing manual discounts?"
Strong answer: pricing analysis per access, record/validity/requirement/procedure checks, inactive via exclusion or errors, wrong values from dates, scales, mapping or manual changes; pricing errors block billing; reprice with pricing type C or G to keep manual elements; fix root causes.

Practice this lesson

Quick check

1. A condition record exists but is not applied in the sales order. Which screen identifies why?

2. Online orders of a new sales channel pick up a generic price instead of the channel price. The records exist. What should be checked early?

3. A discount record is valid but shown as inactive in the order. What is a typical reason?

Interview questions

1. During month-end, users report that a specific discount condition record is being ignored for certain orders even though it's active and within its validity dates. As the architect, how do you systematically diagnose this?

Answer it in your own words first, then compare.

2. A customer reports that a manually entered discount condition record disappeared from a recurring sales order template after mass condition record updates. How would you troubleshoot this using condition record maintenance?

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.