Hapacta turns high-rate machine telemetry into ERP production-order transactions that post exactly once — and clear the first time.
Machines produce telemetry continuously — thousands of samples a second. An ERP records production as discrete, costed transactions that each either clear or fall to an error queue. Between the two sits a mismatch most plants never close.
Forward raw events one-to-one and you flood the ERP. Batch them and you lose the true count. Neither yields one posting per real physical event.
Conventional integrations post first and let failures drop into a goods-movement error queue — COGI — for manual rework, order by order.
So plants confirm at end of shift, at standard. The books still tie — but variance is now a period-end residual that names no order, line, or lot.
That's the trap. A book-to-physical true-up squares the ledger at period end whether or not a single source-level actual was ever captured. Nothing in the close signals the gap.
So the cost system quietly stops being an attribution engine and becomes a reconciliation engine. Variance is no longer measured where it happens — it's computed at the end, by subtraction.
The residual is numerically real and causally mute. It tells you that you lost margin — not where, not on which order, line, shift, or lot.
Hapacta sits between the machine and the ERP. It decides what a real event is, and proves a transaction will clear — before anything posts.
A deterministic engine reads signal features — vibration energy at a machine's resonance, drive current, counts, mass, flow — and detects the boundary of each real production event. Each boundary emits exactly one candidate transaction, stamped with an idempotency key that guarantees it posts once, even across a restart.
Before a candidate reaches the ERP, it's checked against current state: component-to-operation assignment, on-hand at the issuing storage location, order status, posting period, unit of measure. What would clear is admitted. What can be repaired is repaired. The rest is quarantined — never dropped into the ERP's error queue.
What posts is correctly counted, and guaranteed to clear.
Hapacta runs as an edge node between the controls layer and the ERP, alongside whatever connectivity, historian, and MES you already operate.
Optional modules bind a telemetry-derived actual cost to each transaction and reconcile telemetry-derived quantity against the posted ledger.
Same event stream, same failure rate. The only difference is when the check happens.
Plenty of tools move machine data to an ERP. Hapacta is built around what happens to the transaction itself.
One posted transaction per true physical event — not aggregation for throughput, but fidelity of the record to what actually happened on the floor.
The clearing check runs at the edge, before transmission. Error-queue rework drops because the errors never post in the first place.
Boundaries come from threshold and state rules keyed to the machine's physics — not a trained model. Auditable, repeatable, explainable.
Bind a telemetry-derived actual to the transaction as it posts. Cost stops being a residual computed by subtraction at period end.
Posts through BAPI, IDoc, OData, or REST. The integrity layer doesn't depend on any one vendor's mechanics.
Segmentation runs on the high-volume stream itself, at the work center — not on a sampled summary pulled after the fact.
Hapacta is a patent-stage technology with a provisional application in preparation. Two ways to start:
High-volume line, recurring error-queue rework, or costing you can't trace to the order? Let's scope a pilot on one work center.
Start a pilot conversation →Building in the MES, plant-connectivity, or ERP-integration space? The integrity layer is available to discuss for licensing.
Open a licensing discussion →