Auto-filling the Bitrix catalog: where exchange with feeds breaks
Exchange with supplier feeds looks like a "set it once and forget it" task: the supplier provides a file, and the import distributes it across catalog sections.
In practice, auto-filling the Bitrix catalog is a continuous flow where things break either at the source, in matching, or during the upload itself. The cost of a break is orders for a product that is not in stock.
The first and most common failure is stock desynchronization. Product export from 1C runs on a schedule, while sales happen in real time: between two exchange runs, the stock in the store goes to zero but remains positive on the website. There is nothing to fulfill the order with, and the sales department handles it manually.
Second — duplicate items in the catalog. If matching is based on the name or on a SKU that the supplier changes together with the packaging, the import does not find the existing card and creates a new one.
Stock is spread across several items, and search and filters show the customer the same product twice.
Third — overwriting manual edits: the next upload rewrites descriptions and properties added by the editor, because the import does not distinguish what came from the supplier from what a person edited.
Fourth — feed upload interruption in the middle of the file: response timeout, truncated file, encoding change on the supplier's side.
The catalog remains in an intermediate state — some prices are updated, some are not, and from the storefront it is impossible to tell which ones.
None of these breakdowns is fixed by yet another scheduled import. Below we look at how this is addressed: stable matching keys, protection of manual fields, chunked upload, and integrity checks after each export.
What automated exchange delivers: five measurable effects for the store
Automated exchange with supplier exports stops being a manual operation, but its value is measured not by "convenience" but by metrics.
Below are five effects that we record at acceptance: they show that 1C-Bitrix together with exchange handlers works as intended, not just "roughly similar."
Share of manual edits — a few percent
Matching by SKU and barcode plus a synonym dictionary covers most items. The content manager only cleans up new categories and name conflicts — standard rows pass without their involvement.
Full update — minutes instead of hours
Exchange runs in chunks with step-by-step continuation, so a full catalog run does not stretch overnight and does not block the storefront. The discrepancy in price, stock, and availability is reduced to one cycle.
Failure class during upload
An error in one row does not crash the import: the item goes into a report with the row number, and the rest is applied. A failure in the middle of the file no longer leaves the catalog in a half-finished state.
New products are published the same day
The item appears on the website together with specifications, photos, and section assignment, without waiting in line for manual entry. The product can be sold immediately after it appears in the price list.
Employee workload
Routine work moves to a defined procedure: the person focuses on card quality rather than transferring rows. The freed-up time goes to descriptions and fields for search results, which are what affect sales.
Exchange with the Bitrix catalog: supplier feed upload schemes
The catalog is filled from supplier exports — an XML, CSV, or YML file that is updated according to the supplier's schedule.
The difference between schemes is not the format but where the reconciliation point is: in the catalog itself, in a buffer table, or in the accounting system. This determines behavior when stock diverges and how quickly an item returns to sale.
| Feed upload scheme | When it fits | Exchange scheme limitations |
|---|---|---|
| Direct upload to catalog | one supplier, simple products without trade offers | the export writes to live tables: if the connection breaks, the item remains with some properties, and rollback is only from a backup |
| Intermediate warehouse | multiple suppliers, different encodings and section structures | a separate matching table and a procedure for cleaning it are needed, otherwise SKU duplicates accumulate |
| Exchange via 1C | prices, stock, and discounts are calculated in the accounting system | depends on the exchange schedule: between sessions, the catalog shows outdated stock |
| On-demand import | one-time supplies, rare items, test exports | manual launch does not scale: a missed session goes unnoticed until a customer complaint |
The common limitation of all schemes is item matching. As long as the supplier SKU remains the key, any change in spelling produces a new item instead of updating the existing one.
Therefore the scheme is chosen together with key normalization rules and an import log that shows how many rows were accepted, updated, and rejected per session.
Implementation order: from feed analysis to update procedure
We lock the work order before the start: exchange breaks not on code but on assumptions — "the SKU is unique," "the price always includes tax," "stock is updated once a day." That is why each step ends with an artifact that can be verified against data, not words.
- Supplier feed analysis. We take one price list from each source and examine the structure: XML/YML, CSV, or JSON, encoding, delimiters, category nesting, required fields. We count the share of items without a SKU, with duplicates, and with different units of measurement — this determines the scope of the rules.
- Catalog schema design. We decide how products will fit into information blocks and trade offers, which properties the feed fills and which remain manual — descriptions, photos, meta tags. We choose the exchange strategy: full replacement, update by code, or delta, and what to do with items that disappeared from the price list.
- Matching setup. We define linking keys — supplier code, barcode, SKU — normalization of names and brands, unit conversion, and markup rules. We cover each rule with a test case so that a discrepancy surfaces during analysis, not on the storefront.
- Run on a copy. Full import on a test environment: we measure exchange time, the number of created and updated items, and the volume of errors in the log. We check that prices and stock were recalculated, sections were not duplicated, and card URLs did not change.
- Exchange acceptance. We reconcile the catalog with price lists using control samples: number of items, prices, stock, properties, section assignment. We record which discrepancies are acceptable and how they are handled.
- Handover with update procedure. We provide the launch schedule, the procedure for handling errors and notifications, instructions for the catalog editor, and rollback rules: how to restore the previous state if the supplier sent a corrupted price list.
Matching rules and templates: what the team hands over
The client receives a working set of configurations and documents that allows the catalog to be maintained without a developer.
Each artifact is stored in the project repository and duplicated by a section in the admin area — a change of content manager does not require reconstructing the logic from correspondence.
- Category and property matching map — a "supplier category → catalog section" table: synonyms in names, units of measurement, mapping properties to the reference book, behavior for new categories.
- Supplier priority rules — who provides the price, who provides the description and photos, how data overlaps, and what happens when a supplier leaves the list.
- Upload profiles — parameters for each supplier: file format (YML, CSV, XLS), encoding, exchange frequency, threshold for mass item deletion.
- Run log — what was accepted, updated, and rejected, with the reason for rejection: category match not found, price below threshold, corrupted SKU.
- Employee instructions — manual exchange launch, connecting a new supplier, actions on error, whom to contact for a fix.
- Set of checks before publication — required fields, limit on the share of changed prices, quarantine of new items until operator confirmation.
We hand over the set with an on-screen walkthrough: we show a real run, review rejected items, and correct the matching map together. After that, the editor changes the rules — the developer gets involved only when the exchange logic changes.
Project case study: 12 suppliers and 40 thousand items
Twelve suppliers sent price lists in different formats: XML, CSV, and spreadsheets. A manager manually consolidated forty thousand items once a week, halting other tasks.
Stock discrepancies were found only after an order — the product was not in the warehouse, but the card was active.
Starting point
A full catalog update took two days, and throughout that time data accuracy depended on people.
Exchange failed eight to ten times a month: a corrupted file from one supplier stopped the upload of the others, and diagnosing the failure took hours and was done from scratch each time.
What changed after the rebuild
On 1C-Bitrix, we built an exchange with a unified matching rule: products are linked by SKU and barcode; for duplicates, priority goes to the supplier with stock and a short delivery time.
Each feed is processed separately — an error in one file does not block the others, and a failed row goes into the log with the reason indicated.
A full update of forty thousand items now takes eighteen minutes on schedule, without manager involvement. Exchange failures are one per month instead of eight: previously a breakdown was found from a customer complaint, now from a log entry.
If a supplier sends an incorrect price list, the catalog remains on the previous data — rollback does not require manual restoration.
How does scheduled updating differ from event-triggered launching?
These modes differ not in price list parsing but in the trigger: who decides that it is time to start the exchange. Scheduled updating is triggered by a scheduler timer — once an hour, once a day, in a nightly window. Event-triggered launch happens at the moment the supplier publishes a new file.
With scheduled updating, the exchange frequency is set in advance, and this is its strength: the load on the catalog is predictable, heavy runs are spread over time and do not overlap with indexing and exports.
The price is a delay in product appearance: if the price list arrives ten minutes after the exchange, the customer will see the new price only by the next cycle.
Event-triggered launch works differently: the exchange monitors the file modification date or checksum and starts the import only if the content has actually changed.
The product appears almost immediately, but the mode's weak point is supplier discipline: the price list may be re-saved every few minutes without changes, and each such save triggers a full catalog run.
| Mode | When it fits | Limitations |
|---|---|---|
| Scheduled | Price lists update rarely; a steady rhythm matters more | Delay equals the exchange interval |
| Event-triggered | The file is published infrequently and at different times | Extra runs when the file is re-saved |
| Event plus delta | Large catalog; a few percent of rows change | SKU reconciliation and processing of removed items are needed |
In 1C-Bitrix, both modes are configured with standard tools, so in practice they are combined: an event serves as a trigger with frequency limiting, changes are pulled in by SKU, and a full catalog reconciliation moves to a nightly window — this way the delay is minimal, and the load on the catalog stays within acceptable limits.
Technical concerns: what we clarify before work starts
Exchange rarely breaks on the first run — problems surface on real data: the file changed, a product disappeared, two price lists overlapped. We fix the catalog's behavior rules for disputed situations before the start.
Below are the questions most often asked before enabling catalog auto-filling on 1C-Bitrix.
A product disappeared from the feed — will it be deleted from the site?
The item is not deleted immediately: first availability is removed, then publication after a specified period — usually several days. This way seasonal absence does not knock the page out of search; we delete only what no supplier has.
The same product is available from two suppliers — will there be a duplicate?
We match by SKU and barcode, not by name, and normalize the spelling. There is one card; the second supplier is a source of price and stock with priority by delivery time.
The supplier changed the file structure — will the exchange break silently?
The file is checked for required columns and delimiters. If they do not match, the exchange stops with a notification, the catalog remains untouched — we fix the schema and restart.
The exchange was interrupted in the middle — will the catalog remain half-empty?
The upload runs in batches with a log: a repeated launch continues from the last successful batch instead of re-uploading everything. The item key makes the write repeatable.
We are handing the exchange over to another team — what is needed for that?
The configuration, matching rules, and logs are in the repository with field descriptions. An engineer can start the launch without us and see where the exchange stopped.
Let's discuss the task: send sample feeds and the current exchange scheme
For the exchange estimate to rely on facts rather than assumptions, a minimum set of input data for evaluation is needed.
The closer the sample feeds are to production ones — with duplicates, broken rows, and non-standard encodings — the more accurate the work plan and the fewer edits during launch.
- supplier feed samples as is: XML, CSV, JSON, YML, including problematic exports and files with non-standard structure;
- current exchange scheme: what fills the catalog now, scheduled or manual, where intermediate data and logs are stored;
- card composition: which properties and trade offers are needed, how to handle prices, stock, and items withdrawn from sale;
- matching rules: by SKU, barcode, or name, whether there is an accumulated correspondence base and who maintains it;
- source limitations: request limits, export availability windows, requirements for the output data format;
- access: a test environment with a catalog copy, a source key or one-time export, a contact on the supplier side.
In response, we send an exchange estimate with a list of bottlenecks, an exchange scheme with matching points, error handling, and rollback, as well as a stage-by-stage work plan with launch order.
Describe the task and attach what you already have — we will get back to you with an estimate and plan.