Why exporting 1C UT characteristics generates duplicate SKUs
In 1C:UT, an item is described by a pair "nomenclature + characteristic", while in 1C-Bitrix each combination of properties is a separate trade offer with its own set of values.
Catalog exchange links them by identifier, so everything depends on how complete the composite key is and whether it remains unchanged in the accounting system.
A typical catalog exchange error is leaving only the nomenclature code as the key.
When a new characteristic appears, the server cannot find the existing offer by the composite attribute and creates another one: the nomenclature is duplicated during exchange, and the previous SKU is left without price and stock. In the catalog, this looks like a product card that cannot be purchased.
The second layer is properties. If the exchange rule does not include the transfer of offer properties with a reference to the catalog, values arrive empty or as free text. Matching is then done by string, and "black" and "Black" diverge into two SKUs.
Renumbering characteristics when re-posting documents adds its own: the identifier changes, and the next export of 1C UT characteristics again does not recognize what has already been uploaded.
The result is data discrepancy: stock lies on one item, price on another, duplicate SKUs in the catalog grow faster than they can be cleaned manually. Below we analyze how this is closed at the level of exchange rules, matching keys, and property filling.
What a correct exchange gives: measurable results
A single product card instead of a set of duplicates is the basic effect from which the rest are measured.
Characteristics (color, size, material, packaging) come from the accounting system as trade offer properties and are combined into one card with variants, not into separate catalog items.
Search and filters stop showing one product in five rows, and the manager stops having to merge them manually.
The speed of publishing changes is measured not by the number of clicks, but by the time from an edit in the accounting system to its appearance on the storefront.
With a configured exchange, a new price, description, or discontinuation goes out in one pass; with manual transfer, the same edit waits for the next export or gets lost between tables.
Reduction of manual catalog edits is a consequence of the same order. Matching is done by code and rules, not by name, so the volume of manual operations falls to handling exceptions: new property groups, non-standard units of measurement, items without a code.
Separately, a class of failures related to lost product properties goes away. If a property did not arrive or arrived without a link to the variant, the card remains without a filter — the buyer simply does not find it, and the error surfaces later. With a configured exchange, such discrepancies get into the reconciliation report on the same day.
Effect summary: the catalog no longer requires constant supervision, and data in the accounting system and on the website no longer diverge. This provides a steady background for assortment growth — new nomenclature fits into the same loop without rebuilding the logic.
Catalog synchronization options: full, incremental, queue
A full catalog export re-reads the nomenclature and the characteristic catalog entirely. The logic is simple and stateless on the exchange side — but on a catalog of tens of thousands of items, one pass takes hours and all this time keeps a load on both loops. Therefore it is used for initial filling and periodic reconciliations, not as a daily mode.
Incremental exchange transfers only what has changed since a given mark — the load drops several times, but the scheme relies on a reliable change attribute.
If the time on servers diverges or the mark is reset when transferring the database, some edits silently do not arrive, and the discrepancy surfaces only during reconciliation.
The exchange event queue flips the logic: edits are queued at the moment of writing and processed one by one, giving minimal delay and precise knowledge of what exactly did not arrive — at the cost of a separate service and handling of stuck messages.
| Catalog synchronization scheme | When it fits | Limitations |
|---|---|---|
| Full catalog export | Initial filling, rare reconciliations, small catalog | Long pass, peak load, cannot keep up with frequent edits |
| Incremental exchange | Catalog changes regularly, but not constantly | Depends on the correctness of the change mark; gaps are visible only during reconciliation |
| Exchange event queue | Frequent edits, prices and stock needed almost immediately | Requires a separate queue service, handling of failures and retries |
The catalog synchronization scheme is chosen by volume and frequency of edits, not by ease of setup.
For exporting 1C UT characteristics, this is fundamental: the exchange must go by a stable key of nomenclature and property, otherwise one product arrives as several cards and duplicate SKUs accumulate with each synchronization.
Exchange implementation stages: from audit to handover
Exchange breaks not at setup, but at the input: if in 1C:UT characteristics are created as separate items, and product properties on the website are described differently, the export generates duplicate SKUs. Therefore we first analyze the catalog, then write the rules. Each stage is closed with a verifiable result.
- Nomenclature audit — export the catalog to a file, count real items versus variants, find mixed cases: some characteristics are created as properties, some as separate cards. The output is a discrepancy map with the volume of normalization.
- Product property matching — a correspondence table: characteristic in the accounting system → property, trade offer, or field in the website catalog. We mark what becomes an SKU variant and what becomes a filter characteristic. We agree before writing the rules.
- Catalog exchange setup — exchange node, object composition, splitting the export into portions so that large sections do not block the website. We close duplicates in the rules: matching by external key, not by name.
- Test data transfer — a run on a copy of the production catalog: compare the number of items, variants, and prices before and after, check that a repeated export does not create cards. We measure the time of full exchange and change exchange.
- Checking cards and filters — variants are selectable, prices and stock are substituted, the property filter returns the correct list. We fix discrepancies in the rules, not manually in the catalog.
- Handover to support — node scheme, matching table, launch regulations, and procedure for failure. We set up logging so that in case of a discrepancy it is clear at which exchange step it occurred.
Documentation, regulations, and rules for matching characteristics
Exchange with a trade configuration lives for years: new properties appear, product groups change, a second website is connected.
If agreements remain in correspondence, the first edit breaks the correspondence — the export of characteristics goes to the wrong products, and articles are duplicated.
Therefore, at the end of the work, we hand over a set of artifacts by which any engineer and content manager can continue the exchange.
- Exchange scheme: order of exporting characteristics and trade offers, what is returned back, where the responsibility boundary of the systems lies.
- Field correspondence map: source attribute, property or characteristic on the website, requiredness, transformation rule, unit of measurement.
- Property matching rules: what becomes a characteristic, which values are normalized, how empty and conflicting ones are handled — with examples by product groups.
- Catalog update regulations: exchange schedule, actions in case of discrepancy, catalog snapshot before loading, and rollback procedure.
- Instructions for the content manager: how to correct a characteristic manually so that the next exchange does not overwrite it or create a second article.
- Exchange documentation: description of the node, access rights, handlers, and journals — so that the system can be handed over to an engineer without correspondence.
- Log of edits to matching rules: what changed, for which product groups, and why — when analyzing discrepancies, the cause is immediately visible.
Case study: catalog and accounting system without duplicate items
What it was before
In 1C:UT, characteristics are a separate catalog linked to nomenclature, while in the catalog each combination of properties turned into a standalone product.
The exchange exported nomenclature and characteristics in two independent streams: if a property was renamed or a new value added, the website created a new item instead of updating the existing one.
On 18,000 active articles, 4,100 duplicates accumulated, and managers manually edited about 60 cards per week.
What was changed
We made the characteristic part of the matching key: each combination of properties received a stable identifier independent of the name.
The exchange became two-step — first the characteristic catalog is synchronized, then the nomenclature references already existing values; if there is a mismatch, the item is not created but goes into the discrepancy report.
A full exchange took 40 minutes, and during this time the catalog switched to read-only mode; now data is applied in portions, without stopping sales.
What became
Duplicates were closed by merging cards with transferring order history and links to sections — the share of automatically matched items grew from 71% to 99.4%. Manual edits remained around ten per month, and almost all were for new supplies, not previously created products.
Catalog downtime during exchange decreased from 40 minutes to zero: the buyer does not notice the moment when data is updated.
How does event-based exchange differ from scheduled exchange?
Event-based exchange and scheduled exchange solve the same task — deliver characteristic changes from 1C:UT to 1C-Bitrix — but behave differently as nomenclature grows. In the first case, the accounting system itself reports that an object has changed. In the second, the website periodically pulls a portion of data.
Event-based. An edit of properties or trade offer composition goes into the queue, the handler applies it to the card by external key. Catalog update delay is seconds, transfer volume is proportional to the number of edits, not the catalog size.
The downside: a missed event does not return by itself, so a delivery log and idempotent processing are needed — otherwise a repeat creates a duplicate SKU.
Scheduled. Once an hour or at night, an export of 1C UT characteristics and comparison with the current catalog state takes place. The scheme is easy to restart and reconcile, but between runs the website shows old prices and stock. With large nomenclature, the run window grows, runs overlap, and some changes are lost.
| Scheme | Update delay | When it fits | Limitations |
|---|---|---|---|
| Event-based | seconds | frequent edits of prices, stock, characteristics | requires a log and re-processing |
| Scheduled | from run to run | rare changes, nightly synchronization | discrepancy between runs, growing window |
The working option is a hybrid: events deliver critical fields, the nightly run picks up what was missed and serves as reconciliation.
Technical questions of exchange setup
Questions about catalog exchange surface not at the start, but after the first weeks of operation: duplicates of trade offers accumulate, properties without a pair in the accounting system appear, an exchange session interruption occurs. Below are answers to what is most often clarified before work begins.
What to do with already accumulated duplicates?
We sort by the matching key: the unique identifier of an item from the accounting system is stored in the trade offer property.
First we link existing items with accounting system records, then collapse the extra ones — orders, stock, and prices are transferred to the main article. Duplicates without history are deleted, and the exchange then updates only linked items.
How are properties transferred if they have no analogue on the website?
The property is created automatically: type, multiplicity, and reference to the catalog are taken from the export settings.
If in the accounting system this is an enumeration, we bring up the value catalog and match variants by code, not by name, so that renaming does not create a new value. Free text is transferred as a string with a length limit.
What happens if an exchange session is interrupted?
The exchange goes in portions, and each is logged before application. An incomplete set is not transferred: a repeated run processes it again by the same identifier, so no lost or duplicated characteristics remain. The schedule continues from the last successful step, and manual synchronization is not required.
Let's discuss the task: how the first analysis goes
The first analysis is not a conversation for acquaintance, but a collection of facts without which an estimate turns into guesswork.
To discuss the exchange task substantively, we look at how characteristics are maintained in the accounting system, how they get into the catalog now, and where duplicates of trade offers arise.
- What we clarify in the accounting system: which catalogs and characteristic type plans serve as the source of truth, by which attribute an item is linked to a product on the website, whether values have their own articles and stock.
- What we check on the catalog side: the structure of sections and information blocks, property types, the linkage of trade offers to a product, and the rule for generating the symbolic code.
- What initial data is needed for the estimate: an export of nomenclature with properties and values, a list of problem items with duplicates, catalog volume, and frequency of changes.
- What we determine regarding exchange boundaries: direction (export only or reverse writing of orders and stock), launch mode by event or schedule, reaction to deleted and renamed values.
- Scope of integration work: matching fields and property types, normalization of values, rules for collapsing matching characteristics, error handling, and exchange log.
- Exchange implementation plan: test loop, trial export on part of the catalog, reconciliation of the result with the accounting system, then a full run and transition to regular mode.
- What you get at the output of the analysis: a correspondence map, a list of improvements, a sequence of stages with control points, and access requirements.
Describe the exchange task — we will come back with an estimate and a plan where it will be visible at which stages duplicates stop appearing.