Integrations

ESAAB does not replace the ERP or the 3PL: it aligns them

Most healthcare institutions already have an ERP where purchasing and accounting live, and a logistics operator (3PL) that moves the freight. The problem is rarely a lack of systems; it is that those systems do not talk at the speed of the operation, and reconciling them ends up in spreadsheets and emails. ESAAB sits between those pieces as an operational layer that keeps them aligned.

Its role is to be the single operational source of truth: the place where consumption at the point of use, replenishment, reception and inventory are recorded once and reflected consistently across the rest. ESAAB does not take over purchasing or the accounting close —that stays in the ERP— nor does it move the freight —that stays in the 3PL—; it coordinates the flow so that none of those systems falls out of sync.

Inventory reconciliation and catalog mapping

ESAAB integrates with corporate systems so that operational inventory and accounting inventory tell the same story.

• Supported ERPs Integration with SAP, Oracle and Softland, as well as other corporate systems. The connection pattern adapts to whatever interfaces each institution has available.
• Inventory reconciliation against the corporate system ESAAB compares its operational inventory —the one that reflects real consumption and reception— against the stock reported by the corporate ERP, and surfaces the differences product by product. This lets the institution catch discrepancies early, instead of discovering them at the close.
• Catalog mapping and cross-references The same supply item often carries a different code in the laboratory, in the ERP and in the supplier's catalog. ESAAB maintains cross-references between those codings, so that each movement is automatically translated to the code each system expects, with no manual rewriting.

Coordinate orders and dispatches without re-keying

Connected supply prevents the same information from being typed again at every link in the chain.

• Orders that flow, not orders re-typed When consumption turns into a replenishment requirement, that requirement moves toward the purchasing process and the supplier without anyone re-typing it. Double data entry —and the transcription errors that come with it— is eliminated.
• Dispatches and reception aligned with the 3PL Dispatches coordinated with the logistics operator (3PL) reach ESAAB's reception with their associated information, ready to be validated by lot and expiry against the order. The dispatch status stays visible in a single layer, instead of being scattered across systems.

HTTP API, event notifications and file import

ESAAB offers several integration paths to match whatever each corporate system allows — from a modern API to a scenario with no interface available.

• 01 HTTP API HTTP interfaces so external systems can query and record operational information —products, stock, orders, receptions— programmatically. We describe integration patterns; the detailed specification is provided during implementation.
• 02 Event notifications (at concept level) As an integration goal, ESAAB aims to notify connected systems when a relevant event occurs —a closed reception, a generated requirement, a status change— so the rest can react without having to poll constantly. Where the scenario allows it, notifications are delivered by webhook; the concrete mechanism is defined during implementation.
• 03 Assisted file import For scenarios where the corporate system does not expose an API, ESAAB supports assisted file import (Excel) with prior validation. It is the same path used, for example, to feed inventory reconciliation with the ERP stock report.
• 04 Authentication and idempotency (at concept level) Each integration operates under its own access credentials, and operations are designed to be idempotent: resending the same message does not duplicate a movement or an order. It is a design principle that protects the consistency of the single source of truth.

Limits of the integration