1C and Magento 2 integration: where the exchange breaks
1C Magento 2 integration breaks not at the start, but at volume: for the first weeks the catalog exchange runs cleanly, and then duplicate items appear in the export, prices on the storefront diverge from the accounting ones, and some orders hang in an intermediate status.
The cause is almost always the same — the exchange is built on a full export on a schedule, without change marking and without an operations log. The more SKUs and orders there are, the longer the window in which the data on the site and in the accounting system live apart.
The cost of desynchronization is calculated quickly. A customer places an order at a price that is no longer in stock — the manager either cancels the sale or sells at a loss.
Stock synchronization with a delay of hours leads to overselling on items that are physically gone, and to returns.
A hung order status means that fulfillment did not start: the goods are sitting there, the customer is waiting, and the support service manually reconciles the lists. Duplicate items bloat the catalog, break filters and blur search results.
A separate category of failures is mismatched reference data. Units of measure, tax rates, warehouses and counterparties are described differently in 1C and Magento 2, and the exchange silently skips what it could not match.
The error does not surface immediately: it accumulates in the logs until the discrepancy becomes noticeable in revenue.
We break down how this is closed: change marking instead of a full export, idempotent operations, an exchange log with retry of failed packets, and scheduled reconciliation of discrepancies.
What Exchange Setup Delivers: Effect by Node
Catalog: Incremental Exchange Instead of Full Upload
A full catalog upload of 40,000–60,000 SKUs means hours of operation and peak load on both systems. Incremental exchange transfers only the items changed since the previous pass: price edits, descriptions, category assignments. Pass time drops from hours to minutes, and the server isn't idle rebuilding what hasn't changed.
Stock: Event Queue and Exchange Frequency
Stock is the most sensitive node: a 10-minute discrepancy results in selling something that isn't in the warehouse. The event queue records every register movement and delivers it in batches on a schedule — from once every few minutes to once an hour.
The higher the frequency, the smaller the overselling window, but the more requests the database holds. A reasonable compromise is stock exchange every 5–15 minutes plus forced synchronization before hot promotions.
Orders: Reverse Flow Without Losses
An order from Magento 2 goes to 1C with an idempotent key — resending during a communication failure doesn't create a duplicate document. Statuses and payment return via reverse flow, and the customer sees the current state in their account.
The share of lost orders drops to zero, and manual transfer from email and spreadsheets disappears from the process.
| Mode | When It Fits | Limitations |
|---|---|---|
| Full upload | Initial load, recovery after failure | Hours of operation, high load |
| Incremental exchange | Catalog, prices, descriptions in working mode | Requires reliable change markers |
| Event queue | Stock, orders, statuses | Queue depth control needed |
| On-demand exchange | Manual launch before a promotion | Doesn't cover real-time flow |
Our engineers build the exchange on the platform's native mechanisms and RabbitMQ as the queue transport — this provides delivery retry and load decoupling.
Stages of Setting Up 1C and Magento 2 Integration
1C Magento 2 integration begins not with code, but with an audit of the accounting system: which reference books are actually maintained, where item duplicates are, how characteristics and product variants are structured, who changes prices and how often.
At this same stage, we fix the composition of exchange entities — catalog, stock by warehouse, orders, statuses, counterparties — and determine what is the source of truth for each field.
A mistake here is the most costly: if the accounting system does not have a single product key, any exchange will multiply duplicates and discrepancies.
- Audit of the accounting system and catalog. We analyze the structure of items, characteristics, units of measurement, warehouses, and pricing rules. We record discrepancies between how a product is entered in accounting and how it should appear in the catalog on the website.
- Designing the exchange scheme. We determine the direction of flows, synchronization frequency, entity matching rules, and conflict behavior. We separately describe what to do with products withdrawn from sale and with orders placed at the moment of exchange.
- Setting up catalog and stock export. We configure package generation, paginated transfer, and change processing — so that the exchange proceeds in portions and does not block the website's operation. We transfer stock linked to warehouses, and prices taking discount rules into account.
- Setting up order intake. Orders go from the store to the accounting system with their composition, address, delivery method, and payment method. We configure the return transfer of statuses so that the customer sees the current state of the order.
- Testing on production data. We run the exchange on a real catalog and real orders: we reconcile the number of items, stock, prices, and status history. We separately test failure scenarios — connection loss, retransmission, change conflict.
- Setting up monitoring and logging. We log every exchange session, calculate discrepancies, and notify the responsible person on errors. Without this, a failure is discovered from a customer complaint rather than from a system signal.
- Handover of regulations. We provide documentation on launching the exchange, actions during failures, and the procedure for adding new warehouses and pricing rules. We train the employees who will maintain the integration.
Each stage ends with a verifiable result: an agreed scheme, a working exchange on a test environment, reconciliation on production data.
This order makes it possible to launch synchronization without stopping sales and to understand exactly where a discrepancy arose if one appears.
How does stock balance exchange differ from order exchange?
These are two different data flows with opposite directions and different costs of error.
Stock balances go from 1C to Magento 2: the warehouse is the single source of truth for quantity, and the exchange's job is to quickly deliver the number to the storefront so that a customer doesn't place an order for something that isn't there. Orders go the other way: Magento 2 records the fact of purchase, and 1C accepts it into accounting.
Here the source priority is reversed, and the directions must not be confused — otherwise you'll get a stock balance overwritten by the storefront, or an order lost during synchronization.
Stock balance exchange is tolerant of delay and aggressive about frequency. It's enough to update the catalog once every few minutes, but for all items at once, otherwise the site will retain a "ghost" of a product that's already sold out.
Data conflicts here are resolved simply: if 1C sends zero, the storefront must close the item, even if a minute ago it showed it as in stock. Reverse priority is unacceptable, otherwise sales on the site will outpace the real warehouse.
Order exchange, on the contrary, requires guaranteed delivery of every document. An order must not be "lost on the next update" — it must reach 1C exactly once, without duplicates.
That's why an acknowledgment queue is used here: the storefront sends the order, waits for a response from the accounting system, and only then changes the status.
Order statuses are a separate loop: "paid," "assembled," "shipped" come from 1C and must not be overwritten by the site's data.
Data conflicts in orders are more dangerous than in stock balances. If a customer cancels an order on the site while 1C has already processed assembly, the discrepancy will have to be sorted out manually.
That's why we separate the flows into distinct schedules and priority rules: stock balances are a frequent one-way exchange, orders are reliable delivery with a log and retries. This separation eliminates 90% of desyncs before they ever reach accounting.
Case study: how the exchange stopped losing orders and prices
Before implementation, the exchange was built on scheduled jobs: catalog export once a day, stock — once every few hours, orders were picked up in batches.
A queue accumulated between exchange windows, and some orders placed at the moment of export could not be matched by item code — they settled in an intermediate table and required manual review.
Prices on the site lived a separate life: while a manager edited the price list in the accounting system, the storefront showed the old value, and the discrepancy persisted until the next cycle.
What was changed
The exchange was moved to an event-driven model: changes to items, prices, and stock are published to the queue immediately upon document posting, rather than on a schedule.
Orders are picked up incrementally by the identifier of the last successful synchronization — reprocessing is idempotent, duplicates are filtered out at the input.
For matching items, an explicit registry of correspondences between accounting codes and storefront identifiers was introduced, and fuzzy matches by name were removed from the logic.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of lost orders | 3-4% on peak days | isolated cases, resolved via the log |
| Price discrepancy time | up to 24 hours | seconds after document posting |
| Manual edits per day | 40-60 operations | 2-5, mostly new items |
| Error queue handling | manually, without history | via a journal with tracing down to the document |
Rollback was addressed separately: if the exchange fails midway through a batch, the state rolls back to the last confirmed point instead of remaining partially applied. This eliminated a class of incidents where half of the orders went into the accounting system and half hung.
Magento 2 and 1С remain connected through an intermediate layer that can be restarted without stopping the storefront.
Compatibility, access, and rollback concerns
The most common question at this stage is what will happen to the exchange when the attribute schema is updated on the catalog side or the item details are changed on the accounting side.
An honest answer: the exchange is not built on rigid field bindings but on mapping rules, so extending the reference data does not break the flow — new properties are picked up via mapping, and unknown ones are queued for review with a notification to the responsible person.
Version compatibility and access rights are locked in at the start: the service user gets only the objects involved in the exchange, not full access to the database.
What if the exchange breaks at night or during a peak sale?
The exchange runs in batches with logging of every step, so a failure does not leave "half" of the data: an incomplete batch is rolled back entirely and retried on schedule.
The responsible person receives a notification indicating at which step and for which object it stopped, and the discrepancy between the catalog and accounting is visible in the reconciliation — it runs automatically and shows discrepancies in stock and orders.
The rollback plan is described in advance: reverting to the previous exchange schema and re-exporting from the accounting system as the source of truth.
What if we have our own support team? We hand over the exchange documentation and support regulations — your engineers can use them to handle typical situations without us. What if the mapping rules change?
The mapping is moved into a configurable reference table; edits do not require rewriting the exchange code.
After handover, you receive:
- a diagram of data flows between the accounting system and the catalog, indicating frequency and volumes;
- a field mapping map: items, prices, stock, orders, statuses;
- the service user configuration with the minimum required access rights;
- the exchange log and configured error notifications with recipients;
- instructions for the rollback plan and re-synchronization;
- support regulations with areas of responsibility and response times;
- an exchange acceptance checklist for each data type.
Describe your configuration — which reference tables are involved in the exchange and how often stock data is needed — and we will come back with an estimate and a work plan.
Exchange setup timeline by stages
Setting up 1C and Magento 2 integration happens in waves: first we stand up the contour on a test copy, then move it to the production contour. This order lets you see real implementation timelines on your data, not on averaged ones.
The exchange stages run partly in parallel: catalog and stock can be handled on one branch, while orders are connected after the nomenclature stabilizes. That is why the total timeline is usually shorter than a simple sum of the table rows.
Magento 2 is sensitive to the quality of reference data: if 1C has duplicates or empty required fields, the exchange will stall on them, not on the code. That is why discovery is separated into its own stage — it removes the main timeline risks.
