Understanding the distinction between orders and shipments in Centra is essential for anyone setting up or troubleshooting a Centra integration with Junipeer.
Orders vs. shipments — the key distinction
An order in Centra represents the customer's intent to purchase. It contains line items, pricing, customer information, and payment status. However, an order alone does not trigger physical fulfillment.
A shipment is the fulfillment unit. It represents what is actually being sent, when, and to whom. One order can have multiple shipments, which is common when:
Items are split across warehouses
Some items are backordered and ship later
Multiple suppliers fulfill parts of the same order
How shipment creation works
1. Order is placed The order lands in Centra with a status like Pending or Processing. No shipment exists yet.
2. Shipment is created A shipment is created from the order — either manually by a warehouse or ops user in the Centra admin, or automatically via Centra's API (triggered by a WMS or 3PL integration). When creating a shipment, you select which order lines to include. This is the moment an order can be split into multiple shipments.
3. Shipment contains its own data Each shipment has its own line items and quantities, shipping carrier and tracking number, warehouse location, and a separate status lifecycle (Good to ship → Shipped → Completed).
4. Payment capture is tied to shipment In Centra, payment capture happens at shipment, not at order placement. This is intentional — you capture payment only for what you are actually shipping. If order line A ships today and line B ships next week, payment is captured in two separate amounts.
5. Shipment is completed Once marked as shipped (with a tracking number), the shipment is closed. The order is only fully completed when all its shipments are completed.
Why this architecture exists
Centra's shipment model exists to handle the realities of wholesale and DTC commerce at scale:
| Reason | Explanation | |---|---| | Partial fulfillment | Ship what's available now, the rest later | | Multi-warehouse | Route different items to different warehouses | | Returns | Returns are modeled as shipments in reverse | | Payment precision | Capture only for what ships | | 3PL/WMS integration | External systems create and update shipments via API |
How Junipeer uses this model
Junipeer syncs based on shipment events, not order events. This means:
An invoice in Fortnox (or another ERP) is created when a delivery/shipment is confirmed in Centra, not when the order is placed
If an order has multiple shipments, multiple invoices may be created in the ERP — one per shipment
Stock levels are updated based on shipment completion, not order placement
This architecture ensures that invoicing is accurate — you only invoice for what has actually been shipped, not for the full order at placement time.
Practical implications for configuration
Invoice trigger: By default, Junipeer creates the ERP invoice when a Centra delivery is initiated. Confirm with your Junipeer onboarding contact what trigger is configured for your integration.
Partial orders: If a customer's order ships in two batches, expect two separate invoices in your ERP. This is correct behavior.
Refunds and returns: Since returns are also modeled as shipments in Centra, credit invoices in the ERP are triggered by return shipment events, not by order-level cancellations.
For Centra-specific error codes and troubleshooting, see the Error Codes reference or the Centra Setup guide.