Setting up the upload of product series and batches from 1C to 1C-Bitrix

Configuring the Export of Product Series and Batches from 1C to 1C-Bitrix

Serial and batch accounting in 1C is a separate layer of functionality that is barely included in the standard CommerceML. Nevertheless, several industries cannot operate without it: electronics (serial numbers), medical equipment, food products (batches with expiration dates), pharmaceuticals. Data on series and batches is needed on the website — at least in a simplified form.

What series and batches are in 1C

Series — a unique identifier for a specific product instance (serial number). One TV set = one series. Accounting in the register WarehouseGoods is maintained broken down by series.

Batch — a group of goods from a single receipt with shared characteristics (production date, expiration date, manufacturer batch number). One crate of milk of a specific date = one batch. A warehouse may have 10 crates from two different batches.

In 1C:UT 11, serial accounting is enabled in the nomenclature settings: Use Series. Batch accounting is a separate setting. Both mechanisms increase the granularity of warehouse data and complicate the exchange with the website.

What is actually needed on the website

It is not always necessary to transfer all series and batches. Typical scenarios:

Scenario 1: Serial number lookup. The buyer enters a serial number on the website and retrieves product information (warranty, production date). This does not require exporting series to the catalog — only an API request to 1C for a specific serial number is needed.

Scenario 2: Expiration date in the product card. For food or medical products — show the nearest expiration date of the available batch on the website. This requires exporting batch data as a product attribute.

Scenario 3: Batch selection by the buyer. A rare case: the buyer sees available batches (e.g., different wine bottling dates) and selects the desired one. This is a complex implementation — each batch = a separate SKU.

Technical implementation: expiration date as an attribute

The most common case — transferring the nearest expiration date from 1C to the website.

In 1C (on the UT/KA side), a scheduled task is created:

1. For each nomenclature item with batch accounting — identify the nearest expiration date from available stock
2. Write this date to the AdditionalAttribute of the nomenclature "ExpirationDate"
3. At the next exchange, this attribute will be included in the XML and will update the property in 1C-Bitrix

Alternative: a direct HTTP request from 1C-Bitrix to the 1C service when loading the product card. However, this creates a dependency of page load speed on 1C response speed.

Serial numbers in orders

If a buyer orders a product with serial accounting — upon shipment from 1C, a specific serial number is assigned to the order. It is useful to pass this number back to 1C-Bitrix: in the personal account, the buyer can see the serial numbers of purchased products — convenient for warranty service.

Back-transfer of serial numbers: in CommerceML, an order status update can contain extended data. Add logic to the order status update handler in 1C-Bitrix to save serial numbers from AdditionalAttributes of the document.

// Handler for order update from 1C
function onOrderStatusUpdate($arOrder, $arXML) {
    foreach ($arXML['ITEMS'] as $item) {
        if (!empty($item['SERIAL_NUMBERS'])) {
            saveSerialNumbers(
                $arOrder['ID'],
                $item['PRODUCT_ID'],
                $item['SERIAL_NUMBERS']
            );
        }
    }
}

Batch accounting and reservation

When an order is placed on the website and transferred to 1C — a specific batch must be reserved (especially with a short expiration date). The standard reservation mechanism in 1C reserves a batch automatically using the FEFO algorithm (First Expired, First Out — the one that expires soonest goes first).

On the website, the buyer does not select a batch — 1C does. The website only passes the quantity. 1C reserves the appropriate batch and can return information about it (expiration date of the reserved batch) in the order response.

Case study: food manufacturer

A dairy producer: direct B2B sales from the website to retailers. Each order involves specific SKUs with batch tracking (production date, expiration date). The retailer wants to see on the website not just "milk 1L" but "milk 1L, produced 10.03, best before 20.03".

Implemented via a HighloadBlock "Batches": at each exchange (every 2 hours) 1C transfers the list of available batches for each item. In the product card — a dropdown "Select production date". When adding to the cart — the batch ID is saved. When transferring the order to 1C — the batch GUID is specified in the order item attributes.

1C reserves the specific batch — no errors due to expiration dates.