Multi-Level BOM Explosion, Exception Messages, and Planning File Troubleshooting

Explanation

Multi-level MRP relies on the low-level code (LLC) assigned to each material to determine planning sequence. The low-level code represents the lowest position a material occupies across all BOMs in which it appears; materials are planned strictly in ascending low-level code order so that a component is never planned before all its parent assemblies have generated their dependent requirements. This is why a full multi-level MRP run (planning all materials, all low-level codes) is required after major BOM structure changes — a single-level or net-change run scoped incorrectly can leave downstream components with stale or missing dependent requirements. Low-level codes are recalculated automatically when BOMs change, but in very large, deeply nested product structures this recalculation can be resource-intensive and is sometimes deliberately scheduled during off-peak windows. Exception messages are the primary mechanism by which MRP communicates situations requiring planner attention, surfaced on the stock/requirements list and MRP list. Common exception categories include: reschedule-in and reschedule-out (existing receipts dated earlier or later than currently needed), items with shortages beyond the opening period, excess stock situations, and exceptions related to the planning time fence being violated by firmed vs. unfirmed elements. A critical skill is distinguishing exceptions that are purely informational (e.g., date variance within acceptable tolerance) from those requiring immediate rescheduling action (e.g., a purchase order confirmed for a date after the material is already needed on the shop floor). Rescheduling proposals generated by MRP are advisory only in most configurations — the planner or an automated MRP Live rescheduling check must confirm the date change; MRP does not automatically move firmed receipts without explicit business process design allowing it. Planning file entries (maintained internally against materials flagged as relevant for the next planning run) are what actually allow a material to be picked up by MRP; if a material's planning file entry is missing or in a corrupted state, it will silently be skipped in net-change runs even though its master data appears otherwise correct. Planning file entries are created automatically when a material is extended for MRP, when relevant transactions occur (goods movements, order changes) that mark the material as needing replanning, or via mass planning file entry creation tools used after data migration or plant/MRP area setup changes. A very common troubleshooting pattern in production support is: a newly created or newly extended material does not appear in MRP list results — the root cause is frequently a missing or not-yet-created planning file entry, resolved by regenerating planning file entries for the affected scope rather than by re-checking BOM or routing data first. In S/4HANA, the underlying planning file entry concept is retained but implemented against optimized database structures to support MRP Live's parallel processing; multi-level explosion logic and low-level code assignment remain conceptually the same as ECC, though performance characteristics differ substantially for very large product structures. Troubleshooting still starts with the same diagnostic sequence: confirm the material has a valid planning file entry, confirm its low-level code and scope were included in the run, then examine exception messages, and only then investigate BOM/routing/master data content itself. Teams supporting production planning must treat exception message review as a daily operational discipline rather than an occasional audit, because unresolved reschedule exceptions accumulate and compound into material shortages further downstream.

Code example

* Conceptual pseudo-logic for low-level code driven planning sequence* (illustrative only, not actual ABAP/report code) FOR each low_level_code FROM 0 TO max_low_level_code:    SELECT materials WHERE material.low_level_code = low_level_code                        AND material.planning_file_entry_exists = TRUE    FOR each material IN materials:        net_requirement = gross_requirement - available_stock - firmed_receipts        IF net_requirement > 0:            proposal = apply_lot_sizing(net_requirement, material.lot_size_procedure)            create_planned_order_or_requisition(proposal)            IF material.procurement_type = 'E':                explode_bom(proposal) -> generate_dependent_requirements(next_level)        evaluate_exception_messages(material) * Key point: components (higher low_level_code numbers) are only* processed after all parent assemblies at lower codes are finished,* ensuring dependent requirements exist before component netting.

Real project scenario

During a go-live cutover, several newly created finished goods materials failed to generate any planned orders despite having complete BOMs, routings, and correctly maintained MRP views. Initial investigation focused on BOM validity dates and found nothing wrong. The actual root cause was that the data migration load had created the material masters directly via a mass load tool that bypassed the standard extension process, leaving planning file entries never created. Regenerating planning file entries for the affected material scope resolved the issue immediately, and the project team added a post-migration validation step to confirm planning file entry existence before each subsequent load wave.

Common mistakes

• Running a net-change MRP scope after major BOM restructuring instead of a full multi-level regenerative run, leaving stale dependent requirements downstream. • Treating all reschedule exception messages as equally urgent instead of triaging by shortage severity and lead time impact. • Assuming a material missing from planning results has a master data problem before checking whether its planning file entry actually exists. • Manually firming or deleting planned orders to silence exception messages without addressing the underlying demand or supply timing mismatch. • Underestimating low-level code recalculation impact on planning run duration for very deep, multi-plant product structures.

Best practices

• Schedule full regenerative multi-level MRP runs after significant BOM or routing structure changes rather than relying solely on net-change scope. • Build a daily exception message review routine into planner responsibilities, prioritized by shortage date proximity and criticality of the material. • Include planning file entry verification as a mandatory checkpoint in any mass material creation or data migration process. • Avoid manually deleting or firming orders purely to clear exceptions; investigate and resolve the underlying demand/supply timing cause first. • Monitor low-level code recalculation and full MRP run duration trends over time to catch performance degradation as product structures grow.

Interview angle

Expect questions on how MRP determines planning sequence across BOM levels and why planning file entries matter operationally, not just theoretically. Strong candidates can walk through a real exception-message triage process and explain the difference between a rescheduling proposal and an automatic date change, since interviewers use this to gauge production support maturity versus purely academic MRP knowledge.