Thousands of trade offers hang unlinked to products after a mass import from 1C or migration from another platform. As a result, the product card is empty, prices and stock are not transferred, and the cart does not work. Restoring the binding manually for 10,000 SKUs is a week of routine work. We solve this task with scripts for mass binding by XML_ID, article number, or external table. Our bulk SKU binding service saves up to 70% of time compared to manual labor. With over 10 years of experience and 500+ successful projects, we guarantee correct catalog operation. Get a consultation — we will perform a free database analysis and offer the optimal solution. Prices start from $200 for small catalogs.
Case: clothing store with 15,000 SKUs
After migrating from OpenCart to Bitrix, all offers became unlinked. In 2 hours we wrote a script that matched articles by XML_ID and restored the binding. The catalog was working within a day.Why is it important to bind trade offers correctly?
Without correct binding via the CML2_LINK property, Bitrix cannot assemble a unified trade catalog. Offers are not displayed in the product card, prices and stock are not transferred to the cart, and the facet filter returns empty results. This is especially critical for online stores with a large assortment — a binding error leads to loss of conversion and increased returns. The cost of such an error can reach tens of thousands of rubles in lost revenue per day. Proper product-offer relationship management is essential for catalog integrity.
How to mass restore trade offer binding?
Step 1. Data structure analysis
Determine the product infoblock (catalogIblockId) and offers infoblock (offersIblockId). Check the CML2_LINK property in b_iblock_property. This is a prerequisite for any bulk SKU binding or catalog binding errors recovery.
SELECT COUNT(*)
FROM b_iblock_element ie
WHERE ie.IBLOCK_ID = {offers_iblock_id}
AND NOT EXISTS (
SELECT 1 FROM b_iblock_element_property iep
INNER JOIN b_iblock_property ip ON ip.ID = iep.IBLOCK_PROPERTY_ID
WHERE iep.IBLOCK_ELEMENT_ID = ie.ID
AND ip.CODE = 'CML2_LINK'
AND iep.VALUE IS NOT NULL
);
Step 2. Mass binding by XML_ID
The most common scenario: products and offers have an article from 1C in the XML_ID field. We create a mapping and set CML2_LINK in batches of 200 records. This XML_ID binding approach is 20 times faster than manual binding and restores SKU attachment efficiently.
$offersIblockId = 11;
$propRes = \Bitrix\Iblock\PropertyTable::getList([
'filter' => ['IBLOCK_ID' => $offersIblockId, 'CODE' => 'CML2_LINK'],
'select' => ['ID'],
])->fetch();
$linkPropertyId = $propRes['ID'];
$catalogIblockId = 10;
$productMap = [];
$productsRes = \CIBlockElement::GetList([], ['IBLOCK_ID' => $catalogIblockId], false, false, ['ID', 'XML_ID']);
while ($row = $productsRes->Fetch()) {
$productMap[$row['XML_ID']] = $row['ID'];
}
$offersRes = \CIBlockElement::GetList([], ['IBLOCK_ID' => $offersIblockId], false, false, ['ID', 'XML_ID']);
$batch = [];
while ($row = $offersRes->Fetch()) {
$parentXmlId = substr($row['XML_ID'], 0, 8);
if (!isset($productMap[$parentXmlId])) continue;
$parentId = $productMap[$parentXmlId];
$batch[] = ['offer_id' => $row['ID'], 'parent_id' => $parentId];
if (count($batch) >= 200) {
bindOffersToProducts($batch, $offersIblockId, $linkPropertyId);
$batch = [];
}
}
if (!empty($batch)) {
bindOffersToProducts($batch, $offersIblockId, $linkPropertyId);
}
function bindOffersToProducts(array $batch, int $iblockId, int $propId): void
{
foreach ($batch as $item) {
$existing = \Bitrix\Iblock\ElementPropertyTable::getList([
'filter' => ['IBLOCK_ELEMENT_ID' => $item['offer_id'], 'IBLOCK_PROPERTY_ID' => $propId],
'select' => ['ID'],
])->fetch();
if ($existing) {
\Bitrix\Iblock\ElementPropertyTable::update($existing['ID'], ['VALUE' => $item['parent_id']]);
} else {
\Bitrix\Iblock\ElementPropertyTable::add([
'IBLOCK_ELEMENT_ID' => $item['offer_id'],
'IBLOCK_PROPERTY_ID' => $propId,
'VALUE' => $item['parent_id']
]);
}
}
}
Step 3. Binding via CSV mapping
If the logic for determining the parent is more complex (e.g., by color and size), we use an external table. Example file:
offer_xml_id,parent_xml_id
SKU-001-RED,PROD-001
SKU-001-BLUE,PROD-001
The script loads the mapping, finds element IDs by XML_ID, and sets CML2_LINK. Performance: up to 10,000 bindings per minute. This is part of our CML2_LINK configuration process.
How to verify binding correctness?
After binding, be sure to:
- Randomly check product cards on the public side — offers should be displayed.
- Clear the tagged infoblock cache.
- Reindex the facet filter if offers participate in filtering.
\Bitrix\Iblock\InformationBlock::cleanTagCache($catalogIblockId);
\Bitrix\Iblock\InformationBlock::cleanTagCache($offersIblockId);
\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($offersIblockId);
Comparison of manual and automatic binding
| Parameter | Manual binding | Automatic binding |
|---|---|---|
| Time for 10,000 SKUs | ~1 week | 2–4 hours |
| Error risk | High (human factor) | Minimal (algorithmic control) |
| Scalability | Low | High (batch processing) |
| Cost savings | High hourly cost | Tens of times reduction |
What is included in the service
We offer a turnkey solution for catalog restoration. The deliverables include:
- Documentation of the current binding structure (CML2_LINK configuration, product-offer relationship).
- Test script on a copy of the database (staging environment).
- Execution of mass offer update on production database.
- Report with results: how many offers were bound, how many skipped.
- Consultation on further 1C Bitrix integration with CommerceML to prevent future failures.
- 30 days of technical support after completion.
Typical binding errors
- Missing unique key — when XML_ID are duplicated or empty.
- Different article generation patterns — we have to write custom parsers.
- Ignoring caching — after binding, be sure to clear infoblock cache.
- Incomplete reindexing — facet filter shows old data.
- Incorrect catalog binding errors due to improper field mapping.
Timelines and cost
| Offer volume | Approximate time | Estimated cost |
|---|---|---|
| Up to 1,000 | 2–4 hours | $200–$400 |
| 1,000 – 20,000 | 1 day | $500–$1500 |
| 20,000+ | 2–3 days (with mapping debugging) | Custom quote |
Cost is calculated individually. Get a consultation — we will evaluate your project for free. Order catalog restoration — and your products will be back on sale. We can complete the work within 2-4 hours for small catalogs.
Why choose our team
Our experience in restoring large catalogs is measured in hundreds of successful projects. We work with stores where the number of trade offers exceeds 100,000 items. Each project is individual, and we take into account the specifics of data storage in your database. Using batch processing and optimized SQL queries allows us to work with loaded databases without the risk of locks. After completing the work, we provide a detailed report on results and recommendations for preventing similar problems in the future. Our specialists have undergone official training in 1C-Bitrix architecture and hold developer certificates, which guarantees high quality work in all cases.
Our approach to solutions
Each task requires individual analysis and careful planning. We do not use template solutions — each project is adapted to specific requirements and existing infrastructure. Our team has experience with projects of various scales: from small stores to high-loaded platforms with millions of operations per day.
Guarantees and support
We provide a 12-month warranty on the work performed. During this period, we fix any emerging problems for free. After project completion, we provide full documentation and training for your team. Technical support is available for 30 days after launch — we will help resolve any questions.