# How to Design Scrap and Downtime Reason Codes for MES and ERP > Source: https://netray.co/erp-help/mes-scrap-downtime-reason-codes-erp-mes > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Keep one governed list of reason codes with a small hierarchy, owned in a single system and synchronised to the other. Separate scrap reasons from downtime reasons, mark each downtime code planned or unplanned and each scrap code as process, material, design or operator related, and map codes to ERP accounts or cost categories where accounting needs them. Fewer, clearer codes beat long lists nobody uses correctly. ## Kind how-to ## System mfg-systems ## Erp MES and ERP ## Module Scrap and Downtime Reason Codes ## Query how to design scrap and downtime reason codes in MES and ERP ## Alternate Queries - scrap reason codes list manufacturing ERP - downtime reason code hierarchy MES - sync scrap reason codes between MES and ERP - how many downtime reason codes should we have ## Applies To Any MES and ERP pair; examples reference typical ERP scrap, reject and indirect labor structures in SyteLine, LN, M3, SAP, NetSuite and Dynamics ## Steps ### How to build a usable reason code set **Items:** - Decide the purpose: root cause analysis, cost allocation, OEE loss classification, or all three. This drives how detailed and how structured the codes must be. - Create separate lists for scrap (and rework) and for downtime. They have different owners and different downstream systems. - Use a two or three level hierarchy, such as category, reason, and optional detail. For downtime: planned vs unplanned, then equipment, material, labor, quality, or changeover, then specifics. - Mark attributes on each code: planned or unplanned, whether it counts against OEE availability, whether it is scrap or rework, and whether it triggers a quality record such as an NCR. - Name one master system for the list, usually the one finance trusts, and sync to the other with stable code IDs. Never let each system invent its own codes. - Map codes to ERP structures: scrap reasons to reject or scrap reason fields and cost accounts, downtime to indirect labor codes or cost centers where policy requires. - Limit what operators pick: show only codes valid for the machine and operation, and require a choice rather than defaulting to Other. - Review monthly: look at the share of Other, rarely used codes and duplicates, and retire or merge them through a change-controlled process. ## Sections ### Scrap codes: what the data must support **Body:** Scrap codes serve two audiences. Finance needs to know where the cost lands, so codes should map to accounts or cost categories (for example material defect from a supplier versus operator error). Quality and engineering need cause categories to drive corrective action: dimensional, surface, material, tooling, setup, handling, design, and so on. Record scrap with the operation where it was found and, if known, where it was caused. Those are often different steps, and for cost and root cause analysis you want both. In regulated industries, link scrap above a threshold to a nonconformance record so the reason code is not the only trace. ### Downtime codes and OEE **Body:** Downtime codes feed OEE and continuous improvement. The most important split is planned versus unplanned, because it determines what counts against Availability. Within unplanned, separate equipment failure, waiting for material, waiting for operator, quality hold, and changeover, since each is fixed by a different team. Where possible, capture the reason automatically or semi-automatically. A machine alarm code can pre-fill the equipment category, leaving the operator only to confirm. This cuts the amount of Other and keeps timestamps accurate. Prompt for a reason after a stop exceeds a minimum duration to avoid drowning operators in micro-stop entries. **Code:** Downtime hierarchy example PLANNED PM Preventive maintenance CO Planned changeover BRK Breaks / meetings UNPLANNED EQ-ELEC Equipment: electrical EQ-MECH Equipment: mechanical MAT-WAIT Waiting for material LAB-WAIT Waiting for operator QC-HOLD Quality hold / inspection CO-OVR Changeover overrun ### Governance and synchronisation **Body:** Reason codes decay without ownership. Assign an owner for each list, a change request process, and an effective date for edits so history is not rewritten. Deactivate rather than delete codes, because old records still reference them. Synchronise by code ID, not by description text. Descriptions are translated, reworded and corrected; IDs are what the integration keys on. If you operate multilingual plants, store translations against the same ID so reporting stays consistent across sites. ### Common design mistakes **Body:** Too many codes is the usual failure. Operators facing 200 choices on a touchscreen pick the first plausible one, or Other. Aim for a short list per machine type, typically a few dozen at most, with detail captured in a free text note only when the code requires it. The second failure is mixing categories, for example a single list where Setup, Broken tool and Waiting for forklift all sit at the same level and cannot be rolled up. A hierarchy with clear attributes makes the same data usable for operators, supervisors and finance. ## Pitfalls - Letting MES and ERP each maintain their own code lists, so reports never reconcile. - Hundreds of codes, which drives operators to choose Other. - Mixing planned and unplanned reasons without an attribute, corrupting OEE availability. - Deleting old codes, which breaks historical records and reports. - Synchronising on description text rather than a stable ID. - Recording scrap only where found, not where it was caused. ## Ai Angle Once reason codes are consistent, a grounded assistant can summarise them: top scrap causes by item and operation, downtime Pareto by line, or the share of Other by shift, with the query visible and ERP roles respected. ERPray can also point out likely duplicates or sparsely used codes for a human to review. It does not decide your classification policy or change the master list on its own. ## Faq ### How many downtime reason codes should we have? **Answer:** Enough to drive different actions, and no more. A hierarchy with roughly 8 to 12 top-level categories and a short detail list under each works for many plants, and operators should see only the relevant subset per machine. If a code never leads to a different decision, merge it. ### Should the ERP or the MES own the reason code list? **Answer:** Whichever system your finance and quality teams already govern, which is often the ERP for scrap and the MES for downtime. What matters is a single owner per list, stable IDs, and one-way sync to the other system. ### Do scrap reason codes need to post to specific accounts? **Answer:** Often yes. Many companies map scrap categories to different variance or scrap accounts so finance can separate supplier defects from process or operator scrap. Agree the mapping with accounting before go-live, because changing it later restates history. ### How do I stop operators choosing Other? **Answer:** Show a short, machine-specific list, pre-fill what you can from machine alarms, require a selection before the next order can start, and review Other entries weekly with supervisors so common ones become real codes. Pressure alone does not fix a list that does not fit the work. ## Search terms scrap reason codes, downtime reason codes, reason code hierarchy MES, planned vs unplanned downtime, scrap codes ERP mapping, MES ERP reason code sync, OEE loss categories, downtime Pareto, reject reason codes manufacturing, reason code governance --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json