1C, Bitrix24 and a B2B Portal: Architecture Without Duplicates or Data Disputes
Contents
When a company has three systems (accounting in 1C, sales in Bitrix24, and dealer orders on a portal), they are usually connected as they appear. First the portal with 1C, then 1C with Bitrix24, then someone asks for portal orders to be visible in CRM, and a third connection appears. Each is built by its own contractor, following its own rules.
Six months later, a single client has three records with different details, a closed deal does not match a canceled order, and whenever an error occurs, three contractors point fingers at each other. Let us look at how to build an architecture where this does not happen.
Why point-to-point integrations break
- Different rules. Each connection understands clients, orders, and statuses in its own way.
- Duplicates. A single change travels along multiple paths and arrives twice.
- Loops. Systems update each other in circles: 1C updates a counterparty, Bitrix24 accepts the change and sends it back, and 1C accepts it again.
- No unified log. An error cannot be traced from start to finish.
- Growing complexity. Adding a fourth system, such as MoySklad or a delivery service, doubles the number of connections.
- Blurred responsibility. Nobody is responsible for the junction between systems.
The single source principle
The foundation of the architecture: every object has exactly one primary system. The others receive a copy and do not modify it on their own.
| Object | Primary system | Who receives | Who can initiate changes |
|---|---|---|---|
| Product catalog, prices, inventory | 1C | portal, Bitrix24 | only 1C |
| Business partners, contracts, limits | 1C | portal, Bitrix24 | Bitrix24 creates a request for a new client |
| Leads, deals, tasks | Bitrix24 | portal when needed | Bitrix24 |
| Dealer orders | portal creates, 1C accounts | Bitrix24 sees | portal, then statuses from 1C |
| Statuses, documents, payments | 1C | portal, Bitrix24 | only 1C |
This is an example. The specific distribution depends on company processes. For instance, if the sales department enters clients, Bitrix24 can be the primary system for new counterparties until a contract is signed. The key is that the rule is documented and observed.
Integration layer
Instead of point-to-point connections, all systems connect to a single service. It:
- accepts changes from any system;
- verifies them and maps them to a shared data model;
- distributes them to other systems according to rules;
- protects against duplicates and loops;
- maintains a log of all operations with an end-to-end number;
- runs daily reconciliations;
- notifies the responsible owner of errors.
| Without an integration layer | With an integration layer |
|---|---|
| 3 connections for 3 systems, 6 for 4 | one connection per system |
| custom rules in each connection | one data model |
| errors are investigated in three places | one log |
| a new system affects all of them | a new system connects separately |
How to avoid loops
- Source tag. Every change has a tag showing where it originated, so the system does not send back what it just received.
- State comparison. If the new value matches the current one, the change is not transmitted.
- Write permissions. A system that is not primary for an object cannot change its fields.
- Log. Allows you to identify a repeating chain and stop it.
Example: the life of a single order
- A dealer places an order on the portal.
- The integration layer assigns an operation number to the order and creates the order in 1C with inventory reserved.
- Simultaneously, an event appears in the client card in Bitrix24, and for a large order, a deal is created for a manager.
- The order exceeded the limit: an approval task is created in Bitrix24.
- The manager approves, and the result returns to the portal and to 1C.
- The warehouse ships, 1C updates the status, and both the portal and CRM receive the update.
- Payment arrives in 1C, the deal closes, and the dealer sees the completion in their portal account.
Every step is recorded in the log, and a month later you can reconstruct what happened and when.
Step-by-step transition from point-to-point connections
- Document current connections and known issues.
- Create a unified data map and align it with sales and accounting.
- Launch the integration layer for a single flow, usually orders, running in parallel with the old connection.
- Reconcile results between the old and new setups.
- Migrate remaining flows in turn: directories, statuses, payments.
- Disable old connections.
- Set up monitoring and daily reconciliation.
Such a transition does not interrupt company operations for even a single day.
Frequently asked questions
Is this too complex for a mid-sized company?
If you have three or more systems, an integration layer simplifies life rather than complicates it: fewer connections, a single log, and one responsible owner.
Can you use an off-the-shelf data bus?
Yes, but you still need to customize it for your data model, write connectors, and maintain it.
What if you add MoySklad or a marketplace tomorrow?
With an integration layer, a new system connects as another source or recipient without reworking the others.
Where does the integration layer physically run?
On a dedicated company server or in the cloud. It must be accessible to both 1C and cloud Bitrix24.
Who is responsible for the integration after launch?
A single contractor under a support agreement or an in-house specialist who receives the documentation and log.
Can you keep the built-in exchange between 1C and Bitrix24 and connect the portal through the layer?
You can for a transition period, but over time it is better to move this exchange into the layer as well to have a single log and one data model.
