Configuring Production Versions, Planning Tables, and Backflushing in REM
Learn how to configure REM profiles, production versions, and backflush behavior, and how the planning table drives daily execution and integrates with MRP output.
Explanation
Once a material is REM-relevant and has valid master data, the operational heart of Repetitive Manufacturing is the planning table and the backflush process, both governed by REM profile configuration. The REM profile is a reusable configuration object assigned to the material's production version (or defaulted at plant level) that controls a cluster of behaviors: whether backflush is triggered automatically at confirmation, how the system proposes final confirmation quantities, how scrap and rework quantities are treated, and what happens when a backflush cannot post cleanly (for example, due to insufficient component stock). The production version is the linchpin connecting BOM, routing, and REM control data. A single material can have multiple production versions, each valid for a specific date range, lot size range, or plant, allowing a business to run, for example, a summer BOM alternative on one line and a winter alternative on another, or to phase in an engineering change without disrupting current runs. During configuration, the consultant must ensure production version lot size ranges do not overlap ambiguously and that each version's routing type (rate routing versus standard routing) is compatible with REM. The planning table is where planners view and adjust run schedule quantities, typically derived from MRP planned orders or from directly entered production quantities for the period. Unlike discrete order dispatching, REM planning table entries represent quantities to be produced per period (day, shift, or other bucket) for a material/production version/line combination, and the table gives visibility into cumulative planned versus confirmed quantities. Planners use this table to level production, react to short-term demand changes, and confirm run schedule quantities as work is executed. Backflushing is the confirmation mechanism specific to REM: when a produced quantity is confirmed (often at the end of a shift or via automated line reporting), the system simultaneously (a) issues the BOM components based on the standard BOM quantities per unit produced, adjusted for any scrap factors, and (b) receives the finished or semi-finished quantity into inventory, and (c) updates the product cost collector with actual quantities for later costing. This single-step posting is what removes the overhead of separate goods issue and order confirmation transactions found in discrete manufacturing. Common backflush complications include component shortages (where the system may post a negative stock if configured to allow it, or block backflush if not), phantom assemblies that should not generate their own movements, and bulk materials that are excluded from backflush entirely because they are issued via other means (e.g., stock room floor stock). Correctly flagging bulk and phantom materials in the BOM is essential to avoid inventory distortions. Integration with MRP is bidirectional in spirit: MRP considers REM materials' independent requirements and existing planning table entries when calculating net requirements, and planning table changes feed back into available-to-promise and capacity evaluations. Capacity evaluation for REM typically uses the rate routing's throughput figures rather than operation-level standard time calculations, so capacity leveling tools must be interpreted with this rate-based logic in mind. In S/4HANA, planning table functionality and backflush processing remain conceptually aligned with ECC, but S/4HANA has introduced Fiori-based apps for reviewing and confirming production quantities on REM-relevant lines, and some organizations run these apps alongside or instead of classic transactions depending on release and rollout scope; exact app availability and any retirement of classic UI paths should be confirmed against the specific system version rather than assumed uniformly across landscapes.
Real project scenario
A consumer packaged goods company running multiple filling lines for the same beverage SKU needed to plan production at a daily level while allowing supervisors to confirm actual filled quantities per shift without creating individual orders. The PP team configured a REM profile with automatic backflush on confirmation, set up two production versions for the material (one per line, each referencing a line-specific rate routing), and trained supervisors to use the planning table to review MRP-driven daily run schedule quantities and post shift-end confirmations. This backflushed raw materials and packaging components automatically and updated the product cost collector, while a bulk cleaning-in-place chemical was excluded from backflush and tracked via manual stock room issues instead.
Common mistakes
• Overlapping production version validity or lot-size ranges causing ambiguous version selection during MRP or backflush. • Failing to mark bulk or floor-stock components correctly, resulting in inventory being double-counted or incorrectly consumed via backflush. • Enabling automatic backflush without adequate component stock visibility, leading to frequent negative stock postings or blocked confirmations. • Ignoring phantom assembly flags in the BOM, causing unwanted intermediate goods movements during backflush. • Treating the planning table purely as a scheduling tool without recognizing its direct link to MRP requirements and cost collector updates.
Best practices
• Define non-overlapping, clearly validated production version ranges before go-live to avoid ambiguous selection logic. • Explicitly flag bulk materials and phantom assemblies in the BOM to prevent incorrect backflush postings. • Pilot automatic backflush with close monitoring of component stock levels before enabling it plant-wide. • Align planning table review cadence with actual shift or line reporting cycles so confirmations reflect real production timing. • Verify REM app and transaction availability against the actual S/4HANA release in scope rather than assuming feature parity with ECC.
Interview angle
Expect questions on how the REM profile controls backflush behavior, how production versions resolve BOM/routing selection, and how MRP and the planning table interact. Interviewers may probe your understanding of bulk material and phantom assembly handling in backflush, and whether you can explain why REM capacity evaluation relies on rate routings rather than operation-level times. Demonstrating awareness that S/4HANA offers newer Fiori apps for REM confirmation, while classic concepts remain foundational, shows current and grounded knowledge.