How weighbridge to ERP posting works, step by step.

Why re-typed tickets are the problem

The weighbridge is usually accurate. The copying is not. Tickets pile up in the office, someone keys them into goods receipts and delivery notes at the end of the day, and month-end reconciliation becomes a hunt for the ones that were mistyped, skipped or entered twice. A direct integration removes the copying step: the transaction that prints the ticket is the transaction that lands in the ERP.

Master data flows from the ERP to the bridge

Integration starts in the opposite direction from what most people expect. Suppliers, customers, items and open purchase and sales orders are pulled from the ERP and offered as pick lists at the weighbridge. The operator, or the ANPR match on an unmanned lane, chooses from those lists and cannot invent a name or item code the ERP will not recognise. That is what makes the posting later succeed without manual fixing.

• Suppliers and customers, with their ERP codes
• Items or commodities, with units of measure
• Open purchase orders and sales orders, so a weighing can be tied to the document it fulfils
• Vehicles and transporters, where the ERP holds them

The posting sequence

• The transaction completes at the bridge. The second weight locks the net, the ticket prints, and the record is written to the local database first. The bridge never waits on the network.
• It is queued in an outbox. Each completed transaction joins a posting queue. If the ERP is reachable it posts within seconds; if not, it waits in order.
• The ERP acknowledges. The ERP's document number comes back and is stored against the ticket. A rejection is recorded with its reason and surfaced for the office to fix; it never blocks the transactions behind it.
• Nothing posts twice. Every transaction carries a stable identifier, so a retry after a network failure updates the same ERP record rather than creating a duplicate.

What the ERP receives

With that payload the ERP can raise the document itself: a goods receipt against the purchase order for an inbound load, or a delivery against the sales order for an outbound one. The weighbridge does not need to know the ERP's accounting rules; it supplies the facts and the reference.

When the ERP or the network is down

The bridge keeps weighing and printing. Completed transactions stay in the outbox and post when the ERP is reachable again, in order and without duplicates. The office sees the queue length and any rejections in the dashboard, so a link that has been down since morning is noticed before month-end.

Which systems, and where the integration runs

KiloSahihi integrates with Sage X3, Microsoft Dynamics 365, Odoo and SAP out of the box, and with in-house and custom systems through their APIs or a database staging table. The integration runs inside the weighbridge software on the PC at the bridge, so there is no separate middleware server to keep alive. Multi-site sync into one cloud dashboard is an optional add-on, never a requirement.

What to prepare before go-live

• Agree the mapping: which ERP field each weighbridge field lands in, and which document type an inbound and an outbound weighing raise.
• Clean the codes: supplier, customer and item codes in the ERP must be the ones the bridge will pick from.
• Decide the unit of measure and how deductions such as moisture or foreign matter are carried, on the ticket, in the ERP, or both.
• Name the person who clears rejections, and how they are notified.
• Run in parallel for a period: post to the ERP while the old ticket books continue, then reconcile the two.