Bidirectional integration of 1C with a B2B Portal: A Complete Guide for Wholesale Companies
Contents
Nearly every wholesale company in Kazakhstan uses 1C for its business records. Orders come from everywhere: the website, dealers on WhatsApp, email, and sales representatives. Until these channels are connected to 1C, managers transfer data by hand and introduce errors along the way.
Integrating 1C with a B2B portal solves this problem when it is built as an engineered system rather than a one-time file export. In this article, we explain how it works, what data is exchanged, how long it takes, and where things can go wrong.
What two-way integration means
Two-way integration means data flows automatically in both directions according to documented rules, with a single source of truth for each type of data.
- 1C is responsible for product data, prices, inventory levels, business partners, contracts, credit limits, and primary documents.
- The portal is responsible for orders, requests, registrations, and user actions.
If this rule is not documented before work begins, a month after launch the portal will show one price and the invoice another, and no one will know which is correct.
What data is exchanged
From 1C to the portal:
- products, attributes, units of measure, and order multiples;
- price types, customer-specific prices, discounts, and promotions;
- inventory levels and reservations by warehouse;
- business partners, contracts, credit limits, and accounts receivable;
- order statuses;
- invoices, delivery notes, service completion certificates, and account reconciliation statements.
From the portal to 1C:
- orders and their line items;
- new clients and contract requests;
- claims and returns;
- changes to contact details.
Three ways to exchange data
Scheduled file transfers
1C generates XML or CSV files, often in CommerceML format. The portal retrieves the file and updates the data. This works for a small catalog that changes infrequently.
Drawbacks: data becomes outdated between exports, and file errors are discovered after a client complains.
HTTP services and API
1C publishes HTTP services, and the portal requests data and sends orders. Data is more accurate, and orders enter the accounting system almost immediately.
Drawbacks: the configuration needs customization, and you need a specialist who understands both 1C and web development. Few such specialists are available, making this the main scheduling risk.
Integration layer
A separate service sits between 1C and the portal. It receives and validates data, places it in a queue, forwards it, and logs every operation. If one system is unavailable, the message is not lost and is sent again.
This is a robust option for companies with multiple warehouses, multiple 1C databases, or a combination of 1C, a portal, and Bitrix24.
Realistic timelines
| Scenario | Estimated timeline |
|---|---|
| Catalog and inventory export from a standard 1C configuration | 2-4 weeks |
| Two-way exchange of orders and statuses | 1-3 months |
| B2B portal with customer-specific prices, limits, and documents | 4-6 months |
| Multiple 1C databases, CRM, and a unified exchange log | 6 months or more |
An exact timeline can only be provided after reviewing the specific database. A contractor who quotes a fixed price without access to your 1C has either built in a large contingency or does not understand the scope of work.
Common pitfalls
“We have a standard 1C configuration”
Almost every database has customizations: custom fields, processing tools, and nonstandard reservation rules. These need to be identified before estimating the project, or the budget will grow halfway through.
Duplicate orders
The portal sends an order, 1C does not respond in time, and the portal sends it again. Without duplicate protection, two identical orders appear in the accounting system. A properly designed integration assigns a unique key to each operation and ignores repeats. In engineering, this is called idempotency, and it is the first thing to ask your contractor about.
Inventory discrepancies
Shipments, transfers, and sales through other channels constantly change inventory levels. If the portal updates them once a day, clients order products that are no longer available.
No one owns the master data
Three records for the same product in 1C will become three products on the portal. Integration carries over either order or chaos, but it does not fix the data on its own.
Data exchange stops silently
Without monitoring, a failure may go unnoticed for days. You need an operation log and a notification to the person responsible as soon as an error occurs.
Load on 1C
Exporting the entire catalog every 15 minutes during business hours slows down accounting and warehouse operations. Transfer only changes and move resource-intensive operations to the integration layer.
Where Bitrix24 fits in
If your company uses Bitrix24, the integration becomes three-way. An order from the portal must appear in both 1C and the manager’s CRM. It is important to decide in advance which system is responsible for what, or duplicate deals and status disputes will arise. We cover this in detail in our article on the architecture connecting 1C, Bitrix24, and the portal.
Pre-launch checklist
- List your order channels and the data needed in each one.
- Assign a source system for each type of data.
- Identify the 1C configuration and version, along with its customizations.
- Calculate the hours spent manually transferring data each week.
- Assign someone to manage product data.
- Prepare a test copy of the database.
- Audit the current data exchange before commissioning development.
Example: integration for a wholesale company
A hypothetical company uses 1C:Trade Management for Kazakhstan, has three warehouses and customer-specific prices for 300 dealers, and gives its managers Bitrix24. The goal is a dealer portal with orders, documents, and limits.
| Stage | Work performed | Result |
|---|---|---|
| Audit | review of the configuration, customizations, master data, and existing data exchanges | data map, list of issues, and cost estimate |
| 1C preparation | product data cleanup, HTTP services, and a test database | data ready for exchange |
| Catalog and prices | export of changes and price checks against actual invoices | dealer sees their own prices |
| Inventory levels | updates based on changes, accounting for reservations | up-to-date inventory levels |
| Orders | event-driven transfer with an operation key | orders in 1C without duplicates |
| Statuses and documents | returned from 1C to the portal | the dealer sees order statuses and invoices |
| CRM | events and tasks in Bitrix24 | the manager sees client orders |
| Reconciliation and monitoring | daily report, notifications | errors are visible immediately |
What the exchange log looks like
For each operation, the log shows:
- a unique operation number;
- the time and source system;
- the object type and its identifier;
- the status: delivered, queued, error, awaiting review;
- the error message and number of attempts.
When a dealer calls to ask where their order is, support can find the answer in a minute instead of reconstructing events from logs across different systems.
Frequently asked questions
Can you do without a 1C programmer?
Sometimes, for a simple catalog export. Not for two-way data exchange involving orders, customer-specific prices, and documents.
How often should inventory levels be updated?
For a wholesale company with multiple warehouses, updates typically range from several times an hour to whenever inventory levels change.
What if you have multiple 1C databases?
You need an integration layer that combines data from different databases into a single model. Connecting each database directly to the portal quickly becomes unmanageable.
Can you integrate with 1C if the database is in the cloud?
Yes, if the cloud version allows you to publish HTTP services or exchange data through external processing tools. Capabilities depend on the provider.
Who is responsible for the integration after launch?
A contractor under a support agreement or an in-house specialist who has been given the documentation and access to the log. The key is to assign someone before launch.
What happens when the 1C configuration is updated?
The data exchange is checked on a test database after the update. If the data format has changed, the adapter is updated before the update is installed on the production database.
