Supplier MOQ & Order Multiple Preflight

Catch minimum-order and case-pack mistakes before releasing a purchase order. Supply one normalized order and its current supplier rules. Get an exact exception list, order-net-value shortfall, and the smallest non-decreasing quantity satisfying each supplied MOQ and order multiple.

What it checks

• Minimum order quantity (MOQ), zero-anchored order multiples and optional maximum quantities
• Either each order line separately (LINE) or the combined exact SKU and unit within the order (SKU_TOTAL)
• The minimum merchandise net value for one order, supplier and currency
• Missing quantity rules, incompatible units and unused supplied rules
• Whether quantity corrections have a feasible solution without reducing current quantities

For example, an order quantity of 17 with MOQ 24 and an order multiple of 12 produces a review suggestion of 24, an increase of 7. A MOQ of 25 with a multiple of 12 produces 36, not 25 or 37. If the supplied maximum is 30, no such non-decreasing solution exists and the suggestion is null.

Quick start

1. Use the example in the Input tab, or map your ERP/spreadsheet export to the JSON contract below.
2. Confirm whether the supplier applies quantities per line or per combined SKU and unit. Select that scope explicitly.
3. Set coverageConfirmed to true only after confirming the supplied order lines and rules are complete, current and applicable to this order.
4. Run with a maximum charge of $0.05. Open the dataset for the complete report, or REPORT in key-value storage.

This version accepts JSON text in caseJson. It does not read an ERP, parse purchase-order PDFs, scrape supplier terms, or directly import spreadsheets.

Input contract

All fields listed here are required except maximumQuantity.

• caseId, orderId, supplierId: opaque string references
• currency: exactly three uppercase ASCII letters; a label, not a live currency-registry lookup
• coverageConfirmed: boolean
• quantityRuleScope: LINE or SKU_TOTAL
• minimumOrderNetValue: nonnegative plain decimal string, such as "100"; use "0" when no minimum applies
• lines: 1–1,000 rows, each with unique lineId, sku, unit, positive quantity and nonnegative unitNetPrice
• quantityRules: 0–1,000 rules, each with sku, unit, nonnegative minimumQuantity, positive orderMultiple and optional positive maximumQuantity

Quantities and prices must be decimal strings with at most 18 integer and 8 fractional digits. Do not use JSON numbers, exponents, commas, currency symbols, numeric leading zeros or negative values. Leading zeros in identifiers remain valid. Unknown fields, duplicate JSON keys and duplicate rule identities are rejected. The input is limited to 1 MiB.

Identifiers preserve case, leading zeros and whitespace. SKU and unit must match exactly; no fuzzy matching or unit conversion occurs. For an unrestricted item, supply an explicit zero MOQ and an order multiple matching its smallest permitted quantity increment. A missing rule is unknown, not unrestricted.

How the calculations work

• Order multiple: an integer multiple of the supplied orderMultiple, measured from zero. It is not an increment above the MOQ.
• Quantity suggestion: the least multiple greater than or equal to both the current scoped quantity and MOQ, provided it does not exceed the optional maximum. It is a mathematical review candidate, not a recommended purchase.
• Net order value: the exact sum of quantity × unitNetPrice in the header currency. Prices must already be per one stated unit and net of line discounts. Taxes, freight, other charges, order-level discounts, exchange rates and price tiers are excluded.
• Incremental net cost: the proposed increase multiplied by the supplied per-unit net price. For a combined SKU group with different prices, the allocation is ambiguous and this cost is null. Quantity changes can also change commercial prices; this Actor does not estimate that effect.

Amounts are exact decimal strings, not rounded to currency minor units. It does not choose items or quantities to close a minimum-order-value gap.

Results and review status

One dataset record contains groupResults, lineResults, findings, totals, policyApplied and limitations.

• READY_WITHIN_SUPPLIED_RULES: the supplied scope has no blocking issue
• ACTION_REQUIRED: one or more supplied quantity or order-value controls fail
• INCOMPLETE_REVIEW: coverage is unconfirmed or an applicable rule is missing

Unused rules remain visible. Review all findings even when the status is ready. orderApproved is always false. The Actor never approves, submits, changes or contacts anyone about an order.

Pricing and billing boundaries

$0.05 per completed report ($50 per 1,000 reports). Reports containing exceptions or incomplete coverage are completed, billable reports. Malformed inputs and budgets below one report produce no charged report event. There is no configured startup charge. Check the live Pricing tab before running.

The primary deliverable is the dataset report saved with its report event. REPORT and OUTPUT are convenience records written afterward. An interrupted run can have a saved dataset and incomplete convenience records. If the same run is restarted with an identical saved report, the Actor recreates those records without pushing or charging another report; conflicting existing output stops for review. This safeguard does not claim transactional recovery of an interrupted platform charge. A new run of the same input is a new billable report.

Privacy and limitations

The core makes no network requests and uses no AI, OCR, paid API, ERP credentials or supplier credentials. Processing and storage occur in the user's Apify run, subject to its retention and sharing settings. Use opaque business identifiers; omit contacts, employee names, addresses, bank information and other unrelated data. Raw order rows and prices are not logged.

This is a rule-based data review. It does not validate supplier terms, inventory needs, price availability, regulatory compliance, contract interpretation or commercial approval. Validate rule applicability, units, scope and price basis before relying on it. For support, provide a small synthetic input, expected result and run ID.

Reference basis

• Microsoft documents supplier MOQ rules and the distinction between planned and manually created POs: https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/source-from-multiple-vendors
• SAP describes operational consequences of supplier minimum-order restrictions: https://help.sap.com/docs/PRP/35430eca001c452ea8202e8f60958910/0a9235b749d549b3b2db2c47016e4c94.html

These sources establish the workflow need. This Actor uses the explicit rules you supply and is not affiliated with or a replacement for those systems.