Catalog Auto-Filling on Bitrix: Where the Exchange Breaks
Exchange with suppliers formally works: the file is fetched, rows are parsed, products appear on the site.
Everything diverges in the details — and where divergence costs sales: the supplier's price has changed, while the product card still lives with the old one for another day; stock has dropped to zero, but the Buy button remains active. An order is placed for an item that is not available, and the rejection comes only after payment.
The cause is almost always in item matching. The supplier has its own SKUs, we have ours; the link relies on matching names, and the supplier edits the name along with the price.
Duplicates appear, some items silently drop out of the export, and an exchange that fails midway leaves the catalog in a half-finished state — and no one sees it until a customer calls.
Manual product publishing masks the problem but does not solve it: a manager compares price lists by eye and edits prices selectively.
By the end of the month, the catalog and supplier data diverge so much that price errors are sought through customer complaints rather than a report. Catalog auto-filling on Bitrix in this mode does not save time; it shifts manual work to dealing with the consequences.
We break down how this is closed: matching by stable keys, a log of stock discrepancies, and price source priorities — so the catalog reflects supplier data, not the last successful export.
Auto-Filling: What Is Removed from Manual Work
Before automation, publishing a delivery is a manual pass through the price list: download the file, verify SKUs, set prices, unpublish what is not in stock. On a catalog with several thousand items, the cycle takes days, and all that time the site shows yesterday's stock.
Catalog auto-filling parses the feed, matches rows by SKU and manufacturer code, applies rules for price, markup, and units of measure, and publishes the batch as a whole — the same volume takes minutes instead of days.
The share of manual catalog edits shrinks to handling exceptions: rows without a SKU, name conflicts, new categories. Everything else — price rounding, hiding zero stock, bringing attributes to a unified form — is done by exchange rules, not a content manager. Edits are made once in the template and then applied to every subsequent price list.
Stock freshness no longer depends on who remembered about the update and when. The exchange runs on a schedule, the log records every price and quantity change, so a discrepancy with the accounting system is visible immediately, not after a customer complaint.
A whole class of failures goes away: orders for unavailable products, sales at the old price, duplicate items from different price lists, 'stuck' sections with incomplete product cards.
Publishing downtime is handled separately: a broken feed, a missing column, or an unavailable source does not bring down the entire exchange.
Rows with errors go to a queue for review, the remaining items are published as usual, and the previous data version is preserved — the exchange can always be rolled back and you will not be left with an empty catalog.
Loading Methods: Schedule, Events, Manual Import
The loading mode is not an implementation detail but what determines how quickly a supplier's new price reaches the product card. In 1C-Bitrix, catalog auto-filling is built on several basic mechanisms, and each covers its own class of suppliers. Below — by applicability and limitations.
| Option | When It Fits | Limitations |
|---|---|---|
| Exchange on a schedule | The supplier provides an export once a day or less often, volume is tens of thousands of items | The catalog updates with a delay until the next run; a long run competes for resources with the site |
| Event-based loading | The supplier sends notifications that a new export is ready — by email or by calling the receiving endpoint | Protection is needed against reprocessing the same file, plus control that the supplier actually sent the signal |
| Manual export import | One-off purchases, seasonal collections, a supplier without a permanent channel | Keeps a manager busy, SKU and stock discrepancies accumulate, loading history is lost |
| Exchange intermediary service | Five or more suppliers, each with its own format and field set | Setup takes longer, but there is a single normalization loop, queues, and error review |
In practice, the loops are combined: the schedule works as insurance, the event — for suppliers that provide data frequently, manual import — for one-off promotions. This set covers both price freshness and resilience to failures on the supplier side.
Any option writes a loading log: how many items were added, changed, rejected, and why. A discrepancy becomes visible before a customer notices it, and rollback to the previous catalog state remains possible.
Stages of Implementing Supplier Exchange
We structure the work order so that data discrepancies are found before publication on the live catalog, not after. First, we examine what suppliers provide and in what form, then we design the structure, and only then do we enable regular exchange.
- Audit of data sources. We look at what each supplier provides: export format, frequency, column stability, duplicates, and empty rows.
- Catalog structure design. We define sections, properties, and trade offers so that supplier data fits without manual rework.
- Item matching. We build the link by SKU and barcode, describe rules for new items and conflicts when one product comes from several suppliers.
- Exchange setup. We assemble a step-by-step import with a schedule, log, and rollback of a failed run; separately — price and stock updates.
- Run on a test copy of the site. We launch the exchange on a copy with real volumes: measure processing time, check binding to sections, properties, and images.
- Acceptance check. We go through control items and failure scenarios: the file did not arrive, a column changed, stock dropped to zero, the supplier sent an empty price.
- Handover of the support regulation. We document how to connect a new supplier, what to do when the format changes, and how to disable a source without breaking the catalog.
After that, the exchange runs according to this regulation: edits to matching rules and the schedule are made pointwise, without stopping the process. The catalog stays up to date on its own, not after manual proofreading of price lists.
Configurations, Exchange Schemes, and Deliverable Regulations
Auto-filling is not a one-time import setup but infrastructure inside a project on 1C-Bitrix.
After handover, settings, schemes, access rules, and documentation remain — the catalog develops further from them, new suppliers are connected, and support can be handed over to another engineer without reconstructing the logic from memory.
- Exchange scheme — sources (price lists, exports, exchange via supplier APIs), launch schedule, loading order, and storage locations for source files with an archive for reprocessing.
- Matching map — correspondence of supplier fields to catalog sections, properties, and trade offers: section selection, units of measure, SKUs, barcodes, and pack multiples.
- Access policies — which roles work with the exchange, what is available to a content manager and what to an administrator; rights to change prices and stock are documented separately.
- Catalog update instructions — manual exchange launch, restarting a failed step, checking the result, and actions when stock differs from the supplier.
- Publication rules — what to do with a product that disappeared from the price list: unpublish it, move it to the archive, or keep the card with zero stock.
- Exchange documentation — description of formats, processing logs, data flow diagram, and typical errors with ready-made solutions.
- Control regulation — reports after each run, area of responsibility, and signs showing that the exchange has begun to degrade.
Case Study: 40,000 Items and Three Different Suppliers
Before: Manual Consolidation of Three Price Lists
The client is a distributor with a catalog of about 40,000 items and three suppliers, each of which provided a price list in its own format and with its own category structure.
Managers consolidated the exports manually: a full assortment update took 2-3 days, and by the time of publication some prices and stock already diverged from reality. The share of manual edits stayed at 25% — almost every fourth card required intervention.
After: Matching Rules and a Schedule
We described product linking rules — by SKU, barcode, and name, with supplier priority in case of price conflicts, and moved items that the automation did not recognize into a separate queue for review.
The update runs on a schedule: prices and stock are recalculated at night, discrepancies for specific items go into a report.
On the 1C-Bitrix platform, this is a layer on top of the standard catalog — the core and storefront logic were not rewritten, and rollback to the previous catalog state is possible at any time.
The full update cycle was reduced from 2-3 days to 40 minutes, the share of manual edits fell from 25% to 3%, and the load on employees — roughly threefold. Managers handle only exceptions and disputed items instead of transferring rows from someone else's tables.
How Exchange with an Accounting System Differs from Feed Loading
Exchange with an accounting system is a two-way protocol: the source of truth for stock, prices, and orders remains in the warehouse loop, while the catalog on the site only reflects its state.
Export goes in batches in CommerceML format — nomenclature, trade offers, warehouses, stock, prices. Records are matched by external identifier or SKU, so renaming a product on the storefront does not break the connection with the accounting system. Orders and statuses go back, and the manager does not keep double records.
Loading trade offers from a supplier's feeds works differently: it is a one-way stream where the supplier provides a price list in its own format, and we bring it to the catalog structure and distribute it by sections and properties.
Stock here is a snapshot at the time of export, not the current warehouse state; some items come only with a price and a 'made to order' mark. Hence the mandatory deactivation rule: if an item is no longer in the feed, it must not silently remain on sale.
The choice of exchange method dictates the operating model. When a product physically sits in your own warehouse, exchange provides up-to-date stock and correct reservation. When the assortment is a long tail of third-party suppliers, feeds cover it without manual card entry.
In practice, a hybrid more often works: the core of the nomenclature is synchronized with the accounting loop, and additional categories are filled by loading.
The two schemes must not be mixed in one catalog section: stock and prices begin to overwrite each other, and the storefront diverges from warehouse accounting.
That is why we separate sources by sections and properties and set a separate regulation for each — exchange period, price priority, and behavior when a product disappears.
Technical Doubts Before the Start
Supplier exchange rarely goes smoothly from the first run: each export has its own structure, SKUs, and packaging logic. Below are the doubts that most often come up before the start, and how we close them at the level of exchange rules.
How does the exchange avoid duplicates if a supplier's SKU changes?
Matching is not by a single field but by a combination: supplier external code, manufacturer SKU, barcode. When the SKU changes, the card is not recreated — the link is updated, and the row that would create a second card is stopped by a check.
What happens to items that are not in the export?
By default, such products are not deleted: they are unpublished or moved to the 'out of stock' status according to a specified rule. The catalog preserves descriptions and attributes, and a returning item only needs to be enabled again.
How are units of measure and packaging taken into account?
In exports, the price is often indicated per package, while the customer sees the cost per unit. We set a conversion coefficient and rounding rules in the card so that price, stock, and order multiple match each other.
Does the site stop during the exchange?
No. The exchange runs in portions with load limits, and changes are published after a portion completes. Reindexing is performed separately, so the storefront remains available and no downtime window occurs.
Start Procedure and What We Need from Your Side
The first days go not into code but into data review: until the real feed is visible, any estimate of catalog auto-filling rests on assumptions.
That is why we start the project with sources and matching rules — this way the scope of work is fixed before the first line of code, rather than refined along the way.
What we need from your side to come back with an estimate and a plan:
- links to supplier feeds and the access method — export by link, a file on the server, or an account for a protected catalog;
- update format and frequency: CSV, XML, or YML, update on a schedule or on request;
- a full example file, not a fragment — a trimmed file does not show empty fields, duplicates, or broken encoding;
- access to a test copy of the site so imports can be run without risk to the live catalog;
- a correspondence reference: how a supplier's product is linked to a section, trade offer, and properties;
- rules for disputed cases — what to do with a disappeared product, a changed price, and zero stock;
- a contact on the supplier side or from your team for format clarifications.
Then we assemble the scope of work: feed review, matching rules, regular import with a run log, error handling, and failure notifications. After the plan is approved, we deploy the loop on a test copy, check it on a real feed, and only then enable updates on the live catalog.
Describe the task and send links to the exports — we will come back with an estimate, timelines, and a stage-by-stage plan.