Why a dealer showcase on Bitrix breaks as it grows
A dealer showcase on 1C-Bitrix doesn't break from load — it diverges from accounting data. While there are hundreds of items and one dealer, prices and stock are edited manually right in the cards, and everything matches.
But at the first thousands of items and dozens of dealer levels, the catalog and accounting system begin to live separate lives.
The root is manual catalog edits: a manager changes a price in the showcase but not in accounting, and the next exchange returns the old value.
Stock is pulled separately by warehouses and trade offers, and some items are created again — under a different SKU or with a typo in the name.
With each upload, discrepancies grow: part of the catalog is updated, part remains in the old state, and the showcase shows the dealer the wrong price — not the one they will be invoiced at.
A separate area is dealer access errors. Permissions are issued by user groups, and when working conditions, region, or the dealer themselves change, they are not rebuilt: someone sees someone else's price level, someone sees an empty showcase.
The more levels and rules, the higher the chance that access remains from a previous configuration, and it will only be noticed at order time.
Next, we break down how this is closed: how to separate accounting and display so prices and stock don't diverge, and how to keep permissions in order as the number of dealers grows.
What a managed catalog with dealer prices provides
Dealer prices in the catalog are not a card field but the result of a rule. The price type is tied to the counterparty group, region, and purchase volume; the discount is calculated when the page is served; and rounding is set separately for each group.
A manager edits one rule — prices are recalculated for the entire dealer group, and product cards are not overwritten.
Automatic stock updates come from the accounting system through an exchange queue with idempotent keys: re-delivery of a package does not double the quantity or zero out an item on a mid-way failure.
Publication is triggered by a change event rather than a full nightly upload, so a sold item leaves available stock almost immediately.
This removes three classes of failures that usually keep support busy: selling with negative stock, a "stuck" old price after changing conditions for a group, and a mismatch between the site and accounting after a manual edit in the admin panel.
Previously each was treated by manual reconciliation; now — by input validation, an exchange log, and re-delivery of failed packages.
The reduction in manual operations is visible in the composition of the work: rules, exceptions, and handling of disputed items remain, while typical recalculations and reconciliations run on schedule.
Catalog update speed is measured in minutes per package instead of a nightly cycle, and every package leaves a trace — what arrived, what was applied, what was discarded and why.
Such a catalog on 1C-Bitrix is delivered together with a description of pricing rules and an exchange regulation: support sees the logic in documents rather than reconstructing it from code.
Ways to organize a dealer catalog: comparison
There are not many ways to organize a dealer catalog, and almost all of them rely on standard 1C-Bitrix tools: user groups, price types, information blocks, and exchange settings with the accounting loop.
The difference shows at scale — five dealers with a shared matrix and two hundred with partially overlapping assortment and personal terms require different architectures. Below are four schemes that are actually chosen between.
| Option | When it fits | Limitations |
|---|---|---|
| Standard user groups and price types | Dealers sell the same matrix; only prices and discounts differ | Access control works at the level of prices and product visibility; different catalog structures and separate terms cannot be set this way |
| Multi-site on a shared core | Each dealer needs their own address and design with a shared catalog | Settings and templates are maintained separately for each site; with dozens of dealers, maintenance becomes more expensive |
| Separate information blocks for dealer matrices | The assortment differs greatly or overlaps partially | Duplication of cards, divergence of stock and prices, more complex unified search and filtering |
| Separate exchange loop and external presentation layer | Need isolation of dealer data, custom ordering scenarios, and personal terms | Requires designing an exchange scheme, nomenclature matching rules, and support for both loops |
The choice is determined by three questions: how many dealers, how much the matrices differ, and where the source of truth for prices and stock is. In practice, schemes are combined — standard groups cover typical terms, and a separate exchange loop takes on large partners.
We start with an analysis of the current catalog and exchange rules, then assemble a prototype and a transition plan without stopping sales.
Stages of implementing a dealer catalog: work step by step
The stages are arranged so that the dealer showcase on 1C-Bitrix relies on accounting system data rather than manual uploads that diverge from reality by the second day.
First we understand the catalog structure, then design the exchange, set up rules, and only then show the result to dealers.
- Catalog and integration audit. Structure of product groups, properties and trade offers, existing exchanges, discrepancies between accounting and the site for nomenclature and stock.
- Designing the data exchange scheme. Composition of entities, frequency and direction of exchange, rules for matching items, and priority in conflict: update from accounting or edit on the dealer side.
- Setting up pricing rules. Price types, binding to contract and dealer group, rounding, discount thresholds, and priority order — the price in the card matches the invoice.
- Access control. Roles and visibility scopes by region and warehouse: the dealer sees only their own items, prices, and documents.
- Testing on real data. Full exchange on a production nomenclature array, reconciliation of samples, and bringing discrepancies to zero before launch.
- Handover and training. Exchange regulations, instructions for managers and dealers, error monitoring, and a desynchronization log for the first weeks.
Documentation, schemes, and regulations after implementation
Showcase support should not depend on whether a particular engineer remembers why the nomenclature matching rule is configured exactly this way.
Therefore, along with the working loop, you receive a set of artifacts that let you develop the showcase, hand it over to another team, and avoid rebuilding the logic from scratch.
- Exchange map — which entities go in which direction between the accounting system, catalog, and showcase, and where items, prices, and stock are matched.
- Integration schemes with failure points — what happens when the source is unavailable, how version discrepancies are handled, and where to look first.
- Matching rules configuration — exported to a file and stored in a repository, not in the settings of a single administrator.
- Access roles and permissions — a role matrix: manager, dealer, catalog editor, administrator — who sees and changes what.
- Catalog update regulation — launch frequency, exchange window, post-load verification procedure, and actions on failure.
- Instructions for administrators — step-by-step scenarios for typical operations: connect a dealer, restrict a section for them, roll back an erroneous price list.
- Change log and rollback point — what and when changed in rules and permissions, and to what state we roll back.
The documentation is tested on a live scenario: your administrator goes through the instructions themselves, and we correct everything that turned out to be non-obvious. After that, support can be handled in-house or given to us — the regulations work equally well in both cases.
Case study: moving a dealer catalog to managed rules
The client's dealer catalog relied on manual bindings: a manager uploaded a price list, reconciled stock by warehouses, and set discounts for each dealer group.
With four price levels, changing a supplier price turned into a two-day operation, and a mismatch between the showcase and accounting surfaced only after a dealer called.
The showcase ran on 1C-Bitrix, but pricing rules were hardcoded in component templates — editing required a developer.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Display of price and availability in the showcase | 2-3 days of manual edits | 10-15 minutes after exchange |
| Items updated manually | about 100% | less than 5%, only exceptions |
| Recurring exchange failures | 3-4 per month | 0-1, with retry of the failed row |
| Stock reconciliation by branches | one working day monthly | 20 minutes per regulation |
What was changed and how long it took
Pricing and availability rules were moved into managed rules: price list priority, discount group, stock threshold, and minimum batch were described with data rather than code.
The exchange was made regulated, with a run log and retry only of failed rows — a failure on one item no longer stops the entire upload, and the manager reviews an exception report instead of manually reconciling price lists.
The pilot on one product group took three weeks, and the full catalog migration took nine weeks, including transferring accumulated discounts and training managers.
For the first two weeks after launch, exchange support was provided: discrepancies were handled on the warehouse side, not the showcase side.
How a dealer showcase differs from a regular online store
A regular online store is built around one catalog and one price for all visitors.
A dealer showcase works differently: price here is not a product property but a calculated value — the server determines it by the combination "client → group → price type" at the moment of the page request. Therefore, the product card is the same, but each buyer has their own deal terms.
The second difference is visibility management. In a dealer catalog, some items are closed to retail, some are available only to selected groups, and stock and delivery times are shown by the warehouse assigned to a specific dealer.
Visibility rules are set at the level of sections and trade offers, and the dealer physically cannot open what they are not allowed to sell.
Personal terms also set a different ordering logic. A wholesale client has a minimum batch, pack multiple, deferred payment, pickup, and ordering according to a pre-agreed price list.
Such restrictions do not fit into standard order placement, so they are moved into separate scenarios and checked at the cart formation stage, not after it is submitted.
Price differentiation is solved separately. Purchase and retail prices are stored as different types, and access to them is distributed through user groups and catalog-level permissions — in 1C-Bitrix this is done with standard tools, without modifying the core.
An error in linking a client to a group leads to showing a closed price list, so the rules are fixed in configuration and rechecked with every change in assortment or contract terms.
Common technical questions and doubts before starting
Doubts before starting are usually the same: what will happen to the current catalog, how the showcase gets stock and prices, whether dealers will have to be created anew, and how to make sure pricing rules work before launch. Briefly on each point.
We transfer the catalog in packages: products, characteristics, trade offers, and links between them, with reconciliation of item counts and prices on a sample.
Then the showcase lives not on a one-time upload but on regular exchange with the accounting system — so discrepancies between warehouse and site do not accumulate.
The catalog already exists in another system — is migration without stopping sales possible?
Yes. We load in groups: first nomenclature and characteristics, then trade offers and access logic. We eliminate discrepancies in items and prices before opening the showcase to dealers.
How is exchange with the accounting system organized?
In portions on a schedule: nomenclature, stock, prices, order statuses. Each pass writes a change log, so an exchange failure does not turn into a silent stock discrepancy.
We change terms for a dealer — do we need to redo the catalog?
No. Dealer terms are a set of access and pricing rules, not a copy of the catalog. We change the group, discount matrix, or section visibility — the showcase picks up the new settings on the next request.
How to check pricing rules before launch?
We run on a test loop: assemble the entire cart for each dealer group, check discount priorities, rounding, and cases with zero stock. This checklist becomes acceptance and is repeated with every price update.
Let's discuss the task and come back with a work plan
To come back with an estimate and work plan rather than general considerations, we need a brief description of the task and access to a test bench.
From it, we break down the scope of work into blocks — catalog, access control, exchange with the accounting system, order placement — and lay them out by stages. The more precise the input, the fewer assumptions in the estimate.
What is useful to prepare before the conversation:
- A scheme of roles and access rules: what the head office sees, what each dealer sees.
- Rules for forming assortment and prices: by contract, region, brand, or manually.
- An example upload from the accounting system: field composition, frequency, person responsible for exchange.
- A sample showcase or the current template to be reached.
- A list of external services: payment, delivery, warehouse, dealer portal.
- Time constraints and the date by which the showcase must accept orders.
- A contact person on the business side who confirms the requirements.
Then we work: clarify disputed points, check the integration with 1C-Bitrix on test data, fix the scope of work, and come back with an estimate, timelines, and stages — broken down by what result you get at each.
Describe the task in a convenient form: we will send a plan and indicate what will be required from your side at each stage.