1C UPP exchange with the website: where synchronization breaks
Exchange between 1C UPP and the website almost never breaks "out of nowhere" — the failure matures in one of four places: the upload queue, the matching rules, the scheduled job, or manual edits in the catalog.
A typical scenario: at night the catalog synchronization session fails midway, part of the nomenclature goes to the website, part remains in the old version, and in the morning the manager sees a stuck upload queue and manually pushes the positions through the admin panel.
Each such edit breaks the link between the object in UPP and the product on the website — and the next exchange creates duplicate nomenclature instead of updating existing cards.
Then stock and prices diverge. The stock discrepancy accumulates unnoticed: the website shows the product as in stock, the warehouse has already shipped it through another channel, the client places an order and gets a refusal.
Prices live their own life if UPP has several price types and the one uploaded to the website is not the one the manager sees in the invoice.
The longer this drags on, the more expensive it is to sort out: first the cards are edited by hand, then duplicates are cleaned up, then it turns out that some orders from the website never returned to UPP and got lost in the intermediate table.
A separate cause is the scheduled job. Exchange between 1C UPP and the website, launched on a schedule without result control, accumulates errors silently: the session formally completed, but some packages did not go through.
Without an exchange log and failure notification, the problem is noticed from customer complaints, not from logs.
We break down how this is closed: where to put integrity control, how to clean duplicates without losing order history, and how to build the exchange so that it fails loudly and recovers on its own.
What a well-established exchange delivers: the effect in numbers
A configured exchange between 1С УПП and the website is measured not by the fact that "data flows", but by how much manual work it removes from people and how quickly changes reach the buyer.
When the upload runs on a schedule and by events rather than by a button, price and availability are updated within minutes after a document is posted — the manager stops checking the price list manually and stops editing cards before publication.
The main effect is the share of orders that are processed in the accounting system without an operator's involvement.
With correctly described rules for matching items, counterparties, and warehouses, an order from the cart is created in УПП with the required details, reserves the goods, and lands in the right stage — standard scenarios close automatically, and a person gets involved only in non-standard cases.
The second measurable result is the currency of stock balances. While data synchronizes once a day, the website sells what is not in the warehouse, and that means returns, cancellations, and manual calls.
Event-driven exchange shortens the discrepancy window to minutes, and discrepancies in reservations stop accumulating by the end of the day.
The third is the reduction of manual operations and the class of errors.
Manually transferring prices, SKUs, and order statuses produces typos, duplicate items, and lost positions; with rule-based exchange these errors simply do not arise, and disputable situations go into the exchange log with a clear reason.
In total, this is expressed in the speed of publishing changes, the share of automatically processed orders, and the volume of operations that a person no longer performs. Next, we break down how such an exchange is structured and what is needed to configure it.
Methods of exchanging 1C UPP with a website: comparison of approaches
Exchanging 1C UPP with a website is almost never built "head-on": there is always a layer between the accounting system and the storefront, and its choice determines how frequently the data stays up to date and what happens during a failure. Below are three working options that we apply in practice, with the honest limitations of each.
| Option | When it fits | Limitations |
|---|---|---|
| Standard exchange module | The catalog and prices change infrequently, the item list is stable, a quick start is needed without modifying the accounting system | The exchange runs in full on a schedule; with a large catalog, the load on both systems grows; the export logic is almost impossible to customize for non-standard attributes |
| Intermediate database | Real-time stock levels, prices, and order statuses are needed, along with multiple data sources and complex publishing rules | Requires a separate environment and its maintenance; discipline around the data schema is needed, otherwise discrepancies accumulate unnoticed |
| Scheduled file exchange | One-off exports, archived price lists, platforms without direct access to the accounting system | A delay between export and publication; if the connection drops, the file may remain unprocessed, so integrity control is needed |
The standard exchange module wins where predictability and a minimum of moving parts matter: it does not require separate infrastructure, but it handles frequent changes and a non-standard catalog structure poorly.
An intermediate database removes these limitations — it decouples the accounting system and the website, allows data to be reassembled before publication, and keeps the exchange resilient to peak loads.
File exchange remains the simplest and the most fragile: it is suitable for infrequent tasks, but not for synchronizing stock levels.
The choice is dictated not by ease of configuration, but by the requirements for data freshness and the cost of an error. We break down how to build a reliable exchange and discrepancy control for each scheme.
How we set up the exchange: stages of work
Setting up the exchange with 1C:UPP begins not with editing rules, but with an audit of the current upload: we look at which objects go into CommerceML, where trade offers are lost, and how the upload behaves during full and partial exchange.
At this step we identify bottlenecks — duplicate nomenclature items, warehouse discrepancies, broken prices — and assess the volume of data that will need to be synchronized.
Next, we design the field mapping scheme: we match UPP attributes with information blocks and catalog properties, determine what is transferred as is, what requires transformation, and what remains only on the accounting system side.
Separately, we agree on the exchange rules — frequency, direction, behavior in case of version conflicts — so that the exchange does not turn into manual catalog editing after every upload.
- Upload audit: we analyze the current rules, exchange logs, and data structure in UPP.
- Mapping scheme design: we match attributes, properties, warehouses, prices, and trade offers.
- Exchange rules setup: we define frequency, filters, conflict handling, and partial upload.
- Test run on a copy: we check the exchange without risk to the production catalog.
- Control reconciliation: we compare the number of items, prices, and stock balances on both sides.
- Discrepancy resolution: we fine-tune the rules based on the reconciliation results.
- Exchange regulation handover: we document the launch procedure, verification, and actions in case of failure.
Control reconciliation is a mandatory stage, not a formality: a discrepancy in stock balances or prices between UPP and the website means the exchange rules are working incorrectly, and this will be identified before launch, not after.
We hand over the exchange regulation to the client's team: what to launch, how to verify the result, what to do in case of an upload error — so that support does not depend on us for every failure.
What you are left with after setting up the exchange
Setting up an exchange is not a one-time communication session between two databases, but a set of artifacts by which the system lives and is maintained going forward.
Without them, the very first failure turns into a manual search for discrepancies, and a change of administrator turns into re-learning the logic of the uploads. Below is what exactly remains in your hands after the work is handed over.
- Exchange rules — the configuration of upload and download for each direction: which reference books, documents, and registers are involved, in what order, and what goes only one way. The rules are versioned, and changes are recorded separately so that a rollback is predictable.
- Attribute mapping table — a table mapping fields between the accounting system and the website: items, prices, warehouses, counterparties, order statuses, units of measurement. It shows where each value on the storefront comes from and where to look when there is a discrepancy.
- Launch regulations — the exchange schedule, event-based launch conditions, the procedure for when one of the parties is unavailable, and retry settings. It separately describes how to launch the exchange manually if an automatic cycle was missed.
- Administrator instructions — a step-by-step document for your team: how to check the exchange status, where to look for errors, what to do when a session is stuck, and how to safely restart an upload without duplicates.
- Reconciliation log — a form of regular control: which metrics are reconciled, at what frequency, which discrepancies are considered acceptable, and which require investigation. A completed log shows dynamics rather than a one-time snapshot.
- Data flow diagram — who is the source of truth for each object, what happens to an order at each step, and where conflicts are possible when both sides change something simultaneously.
- Acceptance protocol — the test scenarios by which the work was verified: a new product, a price change, placing and canceling an order, a return. They are also convenient for accepting changes after further modifications.
Such a set removes the main risk of an exchange — the loss of knowledge about how it is structured. Your team can maintain the system on its own, and we step in on a targeted basis: extend the rules, add a new document type, or sort out accumulated discrepancies.
Case study: how 1C УПП exchange stopped breaking orders
The client — a wholesale company with several hundred active SKUs — was running on a combination of 1С:УПП and an online store on 1C-Bitrix.
The exchange ran on a schedule but regularly crashed midway: some orders never reached the accounting system, catalog prices diverged from the price list, and managers edited them by hand right in the product cards.
Each such edit survived until the next upload, after which it was overwritten — and the cycle repeated.
What it was like before the setup
Orders placed at the moment of an exchange failure were lost silently: the customer received a confirmation, but no document appeared in 1C УПП. Managers only discovered the loss when the client called, restored it manually, and re-reconciled prices.
Resolving a single such case took up to half an hour, and price list discrepancies piled up for weeks.
What we changed
We split the exchange into independent streams — nomenclature, prices, stock, and orders go as separate packages with their own queue and log. Each package records a status: sent, received, processed.
If a node is unavailable, the package is not lost but queued for retry — once the connection is restored, the exchange catches up on its own, without manual intervention.
We separately resolved the edit conflict: prices and stock are now written only by 1C УПП, and the product card in the catalog is marked as externally managed.
Manual price editing in the store interface is blocked — the manager sees where the value came from and when it was updated.
What the result was
The stable upload runs without interruptions, and order loss is gone as a category: every placed order is guaranteed to reach the accounting system and is posted automatically. Manual price editing is no longer needed — the catalog and the price list match at the time of upload.
The client's team no longer spends time reconciling and restoring missing documents: the exchange log shows the status for each package, and a discrepancy is visible before a customer notices it.
How 1C UPP exchange differs from 1C UT exchange
The key difference lies in the accounting model. UPP is built around batches, accumulation registers, and a "complex" production loop: cost, tolling schemes, output through processing stages.
UT operates on the operational trading loop — items, characteristics, warehouses, prices, discounts. Hence the different data structure: in UPP, items live in conjunction with characteristics and series, while in UT — with characteristics and packaging.
If you export catalogs "as is," duplicates and broken links appear on the site: the product exists, but there is no price or stock under it.
The export rules also diverge. In UT, the standard exchange with the site delivers ready-made views — stock by warehouse, prices by type, properties for filters.
In UPP, the same data resides in registers that cannot be handed over directly: first you need to assemble a current slice by batches and recalculate the cost, otherwise negative stock and prices "from the past" surface on the site.
That is why in UPP, exchange is more often configured through conversion rules with explicit field mapping, rather than "straight" via the standard exchange plan.
Typical errors when exchanging UPP with the site are desynchronization of catalogs after reorganization, loss of the "product — characteristic — price" link, duplicates on re-export, and "stuck" stock when the export fails midway and does not roll back.
In UT, the same spots hurt less: the structure is flatter, and most discrepancies are caught by standard checks. In UPP, without object version control and idempotent export, exchange quickly turns into manual reconciliation.
The practical takeaway: exchange of UPP with the site is designed not as "enable the standard module" but as a separate loop — with conversion rules, an export queue, and a discrepancy log.
Then the data structure on the site remains predictable regardless of what happens in the accounting system.
Technical concerns about exchange: we answer
1C:UPP exchange with the website breaks predictably: the queue stalls, nomenclature gets duplicated, the catalog diverges from the accounting system. Below is a breakdown of common failures and how they are resolved at the configuration level rather than through manual edits.
What to do if the exchange queue hangs?
First, we look at the exchange session log and the status of the last package: a hang almost always means that a session did not complete and the next one started on top of it.
The fix is not a restart but a procedure: blocking parallel sessions, a timeout per package, automatic retry with logging. If a hung queue has already accumulated, we process it in batches by modification time, not "all at once."
Why do nomenclature duplicates appear?
Duplicates are a consequence of mismatched keys: the website and the accounting system match items by different attributes, and the same nomenclature gets created twice.
The solution is a single external key (GUID or code) as the primary identifier, matching by it, and prohibiting the creation of an item without a key. Plus a rule: we archive rather than delete — otherwise the next upload will bring the item back.
Is it possible to exchange without taking the website down?
Yes. The exchange runs in batches in the background, changes are applied transactionally, and heavy operations (price recalculation, reindexing) are moved to a separate window.
During this time, the website serves the catalog from cache, so the visitor sees neither empty pages nor partial data. The key is idempotency: re-delivery of a package must not create a second item.
Which errors occur most often?
Timeout disconnects on large packages, desynchronization of price and warehouse types, encoding in text fields, absence of a log for troubleshooting.
We close each one at the configuration stage: we split packages, fix the correspondence of reference books, and test the exchange on a staging environment before deployment.
Describe your exchange scheme and the volume of nomenclature — we will come back with an estimate and a configuration plan.
Let's discuss your 1C UPP data exchange task
To come back with an estimate and a setup plan, rather than generalities, we need a snapshot of your current exchange scheme. Tell us how the exchange works today: on a schedule or on an event, which nodes are involved, what already breaks and how often.
That is enough to understand the scope of work and propose a solution for your environment, rather than a one-size-fits-all template.
It helps to include the following in your task description:
- which catalogs, documents and registers must be synchronized between UPP and the website;
- in which direction the flow goes — upload to the website, download orders back, or two-way exchange;
- how data is currently transferred: files via a directory, a direct connection, or an intermediate database;
- by what criterion it is determined that something has changed, and how version conflicts are handled;
- what happens when the connection drops — are orders lost, are items duplicated;
- what load constraints exist: peak hours, the volume of nomenclature, the number of concurrent users;
- who on the customer's side confirms the test scenario and accepts the result.
Based on these inputs, we will come back with a work estimate and a setup plan: which nodes we configure, in what order, what we check on the test environment, and by which metrics we consider the exchange operational.
If some of the data is unavailable — no problem, we will clarify part of it on a call with your engineers and the UPP administrator.
Describe the task in any convenient form — a list, an email, or right in the chat. The more specific the current scheme, the more accurate the estimate and the fewer revisions at the implementation stage.