The Inventory Engine is a core integration in the app that centralizes internal inventory logic across your organization.
It manages:
- Virtual location balances and commitments
- Bundle availability calculations
- Inventory events such as
ship,xferin, and other system-driven updates
The Inventory Engine does not perform channel synchronization. Inventory synchronization with sales channels and 3PLs is handled by the respective integration connectors.
You can access the Inventory Engine from Integrations → Inventory Engine. It is disabled by default and must be explicitly turned on using the toggle.
Key Use Cases
The Inventory Engine supports operational control and internal inventory logic, including:
Virtual Commitment Management
- Creates virtual commits per SKU before a shipping request (SR) is generated.
- Maintains virtual location balances until inventory is formally committed to a fulfillment location.
Shipping Request–Driven Commit Flow
- When a shipping request is created, the engine:
- Reduces virtual commit quantities.
- Generates a
shipevent. - Increases the
committedquantity at the fulfillment location.
This ensures inventory transitions from virtual commitment to location-level commitment at the correct operational stage.
Bundle Availability Calculation
- Calculates bundle availability based on component item availability.
- Applies component-based calculation unless the location has the Preserve Bundles flag enabled.
Multi-Location Event Processing
- Generates and processes inventory events across the full order and fulfillment lifecycle:
| Handler | Events Generated |
|---|---|
| Shipments |
ship, futureShip, release, shipCancel, shipCancelRestock, futureShipCancel, xferout
|
| Fulfillments |
fulfill, xferfulfill
|
| Arrivals | xferin |
| Virtual commits | virtualCommit |
| Bundle recalculation | adjust |
| POS orders | POSOrder |
| Bundle trigger | touch |
| Receipts | receive |
- Maintains accurate internal state for incoming and committed quantities across all event types.
Transfer Order Commit Flow
Transfer orders follow a different event path from sales orders:
| Stage | What Happens |
|---|---|
| Transfer order shipment created | A xferout event is generated. Available quantity decreases and committed quantity increases at the source location. |
| Transfer order fulfilled | A xferfulfill event is generated. Committed quantity decreases at the source location and on-hand is reduced. |
This is distinct from the sales order path (ship → fulfill) and applies whenever inventory is being moved between locations via a transfer order.
Inventory Engine Settings
Enable Virtual Location
Virtual Location is a temporary, logical location in Pipe17 that holds inventory commits before a shipping request is created.
Why Use It?
This feature protects inventory before it is formally committed to a fulfillment location.
It applies whenever an order exists, but no shipping request (SR) has been created yet. This may occur for several reasons, including:
- Order review processes
- Routing delays
- Business workflow steps prior to fulfillment
Virtual location behavior is tied to the existence of shipping requests, not to a specific order status. Learn more about virtual locations here.
How It Works
| Stage | What Happens |
|---|---|
| Virtual location does not exist | The engine automatically creates a location named Pipe17 Virtual Location with a default address. You do not need to create this manually. |
| Order created (no SR yet) | Inventory is committed to the virtual location. Source location inventory remains unchanged. |
| Shipping request created | Virtual commit is reduced. A ship event is generated. Committed quantity increases at the fulfillment location. |
| Order canceled before SR | Virtual commit is cleared automatically. |
| POS order created | POS orders bypass the virtual commit flow entirely. No virtual location commit is created for point-of-sale orders regardless of this setting. |
ℹ️ Source inventory is not reduced until a shipping request is created. The virtual location protects sellable availability during the pre-fulfillment phase.
⚠️ POS orders (for example, from Shopify POS) skip virtual commits. If you process POS orders alongside standard sales orders, be aware that their inventory impact is applied directly without passing through the virtual location stage.
Bundle Inventory Auto-Calculation
Bundle inventory calculation is always active when the Inventory Engine is enabled. There is no setting to turn it on or off.
When a bundle product is created or updated, the engine automatically generates a touch event on the bundle's first component SKU. This triggers an immediate inventory recalculation for the bundle. This behavior is always on and is not configurable.
If no product update occurs, the bundle recalculates whenever one of its component SKUs changes inventory.
How Bundle Inventory Works
For locations without the Preserve Bundles flag enabled:
- Bundle availability is calculated based on component availability.
- For each component, the engine divides the component's available quantity by the number of units required per bundle, then takes the floor.
- The lowest result across all components determines the maximum sellable bundle quantity.
Formula:
For each component:
floor(component_available ÷ quantity_per_bundle)Bundle available = minimum of all component results
Example
Bundle SKU: BEARD-CARE-SET Components:
| Component | Required per bundle | Available |
|---|---|---|
| BEARD-OIL | 1 | 50 |
| BEARD-BALM | 2 | 100 |
| BEARD-BRUSH | 1 | 4 |
Calculation:
- BEARD-OIL:
floor(50 ÷ 1)= 50 bundles - BEARD-BALM:
floor(100 ÷ 2)= 50 bundles - BEARD-BRUSH:
floor(4 ÷ 1)= 4 bundles
The limiting factor is BEARD-BRUSH. Maximum sellable bundle quantity = 4 units.
Note that BEARD-BALM, despite having 100 units available, only supports 50 bundles because 2 units are required per bundle. Always account for the quantity-per-bundle multiplier when diagnosing bundle availability.
If the location has the Preserve Bundles flag enabled, bundle SKUs are not broken down into component SKUs during shipment and fulfillment processing, and the component-based calculation does not apply in the same way.
Other Settings
Read-Only Mode (allowWrite) By default, the Inventory Engine runs in read-only mode even when the engine is enabled. The allowWrite setting must be turned on to allow the engine to write inventory events. If the engine appears to be on but no inventory changes are being generated, confirm that allowWrite is enabled. This setting is not shown in the main settings UI by default — contact support if you need it adjusted.
Entity-Level Controls Each entity type processed by the engine can be individually enabled or disabled:
- Arrivals
- Fulfillments
- Inventory
- Orders
- Products
- Receipts
- Shipments
This allows you to limit the engine's scope to only the entity types relevant to your workflow without disabling the engine entirely.
Bundle Puller (bundle_puller) Controls whether product data for bundle calculations is fetched via webhook or polling mode. This is a hidden setting not shown in the main UI. Contact support if you need to change how the engine retrieves product data for bundle recalculation.
Note: View JSON, Compare, and Export/Import settings are not available for the Inventory Engine.
Need Help?
If you need additional assistance:
- Use Ask Pippen, our AI agent, located at the top of the platform page.
- Submit a support request with as much relevant detail as possible. Learn how to submit a request.
- For urgent issues, email us directly at support@pipe17.com.
We're here to help you succeed with your operations.
Comments
0 comments