1C-Bitrix and Prom.ua: Where Order and Stock Exchange Breaks Down
Order synchronization between 1C-Bitrix and Prom.ua rarely breaks completely — more often it "almost works": some data arrives, some hangs in the log, and discrepancies accumulate silently.
After a few weeks, accounting sees orders that are not in stock, and the marketplace manager sees stock that is not in the accounting system.
The price of such "almost" is manual reconciliation in the evenings, cancellations after payment, and a customer who got a refusal for an item that was in stock.
The first gap is orders. If the export runs on a schedule, a repeated run after a failure sends the same items again, and duplicate orders appear during export.
This is not fixed by "resending" but by an external identifier: each record is linked to a document in the accounting system, and repeated receipt is recognized as already processed. Then a job failure does not turn into two shipped kits.
The second gap is stock. The discrepancy between marketplace and warehouse stock accumulates when the export does not include reservations, made-to-order items, and items in assembly.
The marketplace continues to sell according to the last snapshot, the warehouse according to actual stock, and the gap grows with each shipment.
What matters here is not the synchronization frequency but the rule for calculating available quantity and a single point that calculates it.
The third gap is statuses. An order lives in two independent lists: the marketplace has its own set of states, the accounting system has its own, and the link between them relies on manual notes by a manager. Miss one change and a paid order is listed as new, while a shipped one hangs in pending.
Next, we look at how this is closed: where to place idempotent ingestion, how to calculate available stock, and how to bring statuses to a single source of truth.
What a Well-Built Integration Delivers: Effect on Timelines and Failures
While integration relies on manual transfer, every order and every stock adjustment is a human operation, which means delay and risk of error.
A well-built integration turns these actions into a routine: item data, prices, stock, and orders move between the accounting system and the Prom.ua marketplace without operator involvement. You can verify the effect using the checklist below — every item is measurable.
- Automatic stock synchronization. The quantity on the storefront matches warehouse accounting within the export cycle: an item is not sold twice and does not show as "in stock" without inventory.
- Order status update speed. A state change in accounting reaches the marketplace seller account within minutes — the customer sees movement on the order, and the manager works with the current picture without clarifying calls.
- Reduction of manual operations. Catalog export, price recalculation, and order transfer become routine: where there were several dozen actions per day, only exception control remains.
- Elimination of data desynchronization. One card — one SKU: mapping by code, not by name, removes duplicates and stock discrepancies between systems.
- Resilience to interruptions. Unavailability of the marketplace or accounting system does not bring down the export: the queue picks up missed events after connectivity is restored.
- Returns and cancellations. Reverse movements enter accounting automatically, and stock returns to the warehouse without manual adjustment.
- Transparency. The log shows what went out and when, where it stopped, and why — troubleshooting takes minutes instead of hours of searching.
If an item is not fulfilled, then the integration is configured only partially, and that specific area is the first to be improved.
Integration Methods Between 1C-Bitrix and Prom.ua: Comparison of Approaches
"1C-Bitrix" and Prom.ua store the same things differently: the marketplace has its own category structure and required set of attributes, while the site has its own model of sections and properties.
That is why integration is not built "head-on" but through one of the connection circuits, and the chosen circuit determines how quickly the marketplace sees a new price or stock level and what happens if either side fails.
| Option | When it fits | Limitations |
|---|---|---|
| Direct integration via the marketplace API | Small catalog, constant up-to-date prices and stock are important, orders need to be pulled immediately | Dependence on the third-party marketplace's availability, rate limits on requests, errors are visible only at the moment of the call |
| Scheduled batch synchronization | Catalog from hundreds of items, stock changes several times a day, delay is acceptable | Lag between export and publication; on failure the job silently skips a cycle — report monitoring is needed |
| Intermediate data store | Multiple marketplaces or sales channels, complex markup and category mapping rules | Requires a separate database and reconciliation procedure, more expensive to maintain |
| Manual price list export via file | One-time promotions, trial launch on part of the assortment | Human factor, stock discrepancies, does not scale |
In practice, the most stable option is a combination: scheduled synchronization handles the catalog, prices, and stock; the API pulls orders and statuses; and the intermediate data store smooths out structural mismatches and keeps a product mapping log.
We select the circuit based on the load — catalog size, price change frequency, and which system is considered the source of truth for stock.
Integration Setup Stages: From Data Audit to Handover of Procedures
Synchronization between a 1C-Bitrix catalog and the Prom.ua marketplace does not break at setup time but on data discrepancies: reference data is out of sync, units of measure do not match, and stock changes faster than the marketplace accepts it.
That is why integration implementation proceeds in stages from data audit to procedure — otherwise, after each export run, you have to figure out why an item is in the seller account but is not selling.
- Discovery. We record which reference data participates in the integration: items, categories, prices, warehouses, and order statuses. We calculate the volume — how many items go to Prom.ua, how often prices and stock change.
- Audit of reference data and items. We look for duplicates, items without a category, zero and negative stock, and mismatched units of measure. Without this, mapping will have to be redone after the first exports.
- Mapping scheme. We determine which field links an item in 1C with a card on the marketplace: external identifier, SKU, or code. We define rules for new items and for those already published.
- Integration setup. We set the direction of flows (goods, prices, and stock one way; orders the other way), export schedules, and the priority of the data source in case of conflict.
- Test run. We run the integration on a small catalog slice and analyze the marketplace's response: rejections, broken links, items without a price. We make corrections in the rules, not in individual cards.
- Validation on production volumes. We export the full catalog, compare checksums by quantity and prices, and verify that an order from the marketplace correctly enters the accounting system.
- Handover and support procedure. We provide the mapping document, manual launch procedure, a list of typical errors with cause and action, and responsible contacts on both sides.
What the Customer Retains: Configurations, Schemes, Procedures
The result of the work is not the fact that integration is running, but a set of artifacts that your team can use to maintain the connection with the marketplace without us. Below is what exactly is handed over and what task each document solves.
- Configured integration profiles: catalog, stock, and price export; order intake; and status synchronization — each profile with its own schedule, section filter, and item mapping rules.
- Data flow scheme: a "source → target" map, a list of transferred fields, and reference mappings for goods, warehouses, units of measure, and order statuses.
- Discrepancy handling procedure: what to do on export failure, stock conflict, duplicate order, or missing item — and which case requires manual intervention.
- Access policies: separate accounts for integration, minimum required permissions, key rotation procedure, and a log of settings changes.
- Operator instructions: how to check integration status, where to view the log, how to start a resynchronization, and whom to escalate a failure to.
- Test environment: a copy of the integration on test data, where changes to mapping rules are verified before rollout to the production circuit.
After launch, you change the assortment and connect new sections without ordering custom development for every change. The scheme and procedures describe how to do this yourself; we get involved where logic customization is needed.
Case Study: Order and Stock Synchronization for a Retail Chain
A retail chain with four warehouses and several thousand SKUs sold through Prom.ua and kept records in an accounting system.
Managers manually pulled orders from the seller account, and stock was exported twice a day — during active sales, availability diverged from actual stock by noon.
Before: Manual Processing and Discrepancies
No more than 12% of orders went through without human involvement.
Warehouse stock caught up with the marketplace in 3-4 hours, and by the end of the month about 7% of orders had discrepancies in composition or quantity: they were handled manually by reconciling correspondence with the customer and warehouse movements.
After: Integration Without an Operator
We built a two-way integration: orders are pulled by event, stock is recalculated on every warehouse movement rather than on a schedule.
Each operation receives an identifier, so repeated export does not create duplicates, and failed calls go into a queue with retries and a log visible in the admin panel.
The share of orders without manual intervention grew to 96%, reaction to warehouse changes decreased to a couple of minutes, and discrepancies fell below half a percent per month.
Managers switched to returns, exchanges, and non-standard deliveries, and the integration log became the main reconciliation tool.
How Does Event-Driven Integration Differ from Scheduled Integration?
The difference is what triggers the export. Scheduled integration is a scheduler job: at a set interval, it collects accumulated changes and sends them in a batch.
Event-driven integration starts immediately after a change — a price, stock level, or order status changed, and the export goes out without waiting for the next cycle.
For a catalog in Prom.ua, this is a question of the cost of an error: while data waits its turn, the customer places an order at the old price, and the manager later handles the discrepancy manually. An event-driven scheme reduces the discrepancy window from tens of minutes to seconds.
| Trigger Mode | When it fits | Limitations |
|---|---|---|
| Event-driven | Prices, stock, order statuses — where a discrepancy immediately hurts sales | A mass catalog update creates a spike of short requests to the marketplace |
| Scheduled | Reference data, descriptions, photos, attributes — change rarely, not critical to delay | The discrepancy window equals the interval between runs |
| Hybrid | Large catalog with active sales | Requires a queue and a rule for which entity goes through which channel |
Server load with event-driven integration is higher and more uneven: revaluing a catalog of tens of thousands of items turns into a stream of single exports.
That is why events are queued, changes over a short window are merged into one batch, and the number of concurrent handlers is limited — the spike is damped while data freshness remains. A marketplace failure is handled by retry; otherwise, some changes are lost silently.
In practice, a hybrid circuit is used: orders, prices, and stock are event-driven; descriptions and media are scheduled in a night window. Data synchronization frequency and batch size are selected based on measurements, not defaults.
Common Technical Concerns When Setting Up Integration
Integration between a 1C-Bitrix catalog and Prom.ua is not a one-time switch but a permanent mode: a connectivity failure, catalog edits, or connecting a new supplier test its strength. We have collected what is most often clarified before starting.
What happens if the export is interrupted midway?
Integration proceeds in portions, and the result of each is recorded in the log.
A repeated run after an interruption continues from the last confirmed item, not from the beginning: accepted cards and orders are not duplicated, and the log shows at which step the connection was lost.
How do you prevent order duplication?
An order is matched by external identifier: a repeatedly received record updates the status rather than creating a second one.
If an order was changed both on the marketplace and in the accounting system, the dispute is resolved by the time of the last change, and the discrepancy goes into a report.
Why did the item catalog export only partially?
The reason is almost always in the data: an item without a link to the marketplace category, empty required attributes, duplicate SKUs, zero stock, or a missing price. For each filtered-out item, the report states the reason, and after correction it is loaded in a separate run.
Will the store be idle during setup?
No. Initial synchronization and debugging run on a copy of the catalog, and production integration is enabled in an agreed window. If something goes wrong, reverting to the previous mode is one operation, and the storefront continues to accept orders.
Let's Discuss the Task: How We Will Remove Data Integration Risks
To discuss website integration, you do not need to prepare a technical specification — it is enough to tell us what already works and what result is needed.
We will analyze the current integration scheme between 1C-Bitrix and Prom.ua, clarify data sources, and come back with an estimate and work plan: stages, timelines, and areas of responsibility.
The inputs for starting a project are usually gathered in one conversation. It helps to have at hand:
- a list of entities in the integration: goods, categories, attributes, suppliers, counterparties;
- what goes to the marketplace and what comes back — orders, payment and delivery statuses, stock;
- the required synchronization frequency and system behavior when prices diverge or an item is withdrawn from sale;
- access to a test copy of the database and to the seller account — we verify the scheme without risk to live orders;
- who on the customer side accepts the result and confirms the correctness of item mapping;
- customizations in the accounting system that must not be changed, and rules that must be preserved.
Based on the results, you receive an integration map with a list of fields and mapping rules, an effort estimate by stage, and a work plan with checkpoints.
A separate item is post-launch integration support: an error log, failure alerts, and a procedure under which discrepancies are resolved before the customer notices them. Describe the task in free form — we will come back with an estimate and plan and suggest where to start.