Bidirectional Data Exchange with 1C: What Data to Transfer and How Often
Contents
Two-way data exchange sounds simple: data flows from 1C to the portal and back. In practice, this is where duplicate orders, lost documents, outdated inventory levels, and disputes over the correct price arise. The cause is almost always the same: the exchange rules were not documented in advance, so each developer made their own decisions.
Below is a practical framework Yashcher uses when designing integrations.
Data map
| Object | Source | Service line | Frequency |
|---|---|---|---|
| Products and attributes | 1C | 1C → portal | when changed or several times a day |
| Prices and price types | 1C | 1C → portal | when changed |
| Personalized prices and discounts | 1C | 1C → portal | when changed |
| Inventory and reservations | 1C | 1C → portal | from several times an hour to instantly |
| Business partners and contracts | 1C | 1C → portal | when changed |
| Credit limit and accounts receivable | 1C | 1C → portal | several times a day and when an order is placed |
| Orders | portal | portal → 1C | immediately |
| Order statuses | 1C | 1C → portal | when changed |
| Documents | 1C | 1C → portal | when created |
| New clients | portal | portal → 1C | after review by a manager |
| Claims | portal | portal → 1C | immediately |
A data map is created for each project and agreed upon with accounting and sales before development begins.
Three exchange modes
Batch
Data is transferred on a schedule. This works for the catalog, attributes, and reference data. The main rule is to transfer changes rather than everything at once. A full export of thousands of products every 15 minutes overloads 1C and disrupts the accounting team.
Event-driven
The system sends data when a change occurs: an order is created, a status changes, a document is generated, or a payment is received. This mode is needed for anything that affects money or inventory.
On request
The portal requests data when a user takes an action, for example, the exact credit limit or availability of a scarce item before an order is submitted. This mode is used selectively to avoid overloading 1C.
A good integration combines all three modes. Using one mode for everything almost always leads to either outdated data or an overloaded database.
| Mode | Speed | Load on 1C | Use case |
|---|---|---|---|
| Batch | minutes and hours | low when transferring changes | catalog, reference data |
| Event-driven | seconds | low | orders, statuses, documents |
| On request | instantly | depends on frequency | limits, stock of scarce items |
Rules to document
- One source of truth for each object.
- A unique key for each operation, so a retry does not create a duplicate.
- Order of application: what to do if the "shipped" status arrives before "packed".
- Conflict handling: what happens if the price changes between adding an item to the cart and submitting the order.
- Format versioning: what happens when a new field is added in 1C.
- Reconciliation: a daily check that order counts and amounts match in both systems.
- Manual editing permissions: which data can and cannot be changed manually on the portal.
- Handling 1C downtime: whether to accept and queue orders or block them.
How to choose an inventory sync frequency
The frequency depends on how quickly inventory changes and the cost of an error:
- Slow-moving products (equipment, made-to-order spare parts): several times a day is enough.
- Moderate turnover (building materials, household goods): several times an hour.
- Fast turnover and shortages (popular items, promotions): update with every change and check again when the order is placed.
Example: what happens to an order
- A dealer submits an order on the portal. The integration layer assigns it an operation key.
- The order is sent to 1C. 1C is unavailable due to an update, so the order waits in the queue.
- After 10 minutes, 1C becomes available, the order is created, and the stock is reserved.
- The response does not reach the portal because of a network failure, so the portal resends the order.
- 1C recognizes the same operation key and returns the number of the existing order without creating a duplicate.
- The portal shows the dealer the order number and status.
Without a queue and an operation key, this scenario would have ended with either a lost order or a duplicate.
Common mistakes
- a full data exchange once an hour, which slows down 1C during business hours;
- no log, so no one can say when or why an order failed to arrive;
- manual changes to portal data that are later overwritten by the exchange;
- no test database, so changes are tested on the production 1C system;
- different units of measure in 1C and on the portal;
- no one is responsible for monitoring the exchange after launch.
Frequently asked questions
Do you need a test 1C database?
Yes. Developing and testing data exchange on a production database is risky: an error can create extra records in the accounting system.
Can you use a standard module for data exchange?
Sometimes, for a simple catalog and orders. Custom development is usually needed for personalized pricing, limits, multiple warehouses, and documents.
What if 1C is overloaded?
Move resource-intensive operations to the integration layer, transfer only changes, and avoid full exports during business hours.
How should documents be transferred: as files or as data?
Most often, as data plus a printable PDF. This lets users view the document in their personal account and download it.
How often should you reconcile data?
At least once a day for orders and payments. For inventory and prices, the frequency depends on the situation.
Can photos and files be transferred through the 1C exchange?
Yes, but for large volumes of media, it is more convenient to store files separately and transfer only links through the exchange.
