Integration of 1C-Bitrix with Inflow WMS

Integration of 1C-Bitrix with Inflow WMS

Inflow WMS is a warehouse management system aimed at mid-to-large e-commerce operations: address-based storage, picking zone management, SSCC label support. Integration with 1C-Bitrix is more complex here than with typical cloud-based WMS platforms — Inflow is often deployed on-premise, has a configurable API, and requires an agreed data exchange schema tailored to the specific system configuration.

Data exchange architecture with Inflow WMS

Inflow provides a REST API or a SOAP interface depending on the deployment version. Most modern installations use REST with JSON. Authentication via an API key in the X-API-Key header or OAuth2.

Typical Inflow endpoints:

• GET /api/v1/stock — current stock levels by warehouse/zone
• POST /api/v1/orders — create a picking order
• GET /api/v1/orders/{id}/status — picking order execution status
• PUT /api/v1/orders/{id}/cancel — cancel a picking order

A key distinction from simpler WMS platforms: Inflow separates the concepts of a picking order and a customer order. A single customer order may generate multiple picking orders — when working with multiple storage zones or different carriers.

Stock synchronisation with address-based storage

In address-based WMS systems, "stock" is not simply a number but a distribution across storage bins. For an online store, only the quantity available for sale matters: qty_on_hand - qty_reserved - qty_in_picking.

Query Inflow via GET /api/v1/stock?warehouse=main&available_only=true. Receive aggregated stock levels. Update Bitrix via \Bitrix\Catalog\ProductTable::update() with cache invalidation.

Stock synchronisation frequency is a separate discussion with the client. High-throughput warehouses (100+ picks per hour) require synchronisation every 2–5 minutes or a switch to event-driven updates. For less busy warehouses, a 15-minute interval via a Bitrix agent is sufficient.

Order forwarding: status mapping

The most labour-intensive part of the integration is mapping statuses between systems. In Bitrix, order statuses are freely configurable (reference table b_sale_status). In Inflow, the state machine is fixed: NEW → ASSIGNED → PICKING → PICKED → PACKING → SHIPPED → DELIVERED.

A mapping table is required to translate Inflow statuses to Bitrix statuses:

Store the mapping table in the integration module settings so it can be modified without a deployment.

Handling picking errors

Inflow can return a PICKING_ERROR status — the item was not found in the specified bin, or the position is unavailable. In this case, the Bitrix order must receive a special status and a manager task. This is not a standard scenario — it is handled by custom logic on the Inflow status update event.

A typical case: a manager placed an order for an item whose stock had not yet been updated. When the WMS attempts reservation, it returns an error. The integration must: notify the manager, release the reservation in Bitrix, and offer an alternative or cancellation. Without handling this scenario, a "silent" error becomes an unfulfilled order with no notification.

Labelling and barcodes

If the warehouse works with labelled goods (Honest Sign, SSCC), the integration becomes more complex: when forwarding the order to Inflow, labelling codes must be included, and on shipment, the list of used codes must be retrieved for forwarding to the fiscal data operator. This is a separate exchange loop involving b_catalog_product_barcode on the Bitrix side.

Estimated timelines

Pricing is calculated individually — access to the API documentation for the specific Inflow WMS version and a description of the warehouse's business processes are required.