# Division by 0 Error in Sage X3: Find the Cause and Fix It > Source: https://netray.co/erp-help/division-by-0-error-sage-x3 > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A division by 0 error in Sage X3 means a calculation divided by a field that was zero or empty at runtime. Typical sources are a zero unit-of-measure coefficient, a zero quantity or base quantity on a BOM or routing, a zero price or rate, or custom 4GL or report code that never guards the denominator. Find the script and line from the error, then fix the data or guard the calculation. ## Kind error ## System sage ## Erp Sage X3 ## Module Adonix 4GL / Reports / Calculations ## Query division by 0 error sage x3 ## Alternate Queries - sage x3 division by zero - sage x3 error division by 0 script - x3 divide by zero report ## Applies To Sage X3 V7, V11, V12 and later; standard processes, custom Adonix 4GL scripts and report formulas ## Steps ### How to diagnose and fix it **Items:** - Note exactly where it happens: which function, button, batch task or report, and the record being processed. - Read the error dialog or the batch task log for the script name and line number; the 4GL runtime reports the program and line where the division occurred. - Open that script in the development environment (Developer Studio or the script editor in your version) and read the expression at the reported line. - Identify the denominator, then check its value on the record involved: a conversion coefficient, a base quantity, a quantity, a rate or a count. - If standard code is failing, the cause is almost always bad data: correct the zero or empty field (for example an item unit coefficient or BOM base quantity) and retry. - If custom code is failing, add a guard before the division and decide what the result should be when the denominator is zero. - For report formulas, wrap the expression so a zero denominator returns zero or blank rather than failing. - Retest with the original record, then with other records that have zero values, and confirm the batch continues. ## Sections ### The usual data causes **Body:** In standard flows, the failure is usually a master data hole. Common offenders are a unit of measure conversion with a zero or missing coefficient, a BOM header with a zero base quantity, a routing operation with a zero rate or quantity, a currency or tax rate record that is zero, and a costing step dividing by produced quantity when nothing was produced. The record that triggers it is often new: an item created with incomplete units, an imported BOM, or a work order closed with zero output. Look for the most recent master data change before the first failure. ### Custom code and reports **Body:** Customizations and custom reports are the other major source. A ratio, percentage or average that works on test data fails on the first record with a zero denominator. Review customer-specific scripts that run in batch, in costing or in statistics, and report layouts that compute margins or per-unit values. The guard is simple, and the real decision is what a zero denominator should mean to the business: zero, blank, or a stop with a clear message. Write that decision down in the code comment. **Code:** - # Adonix 4GL style guard (adapt names to your code) If [F:XYZ]QTY <> 0 Local Decimal RATIO RATIO = [F:XYZ]AMOUNT / [F:XYZ]QTY Else RATIO = 0 Endif ### Finding the bad records in bulk **Body:** Rather than waiting for the next failure, query for zero denominators before the batch runs. Sage X3 tables carry a suffix on columns (for example _0), and you can query the folder schema read-only to find zero values. **Code:** - -- Example pattern; table and column names are illustrative, confirm in the dictionary SELECT ITMREF_0, BASQTY_0 FROM SEED.BOM_EXAMPLE WHERE BASQTY_0 = 0; ## Pitfalls - Patching the symptom in standard code instead of fixing the master data. - Guarding the division but silently returning zero where the business expects an error. - Testing only with clean records, so zero cases appear in production. - Editing standard scripts directly instead of using the supported customization mechanism, which is overwritten on upgrade. - Ignoring batch logs, where the script name and line are often recorded. ## Ai Angle Once you know the script, the slow part is finding which records hold a zero denominator. A private AI layer such as SyteRay-style assistants grounded in your X3 dictionary can search for zero coefficients, base quantities and rates across tables, and propose a guard for custom code, with a human reviewing every change before it is applied. ## Faq ### Is division by 0 a bug in Sage X3? **Answer:** Rarely. Most cases come from missing or zero data such as unit coefficients or base quantities, or from custom code and reports without a guard. Occasionally a standard process fails on an edge case, in which case check release notes and raise it with your reseller. ### Where do I find the script that failed? **Answer:** The error dialog or batch task log normally names the program and line. Open that script in the development tools for your version and read the expression. If nothing is shown, enable tracing for the user or task and reproduce the failure. ### Can I just ignore the error? **Answer:** No. The calculation stops and the transaction or batch may roll back or stop partway. Fix the data or guard the code so the process completes with a defined result. ### Does this also happen in X3 reports? **Answer:** Yes. Margins, averages and per-unit values computed in report layouts fail when the denominator is zero. Wrap the formula with a zero check or compute the value in the data query with a safe expression. ## Search terms division by 0 error sage x3, sage x3 division by zero, sage x3 runtime error, adonix division by 0, sage x3 uom coefficient zero, sage x3 bom base quantity, sage x3 report formula error, sage x3 batch error --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json