Setting up the upload of warehouse balances from 1C:UT to 1C-Bitrix

Configuring Warehouse Stock Export from 1C:UT to 1C-Bitrix

Stock levels are the "hottest" part of the exchange. Prices change once a day, the item catalog changes once a week, but stock levels can change every few minutes in an active store. An outdated stock level means an order for an out-of-stock item — an unhappy customer plus manual cancellation work. Configuring the stock export therefore requires special attention to frequency, accuracy, and warehouse architecture.

How Stock Levels Are Stored in UT and Transmitted to Bitrix

In 1C:UT 11, stock levels are stored in the accumulation register WarehouseGoods. Stock = receipts − shipments per warehouse for each item (and characteristic, if characteristic-based tracking is used).

In CommerceML, stock levels are transmitted in the offers file (offers.xml) in the Stock tag:

<Offer>
  <Id>product-guid#characteristic-guid</Id>
  <Stock>
    <StockItem>
      <WarehouseId>warehouse-guid</WarehouseId>
      <Quantity>15</Quantity>
    </StockItem>
    <StockItem>
      <WarehouseId>warehouse2-guid</WarehouseId>
      <Quantity>3</Quantity>
    </StockItem>
  </Stock>
</Offer>

On the Bitrix side, each UT warehouse must be created in Trade Catalog → Warehouses with a matching XML_ID (the warehouse GUID from UT). Bitrix either sums up stock across all warehouses or shows per-warehouse figures — depending on configuration.

Warehouse Filtering: What to Transmit to the Site

In many cases, UT has several warehouses: the main warehouse, a production warehouse, a defects warehouse, and a transit warehouse. The website only needs stock from the shipping warehouse — not the total across all warehouses.

In the UT exchange node settings, select specific warehouses for export. This is critically important: if the total stock including "Defects" or "In Transit" is transmitted, the buyer will see availability for items that are not actually ready for shipment.

Free stock vs. physical stock. In UT, it is possible to configure the export of free stock (physical minus reserved). This is correct practice: if 10 units are reserved for existing orders, the website should display the actually available quantity.

Configuration in the exchange node: parameter "Stock: consider reservations" — enable.

Multi-Warehouse Tracking on the Website

If a store has multiple warehouses (different cities, multiple pickup points), buyers may want to see availability at each specific location. This requires transmitting stock levels per warehouse — not as a total.

In Bitrix, this requires:

1. Creating warehouses in the trade catalog (GUID matching)
2. Enabling per-warehouse stock display in the catalog component
3. During checkout — offering pickup from the warehouse that has the item in stock

For a site with multiple pickup points, per-warehouse stock levels are a key feature. XML exchange natively supports this structure.

Update Frequency and Technical Implementation

Frequent stock exchange is implemented via cron on the server, not through Bitrix's "auto-exchange" interface (which is less reliable). Exchange startup script:

# Run stock exchange every 15 minutes
*/15 * * * * www-data /usr/bin/php /var/www/html/bitrix/modules/main/tools/cron_events.php

Or via a direct call to the exchange handler with type=sale (orders only) or type=catalog (catalog + stock) parameters.

Reservation at Checkout

When a buyer places an order in Bitrix, a decision must be made: reserve the item immediately (before payment) or only after payment confirmation?

• Immediate reservation: the item is reserved in Bitrix when the order is created (status "Awaiting payment"). When the order is transmitted to UT — a reservation is created in the WarehouseReserved register. The next stock exchange returns the updated free stock level including this reservation.

• Reservation after payment: risk of selling "phantom stock" during concurrent orders, but fewer "hanging" reservations from incomplete payments.

For most B2C stores — immediate reservation upon order creation with automatic reservation cancellation after N hours if payment is not received.

Case Study: High-Turnover Warehouse

A wholesale-retail electronics warehouse: 15,000 items, peak days — up to 200 orders per hour. Problem: with stock exchange every 30 minutes, 5–10 orders for the same item could be placed when only 1–2 units remained.

Solution: a two-tier system. Stock exchange — every 5 minutes. Additionally — a direct HTTP request to the UT service when adding an item to the cart: retrieves the current stock level in real time and shows it to the user. Full exchange (with item catalog) — once per night.

The UT HTTP service returns a JSON response with the stock level in 150–300 ms. On high-traffic pages, the result is cached for 60 seconds.