SAP Repetitive Manufacturing Tutorial (Part 1)

Repetitive Manufacturing (REM) exists because many production environments make the same or very similar materials repeatedly over long periods, without needing a discrete production order for every lot. Automotive component lines, consumer goods filling lines, and many process-adjacent discrete plants run the same finished good for days or weeks. Creating and closing a full production order for every small run is administratively heavy: order creation, order-specific scheduling, order settlement, and order-level goods movements all add overhead that does not match the physical reality of a continuous or near-continuous line.

REM addresses this by planning and controlling production at the level of a material and production version over a period (daily or period-based run schedule quantities) rather than at the level of individual orders. Instead of a production order, REM uses a 'run schedule quantity' concept tied to a planning table, and actual production is recorded through simplified backflush postings that consume components and confirm output in a single transaction, rather than separate goods issue and confirmation steps.

To enable REM for a material, the material master must carry the REM indicator (typically maintained in the MRP 4 / Work Scheduling view) and must have at least one valid production version. A production version links the BOM alternative and the routing (or rate routing) that will be used to produce that material, and REM specifically supports rate routings, which express capacity requirements as a production rate (units per hour) rather than as operation-by-operation standard times. This matters because rate-based lines are often measured in throughput per shift, not in discrete setup and run times per lot.

Master data prerequisites for REM include: a valid material master REM indicator and REM profile assignment, a BOM (with components flagged for backflushing as appropriate), a rate routing or standard routing usable in REM, and a production version that is 'REM-relevant' and locked to a specific plant and validity period. The REM profile itself is configuration that controls default behavior such as whether backflush is automatic, how scrap and error quantities are handled, and how the system proposes final confirmation.

A critical conceptual difference from discrete manufacturing is that REM has no individual order number carrying cost and status. Instead, actual costs are collected on a period-based cost object, commonly referred to as a product cost collector, which accumulates actual costs for the material/production version combination over a period and is settled periodically (rather than order-by-order). This is a foundational integration point with Controlling (CO-PC) that every REM implementation must account for during blueprint and configuration.

In S/4HANA, the underlying REM concepts (REM indicator, production version, rate routing, product cost collector) remain, though S/4HANA increasingly recommends production versions be maintained directly and consistently across MRP, costing, and REM views, and some legacy transaction codes are being consolidated into Fiori-based apps for planning table and backflush activities. On-premise/private cloud customers can generally still use classic REM transactions in parallel with newer apps, whereas the degree of Fiori-only exposure and any classic transaction restrictions can vary by release and should be verified against the specific system's app availability rather than assumed.

Understanding this foundation is essential before touching configuration, because misclassifying a material as REM-relevant when the business process actually needs discrete order tracking (e.g., serial number-level genealogy, order-specific costing, or complex rework) leads to expensive redesign later.

A tier-1 automotive supplier producing wiring harness sub-assemblies on a continuous line wanted to eliminate the overhead of creating and closing a discrete production order for every shift's output. During blueprint, the PP consultant proposed REM for the finished harness material, set the REM indicator in the material master, created a rate routing expressing line throughput in units/hour, and defined a production version tied to that rate routing and the current BOM alternative. This let the plant's planning table reflect daily run schedule quantities directly from MRP-generated planned independent requirements, and backflushing consumed components and confirmed output in one step per shift, dramatically reducing transaction volume compared to the plant's prior discrete-order setup.

• Enabling the REM indicator on a material without first creating and validating a production version, causing planning table and backflush errors.
• Using a standard (operation-based) routing where a rate routing is actually needed for accurate throughput-based capacity planning.
• Assuming REM automatically eliminates the need for a cost object; forgetting to set up and validate the product cost collector before go-live.
• Applying REM to materials with complex variant configuration or serial-level traceability requirements without confirming REM can meet those genealogy needs.
• Not aligning BOM component backflush indicators with actual shop floor issue practices, leading to incorrect component consumption.

• Confirm REM suitability against production volume, repetition, and variant complexity before configuring the REM indicator.
• Always create and test the production version, BOM, and routing combination before flagging a material as REM-relevant in production systems.
• Use rate routings where throughput-based capacity planning genuinely reflects the line's operating model.
• Set up and validate the product cost collector early in the project, in coordination with the CO team, not as an afterthought.
• Document REM profile decisions (backflush defaults, scrap handling) so operations and finance understand downstream cost and inventory impacts.

Interviewers commonly ask candidates to explain the conceptual difference between discrete production orders and REM run schedule quantities, and to justify when REM is appropriate versus discrete manufacturing. Be ready to discuss the role of production versions, rate routings, and the product cost collector, and to explain why REM reduces transactional overhead without eliminating the need for cost tracking. Strong candidates also mention material master prerequisites (REM indicator, MRP 4 view) and can articulate a business scenario where REM would be a poor fit, such as low-volume, highly configured products requiring order-level traceability.