Synchronizing MoySklad with a website: where the catalog diverges
Divergence begins where the storefront and the accounting system live by different rules.
A warehouse worker writes off an item in the accounting system, but on the website the position remains available until the next exchange — the customer places an order for something that is no longer in stock.
The reverse situation is no better: a receipt was recorded in accounting, but the storefront updated an hour later, and the manager manually takes the position off sale, losing live orders.
Every such window means a canceled order, a refund, an explanation to the client, and a manual fix in two systems.
A separate point of divergence is the nomenclature. The same item is created in accounting and on the website as different cards: SKUs do not match, units of measurement differ, and for some positions the bundle contents change.
Exchange by name or by a code that someone edited by hand starts creating duplicates instead of updating — and double accounting of items grows with every export.
Next, catalog accuracy suffers: prices, specifications, and stock for the "duplicates" diverge, and the customer sees something that exists in neither system.
The third cause is exchange rules. A bulk export once a day is not suitable for items with frequent movements, while an "everything at once" exchange overloads the storefront and overwrites manual content edits.
If an order, cancellation, and receipt have no priorities and no protection against reprocessing, the same operation is applied twice — stock goes negative, and MoySklad synchronization turns into a source of errors instead of eliminating them.
Let's break down how this is closed: matching nomenclature by stable identifiers, separating write permissions, operation priorities, and controlling discrepancies before they reach the customer.
What two-way catalog synchronization delivers
Two-way synchronization is when changes flow in both directions: an edit to a product card or price in the accounting system goes to the website, and an order from the website comes back into the accounting system as a posted document.
One-way export cannot do this: stock levels and prices on the storefront live their own life, and the manager reconciles orders manually.
A properly configured integration removes three things at once. The storefront stops selling what isn't there: stock levels update in real time after every warehouse operation, not once a day on a schedule.
Orders from the website land in the accounting system as ready-made documents — the share of orders without manual edits reaches 90%+ and stays there.
A whole class of failures disappears: selling into negative stock, duplicated line items, price discrepancies between the storefront and the catalog.
- Catalog update speed — from minutes to seconds per item instead of a full nightly export.
- Real-time stock levels — the storefront sees the warehouse after every receipt, shipment, and write-off.
- Manual order edits — only for non-standard cases: pickup, partial shipment, manual discount.
- The "sold something that isn't there" class of failures — closed at the level of stock reconciliation before checkout.
- Price and attribute desync — caught automatically, not by a manager's eyes.
- Change history — you can see who edited a product card and when, and you can roll it back.
The effect is measured not by "it became more convenient" but by concrete numbers: how many items are updated per cycle, what share of orders go through without a human touch, how many discrepancies the reconciliation catches in a week.
We capture these metrics before and after — they show that the integration actually works rather than creating the appearance of it.
Data exchange methods: scheduled, event-driven, and on-demand exchange
The exchange mode determines not the "beauty" of the integration, but how much the data in the catalog diverges from reality at a given moment. Let's break down three working schemes and their limitations.
| Mode | When it fits | Limitations |
|---|---|---|
| Scheduled exchange | The catalog changes rarely: prices, stock, and nomenclature are updated in batches. A nightly run offloads both systems. | The update delay equals the interval: between runs the catalog lives on outdated stock. Frequent runs create unnecessary load. |
| Event-driven exchange | A reaction to change is needed: a price or stock edit goes straight to the catalog. | Requires a queue and idempotent processing — a repeated event must not duplicate an item. Depends on the availability of the receiver. |
| On-demand synchronization | Point operations: rebuild a card, catch up on what was missed after a failure. | Does not replace continuous exchange — it is a manual catch-up tool, not a stream. |
In practice, modes are combined: events cover operational changes, the schedule handles reconciliation and catch-up, and on-demand handles manual restart after an incident. This way the update delay stays minimal where it matters, and the background load does not grow.
The key limitation of any mode is edit conflict: if an item was changed on both sides between exchanges, a resolution strategy is needed, otherwise one side silently overwrites the other's data. We fix the source priority and log discrepancies so that the conflict is visible rather than lost.
Describe how often your catalog changes and how critical the delay is — we will select a mode and come back with an estimate.
Stages of synchronization implementation: from data audit to handover
We start with a nomenclature audit: we export catalogs, products, attributes, prices, stock, and warehouses, count duplicates by SKU and name, and look for items without units of measure and groups with conflicting hierarchy.
At this step it becomes clear which data cannot be synchronized at all without prior normalization — these are corrected before launching the exchange, otherwise discrepancies will be reproduced on every cycle.
- Nomenclature audit. We verify the volume of catalogs, duplicates, broken links "product — attribute — unit of measure," and the history of price and stock changes. We record which entries require manual normalization before launch.
- Designing the field mapping schema. We build a table "source field → target field → transformation rule": how the name is concatenated, how wholesale and retail prices differ, what to do with products that have no stock, and how archived items are flagged.
- Defining conflict rules. We agree on which side is the master for price, stock, and descriptions, and what happens when the same card is changed simultaneously on both sides. Without this rule, the exchange loops on mutual overwrites.
- Configuring the exchange. We set up the channel, enable logging of every request and response, and define the schedule and export batches so that the exchange does not block catalog operations during peak hours.
- Testing for discrepancies. We run a test environment on real data: we compare the number of items, prices, stock, and categories before and after the exchange, and separately review items changed on both sides.
- Error handling and retries. We configure behavior when one of the systems is unavailable: queue, retry, notification to the responsible person. The exchange must not lose changes during a brief connection failure.
- Handover of regulations. We provide documentation: the mapping schema, conflict rules, instructions for adding new fields, and the procedure for handling discrepancies. We train the employees who will maintain the catalog.
After the regulations are handed over, the exchange runs autonomously, and changes in catalogs do not require developer involvement. Describe your task — we will get back to you with an estimate and a work plan.
Rules for matching products, prices, and warehouses
Matching starts with choosing a stable key: a supplier's SKU, a barcode, or an external identifier that does not change when an item is renamed.
If there is no key, the link is made by a combination of "name + characteristics," and then any edit to the name on the МойСклад side or in the website catalog creates a duplicate.
That is why, at the start, we establish a rule: one item — one key, and all other fields are considered mutable attributes.
Units of measurement and multiplicity are the second source of discrepancies. A product may be stored in accounting in packs but sold by the piece or by weight, so the rules specify a conversion factor and a base unit to which stock and prices are reduced.
Without this, МойСклад synchronization returns the correct number but in the wrong dimension, and the website shows "1" instead of "12."
Markup rules are set separately from prices: the base price comes from accounting, while the markup, rounding, and minimum price threshold are applied on the website side by category or counterparty.
This way, a change in the purchase price does not require manually editing the storefront, and promotional discounts do not conflict with accounting ones.
Warehouse accounting is built on an explicit list: which warehouses provide stock to the website, how available quantities are summed, and what to show at zero — removal from sale or pre-order.
Duplicate items are caught during the initial reconciliation stage: we run both catalogs through the keys, show discrepancies, and merge records before enabling the exchange, not after.
What the client receives upon completion of implementation
Implementation ends not with the launch of the exchange, but with the handover of a complete package that your team can use to operate the synchronization without us.
Everything configured in the integration is documented: matching rules, conflict handling, and behavior when inventory balances diverge.
- Configured exchange rules — which entities are synchronized (items, prices, inventory balances, counterparties, orders), in which direction, at what frequency, and by what trigger the exchange is launched.
- Mapping schema — a table mapping fields and reference data between the accounting system and the website catalog: SKU, units of measurement, categories, tax rates, warehouses. It shows what will happen to a product when any attribute changes.
- Exchange logs — logs for each session: how many records were accepted, rejected, which entries errored out and why. They allow an incident to be investigated without server access.
- Operator instructions — what a manager does when a new product appears, a price changes, or a card is manually edited on the website, so that the next synchronization does not overwrite the changes.
- Recovery procedure — the sequence of actions in case of failure: how to roll back a failed session, restart the exchange from a checkpoint, and restore the catalog from a backup.
- Exchange documentation — a description of the integration logic, extension points, and limitations: where a new field is added, how a new warehouse or price list is connected.
- Access and roles — accounts for the exchange service with the minimum required permissions and the procedure for rotating them.
We hand over the package in your format — a repository, an internal knowledge base, or printed procedures. After handover, we conduct a walkthrough with your team: we show where to view the logs, how to read the mapping schema, and what to do when a discrepancy occurs.
From there, you either run the exchange yourselves or return to us for support — in either case, the integration does not remain a "black box."
Describe your task — we will get back to you with an estimate and a plan.
How does one-way export differ from two-way synchronization?
One-way export is when the catalog, stock, and prices flow from the accounting system to the website on a schedule or on an event.
In this scheme, the website only receives data: it does not tell the accounting system that a customer has placed an order or that an item is out of stock at the shipping warehouse.
As long as the business runs on a single sales channel, this is enough — but as soon as a marketplace, a retail location, or a manager selling manually appears, the export stops reflecting reality.
Two-way exchange adds a reverse write: orders, write-offs, and stock adjustments flow back from the web application into the accounting system. This is where the main engineering challenge appears — data conflicts.
The same item could have changed on both sides: a manager adjusted the price in the accounting system, while a content editor changed the description on the website.
Without a source-priority rule, such edits overwrite each other, and the catalog starts to "flicker": the price rolls back, the stock jumps.
That is why two-way synchronization is primarily not about transport, but about a field-ownership model. Usually the agreement is this: the accounting system owns the price, stock, and SKU, while the website owns the description, photos, and SEO fields.
Then the conflict is not resolved "on the fly" but does not arise at all: each side writes only to its own fields, and conflicting changes are rejected by this rule.
The second layer is idempotency. A network failure, a repeated event delivery, or a manual restart of the exchange must not duplicate an order or write off stock twice. Each operation gets an identifier, and a repeat with the same identifier is recognized as already applied.
This is what distinguishes a working two-way exchange from an export that "sometimes duplicates orders."
The third layer is discrepancy resolution, for when the rules still did not cover a case. You need an operations log from both sides and a clear reconciliation procedure: you can see who changed a field and when, which value won, and why.
Without such a log, two-way synchronization turns into a source that no one trusts, and the team goes back to manual reconciliation.
Case Study: How the Catalog Stopped Diverging from the Accounting System
Before implementation, the online store's catalog was updated by an export from the accounting system on a schedule — once every few hours, via a manually launched script.
Between exports, managers sold items that were no longer in stock, and the stock levels in product cards didn't match reality. Orders placed for unavailable items had to be canceled or renegotiated with the customer.
What It Was Like Before
Employees spent time reconciling: some orders required manual correction — verifying availability, substituting an item, recalculating the total. Cancellations came in a stream, and customers lost trust in the availability shown on the site.
Reverse synchronization was also missing: order statuses and item changes weren't sent back to the accounting system, causing data to diverge in both directions.
What Was Changed
Two-way exchange with МойСклад was set up via API: stock levels, prices, and item data are pulled into the catalog, while placed orders and their statuses are sent back to the accounting system.
The exchange runs on events rather than a schedule, so a product card is updated almost immediately after a change in the warehouse.
Product matching by SKU and conflict protection were added: if an item is edited from both sides, priority is given to the accounting system, and the discrepancy is logged.
Exchange errors don't bring down the catalog — the queue retries, and problematic records end up in a report for review.
What It Became
The stock update delay was reduced from several hours to minutes, the share of orders requiring manual correction dropped by a multiple, and the number of cancellations due to "out of stock" was reduced to isolated cases.
Managers stopped reconciling data manually — the catalog and the accounting system show the same state.
Common technical concerns before starting
Before starting, clients usually ask the same engineering questions — not about "interface convenience," but about how the system behaves in non-standard situations.
Below are direct answers without marketing: what happens if the exchange is interrupted, how conflicts are resolved, and whether the catalog can be synchronized partially.
What happens if the exchange breaks off midway?
The exchange runs in transactions by batches, not as a single package. Each batch is committed to the synchronization log only after a successful write on both sides — if the connection is lost, the incomplete batch is marked as failed and retried on the next run.
Duplicates are excluded: each record has a matching key, and re-synchronization updates the existing item rather than creating a second one.
How are conflicts resolved if a product was changed on both sides?
The resolution rule is set at the start and fixed in the configuration: MoySklad priority, website priority, or comparison by last modified time. For critical fields — price, stock, SKU — we usually set the accounting system priority, and for descriptions and media — the website.
Conflicting records are not "silently overwritten": they go into a discrepancy report that can be reviewed manually.
Can the exchange be partial rather than the entire catalog?
Yes. Synchronization is configured by filters: specific warehouses, product groups, nomenclature types, or only records changed since the last run.
This reduces the load and exchange time — with a catalog of tens of thousands of items, a full run is not needed; the delta is enough.
What about data recovery if something goes wrong?
Before each run, a snapshot of the matching state is saved. If an error is discovered after the exchange, we roll back to the snapshot and run re-synchronization — the catalog returns to a consistent state without manual editing of items.
Let's discuss your synchronization task
We show on a real case what this looks like in practice.
The client — a wholesale company with several warehouses — had a catalog in МойСклад and a website on its own platform living separate lives: managers edited stock manually, prices on the website lagged behind accounting by a day or two, and some items went on sale with zero stock.
Synchronization ran on a schedule every few hours and crashed on conflicts — when the same card was edited simultaneously in two systems, the one written last won, and the data quietly diverged.
What we changed
We analyzed the current exchange scheme and moved it to an event-driven model: changes in МойСклад and on the website go into a queue and are applied according to conflict resolution rules — priority goes to the accounting system for stock and to the content editor for descriptions.
Product, category, and unit-of-measure reference books received stable identifiers, so new items are no longer duplicated on re-export.
What it became
A full catalog reconciliation instead of several hours takes minutes, incremental updates — seconds. Stock discrepancies dropped from hundreds of items per week to isolated cases that are immediately visible in the synchronization log. Rolling back to the previous catalog state takes one run, not manual editing.
What the work on your task includes:
- analysis of the current exchange scheme: which systems, which entities, who initiates changes;
- rules for matching products, categories, prices, and stock between systems;
- conflict resolution policy and handling of deleted items;
- logging of operations and failure notifications;
- a phased implementation plan with testing on a staging environment;
- estimation of timelines and scope of work for your catalog volume;
- documentation on the exchange scheme and instructions for managers.
Describe how the exchange is set up now — which systems are involved, how often stock and prices change, where discrepancies have already occurred. We'll come back with a work estimate, implementation plan, and timelines by stage.
