Stock levels
Every 10 to 15 minutes, from 1C to the site. Most often to avoid selling something that is no longer in stock.
Five services. Each removes its own piece of manual work: transferring orders, issuing invoices, calculating delivery and sending receipts.
Two-way exchange: products, specifications, prices and stock go to the site, while orders and customers come back into the accounting system. We configure the schedule and the rules so your staff see the order in the interface they are used to.
Wildberries, Ozon and Yandex Market: product card export, stock and price synchronisation, orders received into one system. One stock pool instead of three separate ledgers.
Acquiring and payment systems: cards, instant bank transfers, invoice payment for companies and instalments. We set up refunds and reconciliation of payments against orders.
Delivery cost calculated in the cart from dimensions and address, pickup point selection on a map, automatic tracking numbers and statuses in the customer account.
Receipt fiscalisation under 54-FZ without buying a physical till: the receipt goes to the customer by email and to the tax service automatically at payment.
Not everything needs real-time synchronisation. Frequent exchange of large catalogues loads both the site and the accounting system.
Every 10 to 15 minutes, from 1C to the site. Most often to avoid selling something that is no longer in stock.
Several times a day, from 1C to the site. They change less often than stock levels, so frequent exports are unnecessary.
Once a day, at night, from 1C to the site. A heavy export puts noticeable load on the accounting system.
Immediately after checkout, from the site into 1C. Sales staff must see the order immediately, in the interface they are used to.
Every 15 minutes, from 1C to the site. The customer sees the order progress in their account.
More than half of data exchange problems are not technical, they are about the data itself. Duplicate products, mismatched units of measure, missing SKUs and categories invented on the fly. That is why we always review the 1C reference data before integrating: sometimes tidying it up is cheaper than writing a handler for the mess.
The exchange is first run on a copy, not straight on the live database. A sync error in the live catalogue costs more than a couple of days of preparation.
We review the product list, units of measure, warehouses and price types, and record what needs tidying up before the start.
We agree what counts as a unique product, which prices are exported and what to do with out-of-stock items.
We run the full cycle on a copy of the database and a staging site, checking the order flow from cart to receipt.
We switch to live data, set the schedule and exchange error alerts, and watch it for the first week.
Usually yes, but the scope depends on the version and on how heavily the configuration has been customised. A standard configuration exchanges data almost out of the box, while a heavily modified one needs a bespoke handler. At the start we look at the database and give a definite answer.
The site keeps running on the last data it received and we get an error alert. Orders accumulate on the site and go into 1C once the exchange is restored, so nothing is lost.
If you sell only online, a cloud POS is enough: it generates and sends receipts with no hardware in the office. A physical till is needed when you take cash or settle payments at the point of sale.
Yes, that is the whole point of the integration. Stock is deducted in the shared system regardless of where the order was placed. We also configure reservations so the same last item is not sold on two marketplaces at once.
Tell us which 1C you run, where you sell and what you currently do by hand. We will estimate the scope of work and the timeline.
Request received
We can already see it. We will reply within one business day, and for urgent matters we will bring in the on-duty engineer right away.
City not found. Please check the spelling.