Skip to content

Connecting Wholechain to Your ERP System

Integrating Wholechain with your ERP system involves two key decisions:

  1. How to map events between the two systems.
  2. When to send those events to Wholechain.

The event mapping is always done on an event-by-event basis, meaning each ERP event is aligned with its corresponding Wholechain event.
The main difference between integration approaches lies in when those mapped events are transmitted — either in real-time or in batches (pooled).

1. Event-by-Event Mapping

Every ERP system represents operational actions as discrete events — for example, Item Receipts, Inventory Adjustments, or Shipments.
To integrate with Wholechain, these must be mapped one-to-one with Wholechain’s event types.

Examples of common mappings:

  • Item Receipt → Receive Event

When goods are received into your ERP system, the same item should trigger a Receive Event in Wholechain.

  • Inventory Adjustment → Multiple possible outcomes:

  • If the adjustment represents processing or conversion (e.g., whole salmon → salmon fillets), map it to a Transform Event.

  • If the adjustment represents loss or spillage, map it to a Decommission Event.

Since ERP systems often use the same event type for multiple scenarios, contextual indicators such as reason codes can be used to differentiate them.
For example:

  • Reason Code = Processing → Trigger Transform Event
  • Reason Code = Loss → Trigger Decommission Event

This mapping ensures that your ERP’s operational data can be accurately reflected within Wholechain’s traceability model.

2. Sending Events: Real-Time vs. Pooled Transmission

Once you’ve mapped your events, you can decide when to send them to Wholechain.
There are two main strategies:

a. Real-Time Transmission

In this method, every event is sent to Wholechain immediately as it occurs in your ERP.
This ensures your traceability data is always up to date, but it can introduce challenges if data changes after submission.

Example:

Let’s say you record a Decommission Event when an item is marked as lost in your ERP.
Later, you discover the product wasn’t actually lost — it was misplaced and is still usable.
To correct this, you would need to create a new Commission Event in Wholechain to bring it back into the supply chain.

However, because this new Commission Event is created after the original Decommission Event, it will not be linked to the original supplier data — effectively creating a disconnected data record in your traceability chain.

When to use Real-Time Transmission:

  • When your operation requires immediate traceability updates.
  • When event reversals or corrections are rare.
  • When simplicity and low maintenance are priorities.

b. Pooled Transmission (Batch Sending on ShipEventCustomer)

With pooled transmission, all ERP events are still tracked event-by-event, but they aren’t sent to Wholechain immediately.
Instead, they are stored temporarily in an internal database or staging table.
Only when a ShipEventCustomer (customer shipment) occurs are all relevant events sent together to Wholechain.

Example:

Using the same “lost item” scenario — if you record a Decommission Event in your ERP but later find the product before shipping, you can simply remove or update that event in the pooled data before it’s sent to Wholechain.
This prevents the creation of unnecessary or incorrect events and maintains a consistent link to the original supplier data.

Advantages of Pooled Transmission:

  • Allows validation and correction before data is sent.
  • Prevents disconnected traceability events.
  • Preserves supplier relationships and lineage continuity.

Considerations:

  • Requires additional infrastructure (database tables or middleware).
  • Can introduce slight delays in visibility since events aren’t reflected in real time.
  • May require more technical resources from the customer’s side.

When to use Pooled Transmission:

  • When maintaining supplier linkage and data accuracy is critical.
  • When your ERP processes are complex or frequently revised.
  • When you have the technical capability to manage data pooling or staging.

3. Choosing Between the Two Approaches

Approach When to Use Pros Cons
Real-Time Transmission For simple operations requiring immediate data visibility Instant updates; easier to implement Can create disconnected data if corrections are needed
Pooled Transmission For complex operations or when accuracy and consistency are critical Enables validation and correction; preserves supplier linkage More technical overhead; requires data management process

Summary

  • Tracking: Always done event-by-event — each ERP event maps to a Wholechain event.
  • Transmission: Can be either real-time or pooled, depending on your operational needs.

Recommendation:

  • Choose real-time if simplicity and immediacy are priorities.
  • Choose pooled if maintaining data accuracy and supplier linkage is more important, and your team has the technical capacity to support it.

For detailed event mappings and payload definitions, refer to the “Connecting Your ERP to Wholechain System” section of the documentation.