One-way 1C export: where the exchange breaks
One-way 1C export is a scheme where the catalog, prices, and stock go from the accounting system to the website, with no reverse flow. It works exactly until the master data on both sides match.
The exchange usually breaks not on the first day but after several months — when someone edits a card manually or a new product group appears in 1C.
The first bottleneck is mismatched master data. In the accounting system, nomenclature lives with a hierarchy of groups, properties, and characteristics, while on the website the same items are assembled from trade offers.
If the matching key (SKU, code, external identifier) changes or is duplicated, the exchange stops recognizing the existing card and creates a new one instead of updating the old one.
This is where duplicate products in the catalog and stock desynchronization grow from. The exchange writes the quantity by its own key, while the customer looks at another item where stock has not been updated for weeks.
Errors in nomenclature exchange accumulate silently: the batch arrived, the response was recorded, but some lines were not applied — and this is not visible in the report at all.
The second class of failures is stuck export batches. Data goes in portions, and if the session breaks in the middle, part is already written and part is not; a repeated run either duplicates items or skips them.
Manual edits on top of the export add their own: the next portion overwrites the description and characteristics, and the manager edits the same thing every day.
We analyze how this is closed: matching by a stable key, logging each portion with a clear status, protecting manual fields from overwriting.
What managed catalog export gives
Managed export is when the exchange stops being "one big script" and becomes a regulated cycle with an explicit contract: which entities, in what order, what to do in a conflict. Such a contract is described before the first export, not edited after a failure. Then the effects are measured, not declared.
The speed of catalog updates is set by the method of data selection.
Incremental exchange by modification time instead of a full run removes the main load: a nightly export that used to stretch for hours and catch up with edits by morning now fits into the window between deployments. The window in which an outdated price hangs on the website is reduced to minutes.
The share of manual edits falls due to the field mapping: prices, stock, and nomenclature are assigned to 1C, while descriptions, images, and advertising attributes are assigned to the website.
Overwriting of others' fields is excluded, so managers do not restore content after every exchange. Discrepancy control is maintained via the journal: how many items were updated, how many were skipped, and why.
Exchange stability is ensured by idempotency and writing in portions with progress fixation: a repeated run after a failure does not create duplicates and continues from the stopping point.
A whole class of failures goes away — "the exchange crashed in the middle, the catalog remained in a partial state": an unfinished portion is rolled back, and the website continues to work on the previous snapshot.
Exchange options and their technical limitations
The exchange scheme is determined by three parameters: the volume of nomenclature, the acceptable stock lag, and the readiness of the 1C environment to give data outside.
The catalog can be exported entirely at night, while stock can be exported in portions every few minutes: the choice is dictated not by convenience, but by the cost of an error in a specific storefront.
Data transfer schemes
| Option | When it fits | Limitations |
|---|---|---|
| Full export | The catalog changes rarely, volume is moderate | Each run moves the entire array — time and load grow, rollback only by full repetition |
| Portion-based exchange | The catalog is large, only changed items are needed | Requires a reliable change indicator and timestamps; desynchronization is harder to track |
| Scheduled exchange | Prices and stock are sufficient to update once every 10-15 minutes | Between runs, data becomes outdated; when windows overlap, tasks stack |
| Event-based exchange | Fast reaction is needed — orders, reserves, statuses | Depends on source availability; at peak it produces request bursts |
| Intermediate database | Direct access to the production 1C is not allowed, environment isolation is needed | A separate node appears for maintenance; the delay is one transfer longer |
In practice, the scheme is assembled from two or three modes: the catalog goes by full export, stock — in portions on a schedule, orders — by events.
We look at your environment, measure the daily volume of changes, and fix a set of modes that keeps the delay within the required boundaries without loading the production database.
Implementation procedure: from audit to handover
One-way export breaks not during exchange setup, but on mismatched master data and on repeated runs that breed duplicates.
Therefore, we work sequentially: first we fix what exactly and how often goes from the accounting system to the catalog, and only then do we enable the exchange.
- Audit of master data and sources. We look at nomenclature, warehouses, prices, stock, units of measure: where there are duplicate codes, empty keys, items without movement, groups with manual sorting. We determine the list of exported objects and the acceptable discrepancy between the databases.
- Field mapping scheme. We assemble a map "source field → target field" with types, precision, and normalization rules: what to do with an empty value, how to convert units, how to store the external key so that a repeated write updates the item rather than creating a second one.
- Setting up the one-way channel. We build the exchange only for reading from the accounting system — accounting remains the only source of truth, the catalog cannot write data there. We configure the schedule, batch export, and logging of each session.
- Test environment. We deploy a copy of the catalog, run the full volume, then a series of short exports. We measure the pass time, look at behavior during a connection break, repeated run, and price change in the middle of a session.
- Export verification. We reconcile the number of items, key attributes, and prices on a control sample; separately we check rollback scenarios — the exchange must correctly complete an interrupted session without loss and without duplicating records.
- Launch and documentation handover. We bring the exchange into operating mode with monitoring and failure notifications, hand over the field map, regulation description, restart procedure, and rules for making changes to master data.
Each step ends with an agreed result, so the transfer to the production environment goes without surprises. Describe your task — we will return with an estimate and a plan by stages.
Set of settings and documents at the output
After launching a one-way export, the customer is left not with a "configured exchange," but with a set of artifacts by which the integration can be operated, checked, and handed over to another engineer.
What is not documented in writing turns into oral knowledge in six months and leaves together with the author of the setup.
- Matching rules — by what attribute products, counterparties, warehouses, and prices are linked: where the key is the 1C code, where the SKU is, and how a duplicate is resolved.
- Exchange settings — composition of exported objects, portion size, schedule, behavior on connection loss, journal depth, and logging level.
- Data flow diagram — what moves and in which direction, which fields on the website are closed for writing so that 1C remains the source of truth.
- Instructions for employees — what a manager does when a price or availability discrepancy occurs, how to create a new product, whom to escalate to.
- Exchange launch regulation — the procedure for the first full export, manual run after a failure, windows when the exchange may be stopped.
- Data protection description — the accounts involved, restriction of access to the exchange node, storage and rotation of keys.
- Acceptance sheet — control operations by which the work is accepted: reconciliation of items, prices, stock, and the exchange journal.
The documents are written for your environment: object names, warehouses, and rules are yours, not abstract. A new engineer deploys and checks the exchange using these materials, without reconstructing the logic from logs.
Case: how stock and price desynchronization was eliminated
A distributor with a catalog of several thousand product items kept records in 1C and the storefront on a website.
The exchange between the systems had existed for years, but was assembled in parts: separate exports for prices, stock, and characteristics, scheduled launch, without control of run completeness.
What was there
Stock and prices diverged from accounting for 12–15% of items: managers sold goods that were no longer available and manually edited up to a third of the cards. Support received dozens of requests per month specifically about incorrect prices.
Worse still: the exchange crashed in the middle of a batch and left the catalog partially updated. A full run took about forty minutes, and all that window the storefront showed outdated stock.
What was changed and what became
We rebuilt the one-way export: one queue, fixed batch order, completeness check, and repeated run only for the failed ones. Data is written to a buffer table and switched over upon batch completion — the catalog does not remain in an intermediate state.
The share of items with discrepancies dropped to fractions of a percent, stock updates were reduced to a few minutes, manual edits became isolated.
Support requests about the catalog are counted in units per month, and exchange failures no longer leave the storefront half-updated.
What to do if the exchange is already configured and failing
Intermittent exchange failures almost never mean the integration is broken — it degrades: some objects pass, some settle in the queue. The first step is to separate the source from the transport.
If the data has not changed and the error repeats, the issue is in the matching rules, not in the channel.
Discrepancy diagnostics are done by keys, not by the number of lines. We compare checksums by nomenclature groups, warehouse stock, and document amounts for the same period — this shows where it is not the data that diverges, but the matching of master data.
The exchange journal in 1C and the change registration protocol show which objects entered the batch and which were cut off by the filter.
A partial exchange is more dangerous than a complete failure: when state is reset, orders and payments are duplicated. Therefore, we make export restart idempotent — each record is assigned an external key, a repeated send updates the object rather than creating a new one.
The recovery order is one: master data, then documents and movements, and finally stock and prices. We limit portions by time and volume so that the export runs in the background and does not block managers during peak hours.
After the queue passes, we reconcile the checksums again — this is the criterion that the exchange is closed.
To prevent the failure from recurring, we set up scheduled discrepancy control and notification on deviation. Then an outdated price or stock does not reach the customer.
Technical questions asked before the start
Before work starts, the same doubts come up: will the catalog suffer, will the website go down, who is responsible for the data after launch. We address them briefly and to the point.
Is two-way exchange needed?
One-way export from the accounting system to the website covers most tasks. The reverse flow — orders, statuses, reserves — is designed as a separate environment: the website does not get the right to write directly to the accounting system, it only transmits documents.
What will happen to manual catalog edits?
There is one source of truth. Fields managed by the accounting system are overwritten on every export; descriptions, meta tags, and media are marked as manual and are not overwritten.
At the start, we inventory the edits — otherwise the first full export will erase the accumulated work.
Will the website have to be stopped?
No. Writing goes in portions, a failure is fixed by repeating from the last successful item, and we schedule heavy full exports during low-activity hours — the catalog remains available to customers.
How are master data matched?
By external key — the identifier from the accounting system, not by name: name matching breaks on renames and duplicates. If the databases have already diverged, we prepare a report on ambiguous items and resolve them before enabling the exchange.
Who is responsible after launch?
The source is responsible for data correctness, and the integration environment is responsible for reception, transformation, and display. Exchange monitoring with notifications remains with support; when changes occur in the accounting system, we update the matching rules.
Let's discuss the exchange scheme for your task
An exchange estimate becomes reliable when the initial picture is visible: what data leaves 1C, how often it changes, and what is already configured on the website side.
If the exchange is already running, send what you have — you will not have to describe the configuration from scratch, and the discussion of the task will start with specifics, not with clarifying rounds.
What is useful to send and what we will clarify during the review:
- List of one-way export objects: nomenclature, prices, stock, counterparties, order statuses. For each, you note what is critical for the website and what does not need to be transferred.
- Current exchange regulation: scheduled or event-based, once an hour or when a record changes, where the queue is and what happens when one of the parties is unavailable.
- Matching and data cleansing rules: by what key items are linked, how duplicates and outdated cards that have already been deleted in the accounting system are handled.
- Accesses and environments: which service user is allowed to export, whether there is a separate environment for test runs, who confirms launch in operating mode.
- Data protection requirements: which fields are closed from publication, who gets access to personal data from orders, and how this is recorded in journals.
- Logs and disputed cases: if the exchange has already operated, show errors and places where data stopped matching — they more accurately show the scope of improvements.
On the call, we will clarify the expected update frequency, system behavior during a failure, and the volume of historical data for the initial load.
In response, we send an exchange estimate, a staged work plan with the implementation order, and a support regulation: what we control ourselves, how we track discrepancies, and within what timeframes we respond.
Describe the task in free form — we will return with an estimate and a plan.