Configuring Exchange Between 1C:Catering and 1C-Bitrix
Catering is an industry-specific configuration with its own item logic: dishes, recipe cards, modifiers, semi-finished products. An online store or food delivery site built on Bitrix expects a different data structure than a standard product catalog. This is the core challenge of the integration.
Items in 1C:Catering: What's Different
In 1C:Catering, the "Items" directory is extended with industry-specific types: Dishes, Semi-finished Products, Goods, Services. For a delivery site, only "Dishes" are needed (sometimes "Goods" — bottled beverages). Semi-finished products are not exported to the site — they are internal production items.
Modifiers. The dish "Margherita Pizza" can have modifiers: size (25/30/35 cm), crust type (thin/thick), extra toppings. In 1C:Catering, modifiers are a separate directory linked to the dish through "Modifier Groups." The CommerceML standard has no dedicated tag for modifiers — they must be transmitted via AdditionalAttributes or as characteristics.
On the Bitrix side, modifiers are implemented as trade offers (SKUs) or as custom properties with a JSON structure. Both approaches work; SKUs are simpler for standard catalogs, JSON is more flexible for complex combinations.
Transmitting Modifiers via Characteristics
Configuration in 1C:Catering: enable the transmission of modifier groups as dish characteristics in the export settings.
<!-- Example XML for a dish with modifiers -->
<Product>
<Id>abc-123</Id>
<Name>Margherita Pizza</Name>
<ProductCharacteristics>
<ProductCharacteristic>
<Id>size-25</Id>
<Name>Size 25 cm</Name>
<Price>450</Price>
</ProductCharacteristic>
<ProductCharacteristic>
<Id>size-30</Id>
<Name>Size 30 cm</Name>
<Price>650</Price>
</ProductCharacteristic>
</ProductCharacteristics>
</Product>
Bitrix reads the characteristics and creates SKUs. Each SKU has its own price. This works for simple modifiers (size). For complex combinations (size × crust × toppings), the number of SKUs explodes: 3 sizes × 2 crusts × 10 toppings = 60 SKUs per dish. In such cases, it is better to pass modifiers as JSON in a custom dish property and handle them on the frontend.
Menu and Categories
In 1C:Catering, the menu is a separate object that links dishes to outlets and times of day. On the website, this is typically just catalog sections (Hot Dishes, Cold Dishes, Beverages). Mapping: "Item Type" or "Item Group" in Catering → infoblock section in Bitrix.
Problem: a single dish may belong to multiple menu categories (e.g., "Business Lunch" and "Main Courses"). Standard CommerceML transmits only one group. Multiple section assignments must be implemented via a custom handler or an additional "Extra Categories" property.
Order Exchange: from Bitrix to Catering
Food delivery orders from the website must arrive in 1C:Catering as "Delivery Orders" or "Sales." Standard CommerceML creates customer orders, but Catering requires a link to the delivery address, delivery time, and delivery zone.
The delivery address is transmitted through order properties. In Bitrix — standard buyer profile fields. In the order XML, they appear in the Counterparty → Addresses section. Catering may not parse non-standard address fields on import — a handler on the 1C side is needed.
Case Study: Pizza Chain
A chain of 8 pizzerias: a unified Bitrix website, each location with its own 1C:Catering database (not centralized). Goal: a unified catalog with prices (prices are the same), but orders must go to the specific location's database based on the delivery zone.
Solution: centralized catalog export from the "master" Catering database to Bitrix (once per day). Orders are routed on the website: the delivery zone is determined by address → the specific location's endpoint is selected → the order is sent to the appropriate Catering database.
Each Catering database has its own exchange URL in Bitrix (multiple exchange nodes in Bitrix, one per location). The router is a custom component in local/components/.
Implementation time: 12 business days including testing at all locations.