Uploading descriptions from 1C to Bitrix overwrites product cards
The exchange between 1C and Bitrix is by default arranged so that the accounting system is the source of truth for all attributes included in the upload rules.
Each session matches items by external code and writes values from 1C into the card without comparing them with what is already on the site. If a description is marked for upload, it will be overwritten on any exchange — even when nothing has changed in the accounting system.
Therefore, overwriting edits on the site looks sudden: an editor corrected the text, uploaded images, wrote SEO headings — and after the nightly exchange everything reverted to the accounting version.
Overwriting product cards affects not only the description: properties tied to attributes, offers, and galleries are also replaced if they participate in the rules.
A separate trap is exchange "by changes". It reduces the package size but does not cancel writes: a field whose date was updated in 1C is transferred in full, together with manual edits.
And if the rules are changed on the accounting system side for one task, the behavior changes immediately for all cards.
We explain how this is closed: uploading descriptions from 1C to Bitrix is configured so that some fields remain under the site's control, and some under 1C's control.
We fix the boundary in the rules and protect it from overwriting so that the exchange stops being a threat to content.
Effect of setup: publication timelines, errors, manual edits
After setting up product exchange, the catalog stops living by two truths: descriptions, characteristics, and stock come from the accounting system, while only what is not in it remains on the site — marketing texts, selections, promo blocks. You can verify that the scheme works by several signs in daily work.
- Publication timelines. A new item appears on the site on the day the card is ready in the accounting system, not after manual transfer. Batch uploading of descriptions removes the queue: dozens of items are published in one run.
- Reduction of manual edits. Descriptions and characteristics are edited in one place. A field changed on the site is not overwritten by the next upload — the conflict is visible in the reconciliation report immediately, not a month later.
- Catalog synchronization. Exchange runs on a schedule and by changed items, not by a full transfer. Items without a category and lost links surface in the log after each run.
- Card relevance. Discrepancies in characteristics and stock tend to zero: what the customer sees matches what the manager sees in the accounting system.
- The class of errors that goes away. Empty descriptions, duplicate SKUs, different units of measurement, incorrect price rounding — the exchange rule catches this, not an editor manually.
After two or three weeks on such a scheme, the reconciliation report becomes short: discrepancies are isolated, additional description sends disappear from the log, and the editor works on content rather than fixing exchange errors. In 1C this is configured with standard tools for exchanging properties and descriptions.
Approaches to exchange: schedule, queue, one-time loading
The exchange scheme is chosen not by developer convenience, but by how much the card description in 1C is considered the only source of truth.
If the catalog and texts are maintained only in the accounting system, and the site serves as a storefront, regular exchange is sufficient.
If a content manager adds descriptions and attributes on the site side, any automatic upload erases this work — and the scheme is designed differently.
In practice, we work with three schemes, and each has its own cost.
| Variant | When suitable | Limitations |
|---|---|---|
| Scheduled exchange | Catalog, prices, and stock change only in 1C; there are no manual edits on the site | Edits on the site side are overwritten on the next run; each run pulls the entire volume |
| Event-based exchange (change queue) | Data freshness matters: a product appears on the site at the moment it is edited in the accounting system | A change log and field conflict resolution are needed; after a failure, a repeated pass through the queue is required |
| One-time data loading | Catalog transfer during site launch, migration, price list import | Does not maintain relevance — discrepancies accumulate immediately after loading |
Comparison of exchange schemes should start from who owns the description. Scheduled exchange is simpler to maintain and predictable in load, the change queue is more precise in timing, and one-time loading covers the transfer and ends there.
On a live catalog, these approaches are usually combined: a queue for descriptions, a schedule for stock.
Implementation order: from exchange audit to handover of the regulations
Description exchange breaks not on code, but on untested rules: a property was renamed in 1C, a second description was added to the card — and the next upload erases text that the editor assembled manually.
That is why we build exchange implementation sequentially, and check each step on a copy of the catalog, not on the live site.
Work stages
- Audit of exchange rules. We analyze which properties participate in the upload, who changes them, in what order handlers run, and exactly where the manual edit is lost.
- Scheme design. We build a mapping of 1C and Bitrix fields and fix the source priority: what the exchange updates and what remains under the editor.
- Test catalog contour. We deploy a copy of the section with real items and enable exchange logging — discrepancies are visible before the production launch.
- Check on real items. We run several full uploads, compare descriptions before and after, and separately look at products with manual edits and empty fields.
- Setup of overwrite protection. We set field priorities, block service values, and add rules under which manual text is not overwritten.
- Handover of the regulations. We provide a document with exchange rules, roles, and the procedure for adding a new property.
- Support of the first uploads. We monitor logs until the exchange completes a full cycle without discrepancies.
After this, changes in descriptions stop being a risk: a new property first passes through the test contour and only then enters the production exchange.
Settings, field matching rules, and exchange regulations
The exchange works only as long as its rules are described in project documentation, not in correspondence with a previous contractor.
Below is the minimum set that we hand over to the client so that catalog edits do not break the upload and a new employee can reproduce the configuration without us.
- Exchange regulations: what runs and when — full upload on a schedule, additional loading of changed items by event, manual launch after mass catalog edits.
- Attribute mapping: a table "field in 1C — property in Bitrix — type — requiredness", including offers, characteristics, and additional properties.
- Source priorities: an explicit rule for who owns the field — the accounting system, the card on the site, or a manager manually — and how value conflicts are resolved on discrepancy.
- Field matching rules: by which key an existing product is searched and how sections are matched, so that a repeated pass updates the description rather than creates duplicates.
- Overwrite protection settings: a list of fields closed to exchange, and a list of places where an edit on the site side is preserved during the next upload.
- Instructions for employees: what may be changed on the site, what is edited only in the accounting system, and where to look when descriptions diverge.
- Exchange documentation: flow diagram, logging points, procedure for rolling the catalog back to a previous state, and a control run on a test copy after updates.
This set is enough to hand over support to another team without losing the upload logic.
Case study: how the exchange stopped breaking product cards
What it was before
A catalog with several tens of thousands of items exchanged with the accounting system on a schedule. Each synchronization pulled the entire set of card fields, including the trade description: if stock changed, the text was also overwritten.
A content editor re-edited about a hundred descriptions per week, and the next exchange erased them again.
What we found and what we changed
The bottleneck was not in the exchange itself, but in the lack of separation of fields by owner.
In setting up the upload of descriptions from 1C to the catalog, we fixed the source priority: text is updated only when attributes actually change, and an edit in the card is marked as authored and protected from overwriting.
Continuous synchronization was replaced by exchange by changed items with an operations log — now it is visible what overwrote a field and when.
- share of cards with erased description: from 18% to zero;
- repeated manual edits: from 120 to 0 per week;
- full exchange time: reduced by about three times;
- cards ready for publication immediately after synchronization: 97%.
Recovery of descriptions was reduced to a one-time pass through the log: we raised texts from backups and re-marked them as authored. Thereafter, content losses are detected in the first minutes, not after a week.
The catalog stopped depending on the upload schedule — the editor edits a card at any moment and knows that the exchange will not touch it.
What to do if the upload is already overwriting cards
First — stop the flow, rather than figure it out on the go.
While the exchange runs on a schedule, any edit lives until the next job run, so we switch the exchange to manual launch or remove the job entirely, take a full snapshot of the database and catalog, then record the list of cards changed manually during the last cycle.
This gives a foothold: it is clear what has already been lost and what can still be saved before the next overwrite.
Next — data source priority.
We break down card properties by the criterion "who owns the value": price, stock, SKU, warehouse links remain with 1C; description, characteristics, texts, images — with the content manager; some fields are mixed, the accounting system provides them, but a person refines them.
Without such an inventory, any protection of edits from overwriting turns into a set of patches that break on the next change in the reference book.
The protection itself is built on a manual change mark: the card stores a flag and edit date for each field, and the exchange skips properties whose mark is newer than the last upload.
A more predictable option is to separate values into different properties: "description from 1C" and "storefront description", where the storefront shows the second if it is filled, and the first as a fallback. Then the exchange does not touch content at all, and the discrepancy is visible to the eye.
Recovery proceeds from a backup: we compare cards, return lost text, and re-mark fields as manually changed. The priority rule and overwrite protection are put in place before the next exchange run — otherwise the cycle will repeat and the work will be wasted.
Concerns about exchange: rights, field conflicts, data volume
Rights are configured before the first exchange: the upload runs under a separate service account that has read access to the catalog and write access only to the properties managed by the exchange.
Descriptions and sections that the editor edits manually are not included in this list — the exchange does not overwrite them or break the layout. Every change remains in the log: it is visible what came from the accounting system and what was added on the site.
Volume is handled by partial exchange. There is no point in running a catalog of tens of thousands of items in full: the first load is complete, then only changed records and required property groups are transferred.
The exchange can be limited by section, warehouse, or brand and scheduled for night hours so that it does not coincide with peak traffic.
What happens if the description in 1C and on the site diverge?
An owner is assigned in advance for each property. If the source is 1C, its value overwrites the site; if the owner is the site, the editor's edit remains, and the exchange only reads it. Properties without an owner are not touched at all.
Can only part of the catalog be uploaded?
Yes, the exchange is configured by filters: section, warehouse, supplier, list of properties. Other items remain untouched, and the schedule sets the frequency and run window.
How to roll back an unsuccessful upload?
Before the exchange, a snapshot of cards and properties is taken. If the rules produced an incorrect result, we return to the previous state and correct the settings — without manually restoring descriptions.
Let's discuss your exchange scheme and come back with an estimate
An accurate estimate of exchange work comes not from a general description, but from your configuration: which attributes form the description, who edits text on the site side and when, and what exactly the next upload erases.
To discuss the exchange task specifically, send what you already have at hand — our engineers will look at the rest themselves.
- the structure of description properties in 1C and on the site: which fields are considered the source of truth and which are derived;
- two or three product examples: how the description looks in the accounting system now and how it should remain after the exchange;
- edit regulations: who edits text through the admin panel, to what extent, and how often;
- exchange schedule and approximate volume of nomenclature that passes in one session;
- exchange log for recent periods, if it has been preserved — it shows disputed overwrites;
- access to the test contour or a copy of the catalog: on them it is safe to reproduce the scenario and check behavior without risk to the production site.
Next, we analyze the exchange node: we look at handlers, the order of property writes, and the moment at which a value is overwritten.
As a result, you receive an exchange scheme with protection points, a list of edits, and a staged work plan — with labor costs, rollout order, and a way to roll back to previous behavior.
You can order exchange setup even without full access: we will start with a review of the scheme and come back with an estimate and plan.