Contract Prices in Bitrix: Where Dealer Discount Logic Breaks
Usually the discrepancy starts because contract prices in Bitrix live separately from the reality of the sales department. The dealer has their own price list in a spreadsheet, the company has dealer price types in the catalog, and they are synchronized manually.
While there are three or four groups, this is tolerable; by the tenth, items appear that are calculated for one dealer at the old price and for another at the new one.
Then wholesale discount logic breaks. The discount is configured from the base price, not the contract price, so a dealer with individual terms gets a percentage not from the right amount.
Cumulative thresholds and rounding add a second layer: when an order is at the edge of a range, the total differs by a few percent, and the manager finds out only after approval.
The most costly are price calculation errors in an order. The price is locked at the moment of checkout, but the price list has time to update, and recalculation gives a different amount.
Hence disputes about the amount, manual recalculations, and refunds, while warehouse and logistics receive an order that has to be reissued.
The cause is not a single setting but the fact that manual dealer price lists and price types are not linked by a single source.
We examine how this is resolved: where to store contract terms, how to build discount priority, and what to lock in an order so the amount does not change retroactively.
What a Managed Pricing System Gives a Dealer Network
In a dealer network, the price depends not on the retail storefront but on the partner level, purchase volume, and contract terms.
If these rules live in a manager's spreadsheet, every order goes through manual reconciliation: finding the right column, checking the contract term, calculating the discount.
At a volume of dozens of items, this causes delays and errors — a line goes out at the wrong price, and the discrepancy surfaces in the invoice or at shipment.
A managed pricing system moves the rules into the platform itself. A counterparty is linked to a price type, and the price type is linked to a recalculation rule: percentage of base, fixed price under contract, tiered scale by volume.
Recalculation happens automatically when an order is created, with discount priority and rounding, while the contract validity period limits the application of terms.
The effect is visible at three points. Order processing speed increases: the manager does not reconcile the price list manually but selects a counterparty and gets correct prices in the cart.
The share of order errors falls — an incorrect price does not get into the document if the rule is set. Updating delivery terms becomes a single edit in the price type instead of sending a new price list to branches.
A unified dealer price list becomes the source of truth: changes apply immediately to all new orders and are recorded in history, so closed deals keep their previous terms.
In 1C-Bitrix this maps to standard price types and cart rules, while non-standard contract logic is added by a separate module.
Ways to Configure Prices in Bitrix: Comparison of Options
Contract prices in 1C-Bitrix are handled by three mechanisms, and they are not interchangeable: standard price types work at the catalog level, cart rules at the order calculation level, and price exchange customization at the level of data from the accounting system.
The choice depends on where the customer's mapping of counterparty to price list resides and how often it changes.
| Option | When it fits | Limitations |
|---|---|---|
| Standard price types | Contract price list for a group of counterparties, product range changes rarely | A price type is needed for each group; changing terms requires manual recalculation or a script |
| Cart rules | Price depends on the order total, quantity, or product category | Price is not stored as an entity: removing the rule reverts to base |
| Price exchange customization | Price list comes from the accounting system separately for each contract | Requires its own export format, product mapping, and desync control |
Limitations should be checked before launch, not at the moment when a manager sees a price that does not belong there in the cart.
The choice of implementation method usually comes down to a combination: the price type stores the contract price list, the cart rule calculates the threshold by order volume, and the exchange fills data from the accounting system. Such a set provides predictable calculation and leaves a rollback point if contract terms change.
Implementation Procedure: From Audit to Handover of Regulations
Implementing contract prices is not a checkbox in settings but a transfer of dealer pricing logic into the catalog structure: price types, counterparty mapping, discount rules, and visibility restrictions. The workflow is arranged so discrepancies surface on test orders, not on dealers' live invoices.
- Pricing audit. We collect current price lists and dealer groups, thresholds and payment deferrals, mark manually set prices and rules that exist only in managers' correspondence.
- Price mapping scheme. We determine which price type corresponds to each dealer group and how the counterparty, contract, and customer profile are linked in the catalog.
- Setting up price types and rules. We create price types and discount rules, limit selection by groups, define recalculation when the price list is updated, and configure catalog cache behavior.
- Exchange with the accounting system. We configure matching of product and counterparty codes, processing of new items, and items dropped from the price list.
- Dealer test orders. We run scenarios for each group: dealer login, cart, checkout, invoice, repeat order, mid-deal terms change.
- Acceptance check. We reconcile final prices and documents against the reference table, check edge cases: multiple contracts, mixed cart, terms rollback.
- Handover of settings to the customer. We provide regulations on price types and groups, manager instructions, access credentials, and a change map with rollback points.
Each stage ends with an artifact — a scheme, mapping table, or reconciliation report — and without it the next one does not begin. This way, support is handed over within the customer's team without reconstructing the logic from memory.
What the Customer Retains: Configurations, Regulations, Documentation
Project delivery is not only working functionality but also a set of artifacts by which your team can develop contract prices without us. We hand everything over on your infrastructure and under your version control.
- Price type configuration: which types are created, which user groups they are linked to, which type the discount is calculated from, and how rounding behaves.
- Product mapping scheme: by which attributes — SKU, code, external identifier — a dealer item is linked to the catalog and what happens to non-matching rows.
- Price list access rights: role matrix — who sees the contract price type, who can edit it, who is allowed to export.
- Dealer onboarding regulation: step-by-step procedure from application to personal price list, with owners and checkpoints at each step.
- Pricing documentation: type priorities when several compete for one item, and behavior when there is no contract match.
- Change log and rollback: where edit history is stored, how to restore the previous price list state, and how to distinguish a manual adjustment from a calculated one.
- Diagnostics guide: typical reasons a dealer sees the base price, and which records to check first.
The handover is completed by an acceptance checklist: scenarios we run together with your specialist — from dealer creation to price recalculation after a price list change.
The items are signed off, so when onboarding a new dealer or changing the responsible person, nothing has to be reconstructed from memory.
Case Study: Moving from Manual Discounts to Managed Dealer Terms
The dealer network ran on manually approved prices: a manager opened a request, reconciled contract terms with a spreadsheet in email, and only then issued an invoice with the required price type. While there were ten shipments a day, the scheme held up.
At a volume of a hundred orders, every fifth invoice went for recalculation, and some dealers received their category prices with a delay of a day or two.
What Pre-Implementation Measurements Showed
Over a month, we collected statistics for the sales department: 8% of orders were returned for price correction, average processing time was 40 minutes, and more than half of it went to approving terms.
Manual edits to the price list reached up to 120 per week, and discrepancies between the invoice price and the accounting system price were found only at the shipment stage — from the dealer's side, this looked like the supplier's unreliability.
What We Changed and What Resulted
In 1C-Bitrix, contract prices were configured: the price type is strictly linked to the counterparty's contract, the dealer's price group is determined by rules, the maximum discount is limited by a threshold for each category, and any change is recorded in the log with author and time.
The exchange with the accounting system pulls approved values automatically, so the manager no longer calculates the price manually.
Two months after launch, the share of erroneous orders fell from 8% to 1.2%, processing time decreased from 40 to 12 minutes, and the volume of manual edits dropped almost sixfold.
The sales department shifted from resolving discrepancies to working with the network: dealers could now be onboarded under a standard contract without expanding the approvals staff.
What to Do If the Catalog Is Already Synchronized with the Accounting System
The catalog does not need to be rebuilt: the exchange with the accounting system remains the same node, and contract prices are added on top of the existing price type as a separate layer.
Items, stock, and properties are untouched — only the part of the export responsible for pricing is extended.
The path is chosen based on two criteria: how often delivery terms change and how fully they are described in the accounting system.
If dealer agreements are maintained there as well, it is cheaper to extend the current exchange; if prices are calculated outside it, they are supplied by a separate handler and distributed by customer groups on the 1C-Bitrix side.
| Option | When it fits | Limitations |
|---|---|---|
| Extending the current exchange | Delivery terms are maintained in the accounting system, few rules | Editing exchange rules, a test environment is required |
| Separate contract price handler | Prices are calculated outside accounting, linked to a contract or manager | Its own reconciliation with the base price and logging |
| Hybrid: base price list in the exchange plus an add-on | Base price is needed by everyone, contract price by some dealers | Two price sources, an explicit priority is required |
Step-by-step extension looks like this: price types and agreements are created in the accounting system, added to the export in the exchange rules, and mapped to customer groups on the website.
Next comes a run on the test environment and enablement group by group; the production exchange is not stopped.
This procedure minimizes rework: the existing exchange continues to work, while the add-on is disabled with a single setting and you return to a unified price list. New delivery terms are added by extending the rules, without rebuilding the catalog.
Technical Concerns Before Launch: Frequently Asked Questions
The basic exchange of catalog, stock, and orders remains untouched: contract prices are a separate price type that is transmitted additionally and does not overwrite retail.
Therefore synchronization continues to work on the standard schedule, and a failure in dealer pricing rules does not stop product export. We examine what most often raises questions before launch.
Will the exchange with 1C have to be completely redone?
No. The dealer price type is added to the existing exchange as a separate node: the field set is extended, the export order and product mapping are preserved. The edits are localized in the rules and do not affect the logic of stock and orders.
How are rounding and tax handled in the price?
Rounding and tax are calculated on the accounting system side — the website receives an already final price. Otherwise, the storefront and the invoice will differ slightly, and this will surface in reconciliation. We define rounding rules once and transfer them to the exchange.
Can a price be shown only to a specific dealer?
Yes. The dealer price type is linked to a user group or to a counterparty, and the storefront serves it only after authorization. For other visitors, the retail price remains, and page cache does not mix variants.
Will dealer-specific customization break updates?
No, if we extend standard mechanisms rather than modify the core: custom logic lives in a module and survives platform updates. Before deployment, we run the exchange on a database copy — discrepancies are visible before production.
What will happen to old orders?
Nothing: the price is locked in the order at checkout and is not recalculated retroactively. The new price type affects only orders created after the rules are enabled — history and documents remain correct.
Let's Discuss the Task: Where to Start and What to Prepare
To keep the conversation about architecture rather than a retelling of the current process, it helps to bring a few inputs. From them, we immediately see where the contract price is calculated in 1C and where it should be substituted on the website side.
- product export and the list of price types — which levels are already set up in 1C and which are simulated manually;
- dealer list and group membership attribute: contract, segment, region, or a separate field in the counterparty card;
- calculation rules: entry threshold, shipment multiple, volume range, delivery terms — everything that affects the final price;
- behavior when a dealer's status changes within a period: from which date the new level applies and what to do with already issued documents;
- examples of real documents — invoice, shipment, specification — to see where the contract price must be substituted automatically;
- access to the test stand and database copy: we check the exchange on your data, not on demo data;
- limitations: what cannot be changed in the current configuration, who approves the rules, and what timeframe is allotted for rollback.
Based on this data, we will return with an estimate and work plan: sequence of stages, acceptance points, price exchange scheme, and switchover procedure.
If some inputs are not yet defined, we will discuss them during the conversation, record assumptions, and include them as separate plan items so they do not become a surprise at acceptance.
