> For the complete documentation index, see [llms.txt](https://docs.hotwax.co/documents/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hotwax.co/documents/retail-operations/workflow/job-workflows/inventory.md). # Inventory Monitor Shopify inventory event sync for channels and physical locations, separately from inventory entering OMS. Shopify inventory event sync publishes OMS inventory changes to Shopify through two ledgers: channel inventory events and physical-location inventory events. Inventory entering OMS from an ERP, receipt, or file import is a separate step; successful import does not establish Shopify delivery. ## Shopify inventory event sync 1. Open the Company App and select `Shopify`. 2. Open the affected connection and confirm its shop and Product Store. 3. Select `Inventory sync`. 4. Choose the channel or physical-location path that matches the Shopify target. 5. Follow the event into its batch and check delivery, then verify the quantity in Shopify. | Path | Inventory basis | Monitor and publisher | | --------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Channel inventory | ATP calculated for the channel's facility group, published to its aggregate Shopify location | `Channel inventory events`, the channel card, and `Send channel batches` | | Physical-location inventory | Facility ATP changes published as available-quantity adjustments to the mapped physical Shopify location | `Physical inventory events` and `Publish physical batches (all shops)` |
Company inventory event sync with separate channel and physical-location queues, waiting events, and publisher jobs

Sandbox example of the two Shopify inventory event paths. The shown pending events and paused jobs are sample states, not successful delivery results.

### Follow events, batches, and delivery Inventory changes captured by the enabled event sources produce ledger rows. Publishers group eligible waiting rows into batches, and the corresponding sender delivers each batch to Shopify. Inspect both capture and delivery when a target is stale. * `Events waiting to batch` counts event rows, not products or units. * `Batches waiting to send` identifies work not yet delivered. * Open an event to inspect its source, signed change, target, and linked batch. * Open the batch to review its summed change entries, delivery state, and errors. * Review the correct publisher's pause state, schedule, parameters, and recent runs. A completed publisher run or queued batch does not prove Shopify accepted an adjustment. Verify the batch and the actual target quantity. ### Reconcile the affected target Use the reset job that matches the target and quantity: | Company App job | Purpose | | -------------------------------- | --------------------------------------------------------------------------- | | `Reset channel ATP` | Reconcile aggregate ATP for the selected channel | | `Reset physical ATP (this shop)` | Reconcile ATP for the connection's mapped physical locations | | `Reset physical on-hand` | Reconcile physical on-hand quantity when that separate quantity is required | Review mappings, source quantities, outstanding Shopify order imports, and recovery scope before an approved reset. Physical event adjustments use available inventory; an on-hand reset is a separate reconciliation operation. `Resend` sends an existing batch's frozen payload and idempotency key. It does not recalculate current inventory. Correct the delivery error before an approved retry, and use an appropriate reset when missed capture or an obsolete payload requires reconciliation. ### Configure capture and schedules Review both `Channel events` and `Physical location events`, the selected shop's push control, and the event-source controls. Changes made while capture is off are not recorded for later replay. Reconcile every affected target before relying on incremental updates again. Job creation and activation must follow the approved configuration. Missing jobs that offer `Set up` are created paused; a successful setup does not enable publication automatically. Keep manual discard jobs paused and unscheduled. Use [Monitor Shopify inventory sync](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/system-admin/administration/company/manage-shopify-inventory-sync.md) for the complete setup, history, job, and recovery procedures. Do not substitute a file-import job or an inbound inventory webhook for either outbound event path. ## Inventory entering OMS The workflows below update inventory records or supporting configuration inside OMS. Verify that result first, then investigate outbound Shopify events separately. ### Inventory and configuration files Use the configured Data Manager import for the approved inventory or product-facility file. Confirm its configuration, source path, expected quantity meaning, import status, failed records, and resulting OMS records. File retrieval or upload alone does not establish processing success. * [Choose inventory import quantities and methods](/documents/retail-operations/inventory/inventory-upload/import-methods.md) * [Troubleshoot file imports](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/system-admin/administration/job-manager/troubleshooting/file-imports.md) * [Verify sourcing changes](/documents/retail-operations/inventory/available-to-promise/use-cases.md#verify-sourcing-changes) ### Receipts and transfers Follow the configured receipt or transfer integration and verify the resulting inventory at the correct facility. Importing a transfer or inbound shipment is not the same as physically receiving stock. * [NetSuite inventory integration](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/learn-netsuite/integration-flows/inventory.md) * [Receive transfer orders](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/store-operations/receiving/transfer-orders.md) ### Kit inventory OMS-derived kits use component-based calculations and dedicated channel and physical-location reset feeds in the reviewed connector. Do not assume ordinary component events immediately publish a kit quantity. See [Kit inventory synchronization](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/learn-shopify/shopify-integration/inventory/inventory-sync-kitproducts.md). ### Scheduled restocking A scheduled restock changes the inventory entering OMS. Follow the [scheduled restock procedure](/documents/retail-operations/inventory/inventory-upload/schedule-restock.md) and verify the OMS result separately from Shopify event delivery. An intended launch time is not proof that both steps completed at that time. ### Starting inventory from Shopify The one-time starting inventory seed is inbound, from Shopify to OMS. Follow [Chapter 8 of Shopify onboarding](https://github.com/hotwax/oms-documentation/tree/user-guides-pub/documents/system-admin/administration/company/product-store-onboarding.md#8-seed-starting-inventory-from-shopify). It is separate from the channel and physical-location event publishers described above. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.hotwax.co/documents/retail-operations/workflow/job-workflows/inventory.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.