Aptean catch weights need unit-and-invoice controls

Keep counted units and measured weight together

The direct answer is that a catch-weight record needs two controlled quantities rather than one overwritten number. Preserve the food item and variant, item and lot identifier, package or container identity, counted unit and quantity, measured-weight unit and value, gross, tare and net basis where used, capture time, facility and operation, responsible user or device, status, and linked order, shipment and invoice line. A case count cannot stand in for the actual weight on which a variable-weight sale may depend.

Define which quantity controls inventory handling, customer ordering, pricing, and billing for each item and commercial arrangement. Pieces, cases, pallets, pounds, kilograms, and other units should have explicit meanings and precision. If a package is split, repacked, reweighed, returned, or corrected, retain the prior measurement and relationship to the new commercial record. This narrow control is not a recall-scope, product-genealogy, recipient-reach, or mass-balance analysis.

Govern scale capture, tare, conversion, and rounding

For each measurement, retain the scale or capture source, device and interface identifier, configuration and unit, gross and tare method, manual-entry flag, operator, timestamp, precision, rounding rule, and exception. Where calibration, verification, or maintenance applies under the organization's program, link the measurement to the relevant equipment status without inferring accuracy from the presence of an interface. A populated weight field is not proof that the correct product, package, unit, or tare was used.

Conversions need effective-dated rules. Store the entered value, source unit, target unit, conversion factor, rule version, rounding point, resulting value, tolerance, and reason for any override. Do not recompute a historical commercial record silently when a default pack size, conversion, precision, or scale configuration changes. Corrections should create a visible superseding event and identify which order, shipment, price, or invoice artifact must be regenerated or reviewed.

Freeze the pricing basis on the invoice artifact

The order and invoice should state whether price is based on counted units, measured weight, a declared weight, a minimum or range, or another agreed commercial rule. Preserve the contract or price-list reference, currency, unit price, captured weight, allowed variance, calculation sequence, taxes or charges handled by their owning rules, invoice quantity, line amount, correction status, and artifact version. A visually plausible total can still use the wrong unit or measurement event.

Later operational changes must not rewrite what the customer received. If reweighing, an accepted variance, a data correction, return, credit, or rebill changes the commercial result, keep the original invoice and issue the appropriate linked artifact with an accountable reason and time. Reporting should distinguish physical counts, captured weights, priced weights, and invoiced weights so users do not combine unlike measures in one unlabeled quantity column.

Test one variable-weight order from scale to invoice

A representative evaluation should order several cases of one item, capture different net weights, receive one weight from the wrong scale unit, apply a tare correction, take one scale offline, split a package, change a conversion rule after shipment, and generate a credit and rebill. Reviewers should reproduce every counted and measured value, capture source, conversion, rounding result, pricing basis, exception, invoice version, and later correction without invoking recall, genealogy, reach, disposition, or mass-balance logic.

Aptean's official page supports the attributed positioning about lot- and item-level catch weights, scale calculations, catch-weight values through invoicing, and food-product variations. It does not establish a customer's item definitions, scale accuracy, tare method, conversion, tolerance, price, tax, invoice correctness, accounting treatment, traceability, food safety, compliance, or outcome. Food Traceability Ledger did not independently test the software.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Food Traceability Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.