If you manage operations or technology, a delivery marked complete in one system and pending in another forces you to investigate before moving on. Your ERP—the company's management system—and a blockchain network need to coordinate. The integration must explain what happened, even when a response is missing.
Two systems, one delivery
What must you decide before connecting them?
Decide which system holds each piece of data, which changes are shared and how you will check the outcome. Decide who will review a discrepancy, too. Start with one complete operation your team recognizes; connecting tools without that agreement may leave you with more screens to check and the same unanswered question.
Illustrative example: your distribution company records a delivery, but the shared ledger does not return a confirmation. Resending blindly could duplicate the effect. Marking it complete could conceal unfinished work. The team needs to check its status before deciding.
Send the request and check the outcome
Why is a missing response no reason to retry immediately?
Because the response may have been lost after the operation was carried out. Your integration must be able to identify the request and check what happened. A retry is another attempt; to do it safely, you must distinguish a new operation from one already received or completed.
Fabric Gateway separates submission from confirmation checks. Microsoft explains when retries require safeguards. We propose keeping a shared reference in your ERP and the network to track each delivery, with states that the person supervising it can understand.
Recover without multiplying the work
What should the integration show when something fails?
It should show what was completed, what remains pending and which action is allowed next. Ask to test a lost response, a duplicate request and a reconnection. The aim is to let your team recover the task without accidentally creating another delivery or relying on an improvised investigation.
Idempotency is the property that lets you repeat an operation without adding new effects because of that repetition. How to implement it depends on the system. For this example, we would check whether repeating the same identifier preserves a single delivery and leaves a comprehensible history.
Prepare a first integration that can be reviewed
What information do you need to request a proposal?
Describe one delivery, the systems involved and an incident that concerns you. Add who may view, correct or retry it. You do not need to share credentials or customer data for that conversation. A synthetic example can help define the integration and agree on how to test it before expanding its use.
Calicata can assess the integration and consider Rust components with Oscar González, technical partner. The opportunity is to make the process and recovery visible, so an incident does not become a chain of checks with no clear owner.
Related service: Blockchain for businesses
Related reading: Blockchain for businesses: when it adds value over a database
Related reading: Distributed systems: what a programming language cannot solve for you
Related reading: When a Rust backend makes sense
Sources consulted on 20 October 2026. Explore the concepts and tools in these primary sources. The examples are illustrative, and any proposed application should be checked against your own process.
Hyperledger Fabric: submitting and confirming transactions
Microsoft: recovery through retries
Do your ERP and another ledger show different states for the same delivery? Tell us what you need to coordinate through our Blockchain for businesses service.