Why transit delivery on Bitrix breaks on partial shipments
Transit delivery begins with a harmless scenario: the client places one order, and it contains items from two suppliers. The first ships from its warehouse immediately, the second — a few days later, when the required batch arrives.
In the accounting system this is one order and one set of documents, physically — two supplier warehouses, two invoices and two deadlines. The gap between these circuits is the source of almost all failures on partial shipments.
The gap manifests on the “order line — shipment” link. Until the correspondence is fixed, the exchange pulls supplier stock in a general upload and distributes it across the catalog, not knowing that some items are already assigned to a specific order.
Double reserve arises: the same unit is seen by two buyers, but it is not in the supplier warehouse — and the second order goes to cancellation after confirmation.
Then statuses diverge. The order moves to “shipped” because the first part left, although the second is still in transit. The client waits for the entire set, delivery assembles an incomplete order, the manager manually reconciles invoices and deadlines.
In a stream this repeats every time, and what pays for it is not the manager’s time, but returns and store reputation.
We explain how this is closed: the order line gets a binding to the supplier, reserve is placed not on the product in general, but on a specific shipment, and the order status is assembled from the states of all parts. Then supplier stock, deadlines and statuses stop diverging.
What integration with supplier warehouses gives
The scheme works on top of the standard 1C-Bitrix exchange with the supplier accounting system: catalog, stock and prices arrive on schedule, orders go back. Below is what exactly changes in the daily work of the store.
Stock is taken from source, not from a table
Stock information is updated on schedule, so the operator does not reconcile availability manually before each call. An item without stock goes to “on order” with a real lead time, instead of turning into a refusal after checkout. On a catalog of thousands of items this removes the main part of routine operations.
Reservation at checkout
The order assigns stock to the buyer immediately upon confirmation, and an unpaid reservation is released after the allotted time.
The share of orders that the manager edited by hand because the product was already sold drops manifold — a whole class of “sold what isn’t there” errors goes away.
Delivery time is calculated by rules
Assembly and delivery time is assembled from the supplier warehouse, region, shipment schedule and buffer for picking. The buyer sees the date the system is ready to confirm, not a rounded “three–five days”.
Notifications to buyer are sent automatically
Statuses go along the chain: confirmation, transfer to supplier, shipment, handover to delivery — emails and messages in the personal account are generated automatically. This closes forgotten statuses, duplicates and discrepancies between the account and manager correspondence.
Modes of transferring orders to supplier: comparison of options
Order transfer mode is set by two things: what triggers the exchange and where the intermediate state is stored. This determines the delay in status updates, resilience to supplier unavailability, and how expensive it will be to change the accounting system on their side.
In practice the choice comes down to four schemes — from strict exchange regulations to manual file upload.
| Option | When suitable | Integration limitations |
|---|---|---|
| Scheduled exchange | Stable stock, dozens of orders per day, supplier not ready to provide events | Update delay equals launch interval; order spike waits for the next cycle |
| Event-based exchange | Need reservation and confirmation at checkout | Requires a constantly available receiver; on failure events accumulate in queue and are processed later |
| Via intermediary service | Multiple suppliers with different exchange formats | An extra link for monitoring appears, some fields are lost when matching reference data |
| Manual file upload | One-off batches, rare items, trial operation period | No document history, input errors, volume limited by manual work |
Exchange regulations should be fixed in writing: what counts as receipt confirmation, after how many failed attempts an order goes to error, and who handles discrepancies.
The working scheme is often mixed — we pull stock on schedule, send orders themselves on event, and manual upload remains as an emergency channel.
Stages of delivery setup: from audit to handover to support
Transit delivery breaks not at order placement, but at the junction of processes: the order is created in 1C-Bitrix, and goods travel from supplier to client bypassing our warehouse.
Therefore setup goes as a sequence of six steps, where each next relies on the artifacts of the previous.
-
Integration audit. We analyze the current supply scheme: where stock comes from, how deadlines are calculated, who learns about the order and at what point.
We record the discrepancy between what is configured and how the process actually goes — it is exactly what produces stuck orders.
-
Designing order linkage. We describe the exchange scheme: which entities are synchronized, with what frequency, by what attribute the client order and supplier order are matched.
Here we also lay out order splitting — one client order can be fulfilled by several shipments from different suppliers.
-
Exchange setup. We implement the linkage according to the designed scheme: statuses, item composition, deadlines, binding to delivery. Separately we write behavior on supplier refusal and on deadline shift.
-
Processing partial shipments. Some items leave earlier, some later. We configure how this is reflected in the order, what notifications the client receives, and how delivery is recalculated for multiple dispatches.
-
Testing on control orders. We run scenarios on test orders: full shipment, partial, cancellation, deadline postponement. We reconcile statuses, notifications and data convergence in both directions.
-
Handover and training. We provide access, regulations for actions on failure, and instructions for employees: what the manager does with a stuck order, whom they notify, what they tell the client. Then the scheme goes to support.
Composition of transferred settings and documentation
After transit delivery launch, the configured logic does not remain in correspondence and the developer’s heads — it is transferred to your team as a working set.
Below is what you receive and by which documents the administrator can change rules and handle disputed orders without our involvement.
- Order distribution rules — warehouse priority, restrictions by region and deadlines, conditions for switching to a backup supplier, and the procedure for changing the rule itself.
- Notification templates — emails to buyer and supplier for each order status, with a list of placeholders and marking of mandatory ones.
- Exchange scheme description — composition of data for supplier, format of confirmations with tracking numbers, system behavior when the external side is unavailable and on resend.
- Discrepancy handling regulations — what to do if an item is not confirmed, the deadline is shifted, or the shipment is partial: who responds and within what time.
- Administrator instructions — scenarios: add supplier, change deadline by direction, disable rule, handle a stuck order by exchange log.
- Control points — share of confirmed orders and deadline discrepancies; from them it is visible that Bitrix transit delivery works normally even before buyer inquiries.
The set is fixed by a handover act: after it you make edits yourself or engage us for specific tasks.
Case study: how manual transfer of orders to suppliers was removed
The client works under a transit scheme: goods travel from supplier directly to buyer, bypassing their own warehouse.
Before the improvement, each order was processed manually — the manager uploaded the composition from the 1C-Bitrix admin panel, checked availability at the supplier, sent the request by email, and manually returned the invoice number to the order.
With a stream of several hundred orders per month, 6–8 hours passed between payment and request, and composition discrepancies surfaced already at the buyer’s receiving.
The cause was not the manager’s speed, but that order statuses lived in two systems and were not reconciled with each other.
We linked them via exchange: the order goes to the supplier on the payment event, nomenclature is matched by external code and barcode, and the invoice and shipment status return to the admin panel automatically.
Failed sends are not lost — they go to the log with the supplier response and are retried on schedule, so the order does not hang without movement.
What changed in measurable values
| Metric | Before | After |
|---|---|---|
| Time from payment to supplier request | 6–8 hours | 10–15 minutes |
| Share of orders with manual composition edits | about 40% | 1–2% |
| Share of on-time shipments | 82% | 97% |
| “Where is my order” inquiries | 3 out of 10 | 1 out of 10 |
A separate effect the client did not plan: the buyer sees the status “transferred to supplier” and the shipment number in the personal account immediately after sending, so the flow of clarifying calls dropped without changes in support work.
The integration case is replicable — the same exchange scheme suits any supplier with order upload and status return.
How to process an order if supplier ships in several batches?
An order that the supplier ships in two or three batches cannot be handled as one shipment.
Warehouse reserve is written off in parts, the buyer waits for the first set earlier than the rest, and the order cannot be closed until the last item arrives — otherwise documents will show non-existent stock.
In 1C-Bitrix there are two working approaches: keep one order with partial shipments or create child orders for each batch. The choice affects statuses, emails to the buyer, and the number of closing documents in the accounting system.
The partial shipment scheme is chosen when there is one supplier and the batch price does not change.
If batches come from different suppliers or with different payment terms, child orders are more reliable: accounting sees a separate deal, the buyer sees an email for each dispatch.
Notifications in both cases are attached to the status change event, and the template substitutes the batch composition and dispatch numbers so the buyer does not call support.
Frequent technical questions on order transfer
With transit delivery, the order is placed on the website, while physically the goods travel from the supplier warehouse, so disputed situations almost always fit into five scenarios.
Below is how each of them is closed by exchange settings and status rules, without manual review of each request.
Supplier has no exchange — how to get stock?
We work by price list: the supplier uploads a file according to regulations (email, link, catalog), we parse it by SKU and barcode and update stock on the website.
If there is no exchange at all, items not present in the file are automatically hidden — the buyer will not order what will not be delivered.
Stock diverged — what will buyer see?
We set a buffer: on the website we show stock minus the technological reserve, and at zero the item becomes unavailable for ordering. Discrepancy is caught at confirmation — the order does not go to shipment until the warehouse confirms availability.
Deadline was postponed after checkout
An update from the supplier changes the date in the order, the status moves to “deadline changed”, and the buyer receives an email with the new date. Change history is stored in the card so the manager can see who and when shifted delivery.
Cancellation after shipment — how not to lose goods?
By rule we fix the status after which cancellation goes only through return: the order gets the mark “cancellation in process”, and the supplier warehouse gets a counter document. This excludes the case when the order is canceled on the website but the truck is already en route.
How is deadline calculated for partial shipment?
By default the deadline equals the latest item in the order, so the buyer does not wait for the second parcel blindly. If the supplier ships in parts, the order is split into suborders, and both dates are visible in the personal account on 1C-Bitrix.
Let’s discuss your supply scheme and estimate scope of work
So that the scope estimate relies on facts, not assumptions, we build the first conversation around your current supply scheme.
Below is what to send in advance: from this set it is visible which data suppliers already have in machine-readable form, and which will have to be normalized during exchange setup.
- List of suppliers and warehouses: who provides stock in real time, and who by scheduled upload.
- How orders go to supplier today: manually in the panel, by email, file exchange, or via software interface.
- Rules for choosing supplier when an item is available from several: by stock, delivery time or buyer region.
- Where the scheme breaks now: stuck orders, stock discrepancies, manual status edits.
- Requirements for statuses and deadlines that the buyer sees, and for notifications about shipment postponement.
- Sample upload for a period and access to the test environment — we use them to check nomenclature matching.
- Who on your side makes decisions on disputed items: replacement, partial shipment, cancellation.
Then we compile an implementation plan: the order of supplier connection, control points at each stage, and realistic setup timelines for your order volume.
You can discuss the task even without a full package — missing details are clarified on a call with the engineer who will lead the project.
After launch, handover to support goes with regulations: what we monitor, how we respond to stock discrepancies, in what order we connect a new supplier.