1C integration: common scenarios, methods and pitfalls

Why 1C integration comes up when you work in Central Asia or the CIS

If your company has a subsidiary, distributor or customer base in Uzbekistan, Kazakhstan or nearby markets, there is a good chance the local books run on 1C:Enterprise. Integration lets your CRM, online store or app work with that data without staff retyping it.

1C usually holds items, stock, prices, counterparties and settlements, while sales and customer communication happen elsewhere. Without a link, sales promises stock that is no longer there, accountants re-enter orders by hand, and reports from the two systems disagree. Integration closes that gap, but only if you first settle one organisational question: which system owns each type of data. The technical method comes after that.

Common 1C integration scenarios

Most projects come down to five scenarios. They differ in the direction of data and in how much delay the business can tolerate.

• CRM and 1C. Counterparties, deals, invoices and payments. Sales sees payment and shipment status without opening the accounting system.
• Website or online store and 1C. The catalogue, prices and stock flow out of 1C; orders flow back in.
• Marketplace and 1C. Orders, stock and prices pass through the marketplace API, often with a middleware service in between, because each marketplace has its own reference data and request limits.
• Mobile app and 1C. Sales reps, couriers or customers get data through a dedicated API rather than from the database directly.
• E-invoicing. Invoices leave the accounting system for an electronic document operator.

The last scenario matters in Uzbekistan. According to the country's Tax Committee, electronic invoices have been mandatory for business entities since 1 January 2020, and the system allows integration with accounting and billing software. The committee lists more than two dozen operators, so check that your chosen operator works with your setup before you start.

What integration methods does 1C offer?

The 1C:Enterprise platform has several built-in mechanisms: an automatic REST interface, custom HTTP services and exchange in standard formats. The right one depends on the job, the configuration and whether the database can be modified.

A few details that affect the choice:

• The REST interface works only after the database is published on a web server. 1C says it exposes nearly all main configuration objects, plus some actions such as posting a document.
• Fill checks are skipped. On REST writes, the platform checks permissions and runs event handlers but does not run the fill check. Your integration has to enforce mandatory fields and business rules itself.
• HTTP services are designed by the developer: URL templates, methods and response format. 1C notes that, compared with SOAP, they are simpler for clients and potentially send less data, which matters most on mobile.
• Check connector lists. Bitrix24's integration page lists configurations for Russia, Belarus and Kazakhstan, with no Uzbek versions on that list. If you run a local configuration, confirm compatibility early or plan a custom exchange.

Where data gets lost: the usual pitfalls

Most failures happen not at connection time but at process boundaries: duplicates, retries and concurrent edits. Work through these during design.

• No system of record. If a customer is edited in both the CRM and 1C, one change can overwrite the other. Assign a source system for each field.
• Matching by name. "Romashka LLC" and "LLC Romashka" become two counterparties. Match on tax ID, SKU or an external identifier; EnterpriseData and CommerceML use GUIDs for this.
• Retries. If a response is lost, the sender retries and 1C gets a second order. Make the exchange idempotent by checking the external ID before creating anything.
• Different reference data. Units, warehouses, statuses and VAT rates are named differently in each system. Without a mapping table, records fail to load or land in the wrong place.
• Partial operations. Partial payments, returns, cancellations after shipment and edits to posted documents rarely make the first version, yet they occur every month.
• Excessive polling. Polling 1C without need loads the database. Send only changes; in EnterpriseData, message acknowledgement shows which changes are already synchronised.
• Configuration updates. A renamed field or a new format version breaks the exchange. The EnterpriseData description on 1C's ITS portal gives a guaranteed support period of 1 year after a new format version is released.
• Silent errors. If nobody watches the exchange log, you hear about failures from customers. Set up alerts and name a process owner.

How to test a 1C integration

Test more than the happy path: failures and retries matter more than a normal run. You need a test copy of the 1C database with real reference data and sample documents, otherwise mismatches surface only in production.

A minimum test set:

1. Clean run. An order from the CRM or website becomes a document in 1C, and the payment status comes back.
2. Retry. The same message is sent twice and no second document appears.
3. Downtime. 1C or the external system is offline during exchange; after recovery, data arrives with no loss or duplicates.
4. Conflict. One record changes in two systems at once and the agreed rule applies.
5. Bad data. An empty mandatory field, an unknown unit, a wrong tax ID: the record goes to an error log and does not vanish.
6. Volume. The first full catalogue load and peak order volume do not disrupt 1C users.
7. Reconciliation. Period totals match in both systems.

Launch one route at a time, such as deal, order, payment. That makes errors far easier to trace than switching every object on at once.

What to put in the integration spec

"Integrate with 1C" is not a requirement. A spec needs objects, fields, direction, frequency and error rules; without them, the estimate stays rough and acceptance turns into an argument. Our specification checklist covers the overall structure. For integration, add:

• the 1C configuration and version, where the database is hosted and whether a developer can get access;
• objects and fields, with the source system for each;
• direction and frequency for each object;
• matching rules, reference-data mappings and the initial load procedure;
• behaviour on errors, retries and downtime;
• who owns the exchange after launch and what happens when the configuration is updated.

Integration is often part of a larger job. If you need sales, warehouse and finance connected, see our ERP, CRM and HRM service, which includes integrations with 1C, AmoCRM, payment systems and external APIs. If the goal is quick answers from accounting data, Company Brain connects to 1C and your CRM and answers with links to sources.

Where to start

Start with a short data map: which objects live in 1C, which live elsewhere, and which system owns each one. A single-page table is enough for a first estimate.

Then:

1. Pick the one route with the most manual work.
2. Confirm the 1C configuration, version and whether it can be changed.
3. Prepare a test copy of the database and sample documents.
4. Book a 30-minute call: we will go through the task, and W2W prepares a proposal within 2–3 days.

The W2W team rate is $10–30 per hour, and source code, architecture and documentation are handed over to the client. Brief, specification, contract and NDA templates are in Documents.