Integrating 1C with Your Website, Online Store or CRM: Exchange Methods, Sync Rules and Who Does What
How to integrate 1C with a website, online store or CRM: what to sync and how often, CommerceML, OData and HTTP services compared, shared IDs and testing.
In many companies the website or CRM learns about a sale before accounting does, and someone closes the gap by retyping. A manager copies each web order into 1C, stock on the site is updated from a spreadsheet, and salespeople phone the accountant to ask whether a client has paid. Integrating 1C with your website, online store or CRM removes that work, but only if the data exchange rests on clear rules rather than on "sync everything".
This vendor-neutral guide for companies in Uzbekistan covers what to sync and how often, the main 1C data exchange methods, master data, reliability, who does what, and a launch checklist.
Why integrate 1C with a website, online store or CRM
- No more re-entering orders. Orders from the site or CRM arrive in 1C as documents, with no copying, no typos and fewer mismatches between what was sold, shipped and paid.
- Real stock and prices online. Customers see actual warehouse stock at the price set in accounting, and the store stops selling items that ran out yesterday.
- Sales staff see the money. Managers in the CRM see a client's debt, payment status and shipments from 1C before promising delivery or a discount.
In Uzbekistan 1C is often the accounting system of record, and the installation is frequently a localised or customised configuration. Local developers produce editions adapted to Uzbek practice, such as a 1C:Accounting 3.0 edition reported in 2021 with connections to Didox, Dibank, Mehnat.uz and my.soliq.uz. Which exchange mechanisms exist, and what data they carry, therefore depends on your configuration and its version, not on what 1C supports in general. This variety is also why integration can be a major line in a CRM budget.
Decide what to sync, in which direction and how often
In a typical 1C online store integration, the catalogue, prices and stock flow out of 1C and orders flow back in. A 1C CRM integration adds customers, debts and payment status. Give each flow its own direction and frequency:
- Products and catalogue: 1C to the site, on a schedule, often overnight.
- Prices: 1C to the site and CRM, on change or on a schedule. Agree which 1C price type customers see.
- Stock: 1C to the site, frequently, depending on how quickly items sell out.
- Orders and statuses: orders from the site or CRM to 1C as each one is placed; statuses back from 1C, on event.
- Customers and counterparties: usually created on the web side and completed in 1C; two-way only where both sides genuinely edit them.
- Payments and documents: payments from the provider or site to 1C; payment status, debts and invoices from 1C to the CRM.
One-way flows are simpler to build, test and support. Make a flow two-way only when both systems genuinely change the same data, and decide field by field which side wins.
"Real time for everything" is rarely needed and has a cost. Every request lands on the 1C server your accountants work in, and polling the whole catalogue all day can slow them down. Keep near-real-time for flows where delay costs money, such as order intake and stock of fast-selling items, and schedule the rest.
Prefer deltas to full exports: send only what changed since the last successful run; 1C's data exchange mechanism can track these changes. An occasional overnight full export catches anything a delta missed.
1C data exchange methods compared
1C:Enterprise applications can publish and call HTTP and web services, exchange files and use standard formats:
| Method | How it works | 1C-side development | Typical use | Watch-outs |
|---|---|---|---|---|
| CommerceML | XML standard: catalogue, prices and stock go to the store, orders come back, over the network or in files | Settings if your configuration has site exchange; otherwise development | Stores whose platform supports CommerceML | Format versions must match; non-standard fields need extra work |
| EnterpriseData | Business-oriented XML format for exchange within a company | Depends on your configuration's support | Exchange between 1C applications or with systems that implement it | Mainly supported in 1C applications; other systems must implement a matching version of the format |
| Custom HTTP services | REST-style endpoints written in 1C's built-in language, published on a web server | Yes | Flows needing 1C's own logic, such as creating an order or returning a debt | Code lives inside 1C and must survive configuration updates |
| SOAP web services | WSDL-described services published by 1C or called from it | Yes | Corporate systems that expect SOAP | Heavier than HTTP services; many web stacks prefer REST |
| Standard OData interface | Platform-generated REST interface (OData version 3, Atom/XML or JSON), published to a web server | No code; publication, exposed objects and access rights | Reading reference data and documents; simple writes | Clients depend on the configuration's internal structure; limit the integration user's rights |
| Scheduled file exchange | XML, JSON or CSV files exported and imported on a schedule | Usually an export or import procedure | Batch flows; no direct network access to 1C | Delays; half-written or twice-processed files; silent errors |
| Integration layer or queue | A separate service that stores messages, maps fields, retries and logs | Whatever links 1C to the layer | Several systems, two-way flows, 1C not always reachable | One more component to host, monitor and document |
A 1C OData integration is often the quickest start: the platform generates the interface, which can read, create, edit and delete records. But it exposes the configuration's objects as they are, so clients may need changes after a configuration update; custom HTTP services take more work inside 1C but give the site or CRM a stable contract. For new work, avoid COM connections: COM is Windows-only, and 1C itself does not recommend it for new solutions.
Do not assume a given configuration, Uzbek localised ones included, supports CommerceML, EnterpriseData or OData out of the box; check with your 1C specialist before choosing a method.
Master data, identifiers and conflicts
Most integration problems are data problems, so settle these before anyone writes code.
One source of truth per entity, sometimes per field. 1C typically owns prices, stock, legal details and debts; the CRM owns deals, contact history and tasks. A customer record may be split: the CRM owns the contact person, 1C the legal name and tax details. Record the owner of each field and make it read-only elsewhere.
Stable shared identifiers. Store the 1C identifier of each record on the web side and the web or CRM identifier in 1C. Names and article codes get edited and reused; identifiers keep a renamed product the same product.
Matching what already exists. Phone numbers appear with and without +998, with spaces and brackets, so normalise them before comparing. Names are written in Latin and Cyrillic, often in a different order: one client can be "Jasur Karimov" in the CRM and "Каримов Жасур" in 1C, and a legal form can be MChJ in one system and ООО in the other. For companies, the taxpayer identification number (STIR, or INN in Russian) is a far better key than the name. Merge duplicates before go-live, not after.
Conflicts and deletions. When both sides change a record between runs, the field's owner wins and the conflict is logged, not silently overwritten. A product removed in 1C is hidden on the site, not erased with its order history; a customer deleted in the CRM stays in accounting.
Units, VAT and IKPU. Agree units of measure so that an order for one box does not arrive as one piece, and keep VAT treatment consistent across 1C, the site and the receipt. Since 1 January 2022, cash register and virtual cash register receipts in Uzbekistan must include the 17-digit product and service identification code (IKPU) from the tasnif.soliq.uz classifier, so the IKPU and package code held in 1C have to match what the site and payment provider send for fiscalisation. Our guide to Click, Payme and Uzum payment integration covers the receipt side.
Reliability: queues, retries and monitoring
A sync has to survive server restarts, 1C updates, month-end closing and an office connection that drops while the website keeps taking orders.
- Queue outgoing changes. If 1C is unavailable, orders wait and are delivered when it returns.
- Retry safely. Each message carries a unique ID and the receiver ignores one it has already processed (idempotency), so a repeated delivery never creates a second order or payment.
- Log every run: what was sent, how many records, and every error with its record.
- Alert on failure. After repeated failures the message is set aside and a named person is notified, for example through a Telegram bot.
- Reconcile daily. Morning reports compare stock, orders and payments between systems, so mismatches surface the next day, not at month end.
Who does the 1C side and who does the web side
Integrations stall when each party assumes the other is responsible. A typical split:
- The 1C specialist changes the configuration, writes HTTP services or exchange procedures, publishes services or the OData interface on a web server, configures exchange settings, and keeps changes compatible with configuration updates.
- The web or CRM developer builds the API client, field mapping, queue, retries, logging and an admin view for inspecting and resending failed messages.
- The accountant or business owner sets the rules, such as which price type is public, which warehouses count as stock and when an order counts as paid, and owns master data quality.
- IT or infrastructure runs the web server, provides secure network access instead of exposing 1C to the internet, and creates integration accounts with only the rights each flow needs.
Write these boundaries into the contract, including who responds first to an alert, and decide who re-tests and supports each flow after a 1C update, because that is when flows break.
Testing and launch checklist
- A copy of the infobase for development and testing, never the live one.
- A mapping document: every field with its owner, direction, format and frequency.
- Sample and edge-case data: items without stock, names in both scripts, customers with two phone numbers, orders with discounts and returns.
- Each flow tested in both directions, including statuses coming back.
- Realistic volumes: the full catalogue and a busy day of orders.
- Failure scenarios: 1C unavailable, a duplicate message, an item deleted on one side.
- Reconciliation reports working before launch.
- A parallel run alongside the manual process until the numbers agree.
- A rollback plan for returning to manual entry without losing data.
- A named owner for monitoring and alerts.
Common mistakes
- Two systems both editing prices, so the figures drift and nobody knows which is right.
- No shared identifiers. Matching by name works until someone renames a product.
- Syncing everything every minute, slowing 1C for the people working in it.
- Writing directly into 1C's database. It bypasses 1C's business logic, so documents and balances can become inconsistent. Use 1C's own interfaces.
- Ignoring Latin and Cyrillic duplicates, so one client exists twice and their debt is split between two records.
- No alerts, so failures appear at month end when the reports do not reconcile.
- Undocumented flows that only their author can maintain.
How BITS Technology can help
We connect 1C with websites, online stores and CRMs as part of our system integration work. Typical flows send products, prices and stock from 1C to the store, and orders, customers and payments back into 1C. Each entity gets one source of truth. The mechanism depends on your 1C configuration and version, whether web services, OData or scheduled file exchange, and changes inside 1C may involve your 1C specialist. Sync frequency is agreed per flow.
Every run is logged, failures are retried, data is reconciled and alerts are raised. Each flow is documented so any capable team can maintain it, and integrations run in parallel with the existing process and are reconciled before cutover. The other end can be a custom CRM, a website or online store, or wider business process automation; see all our solutions. Contact us with your 1C configuration and the flows you need, and we will send a quote after a discovery call.
