Setting Up Item Export from 1C:UT to Bitrix: No Data Loss

Why exporting the 1C UT item catalog to Bitrix breaks

Catalog exchange between 1C and the website breaks not on transport, but on matching reference data. In the accounting system, items, characteristics, prices, and stock balances are stored in different registers, while on the website this is one infoblock with trade offers.

As long as the rule finds an item by code or external code, everything matches; if you rename an item in the accounting system or recreate it, the exchange does not recognize the record and creates a second card instead of updating the first.

Hence the typical item exchange errors: duplicate items in the catalog, mismatched characteristics, empty or overwritten properties.

Properties and values in 1C are a separate reference catalog, it has its own hierarchy, and without explicit mapping to infoblock properties it either is not exported at all or overwrites with each synchronization what managers edited on the website by hand.

Trade offers add a second level: variants of one model with different characteristics attach to the wrong product, and the catalog starts duplicating items instead of grouping them under one card.

The cost of such a failure is measurable: after each change in the accounting system, someone goes into the admin panel and manually loads items, the catalog and accounting diverge, and some pages lose their URLs and drop out of search.

The more often the assortment changes, the faster manual work grows — and the more the exchange lags behind the real state of the warehouse.

We analyze how this is closed: where exactly reference matching is configured, how to maintain card uniqueness, and what to do so properties and characteristics travel to the website without manual loading.

What changes after a well-configured exchange: effect in numbers

A well-configured exchange turns the catalog into a reflection of the accounting system. Below are five results measured before and after launch.

Catalog updates — minutes instead of hours

The full cycle of item export from 1C:Trade Management fits into minutes, and a single price edit reaches the storefront almost instantly. The exchange proceeds in batches by changed items, so catalog growth does not lengthen the cycle linearly.

Stock balances on the website match accounting

The balance updates at the moment a document is posted, not on a schedule. The share of items where the website diverges from the accounting system falls from percentages to units — “out of stock” stops being a lottery for the buyer.

Manual edits are the exception, not the norm

Nine out of ten items pass through the exchange without an editor’s involvement: properties, prices, units of measurement, and images are pulled in by matching rules. Editorial labor costs are reduced several times over.

Cards are filled in completely

The share of cards with a full set of properties, description, and photos grows to 90–95%: an empty field is immediately flagged in the exchange report. This directly affects both search output and card conversion.

An entire class of failures goes away

Zeroed prices, duplicate items, and overwriting of manually edited cards disappear as a class: the exchange runs by key, and conflicts are resolved by source priority. The editor no longer restores the catalog after a failure.

Catalog exchange methods: standard module, files, service bus

The standard exchange module, intermediate database, files, and service bus solve one task — deliver item changes from the accounting system to the website — but behave differently under volume, frequency, and communication failure.

The mode choice is determined by how many items change in one session, how often this happens, and what the website shows at the moment of failure.

In practice, modes are combined: the nightly export is run by the standard module, while a new supplier or archive is loaded as a one-time file. When which option is justified for your catalog — we discuss below.

Exchange setup stages: from audit to handover to support

The exchange breaks not during the export itself, but on a mismatch of data models: in the accounting system, items live as a hierarchy of groups with characteristics and units of measurement, while in the catalog they are sections, trade offers, and properties.

Until this mismatch is described explicitly, a test run turns into manual item editing. Therefore the work proceeds in sequential stages, where each relies on the result of the previous one.

1. Audit of reference data — we export a snapshot: how many active groups there are, whether duplicates and empty nodes exist, which characteristics and units of measurement are actually used, what share of items is discontinued or has no price.
2. Schema design — we fix what becomes catalog sections, what becomes trade offers, and what becomes properties; separately we describe the rule for items that are not yet in the catalog.
3. Attribute mapping — a table “source field → target field” with types, required status, and default values for empty cells.
4. Exchange rules setup — nodes and directions, filters by groups, schedule, behavior on update and unpublishing, order of transferring images and stock balances.
5. Test exchange run — launch on a copy of the catalog: we verify the number of items and prices for control groups, check a repeat run — it must not create duplicates or lose links.
6. Handover of exchange to support — launch regulations, error log, control points after each export, and procedure for deviations, access for responsible persons.

At the output, the client receives not a one-time launch but a managed process: deviations are visible in the log, and changes in reference data do not require rewriting rules.

What stays with you: exchange schemas, matching rules, regulations

The item exchange lives longer than the contractor who configured it: if the rules remain in correspondence, the next catalog edit starts with archaeology.

Therefore at the output you receive a set of documents by which the exchange can be expanded, accelerated, or handed over to another team without parsing code.

• Exchange schema: which objects go to the website catalog, in which direction, what starts a session — a schedule or a record change — and which fields the exchange deliberately does not touch.
• Property matching rules map: a table “source field → catalog property → type → conversion rule” for items, trade offers, characteristics, units of measurement, and prices.
• Identification rules: by which external identifier a product is linked to a page, what happens on a duplicate, renaming, or SKU change.
• Error handling regulations: which error stops the exchange, which skips an item, where the notification arrives, and within what time it is reviewed.
• Discrepancy map: fields that are interpreted differently in the accounting system and on the website, with the adopted decision for each.
• Launch and rollback instructions: how to enable the exchange manually, how to verify the result after a failure, and how to return the catalog to its previous state.
• Exchange documentation: a single file with the schema, property map, regulations, and revision history — what is handed over to the next contractor in full, without verbal explanations.

Case study: a catalog of 40,000 items — exchange without manual edits

For an equipment distributor, a catalog of 40,000 items was updated manually: a manager launched a full export of items from 1C UT once a day and after each launch sorted through the error log.

Export completeness stayed at 85–88% — items without a filled unit of measurement or with a duplicate SKU simply did not reach the website, and discrepancies surfaced through customer calls. A price or characteristic change waited for the next scheduled run.

What was changed

1C:Trade Management remained the accounting system, the website — the storefront; between them they placed an automatic item exchange based on document change events, not on a schedule.

Items are matched by the external code from the accounting system, so renaming or changing an SKU does not create a duplicate and does not break the link.

Items with unfilled required attributes do not hold up the whole batch: they go into quarantine with a log entry, while the remaining 40,000 continue to exchange.

Metrics before and after

Export completeness grew from 85–88% to 99.9%, the share of discrepancies between the website and accounting fell from 6–7% to 0.1% — disputed items are now visible in the report, not in correspondence with a customer.

Response time to a change in the accounting system decreased from a day to 2–5 minutes. Manual catalog edits after implementation — zero.

How does direct exchange differ from exchange via an intermediate database?

Direct exchange is when the website accesses the accounting system directly: on a schedule or event, a published service is called that reads the item catalog, characteristics, prices, and stock balances and serves them to the website.

Each session is executed by 1C UT itself: it builds the selection, expands characteristics, and forms a package. While the catalog is small, this works predictably and is edited in one place.

Then the price of simplicity begins. The export runs on the live accounting contour: a long query holds the connection and competes with user work, while website unavailability or a communication break brings down the entire session. You have to set retries, limit selection depth, and move the exchange to non-working hours.

The intermediate database decouples the contours. The accounting system sends items and prices according to exchange rules to a separate node, and the website pulls data from there at its own pace.

The accounting contour does not know about the website, and the website does not know about the load on accounting: the sides can be stopped and updated in turn, while the exchange queue picks up missed changes.

Decoupling is needed when there are several channels, when a large catalog with characteristics and stock balances is published, when the accounting database cannot be slowed down, and when resilience to failure on either side is important.

Direct exchange wins in simplicity: edit logic lives in one place, without synchronization of two contours and an extra node in the schema.

We choose the mode by load: we calculate the export volume, frequency of changes, and acceptable data lag — and based on this we decide whether to run the exchange directly or build an intermediate node.

Common technical doubts before starting catalog exchange

Engineering doubts before launching an exchange are almost always the same: how to transfer characteristics and trade offers without rewriting the entire catalog, what to do with discontinued items, and how to catch discrepancies if the catalog was filled manually.

Can I update only changes rather than the entire catalog?

Yes. Only changed objects are registered in the accounting system, and the difference goes to the website — this is partial catalog update.

A full reload is needed once at the start and later as a control reconciliation: in terms of time and load on the database, it is noticeably more expensive.

How are discontinued products deleted?

An item does not disappear silently. Discontinued items are first deactivated: unpublished but remain accessible via a direct link and in old orders. Physical deletion is a separate operation with confirmation, so as not to break links with order history.

The catalog is already filled manually — will the data be overwritten?

This is the main risk, and it is removed by a run on a copy. We reconcile catalog discrepancies with accounting, mark the fields that we maintain on the website (descriptions, photos, meta tags), and exclude them from overwriting. The exchange then touches prices, stock balances, and structure — manual edits remain in place.

Let’s discuss the catalog exchange task and come back with a plan

Describe the current schema: which reference data is involved, how often prices and stock balances change, how many trade offers and properties need to be processed, and what limits the acceptable website downtime.

This is enough to come back with an estimate and work plan, not with general assumptions. If the exchange is already configured and failing — attach the log and examples of discrepancies; we will start the analysis with them.

What is included in the turnkey exchange setup plan:

• object correspondence map: items, trade offers, properties, warehouses, price types — with an indication of the fields that remain with the website;
• identification schema: linking by external identifiers instead of matching by name, so that renaming does not produce duplicates;
• synchronization regulations: schedule, batch volumes, behavior when one of the sides is unavailable, and reprocessing of failed items;
• handling of special cases: discontinued items, made-to-order products, packaging multiples, units of measurement;
• implementation procedure without stopping the website: initial load in the shadows, reconciliation of control samples, switching, and rollback point;
• documentation set: exchange node settings, instructions for the content manager, and regulations for actions on discrepancies.

To discuss the exchange task concretely, write what already works and what is in the way: a one-time load, regular synchronization, or a complete schema replacement.

We will come back with an estimate, scope of work, and order of stages — with clear timelines and without stopping sales during the switchover.