Integrating a website with 1C and local CRMs: ending manual stock work
Every hour a manager spends retyping web orders into the accounting system is salary paid for work a script does in a second without mistakes.
What actually gets synchronised
The exchange splits into four independent flows: products with descriptions and attributes, prices including price types and discounts, stock levels per warehouse, and orders going out with statuses coming back.
Their frequencies differ, and that matters. Products change rarely and can export daily; prices every few hours; stock in live retail every 10–15 minutes; orders must go instantly.
Pushing everything through one heavy nightly exchange is the classic mistake: stock goes stale, a customer orders something unavailable, and a manager calls to apologise. Separate the flows onto their own schedules.
Three technical connection options
File exchange: the accounting system drops XML or CSV on a schedule and the site parses it. Primitive but reliable, and appropriate when 1C sits on a LAN with no external access. The downsides are latency and no error feedback.
A REST API on the site: 1C posts to protected endpoints and the site answers with 200, 400 or 409. This is the most transparent option — a clear initiator, real logs, and retries.
An intermediate database or message broker is only warranted at high volume, or when more than two systems are involved. For mid-sized business it is overkill.
The matching key is the critical decision
Every item needs a stable identifier shared by both systems: the 1C GUID or an SKU nobody edits. Matching by product name collapses at the first typo.
Store an external_id column on the site with a unique index. Re-importing the same product then updates instead of duplicating, and the operation becomes idempotent.
Apply the same logic to orders: the site sends its number, 1C returns its own, and both live on one record. Without that, reconciling discrepancies becomes manual searching by date and amount.
Stock, reservations and prices
Decide up front whether to show exact counts or bands like in stock / low / made to order. The latter is more honest, since between two syncs the number is wrong anyway.
Reservation must happen when the order is placed, not at sync time. Otherwise two customers buy the last unit simultaneously — routine locally for goods also sold over the counter.
Store UZS prices as integers in the smallest unit and round by one agreed rule on both sides. A rounding mismatch produces different totals on the site and in accounting, and reconciling that takes days.
Errors, retries and observability
Every exchange must be idempotent: resending the same order must not create a second one. The simplest approach is a unique request key checked before writing.
Keep an exchange log table: timestamp, direction, payload size, response codes, error text. During an incident, 'did the order arrive' should be one query, not a chat thread.
Send a Telegram alert on failed exchanges — locally that is the fastest channel to whoever is responsible. A silent sync failure surfaces a week later through customer complaints, and that is expensive.
Timelines and budget
One-way catalogue and stock export is typically 1–2 weeks. Two-way exchange with orders and statuses starts at 3 weeks. Multiple warehouses, price types and dealer terms stretch it further.
Local pricing guidance: 8,000,000 to 25,000,000 UZS depending on the number of flows and the state of the accounting system. The unpredictable part is never the code — it is data quality inside 1C.
Budget a separate phase for cleaning the product catalogue before development starts. Duplicate items, empty attributes and products without SKUs cause most blown integration deadlines.