For several weeks, wholesale EDI orders from major retailers were not flowing through to Realsy's 3PL. The orders were coming in through Crystal, the wholesale EDI platform. They were visible in Cin7, the inventory and accounting system. They were getting acknowledged and processed correctly on paper. But RAD 3PL wasn't receiving the pick instructions. Shipments weren't going out.
The investigation went in the wrong direction for longer than it should have.
What the failure looked like
From the outside, the symptoms pointed everywhere except where the problem actually was.
CartRover, the middleware connecting wholesale channel orders to Extensiv, seemed like the obvious candidate. It was sitting in the middle of the flow. We pulled the CartRover logs. Orders were queuing. Some were syncing. Some weren't. The inconsistency looked like a CartRover configuration issue, so the team dug into CartRover settings.
Nothing there fixed it. Next candidate was Cin7. Maybe the PO structure was wrong, maybe the item configurations had an issue that was blocking the sync. We reviewed the Cin7 setup. POs looked correct. Items were configured. Sync settings looked fine.
Then we looked at Extensiv.
In Extensiv's order management configuration, there is a setting called the lock code. The lock code controls how the system handles purchase orders when the inventory state doesn't meet certain conditions. The specific setting in question: how Extensiv handles POs when inventory is on backorder.
The setting had two options: "Ordered" and "Ordered and Backordered."
Set to "Ordered" only, Extensiv would only sync POs where inventory was fully on hand. Any PO that touched a backordered SKU would not sync to the 3PL. It would fail silently. No error in CartRover. No error in Cin7. No alert to anyone on the team. The order would sit in a queue indefinitely, and RAD 3PL would never see it.
Changing the setting to "Ordered and Backordered" fixed it. POs began syncing normally.
What this cost in practice
The weeks during which this setting was wrong meant wholesale EDI orders from UNFI, Jewel Osco, and other retailers were not getting fulfilled on time. In a wholesale context, late shipments trigger deductions. Compliance failures create chargebacks. Retailer relationships take damage that doesn't repair immediately.
The underlying inventory wasn't missing. The operational capacity to pick and ship was there. RAD 3PL was ready. The only thing preventing fulfillment was one dropdown menu in a settings panel that no one had reason to check.
The pattern, not just the fix
The Extensiv lock code is a specific problem with a specific fix. This case study isn't really about that setting. It's about the pattern.
When an integration between two systems fails, the failure is almost never in the data. Data errors produce obvious failures: wrong quantity, wrong SKU, missing field. When the data looks right and orders still aren't flowing, the problem is in the configuration.
Every middleware system, every integration layer, every API connection has settings that control its behavior in edge cases. What happens when inventory is unavailable? What happens when a field is blank? What happens when two orders arrive simultaneously for the same SKU? These edge case behaviors are configured somewhere, and the defaults are set by the software vendor's assumptions about how you want to run your business, not by your actual requirements.
Those defaults are almost never documented in the standard onboarding materials. They're in the advanced settings, the technical documentation, or the knowledge base articles that only get read when something breaks.
The diagnostic approach that catches these failures faster: when an integration stops working and the obvious suspects (CartRover, the upstream system) are cleared, go to the most recently changed configuration in any system in the chain. If no configuration recently changed, go to the default settings for every middleware system and ask: does this default match how our business actually operates?
For Realsy, the answer to that question in Extensiv was no. The default "Ordered" setting assumed that the warehouse management system should only receive POs for in-stock inventory. Realsy's operations regularly involved backordered SKUs on active POs. The assumption built into the default was wrong for their business.
The configuration audit
After finding the lock code issue, the team did an audit of every default setting in Extensiv's configuration that touched order management. Twelve other settings had defaults that may or may not have matched operational requirements. Most were fine. Two were adjusted to better match actual workflows.
That audit would have taken about two hours at the start of the engagement and would have found the lock code issue before it caused weeks of fulfillment delays.
Add it to the onboarding checklist for any new Extensiv implementation: before going live, walk through every order management setting and confirm that the default behavior matches what your business actually needs when things go wrong.
