A hierarchy reorganisation that silently deleted an 8% discount
Customer group ACC is modelled in a customer hierarchy: node 2000 (national parent) sits above ship-to parties 3001 to 3005. Discount condition ZD01 is maintained as 8% on node 2000, valid 01.01 to 31.12, and its access sequence reads hierarchy level 2, then sold-to party. The standard pricing procedure contains ZD01 at step 420 inside condition exclusion group A. On 01.02 the hierarchy was reorganised: ship-to 3003 was moved from node 2000 to a newly created node 2100, which itself reports to 2000. Ship-to parties 3004 and 3005 were not touched. In February, orders for 3003 receive 0% while 3004 and 3005 still receive the full 8%. In the same month, rush orders created in order type ZOR2 for the same customer and material show no ZD01 line at all in the pricing analysis - not even a failed access.
1. Explain both symptoms. Why does 3003 differ from 3004/3005, and why is ZOR2 different in kind?
Read the worked answer
3003 versus 3004/3005 - a hierarchy-level problem, not a condition-record problem. ZD01 sits on node 2000 and the access sequence reads hierarchy level 2 only, then sold-to. For 3004 and 3005 the level-2 node is still 2000, so the first access step hits. For 3003 the level-2 node is now 2100, which carries no ZD01 record; the access falls through to sold-to, where nothing is maintained. Nothing about the record looks broken - the path to it changed. Note that 2100 reports to 2000, so the commercial entitlement is clearly still intended; the configuration simply cannot see the grandparent because level 1 is not in the access sequence.
ZOR2 - a different kind of failure. No ZD01 line at all, not even a rejected access, means the condition is not in the pricing procedure that was determined. Pricing procedure determination combines order type, document pricing procedure and customer pricing procedure. ZOR2 evidently resolves to a procedure without ZD01, or to a combination that changes the result. That is a determination defect and it affects every customer using ZOR2, not just ACC - which makes it more serious than the 3003 issue.
2. What do you check in the pricing analysis, and what does each observation prove?
Read the worked answer
Run the analysis on the actual order, not on a newly built test order - the test order will not carry the same pricing date.
- Is the ZD01 step present at all? Absent → pricing procedure determination (order type, document pricing procedure, customer pricing procedure). Present but with no access → the record was not found; continue.
- Access columns. The analysis lists each step of the access sequence with a hit or a miss. A miss on hierarchy level 2 for 3003 and a hit for 3004 confirms the diagnosis above without opening any customizing table.
- Requirement on the condition. If the step shows as not executed, a requirement routine excluded it - a different root cause from not found.
- Validity and scales. The record is valid 01.01 to 31.12, so compare the record's validity with the pricing date of the order rather than with today's date. A pricing date defaulting from the delivery date can fall outside a record that looks perfectly valid.
- Condition exclusion group A. Compare against any other condition in the same group. If another discount was found and excluded ZD01, the analysis shows ZD01 as excluded, not as missing - and the fix is in the exclusion logic, not in the access sequence.
3. What is your fix, and what governance do you add so that a hierarchy reorganisation cannot silently drop discounts again?
Read the worked answer
Immediate fix - two options with different side effects.
- Maintain ZD01 on node 2100 at 8%. Fast, but every future node needs the same manual step and the two records will drift.
- Extend the access sequence to include hierarchy level 1 (and level 3 where relevant), so one record on 2000 covers the whole subtree. This is a transportable change with a wider blast radius: every condition using that access sequence is affected, so all of them must be retested.
Choose on the basis of whether the business maintains prices per national parent or per local node - not on the basis of the one customer in front of you.
For ZOR2: correct the pricing procedure determination or the procedure so rush orders price like standard orders, then re-price the open rush orders before they are billed.
Governance: a hierarchy change is a pricing change. Add hierarchy nodes to the master data change process, and run a periodic report comparing nodes in use against existing condition records, so a new node without a discount is found by the system rather than by a customer complaint.