In this article
Shared EDI mapping for Shopify and BigCommerce prevents duplicate integration work by placing common order, product, inventory and shipment rules in one business model. You translate each storefront's data into that model, then apply the appropriate ERP, warehouse and trading partner mappings. Separate storefront connections and partner rules remain necessary, but your team does not have to rebuild the same business logic for each channel.
This design is useful when you run both storefronts alongside retail EDI or expect to add channels. BOLD VAN works with EDI mapping and connections to platform APIs, including Shopify and other e-commerce platforms, as part of BOLD Integration. For BigCommerce, confirm the proposed connection against your implementation and its current platform documentation before treating a shared design as ready to deploy.
What shared mapping means
A shared map defines the business meaning of data independently of where it originated. For an order, that might mean an order identifier, buyer, delivery destination, item identities, requested quantities and fulfillment status. Shopify, BigCommerce and an EDI 850 purchase order can each express those concepts differently. The common model gives you a consistent place to interpret them.
The design has boundaries. A storefront connection handles that platform's documented format. A partner map handles the partner's required EDI version and rules. The shared layer handles concepts that genuinely mean the same thing across sources. BOLD VAN's recommended approach is to decide ownership and business meaning first, then build the platform and partner translations around those decisions.
The data structure and document flow
Think of the shared model as a set of related records rather than a single flat file. An order has a header and item lines; a shipment refers back to an order and may cover only some of its lines. Product references, locations and statuses need documented relationships. If you flatten a split shipment into one completed order status, you can lose information needed by the warehouse, storefront or trading partner.
| Shared object | Define in the common model | Keep distinct |
|---|---|---|
| Product | Internal item identity, sellable unit and cross-references | Storefront product references and partner item identifiers |
| Order | Source, order identity, buyer, destination and item lines | Channel-specific order states and partner requirements |
| Inventory | Quantity meaning, location and system of record | Channel allocation and platform-specific availability |
| Shipment | Order reference, shipped items, quantities and tracking context | Partial fulfillment and partner-specific ship notice rules |
| Invoice | Order reference, billed items and totals | Partner rules and ERP invoice approval process |
For example, imagine you receive a retail 850 while your own Shopify and BigCommerce stores take direct customer orders. The 850 is mapped into the shared order structure for downstream processing. Storefront orders enter through their respective platform connections and reach the same business structure, with their source retained. Warehouse shipment data then feeds the appropriate outbound process. A retail partner might require an 856 advance ship notice, while a storefront needs an update through its own connection. Whether a particular transaction or data value is required depends on the partner's published EDI implementation guide and the platform's current documentation.
Keep exceptions outside the shared rule. A common model can preserve an order's meaning across channels, but it should not silently impose one retailer's document requirements or one storefront's status meanings on every other connection. Check each trading partner's published EDI implementation guide before approving its map.
A practical mapping process
Inventory flows and assign ownership
List the events that move data: order receipt, acceptance, allocation, shipment, invoicing and inventory change. For each value, name the system that owns it and the systems that consume it. You might use an ERP as the item master and a WMS as the source of shipped quantities, but confirm ownership in your own workflow. Include cancellation and split-fulfillment paths before designing the shared model.
Build the common structure, then the adapters
Document which concepts are required to process an order and which are optional. Maintain cross-references for differences in item identity, units, locations and status vocabulary. Map Shopify and BigCommerce separately to that structure. Then map the structure to the ERP or WMS and to each applicable EDI document. This separation lets you revise a platform connection without automatically rewriting every partner rule.
Test business outcomes as well as transmission
Run the same business scenarios through both storefront paths: a standard order, an item mismatch, a cancellation and a partial shipment. Confirm that downstream systems receive the right order identity and that returns or updates can be traced to their source. Test each partner document against its published implementation guide. A 997 functional acknowledgment can report whether a document passed the receiver's syntax check, including acceptance or rejection; it does not confirm that the order or its content was accepted.
BOLD VAN maps data to and from ERP systems such as SAP, Oracle ERP and Infor CloudSuite, WMS systems such as ShipHero, TMS systems such as Oracle TMS and other systems. The team connects to a platform's API when that platform uses an API rather than EDI, supporting both EDI-to-API and API-to-EDI flows. New maps are typically ready to test in about two days. That timing concerns readiness for testing, not completion of your partner and business validation.
Common pitfalls and best practices
- Avoid duplicate identities. Preserve the originating channel and its order reference. Define how your system recognizes a repeated message before it creates another business order.
- Keep inventory ownership explicit. Decide which system supplies available quantities and how allocations affect each storefront. Test a change that occurs while an order is being fulfilled.
- Do not confuse acknowledgment with fulfillment. Track syntax results, business acceptance and shipment progress as separate states.
- Version changes deliberately. Record what changed in a shared rule, platform connection or partner map and retest all affected paths. When a trading partner changes its requirements, BOLD VAN updates the map, and minor changes are typically handled at no cost.
Every document is tracked in the BOLD VAN portal, where customers can search, requeue and report, with notifications when something needs their attention. That record helps you distinguish a document handling problem from a business-rule problem without claiming that one acknowledgment proves the whole workflow succeeded.
When the shared approach fits
If you operate one storefront and have few downstream variations, a direct mapping may be easier to maintain. Shared mapping becomes more useful when the same item, order and shipment rules appear across Shopify, BigCommerce, an ERP, a WMS and multiple partners. Evaluate the approach by counting the rules you currently maintain in more than one place, then identify which are actually identical. Consolidate those rules while keeping documented exceptions close to their platform or partner.
The result is a clearer integration design, not a shortcut around testing. For help defining reusable mappings and separate platform connections, you can discuss the workflow with BOLD VAN through BOLD Integration.
Frequently asked questions
Can the same EDI map connect Shopify and BigCommerce?
You can reuse a shared business model and common transformation rules. Shopify and BigCommerce still need separately tested platform connections, and each trading partner still needs mapping based on its published EDI implementation guide.
Does shared mapping mean Shopify and BigCommerce use the same data structure?
No. The shared structure describes business concepts such as orders, items and shipments. Each platform connection translates those concepts to the structure supported by that platform's documented implementation.
Which EDI transactions should we plan for?
An 850 purchase order, 855 purchase order acknowledgment, 856 advance ship notice, 810 invoice and 846 inventory inquiry or advice may be relevant. Check each trading partner's published EDI implementation guide to establish which transactions, versions and rules apply.
Does an accepted 997 mean the order is approved?
No. A 997 functional acknowledgment tells the sender whether a document passed the receiver's syntax check. It can report acceptance or rejection, but it does not mean the order or its content was accepted.
