Setting Up Data Exchange Between 1C:Retail and 1C-Bitrix

1С:Розница and Bitrix exchange: where stock and prices are lost

The most common failure in 1С:Розница and Bitrix exchange looks like this: an order is placed and paid for on the website, but the retail warehouse no longer has the item — the stock went negative, and the manager finds out about it from the customer.

The second most common issue is outdated prices on the website: the storefront shows the price from the previous delivery, the POS rings up a different one, and the stock discrepancy trails every shipment.

The cause is almost always in the scheme, not in a “module failure.” Exchange runs in scheduled batches, and between sessions the stock on the website is a snapshot, not warehouse fact: if retail is selling at that moment, the delta is not caught up.

Reservations, write-offs for sets, returns, and mismatched items often do not make it into the export at all, so the stock discrepancy accumulates and stops reconciling in the report.

Duplicate catalog items appear where matching is done by name or SKU instead of a stable identifier. You rename an item, change its SKU, recreate the exchange node — and the next export creates the card again, while the old one hangs with zero stock.

Product export errors rarely bring down the entire exchange: some items fail due to unfilled properties, images are not linked, offers hang without a parent — the exchange reports success, while the catalog quietly loses a section.

We look at how this is closed: strict matching by identifiers, batch control on input, and result verification after each session.

What correct catalog and warehouse synchronization gives

Catalog synchronization is built around the SKU: catalog items, offers, characteristics, and images are exported to 1C-Bitrix on a schedule, while stock is updated more often, by a sales event on the floor.

The matching key is configured once, so new items appear on the website without manual card edits, and sold goods immediately leave the available-to-order pool.

Prices are updated in the same flow: markup rules, rounding, and promotion validity period are set in the accounting system, and the website receives the final value.

In the catalog and cart, the price matches the one active at the POS — the discrepancy between the storefront and the receipt stops being a reason for disputes.

Orders from the website are created in the accounting system as documents: items, delivery, contact, applied discount, and payment method are transferred without re-entry.

Statuses and reservation data are returned back to the website, so the customer sees that the order is assembled, paid, or handed over for delivery.

The effect is measured by concrete metrics: share of items with stock discrepancies, time from sale on the floor to website update, share of orders that did not have to be corrected manually.

The class of failures “sold something that is not there” goes away with regular export — the manager does not confirm availability by phone but sees it in the system.

Data synchronization methods: files, service, message bus

Exchange between 1С:Розница and the website is rarely handled by one mechanism. The catalog, prices, and stock can tolerate a delay of minutes, but an order and its status cannot: the customer is waiting for confirmation, and the manager must not see a sold item as in stock.

Therefore, we first fix the requirements for latency and the cost of error during desynchronization, and only then choose the method.

In practice, a combination more often works: catalog items and stock go in scheduled batches, while orders go through a service with confirmation. When there are several points of sale or warehouses, batch exchange starts conflicting with itself, and we move it to the bus. What each option turns into in support — we look at further.

Implementation stages: from catalog audit to handover

Exchange between the accounting system and the website is not switching on a ready-made module but a sequence of work where the order of stages determines how many manual corrections will fall on managers after launch.

We always go from the state of reference data to the flow scheme and only then touch the production catalog. Below is what this sequence looks like on “Розница” — “Bitrix” projects.

1. Catalog audit. We export the reference data as is and analyze it: duplicates by name, items without an SKU, offers without characteristics, truncated names, products with zero price.

   We record the list of corrections to be made in the accounting system, not in the website catalog — otherwise the first exchange will overwrite them.

2. Reference data matching. We build a correspondence table: warehouses, price types, units of measurement, counterparties, order statuses. Without it, the “Paid” status from the website turns into a new status in the accounting system, and orders go to the wrong warehouse.

3. Flow scheme and export rules. We determine the direction and composition of the exchange: catalog items, prices, stock, orders, images, properties.

   We configure filters and schedule — for example, export only products with stock and from active groups so the catalog does not bloat with dead items.

4. Test environment. We deploy a copy of the catalog and a copy of the accounting database, run the full cycle: catalog export, order from the website, status return, item cancellation. We review the exchange log and the time of each run.

5. Data conflict check. We decide in advance what wins in a discrepancy: website stock or accounting system stock, manual card edit or export, duplicate by SKU or barcode. We document the rules in writing so they are not revisited on every failure.

6. Transfer to production. We perform the initial full export, enable the schedule, monitor the first cycles and item errors. Then we hand over the exchange regulation, access credentials, and instructions for managers on catalog edits.

Set of documentation and settings at handover

After launching 1С:Розница — Bitrix exchange, the customer has a package of artifacts that allows the system to be maintained without us: what is matched with what, on what schedule sessions run, what to do when the export stops. This is a description of your environment, not a template.

• Integration scheme — exchange nodes, flow direction (catalog items, stock, prices, orders, statuses), service users and their permissions.
• Data flow map — table “object in 1С — catalog entity — frequency — export mode — reference data owner.”
• Matching rules — catalog items and offers, warehouses, price types, order statuses, payment methods; separately — behavior for new items and duplicates.
• Node and schedule settings — session parameters, scheduled jobs, export windows and batch sizes so the exchange does not coincide with peak catalog load.
• Error log — typical failures: item not matched, stock conflict, interrupted session, authorization failure; for each — cause and procedure.
• Maintenance regulation — who and when reviews the log, how to start a full exchange manually, how to roll back a failed export.
• Administrator instructions — scenarios: starting and stopping the exchange, diagnostics, adding a warehouse, changing the schedule, pre-publication checks.
• Acceptance protocol — control items and orders run through the exchange before handover, with the expected result.

Case study: how a retail chain eliminated stock discrepancies

What was the situation

A retail chain exported stock manually: once a day a file was generated and uploaded to the website. Up to 20 hours passed between a sale on the floor and the catalog update — the storefront displayed goods that were no longer on the shelf, and new batches appeared late.

Result: up to 15% of order lines were corrected manually, support received about 30 requests per month for the reason “it is on the website but not in the store,” and managers regularly canceled orders and refunded payments.

What we did

We switched the exchange from “1С:Розница” to 1C-Bitrix from a nightly export to event-based exchange: a change in stock or price goes to the website immediately after the document is posted.

Orders are returned to the accounting system linked to the warehouse from which the goods are actually issued, so the reservation no longer “sticks” to the wrong item.

Separately, we closed reference data discrepancies: we matched catalog items by code and barcode and added a conflict log — if an item does not match, it does not reach the storefront but goes to a report.

What changed

• Data update delay: 20 hours → 2-3 minutes.
• Share of manual corrections in orders: 15% → less than 1%.
• Support requests about stock: 30 → 4-5 per month.

Resolving conflicts once a week takes the merchandiser about half an hour instead of daily reconciliation across all stores. We kept a repeated full catalog export as a safety net — it runs at night and does not load the storefront.

How does scheduled export differ from event-based export?

Scheduled export is a scheduled job with a fixed synchronization frequency: every few minutes, every half hour, less often at night. The load is predictable, distributed over time, and a missed run catches up changes on the next cycle.

The cost is the delay between sale and website: the receipt has already been printed, but stock on the storefront will update only on the next pass.

Event-based export starts when a change occurs — a receipt is posted, a receipt of goods is created, a price changes. The exchange runs immediately, and the delay between sale and website is measured in seconds, not intervals.

This solves cases where the last item is sold within minutes: the storefront takes the product off sale before it can be sold twice.

The flip side is peaks: evening sales and goods receipt cause a spike of runs, and each one reads the 1С database and writes to the catalog. Therefore, event mode is limited by a list of objects, and a queue and retry on connection loss are set up. Without this, exports pile into an avalanche and slow down both the POS and the admin area.

Both schemes face data version conflicts in the same way: a product is edited both in 1С and in the card on the website. We agree in advance whose source is master and pass a change label so that a later record does not overwrite a fresher edit.

In practice, a mixed option is more often chosen: prices, stock, and stop lists — by event; descriptions and photos — by schedule. What to choose — scheduled or event-based export — is decided not by catalog size but by how expensive a stock error is. We fix the parameters during setup: list of objects, synchronization frequency, source priority.

Common technical doubts before starting work

Catalog integration with the accounting system is frightening not in itself but because of risks: stopping sales during work, an interrupted export, and mismatched catalog items. Below are answers to the doubts most often voiced during the estimate stage.

Timelines depend on catalog volume and the number of warehouses: a typical exchange for one price list — days, a matrix with several warehouses and price types — noticeably longer.

After launch, an exchange log with batch history and a regulation for resolving stock and price discrepancies remain.

What happens if the export is interrupted midway?

The regulation runs in batches and saves state step by step, so the next export continues from the point of interruption rather than starting over. Stock and prices are recalculated so that goods do not go to zero on the storefront.

We have several warehouses and price types — how does this map to the catalog?

Each warehouse and price type corresponds to a separate offer with its own stock. We transfer properties according to matching rules, so selection by characteristics and filters do not fall apart.

We change SKUs and names — will the exchange survive this?

The link is by the internal item identifier, not by name, so renaming does not create a duplicate card. When the SKU changes, we close the old URL with a redirect so the page does not drop out of search.

What about support after implementation?

The exchange log shows at which step and for which item the data diverged, so troubleshooting is fact-based rather than restarting the entire exchange. On-call duty for failures and edits to export rules are discussed as a separate regulation.

Let's discuss the task and come back with an estimate and plan

To discuss the integration task concretely rather than using average figures, in the first call we analyze your exchange environment: which reference data is involved, where the master data for products, stock, and prices resides, how many points of sale there are, and how an order from the website reaches accounting. Separately, we look at what is already configured — export rules, catalog item matching, schedule.

• Which entities are synchronized: catalog items, characteristics, prices, stock by warehouse, orders, and payment statuses.
• Who owns the data and in which direction writing goes, so edits do not overwrite each other.
• How often exchange is needed and whether stock lag behind the real warehouse is acceptable.
• How discrepancies are handled: exchange log, batch retries, duplicate item protection.
• How we test in the test environment: reconciliation of stock and totals, connection loss scenarios.
• What is included in documentation handover: data flow scheme, rule settings, launch and rollback regulations.
• How post-launch support is organized: monitoring exchange queues and refining rules for new categories.

The estimate and work plan come as a list of stages with the composition of settings and acceptance criteria for each item — it can be checked with your team and accountants. Describe the task: which systems, how many locations, what already works. We will come back with an estimate and plan.