Custom MRP system development

MRP stands for Material Requirements Planning: a planning method and accompanying system that, based on demand (sales orders, forecasts and the master production schedule) and master data (BOMs, stock, lead times, lot sizes), calculates which components and raw materials are needed, when and in what quantity. From this, work and purchase orders are generated with the correct start date. MRP is therefore the engine between what you want to sell or produce and the orders that actually reach the shop floor and the purchasing department. Without MRP, this becomes manual work in Excel; with a good MRP, it becomes a controllable, repeatable process.

For a broad ERP context with finance, HR and logistics modules, an established package such as SAP S/4HANA, Microsoft Dynamics 365 or Exact Globe is usually the right starting point. Custom MRP makes sense when your production domain is so specific that a standard MRP module costs more in configuration and workarounds than a custom solution. Think of a food manufacturer with multi-level shelf life and allergen cascades, a pharma producer whose batch traceability deviates from a standard model, a fashion brand with seasonal MRP and collection-aware capacity planning, or a high-mix, low-volume machine builder where lot size one and kanban exist alongside work orders. We then build an MRP layer that runs alongside the ERP and takes over, or replaces, only the planning logic that is truly distinctive.

We regularly work with SAP S/4HANA and SAP ECC for enterprise contexts, Microsoft Dynamics 365 Business Central and Finance & Operations for the broader mid-market segment, Oracle E-Business Suite and Oracle NetSuite, Infor LN and Infor M3 (mainly fashion, food and discrete manufacturing), Exact Globe and Exact Online, AFAS Profit, Unit4 and Ridder iQ. In heavier production environments we also integrate with Plex (cloud MRP for automotive and discrete manufacturing) and QAD. For custom work, we build lighter MRP layers with PostgreSQL, a service-oriented architecture and REST/GraphQL APIs, often alongside an ERP that handles the financial and logistics layer.

BOM explosion is the process whereby an MRP system breaks down a finished product's Bill of Materials step by step into components, sub-assemblies and raw materials, multiplying them by the quantity to be produced. If you want to make 200 units of product A, and each unit contains a sub-assembly B which itself contains three components C, D and E, the explosion shows that you need 200 Bs, 200 Cs, 200 Ds and 200 Es, minus whatever is already in stock or already on order. By confronting this gross requirement with stock levels, open purchase orders, lead times and lot sizes, the MRP determines at any moment which work order or purchase order should be started. Sound BOM management is therefore the first prerequisite: an incorrect BOM means the entire explosion will be wrong.

MRP plans; MES executes. MRP generates work orders with a start date, quantity, BOM revision and route, meaning the sequence of operations and the associated workstations. The MES (Manufacturing Execution System) takes that work order onto the shop floor, controls machines, and records what was actually produced, how much scrap was generated and which deviations occurred. We connect MRP and MES via REST or MQTT bridges and follow the ISA-95 layering model, so that planning, execution and machine data each keep their own role. For machine data itself, we often use OPC UA for modern shop floors and MQTT for IoT-driven production lines. We integrate with MES platforms such as Siemens Opcenter, AVEVA, Rockwell FactoryTalk and GE Proficy where these are already in place.

The Master Production Schedule is the intermediate layer between forecasts and MRP. The MPS determines, for each finished product per planning period (usually week or day), how many units are scheduled for production, taking into account sales forecasts, open orders, available capacity and inventory policy. A good MPS smooths out demand peaks that the system would otherwise pass straight through into unfeasible work orders, and prevents yo-yo behaviour in purchasing. We build MPS modules with scenario functionality, allowing planners to compare different demand and capacity assumptions side by side before the published MPS feeds into the MRP explosion.

For food, pharmaceutical and cosmetics products, lot and expiry tracking is not an extra but a basic requirement. We build MRP flows in which every raw material, semi-finished product and end product receives a unique lot number, linked to production date, best-before or expiry date, supplier and source batch. In the event of a product recall, you can see within minutes, from a single screen, which batches went to which customers. For FEFO (First Expired, First Out) stock allocation and automatic rotation of lots nearing expiry, we build the logic into the issuing layer. For pharma, we account for GMP requirements around audit trails, electronic signatures under 21 CFR Part 11 and the validity of quarantine status; for food, we cover HACCP documentation and the EU traceability obligation (Regulation 178/2002).

MRP integrations almost always combine several protocols. We use REST and GraphQL for modern service-to-service integrations between MRP, ERP, e-commerce, EDI platforms and supplier portals. We regularly come across SOAP services in older SAP and Oracle installations. EDI (EDIFACT, ANSI X12) is still the standard for purchase orders, delivery notifications and invoicing with retailers and large suppliers. OPC UA is the standard for machine data and fits the ISA-95 architecture, and MQTT is used for IoT-oriented production and sensors. For batch exchange with legacy systems, such as old ERPs that still expect flat-file imports, we build secure file transfer with checksum validation. Also read our page on smart API integrations.

Not every product belongs in a classic MRP explosion. Fast-moving items with stable demand often work better through kanban or just-in-time replenishment: a simple pull signal from the shop floor that triggers a replenishment order straight away. We build MRP environments that operate in a hybrid way: MRP for the complex, long-lead-time components and kanban for the high-volume items. Visual kanban boards, e-kanban signals via barcode or RFID, lot sizes per item and automatic supplier orders make the difference between planning on paper and planning that the shop floor actually follows. For the automotive context we build vendor-managed inventory flows; for food we often build rolling MRP with daily re-runs.

Compliance is not a separate module but a continuous layer within the MRP data. For ISO 9001, we record audit trails, change management and non-conformities in a structured way and link them to product revisions. For automotive (IATF 16949), we build in APQP and PPAP flows, supplier quality monitoring and advanced shipping notices. For GMP-regulated pharma, we provide electronic signatures compliant with 21 CFR Part 11, batch records, deviation management and quarantine status. For food, we work in line with HACCP, covering critical control points, sampling flows and allergen cascades, and we meet the EU traceability obligation for food. The aim is always that when an audit lands on your doorstep, you can produce the evidence within the applicable deadlines without anyone piecing together spreadsheets.

Yes. We're regularly brought in to work on existing SAP, Dynamics, Infor or Exact implementations where the MRP layer is struggling, for example an explosion that runs too slowly, supplier EDI that keeps failing, a MES integration that breaks with every release, or a hybrid kanban/MRP flow that causes stock shortages. We audit the architecture, API calls, error handling and data quality, document the current setup and propose improvements. From there, we can take on adjustments, extensions and ongoing support, or work alongside your existing ERP partner where that makes sense.