Custom CRM Integrated with 1C: Exchange Routes, Data Ownership and a .NET Reference Architecture
A technical note for companies keeping 1C for accounting while building a CRM they own: OData, HTTP services or file exchange, which system owns customers, products, prices and invoices, how errors and reconciliation work, and when a move to Business Central makes more sense.
A custom CRM connects to 1C through one of three exchange routes: the OData REST interface the 1C platform can publish, HTTP services written inside the 1C configuration, or scheduled file exchange in XML or JSON. Decide sync direction per data set first. 1C usually owns legal counterparties, products, prices, invoices and payments, while the CRM owns leads, contacts, activities and the orders it sends to 1C. A .NET integration service keyed on 1C identifiers retries failures, logs every message and reconciles both sides daily. If the 1C configuration is already a burden, plan a later move to Business Central and keep the integration layer swappable. Solzet builds the CRM and the integration; it does not implement or administer 1C.
Which exchange routes can a custom CRM use to integrate with 1C?
The same three routes that serve a one-off extraction also serve an ongoing integration, but the criteria change: an integration needs writes as well as reads, predictable latency and an error you can act on. Our 1C to Business Central migration guide describes the routes for leaving 1C; the table below looks at them for staying on 1C and connecting a CRM. Which route a given configuration supports, and how it is published, is confirmed with your 1C programmer in the assessment.
| Route | How the integration uses it | Fits when | Watch out for |
|---|---|---|---|
| OData interface | The CRM reads and writes catalogs, documents and registers over REST, with the 1C web server publishing the interface. | The configuration is close to standard and the objects the CRM needs are exposed as they are. | Which objects are published, performance on large registers, and business logic that only runs when a user posts a document inside 1C. |
| HTTP services | Endpoints written inside the 1C configuration accept and return exactly the payload the CRM needs, with 1C business logic applied. | The configuration is heavily modified, or an order must be validated, priced or posted by 1C logic. | The endpoints are code in your 1C configuration: they need an owner, versioning and testing on every 1C change. |
| File exchange | Scheduled XML or JSON files in an agreed format, dropped to a shared location and picked up by the other side. | Batch updates are acceptable, network access to 1C is restricted, or the 1C side already has exchange rules. | Latency, partial files, duplicate processing and no immediate error back to the user. Every file needs an acknowledgement. |
Which system should own customers, products, prices and invoices?
Write the ownership down per data set before any code is written, because two systems that both think they own a customer will overwrite each other. The usual split follows a simple rule: accounting truth stays in 1C, selling activity lives in the CRM. Each row then gets a direction, a trigger and a key.
| Data | Usual owner | Direction | Design note |
|---|---|---|---|
| Leads, contacts, activities, opportunities | CRM | CRM only | Never sent to 1C. They are the reason the CRM exists. |
| Customers (counterparties) | CRM until the first order, then 1C for legal and tax details | CRM to 1C on conversion, 1C to CRM afterwards | Match on the tax registration number before creating, to avoid duplicates in 1C. |
| Contracts | 1C | 1C to CRM | The CRM shows contract terms and validity; changes are made in 1C. |
| Products and nomenclature | 1C | 1C to CRM | The CRM never creates items. New items are requested from accounting. |
| Prices | 1C price types | 1C to CRM | Discounts the CRM may apply are limited by rules agreed with finance. |
| Orders | CRM until accepted by 1C | CRM to 1C, status back | Sent once, idempotently, and locked in the CRM after 1C accepts them. |
| Invoices, payments and balances | 1C | 1C to CRM | Read-only in the CRM, so sales sees debt and payment status without access to 1C. |
| Stock | 1C | 1C to CRM | Refreshed on a schedule or on request, labelled with the time of the last update. |
What does a .NET reference architecture for a CRM and 1C integration look like?
We build custom CRM systems on React, Node.js, PostgreSQL and .NET, and for a 1C integration the integration layer is usually .NET: a separate service, not code inside the CRM screens, so it can be deployed, monitored and replaced on its own. The components below are the pattern we start from and adapt to the route your 1C configuration supports.
- CRM application: a React front end and an ASP.NET Core API over PostgreSQL. Every record that also exists in 1C stores the 1C identifier next to its own key.
- Outbox table: when a user creates an order or converts a customer, the CRM writes the change and an outbox message in the same database transaction, so nothing is lost if 1C is unavailable.
- Integration worker: a .NET worker service that reads the outbox, calls the 1C OData interface or HTTP services, or writes exchange files, and polls or receives changes from 1C on a schedule.
- Adapter boundary: all 1C-specific mapping sits behind one interface, translating between the CRM model and 1C objects. A later move to Business Central replaces this adapter, not the CRM.
- Idempotent writes: every message carries a stable key, so a retry after a timeout updates the same 1C object instead of creating a second order or a duplicate counterparty.
- Integration log: every request, response and error stored with the record it belongs to, readable by support staff from inside the CRM.
- Hosting: in your own data centre or a cloud region you choose, with the integration worker placed where it can reach the 1C web server securely.
How should errors and reconciliation be handled between the CRM and 1C?
An integration that only works when everything works is not finished. Most of the effort that keeps a CRM and 1C in step goes into what happens when a message fails, and into proving every day that both sides still agree.
- Classify errors: transient failures such as a timeout are retried automatically with increasing intervals; business errors such as an unknown product or a closed period go to a queue that a person resolves.
- Show errors where users work: an order that 1C rejected carries a visible status and the reason in the CRM, instead of failing silently in a log.
- Daily reconciliation: a scheduled job compares counts and totals per data set, such as orders sent against orders received and open balances per customer, and lists every difference.
- Replays: a corrected message can be resent from the integration log without retyping the order.
- Change control: any change to the 1C configuration that touches a published object or an HTTP service is tested against the integration before it reaches production.
- Ownership: one named role on your side owns the error queue, so failed messages are cleared daily rather than discovered at month end.
What does the 1C side need, and who does that work?
Solzet integrates with 1C; it does not implement, configure or administer 1C. The work inside 1C, such as publishing the OData interface on the web server, writing HTTP services, adjusting exchange rules or creating the integration user, is done by your 1C programmer or the 1C service provider you already work with. Our part is everything on the CRM side and the integration contract between the two.
In practice we deliver a written interface specification for each data set (fields, keys, direction, triggers and error codes), test data and test cases, and a sandbox CRM to test against, so the 1C side can build and verify its part independently. We then run end-to-end tests together against a copy of your 1C database before go-live.
When should you plan a move from 1C to Business Central instead?
Integrating a CRM with 1C is the right step when 1C works for accounting and is going to stay. It is the wrong investment when the 1C configuration is already the problem: when changes depend on one programmer, when an owner or auditor needs group reporting in English, or when the company is adding legal entities and countries. In that case, plan the move first, or at least build the integration so the 1C adapter can be swapped for the Business Central APIs when the time comes. The 1C to Business Central migration guide covers what the move involves and who it suits.
For companies in Armenia, the Business Central Armenian localization is Solzet's own set of extensions on the international (W1) version of Business Central, and the CRM Armenia page compares Dynamics 365, Power Platform and a custom CRM for Armenian businesses. When the ERP is Business Central or Finance and Operations, the CRM side is covered on our CRM and ERP integration page.
How does Solzet deliver a custom CRM with a 1C integration?
We deliver the CRM turnkey: discovery, data model, screens for each role, the integration service, data migration from spreadsheets or an older CRM, hosting, training and support, all by the same senior consultants and full-stack developers. You own the source code and the data. The custom CRM development page explains the service, the stack and the cost factors over time.
We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them.
- Assessment: CRM processes, the 1C configuration and its exchange options, data ownership and the people on both sides.
- Interface specification: one contract per data set, agreed with your 1C programmer before build.
- Build: the CRM and the .NET integration service in phases, with the integration tested from the first release.
- Test: end-to-end against a copy of your 1C database, including failures, retries and reconciliation reports.
- Go live and support: monitoring of the error queue and reconciliation in the first weeks, then changes as either system evolves.
Как интегрировать собственную CRM с 1С?
Собственная CRM подключается к 1С одним из трех способов: через OData REST-интерфейс, который публикует платформа 1С, через HTTP-сервисы, написанные внутри конфигурации 1С, или через регулярный обмен файлами в XML или JSON. До начала разработки для каждого набора данных определяется, какая система им владеет и в каком направлении идет синхронизация. Обычно 1С владеет контрагентами с юридическими реквизитами, номенклатурой, ценами, счетами и оплатами, а CRM владеет лидами, контактами, активностями и заказами, которые она передает в 1С.
Интеграционный сервис на .NET хранит идентификаторы 1С рядом с записями CRM, повторяет запросы после сбоев без создания дублей, ведет журнал каждого сообщения и ежедневно сверяет обе стороны. Вся логика, связанная с 1С, находится за одним адаптером, поэтому при последующем переходе на Business Central заменяется адаптер, а не CRM.
Solzet разрабатывает CRM на React, Node.js, PostgreSQL и .NET и строит интеграцию, но не внедряет и не сопровождает 1С: работу внутри 1С выполняет ваш программист 1С или ваш подрядчик по 1С. Если конфигурация 1С уже тормозит бизнес, имеет смысл сначала спланировать переход с 1С на Business Central.
What do people ask us?
How can a custom CRM integrate with 1C?
Through the OData REST interface the 1C platform can publish, through HTTP services written inside the 1C configuration, or through scheduled XML or JSON file exchange. OData suits configurations close to standard, HTTP services suit heavily modified ones or logic that must run in 1C, and file exchange suits batch updates or restricted networks.
Which system should own customers, products and prices when a CRM is connected to 1C?
1C usually owns legal counterparties once invoicing starts, products, price types, contracts, invoices, payments and stock. The CRM owns leads, contacts, activities and opportunities, creates customers until their first order, and sends orders to 1C. Write the split down per data set before building.
Why use .NET for a CRM and 1C integration?
A .NET worker service is a dependable home for the outbox, retries, idempotent writes, logging and reconciliation, and it fits organizations that already standardize on Microsoft technology. The CRM itself can run on React with an ASP.NET Core or Node.js API over PostgreSQL.
Does Solzet implement or support 1C?
No. Solzet builds the custom CRM and the integration with 1C and writes the interface specification. Work inside 1C, such as publishing OData, writing HTTP services or changing exchange rules, is done by your 1C programmer or 1C service provider. Solzet also migrates companies from 1C to Business Central.
How do you stop a CRM and 1C from drifting apart?
Store the 1C identifier on every shared record, send every change through an outbox with a stable key so retries do not duplicate, show rejected messages to users in the CRM, and run a daily reconciliation of counts and totals per data set with a named owner for the error queue.
Should we integrate with 1C or move to Business Central first?
Integrate when 1C works for accounting and will stay. Plan a move first when the configuration depends on one programmer, when owners or auditors need group reporting in English, or when the company is adding entities and countries. Either way, keep the 1C logic behind one adapter so it can be swapped later.
Можно ли интегрировать CRM на .NET с 1С?
Да. CRM обменивается данными с 1С через OData-интерфейс, HTTP-сервисы конфигурации или обмен файлами XML и JSON. Интеграционный сервис на .NET отвечает за повторные попытки, журнал сообщений и ежедневную сверку. Solzet строит CRM и интеграцию, а работу внутри 1С выполняет ваш программист 1С.
Where should you go next?
Custom CRM Development
CRM on React, Node.js, PostgreSQL and .NET that you own, with no per-user licence.
1C to Business Central migration
How accounts, analytics, balances and documents move from 1C to Business Central.
Business Central Armenian localization
AMD, Armenian tax and statutory reporting and Armenian documents, built as extensions on W1.
CRM in Armenia
Dynamics 365, Power Platform or a custom CRM for businesses in Armenia, with 1C and bank integrations.
CRM and ERP integration
Integration patterns between a CRM and Business Central or Finance and Operations.
Which solution is right for your business?
Tell us what you need. A senior consultant replies within one business day with a recommendation (Customer Engagement, Business Central, Finance and Operations, Power Platform or a custom-built CRM), not a sales script.