Integrating 1C-Bitrix with MoySklad: where the exchange breaks down
Integrating 1C-Bitrix with MoySklad most often fails not at the start, but after several weeks of operation, when discrepancies accumulate.
The classic case: a product is listed as in stock on the website, the customer places an order, but the item is already gone from the warehouse — the manager calls to apologize.
The reason is usually that stock synchronization runs on a schedule once an hour rather than on an event, and between two exchange runs a sale through retail or a marketplace manages to slip through.
The second typical failure is a nomenclature mismatch. The same item is created in MoySklad and in Bitrix under different names or SKUs, matching is done by name, and the product exchange breeds duplicates: two cards on the website, one in the warehouse.
Then stock gets spread across the duplicates, and the real quantity doesn't add up for either of them.
The third and most costly one is lost orders. If the exchange fails midway (timeout, request limit, connection drop), some orders never reach the warehouse, and they are only found during a manual order reconciliation at the end of the month.
Each such reconciliation means hours of a manager's work and the risk of shipping the wrong thing or not shipping at all.
A separate pain point is prices and attributes. The purchase price changes in MoySklad, but the old one remains on the website, because the exchange is configured only for stock.
Or the units of measurement don't match: the warehouse counts in packs, the website sells by the piece, and a stock of "10" turns into 10 packs instead of 10 pieces.
All these failures are cured not by "tweaking" a ready-made module, but by a proper exchange scheme: matching by a stable key, event-driven exchange, an operations log, and automatic reconciliation. Let's break down how this gets closed.
What a website and warehouse integration delivers: the effect in numbers
Exchange modes: what is synchronized and how often
Integration of 1C-Bitrix with MoySklad is built around three independent streams: nomenclature and prices, stock by warehouse, and orders with their statuses. They cannot be mixed into a single exchange — each has its own acceptable latency.
Stock is sent incrementally, only for changed positions: a full catalog run of 20-30 thousand SKUs takes minutes and loads both systems, whereas a delta export fits into seconds.
Orders flow in the opposite direction and require write confirmation, otherwise a failure on the warehouse side will duplicate the document.
Stock freshness and the cost of downtime
The key metric here is the share of orders placed against outdated stock. With an hourly exchange on active traffic, it reaches 3-5%, and each such order turns into a cancellation, a return, and a conversation with the customer.
Switching to event-driven exchange (a stock change triggers an export) removes most of the discrepancies: the stock on the storefront lags behind the warehouse by tens of seconds.
Downtime cost is calculated separately — if the exchange goes down, the website keeps selling based on the last snapshot, and the longer the channel stays silent, the more "phantom" positions appear.
Failure classes that are closed at the implementation stage
| Exchange mode | When it fits | Limitations |
|---|---|---|
| Scheduled (batch) | Small catalog, infrequent sales | Stock latency, peak load on both systems |
| Event-driven (entity change) | Active sales, wide assortment | Need protection against an avalanche of events during bulk edits |
| Hybrid: events + scheduled reconciliation | Catalog with frequent edits and high load | Harder to maintain, requires discrepancy monitoring |
The hybrid closes the main failure class — the "silent" discrepancy, when the exchange formally works but some positions have stopped updating. A nightly reconciliation catches such positions and force-rebuilds them.
MoySklad delivers changes via the API with a cursor based on modification time — this is what makes it possible to build a delta instead of a full run.
How we conduct implementation: stages of engineering work
Implementing an exchange between a website and warehouse accounting is not "plugging in a module" but building a predictable data flow: stock levels, prices, nomenclature, orders, and statuses must reconcile in both directions without manual edits.
That is why the work proceeds in fixed stages — from auditing the current exchange to handing over a configured system with documentation. Below is the order in which we run a project.
- Exchange audit. We capture the current state: which reference books and documents are already synchronized, by which attributes items are matched, where stock levels and prices diverge, how often exchange sessions fail. The output is a map of bottlenecks and a list of discrepancies that need to be closed.
- Integration schema design. We determine the direction and priority of flows: nomenclature and prices — from the warehouse to the website, orders and statuses — from the website to the warehouse. We fix the matching rules by SKU and barcode, the behavior for duplicates and deleted items, and the launch schedule.
- Data matching setup. We define the correspondence of reference books, warehouses, price types, counterparties, and order statuses. We separately handle items without an SKU and products with variants — this is exactly where stock levels most often "drift."
- Test synchronization. We run the exchange on a copy of the data: a full pass of nomenclature, then orders and statuses. We reconcile stock levels and prices line by line, check the behavior on connection loss and re-run — the exchange must catch up on what was missed, not duplicate it.
- Error handling and monitoring. We set up exchange logging, failure notifications, and retry rules. The responsible person sees exactly what failed and why, without manually digging through logs.
- Switching to operating mode. We launch the exchange according to the schedule, support the runs for a while, and reconcile the results. We make sure discrepancies do not accumulate.
- Documentation handover. We provide the integration schema, launch schedule, matching rules, and instructions for employees: how to check the exchange and what to do in case of a failure.
Each stage ends with a verifiable result, not a report of work performed. Describe your task — we will come back with an estimate and a stage-by-stage plan.
How does API exchange differ from file uploads?
API exchange is event-driven synchronization: a change in stock, price, or order status in one system immediately triggers a request to the other.
File uploads work on a schedule: the system generates a package (XML, CSV), places it in an exchange folder, and the other party picks it up and parses it.
The difference is not about convenience, but about update latency: API delivers seconds, while file exchange depends on the interval between job runs.
Latency directly affects what the customer sees. If stock levels update once an hour, some orders come in for items that are no longer in the warehouse — cancellations, manual calls, and returns begin.
With API exchange, the reservation reaches the store almost instantly, and the share of such rejections drops to isolated cases.
Synchronization reliability also differs: API returns a response code for every operation, and a failure is visible at a granular level, while file exchange silently skips a corrupted package — the discrepancy is only discovered during reconciliation.
File exchange, however, is not outdated. It wins where systems do not have direct access to each other, where the channel is unstable, or where volumes are such that batch processing is cheaper than constant requests.
A hybrid is often chosen: reference data and prices are pulled in batches at night, while orders and stock levels go through API in real time. This mode relieves the load on both systems and preserves currency where it is critical.
The choice of exchange method is dictated not by fashion, but by the data profile. Products change rarely — they can be moved in packages; orders and warehouse movements change constantly — they need API.
We start by analyzing which entities must match and how frequently, and then select the transport accordingly, not the other way around.
Case study: how we eliminated stock discrepancies and duplicates
The client is a wholesale business with a retail arm: several warehouses, sales through a 1С-Bitrix website, and accounting in MoySklad.
Before we stepped in, the exchange between the systems ran on scheduled exports: products and prices were transferred in files once a day, and orders from the website were entered into the accounting system by an operator manually.
By the time they contacted us, stock discrepancies had reached 12–15% on active SKUs, and reconciliation plus manual entry took 3–4 hours a day.
What it was like before the integration
Stock on the website lagged behind actual stock by a day: a manager would sell a product that had already been shipped, and vice versa — "zero" SKUs were sitting in the warehouse.
Orders were duplicated when the form was resubmitted and when operators worked in parallel, which created extra reserves and "hanging" shipments in the accounting system.
Prices for some of the nomenclature differed between the website and the warehouse, and finding the cause of a discrepancy took hours.
What we changed
We switched the exchange to event-driven synchronization via API: a change in stock, price, or order status in the accounting system goes to the website immediately, and a new order from the website goes into the accounting system with a unique identifier.
The identifier suppresses repeat writes, so duplicates are not created even during a network failure and resubmission.
We kept full-nomenclature stock reconciliation as a safety net — it runs at night and corrects only discrepancies rather than overwriting everything indiscriminately.
Exchange logs are written to a separate journal: you can see what was synchronized and when, and a discrepancy is investigated from the record rather than by searching blindly.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Stock discrepancy | 12–15% | less than 1% |
| Manual order entry | 3–4 h a day | not required |
| Order duplicates | regularly | isolated, suppressed automatically |
| Data update delay | up to 24 h | minutes |
| Nomenclature reconciliation | manually | nightly automated run |
Manual warehouse operations were reduced to exception handling: the operator only deals with the SKUs where the automation flagged a discrepancy. The freed-up time went into working with suppliers rather than reconciling spreadsheets.
The exchange is built on the standard data exchange mechanism of 1С-Bitrix with an external accounting system — this makes it possible to update the synchronization logic without rewriting the website.
Doubts before starting: compatibility, migration, rollback
The exchange between the website and warehouse accounting runs over a documented software interface, so the key question is not "is it supported" but "which entities are synchronized and in which direction." We define this before starting: nomenclature, stock balances by warehouse, prices and price types, counterparties, orders and their statuses, reservations.
If some reference data is maintained only on the warehouse side and some in the website catalog, we determine the source side for each field, otherwise counter-records will begin overwriting each other.
What if the warehouse is already populated and the website is running? Migration is performed in two passes: first matching by external identifiers and SKUs, then reconciling discrepancies with a report before enabling writes.
Duplicates and items without an unambiguous match are handled separately rather than "auto-appended."
What if something goes wrong after launch? The rollback plan relies on a database restore point and a snapshot of the exchange settings: returning to the previous environment takes minutes, not hours.
Access is granted on the principle of least privilege: a separate account for the exchange, restricted rights, logging of every call.
How difficult is it to set up the exchange if accounting is already maintained in 1C?
Exchange with 1C and exchange with the warehouse solve different tasks and do not conflict: the first is responsible for the accounting and management environment, the second for operational balances and order assembly.
We separate the flows by different sets of fields and configure the sequence so that data does not arrive twice. We verify compatibility with 1C on your configuration before starting work.
Upon completion, we hand over:
- a data flow diagram indicating the source side for each reference book;
- working exchange configurations and the launch schedule;
- a table of field mapping and rules for recalculating prices and units of measurement;
- a rights policy and a list of accounts involved in the exchange;
- instructions for the rollback plan and restoration from a save point;
- a log of test runs with reconciliation results before and after enabling writes.
Describe your configuration and current accounting environment — we will come back with an estimate, exchange diagram, and migration plan.
Integration implementation timeline by stages
The timeline depends not on the volume of code, but on how quickly the parties can agree on the rules of exchange: which warehouses are involved, how items and counterparties are matched, and what to do about inventory discrepancies.
That is why we fix a stage-by-stage schedule — the client can see where the project stands and what is required from them at each step.
The duration of the setup is determined primarily by the quality of the source data: if the item lists in both systems are maintained chaotically, the matching stage drags on, and we break it out as a separate block in the schedule.
The estimated durations above are for a typical setup; with multiple legal entities, non-standard order statuses, or exchange with external platforms, stages are added, and we discuss this before the start, not in the course of the work.
The stages partially overlap: design begins while discovery is still underway, and the test environment is prepared in parallel with the setup.
This shortens the overall implementation time, but does not cancel the checkpoints — after each stage the client receives a result that can be verified.