# AI Agents for SAP Production Planning, MRP, and Exception Triage > Source: https://netray.co/erp-ai/sap-production-planning-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer A planner running SAP MRP typically opens MD04 to a wall of exception messages with no ranking beyond the default sort order. An AI agent grounded on the same MRP data can group and prioritize those exceptions, explain a predictive MRP shortage in plain language, and draft the planned-order or purchase-requisition action for the planner to approve, without ever changing an order on its own. ## Kind use-case ## Erp Family sap ## Erp Products - SAP S/4HANA - SAP ECC 6.0 ## Industries - Manufacturing - Automotive - Electronics - Industrial Equipment ## Region Global ## Persona Supply Chain Director ## Eyebrow SAP PP/MRP + AI agents ## Intro Every SAP shop running MRP has the same daily ritual: a planner opens MD04, scrolls a stock/requirements list full of exception messages, reschedule-in, reschedule-out, missing parts, excess coverage, and decides in their head which ones actually matter today. That triage is real expertise, built up over years of knowing which exception codes are noise for this plant and which ones predict a line-down event next week. It does not scale past the handful of senior planners who have it. Predictive MRP was supposed to help by simulating shortages before they become firm exceptions, but a simulative shortage message is not self-explanatory. A planner still has to dig into why the simulation flagged it, which consumes the same demand or supply element, before deciding whether to act early or wait. Most planners we talk to say pMRP tells them something is wrong without telling them why, which limits how much they trust it. As a Supply Chain Director, the cost of this shows up in two places: planners spending their time on manual triage instead of the judgment calls that actually need a human, and exceptions that get missed because there were simply too many to work through before the next MRP run overwrote the list. Neither problem is solved by running MRP more often or adding more exception messages. This page describes a narrower, more concrete fix: an AI agent that reads the same MD04/MD05 exception data, PLAF planned orders, and pMRP simulative results your planners already look at, ranks and explains them in plain language, and drafts the specific action, convert this planned order, expedite this PO, adjust this safety stock, for a planner to approve. It does not run MRP differently or replace the planner's judgment. It removes the manual reading and typing between the exception appearing and the decision getting made. ## Pain Points ### MD04 exception volume outpaces planner capacity **Detail:** A mid-size plant can generate hundreds of exception messages across a single MRP run, and the standard MD04 view offers no ranking beyond material and plant, so planners default to working the list top to bottom or relying on memory for what usually matters. ### Exception codes require tribal knowledge to interpret **Detail:** Knowing that exception code 05 (reschedule to earlier date) matters more for a bottleneck work center than for a low-runner part is not written down anywhere in SAP. It lives in the head of whoever has been planning that material family the longest. ### Planned order conversion and firming is manual and repetitive **Detail:** Reviewing a batch of PLAF planned orders, checking capacity and material availability, and converting the right ones to production orders is a mechanical task planners do by hand every day, one order at a time. ### Predictive MRP output is hard to trust without an explanation **Detail:** A simulative shortage in the Monitor Predictive MRP app tells you a demand element is at risk, not why, so planners often ignore pMRP signals until they become firm exceptions anyway, which defeats the point of running it predictively. ### Supplier expedite requests are written from scratch every time **Detail:** When a purchase requisition or PO is at risk of missing a required date, someone has to look up the vendor, the PO history, and the required date, then write an expedite email, a task that adds no judgment beyond what SAP already knows. ## Use Cases ### MD04 exception triage and prioritization **Description:** Each morning, the agent reads the current MD04/MD05 exception messages for a planner's material scope, groups them by likely business impact (customer order at risk, bottleneck work center, low-runner part), and presents a ranked list with a one-line rationale for each. **Erp Objects:** MD04 stock/requirements list, MD05 MRP list, exception message codes, MRP controller assignment **Outcome:** Cuts the time a planner spends scanning the raw exception list before deciding what to work on first, without changing which exceptions exist. ### Planned order review and conversion drafting **Description:** The agent reviews the current batch of planned orders against capacity and material availability, and drafts a recommended list of which to convert to production orders now versus hold, for the planner's sign-off. **Erp Objects:** Planned orders (table PLAF), capacity leveling data (CM01/CM07), material availability **Outcome:** Turns a one-by-one manual review into a single batch decision the planner confirms, typically in a fraction of the original time. ### Predictive MRP shortage explanation **Description:** When the Monitor Predictive MRP app flags a simulative shortage, the agent explains in plain language which demand and supply elements are driving it and how confident that projection is given recent consumption patterns. **Erp Objects:** Predictive MRP simulative materials, demand and supply elements, consumption history **Outcome:** Gives planners a reason to act on a pMRP signal before it becomes a firm exception, closing the gap between prediction and trust. ### Supplier expedite drafting **Description:** For purchase requisitions or orders at risk of missing a required date, the agent drafts an expedite email referencing the specific PO, line, quantity, and required date, for the buyer to send. **Erp Objects:** Purchase requisitions (ME51N), purchase orders, vendor master, required delivery dates **Outcome:** Removes the manual lookup-and-write step from an expedite request that a buyer would otherwise start from a blank email. ### Capacity overload summary for the production meeting **Description:** Before the daily or weekly production meeting, the agent summarizes which work centers are overloaded, by how much, and which orders are contributing, in plain language rather than a raw capacity leveling screen. **Erp Objects:** Capacity planning table (CM01/CM07), work center master, order operations **Outcome:** Replaces a manually prepared capacity slide with a grounded summary the production planner edits rather than builds from the raw data. ### BOM and routing exception flagging before the MRP run **Description:** The agent flags materials where a recent BOM or routing change looks inconsistent, a missing component, an unusually long lead time, before the next MRP run propagates the issue into dozens of downstream shortages. **Erp Objects:** Material BOM (CS03), routing (CA03), recent engineering change records **Outcome:** Catches a class of shortages at the source rather than after MRP has already generated exceptions across every affected order. ### Safety stock and reorder point review **Description:** Using recent consumption history against current MRP1-MRP4 settings, the agent suggests specific safety stock or reorder point adjustments with the reasoning shown, for the planner to approve and apply through the normal material master change. **Erp Objects:** Material master MRP views (MRP1-MRP4), consumption history, MRP controller **Outcome:** Turns an occasional, ad hoc safety stock review into a routine, data-backed suggestion the planner acts on or dismisses. ## Architecture **Overview:** The agent sits alongside SAP, reading MRP, capacity, and material master data through standard connectors, and never runs MRP itself or changes a planned order without a planner's explicit action. Five layers keep that boundary clear and auditable. **Layers:** #### ERP connectors **Detail:** Read access to MD04/MD05 exception data, PLAF planned orders, and capacity leveling tables via OData services and CDS views on S/4HANA, or RFC/BAPI reads on ECC 6.0, through a scoped service user. #### Data and semantic layer **Detail:** Exception codes, capacity terms, and material groupings are mapped to the language your planners actually use, so a question about which orders are at risk this week resolves to the right combination of exception codes and dates. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on your own GPUs or in a private cloud tenant, sized to the query volume of a planning team rather than an enterprise-wide deployment. #### Retrieval and agents **Detail:** Multi-step agent workflows for triage, conversion drafting, and expedite drafting, each producing a proposed action and its supporting data rather than executing anything directly. #### Governance and audit **Detail:** Every recommendation is logged with the data it was based on. Converting a planned order, changing a safety stock value, or sending an expedite email always requires the planner or buyer to take the action themselves in SAP. ## Deployment Options ### Air-gapped on-prem **Fit:** Plants supplying defense or regulated programs where MRP data itself is sensitive, or any site with a strict no-outbound-internet policy for production systems. **Detail:** Model and connector run entirely inside the plant network, with the same no-external-call guarantee as the rest of this surface. ### Private or sovereign cloud **Fit:** Multi-plant operations without GPU capacity at every site, or where centralizing the AI layer for several SAP instances is more practical than deploying per site. **Detail:** A dedicated tenant serving multiple plants' MRP data, still isolated from public model APIs, with per-plant authorization scoping preserved. ### Hybrid **Fit:** Organizations piloting at one plant before deciding on a standard deployment pattern. **Detail:** Start on-prem at a single site to prove the connector and exception taxonomy, then move to a shared private cloud instance once the pattern is validated across plants. ## Compliance ### You choose where the model and data live, on-prem or a private cloud region you control, so MRP and cost data never crosses a border you have not approved, relevant for multinational operations with regional data rules. **Framework:** Data residency and sovereignty ### The AI layer's service account is scoped the same way a planner's SAP role would be, plant by plant and MRP controller by MRP controller, so it never surfaces data a given user could not already see in MD04. **Framework:** SAP authorization concept ### For plants with export-controlled work mixed into the same SAP instance, the connector can exclude ITAR-flagged materials and orders from the AI layer's scope entirely, or the whole deployment can run air-gapped as described above. **Framework:** ITAR / EAR (where the plant supplies defense programs) ### Because no action is taken automatically, the existing SAP change document trail for planned order conversions, safety stock changes, and PO updates remains the system of record; the AI layer adds a log of what it recommended and why, alongside it. **Framework:** Change and audit logging ## Integration Notes MD04/MD05 exception data and PLAF planned orders are read via CDS views or RFC/BAPI calls, refreshed on a schedule that matches your MRP run cadence rather than polling continuously. Predictive MRP simulative data is read from the same tables the Monitor Predictive MRP Fiori app uses, so the agent's explanation matches what a planner sees in that app. Capacity leveling reads from CM01/CM07-equivalent tables; work center master data is cached and refreshed less frequently since it changes rarely. Converting a planned order, changing a safety stock value, or updating an MRP controller assignment all require the planner to execute the change in SAP directly; the agent never calls a write BAPI on its own. The same architecture supports ECC 6.0 via RFC/BAPI where S/4HANA-specific OData services are not available. Multi-plant deployments scope the connector per plant and MRP area, so a single instance can serve several plants without mixing their planning data. Custom Z-tables used for plant-specific exception logic can be incorporated into the semantic layer during discovery, they are common in mature SAP PP implementations and worth surfacing early. ## Product Fit ### ERPray **Why:** Natural-language question answering over MRP exceptions, capacity, and planned order status is ERPray's core pattern, deployed against your SAP PP data on-prem or in a private tenant. ### Custom build **Why:** Multi-step agent workflows, exception triage with ranking logic, conversion drafting, expedite drafting, are built around your plant's specific exception taxonomy and approval process. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Exception taxonomy workshop with senior planners to capture the judgment that currently lives in their heads - SAP PP/MRP data and authorization review for the target plant or MRP area - Prioritized use case list, typically triage first, conversion drafting and expedite drafting next - Deployment sizing against available GPU capacity ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Exception triage and ranking live for one MRP area or planner group - Accuracy validation against the same planners' own judgment on a sample of historical exceptions - Predictive MRP explanation feature tested against a set of known past shortages - Go/no-go review with measured time saved per planner per week ### Production **Duration:** 8-10 weeks **Deliverables:** - Rollout across the full planning team for the pilot plant - Conversion drafting and expedite drafting added with planner approval workflows - Integration into the existing daily/weekly production meeting reporting ### Scale **Duration:** Ongoing **Deliverables:** - Extension to additional plants and MRP areas - Safety stock review and BOM/routing exception flagging added as later-phase use cases - Periodic re-tuning as exception taxonomy and plant priorities evolve ## Buyer Questions - How does the system rank exceptions, and can our senior planners review and adjust that ranking logic directly? - Does the agent ever convert a planned order, change a safety stock value, or send a supplier email without a person approving it first? - How is accuracy validated, against what set of historical exceptions, and by whom? - Can the system explain a predictive MRP shortage in terms our planners already understand, not just flag it? - How does the deployment handle multiple plants or MRP areas on the same SAP instance without mixing data across them? - What happens to the recommendation log if a planner disagrees with the agent, is that disagreement captured anywhere? - Can this run entirely on our own infrastructure with no external network dependency? - What is the actual time-saved measurement from the pilot, not a projected estimate? ## Faq ### Will this change how SAP runs MRP? **Answer:** No. MRP runs exactly as it does today. The agent reads the exceptions and planned orders MRP already produces and helps a planner triage and act on them faster. It does not change MRP logic, live cache settings, or scheduling. ### Can it convert planned orders automatically? **Answer:** By default, no. It drafts a recommended batch of conversions with its reasoning, and a planner reviews and executes the actual conversion in SAP. Automatic conversion can be scoped in later for low-risk, high-confidence cases if your team wants that, but it is never the starting point. ### How does it handle predictive MRP differently from standard MRP exceptions? **Answer:** It reads the same simulative shortage data the Monitor Predictive MRP app surfaces and adds a plain-language explanation of which demand and supply elements are driving the projected shortage, so a planner can judge whether to act early rather than wait for it to become a firm exception. ### Does this require a separate MRP run or extra system load on SAP? **Answer:** No, it reads existing MRP output on a schedule matched to your normal MRP run cadence rather than triggering additional runs or continuous polling, so the load on your SAP system is minimal. ### How accurate is the exception ranking compared to a senior planner's judgment? **Answer:** Accuracy is validated during the pilot against your own planners' historical decisions on a sample of past exceptions, not against a generic benchmark, since what counts as a priority exception varies by plant and material family. ### Can this work across multiple plants on one SAP instance? **Answer:** Yes, the connector is scoped per plant and MRP area using the same authorization boundaries SAP already enforces, so a multi-plant instance can be served without one plant's planners seeing another's data. ### What is the realistic first outcome from a pilot? **Answer:** Most pilots target a measurable reduction in the time planners spend manually scanning and prioritizing the MD04 exception list each day, since that is the highest-volume, most repetitive part of the job and the easiest to validate against a before-and-after time measurement. ## Search terms SAP MRP AI, SAP MD04 AI, SAP production planning AI, SAP AI agents, SAP PP AI integration, SAP predictive MRP AI, SAP copilot production planning, on-prem AI for SAP MRP, SAP AI exception management, SAP planned order AI, SAP generative AI supply chain, SAP AI for supply chain director --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json