Contract prices for dealers in 1C-Bitrix: setup and integration

Contract prices in Bitrix: where the discount logic breaks

Contract prices in Bitrix rest not on a single entity, but on a combination of three: the price type in the catalog, the customer group, and the link of the counterparty to that group.

A failure occurs not in the middle of the scheme, but at its boundaries — when a user logs in, during exchange with the accounting system, and in the catalog cache.

Let's break down exactly where the price calculation for a counterparty loses the contract and gives the dealer retail pricing.

The first gap is the customer group. The dealer logs in, but the group is attached to an employee rather than to the company, or it is not recalculated when the counterparty changes in the session.

The card displays the base price type because the filter by group did not work; outwardly this looks like “the discount was lost,” although the logic simply did not reach the required branch.

The second is that individual prices for dealers are stored as a separate price type and updated by exchange, while discounts by customer group are calculated on top of the base price.

If the price list arrives later than the discount calculation or vice versa, the discount is calculated from the old price list: the price goes below the purchase price or begins to “float” within a few percent from one upload to the next.

The third is manual edits. A price adjusted by a manager in the card lives until the first synchronization: without an explicit priority rule between the manual value and exchange data, the next export overwrites the field silently, with no errors in the log.

Separately, the cache: if it is not separated by customer groups, the dealer after logging in sees retail until the page is refreshed.

All these failures are fixed at the level of configuring price types, priorities, and the recalculation moment — we break down how to build a scheme in which the contract always wins over retail.

What changes after setup: orders, price lists, requests

Automatic price calculation in an order is the first thing managers notice after integrating contract terms into 1C-Bitrix. Then the effect spreads across three directions: price list preparation, order placement, and support load. Below is what exactly should be checked in the first month after launch.

Orders and price lists

• The price in the order is filled in from the dealer's contract automatically: the manager does not check a table or edit the line manually.
• A single price list for dealers lives in one place — when terms change, there is no need to send out new files and figure out which copy is current.
• Order placement time is reduced so much that more requests are processed per shift without loss of quality.
• Fewer pricing errors: the invoice, order, and shipment match in amount, and manual correction remains only for a separately agreed exception.

Support requests

• A whole class of requests disappears — “calculate using our price list” and “why is the price different” — the system itself closes them.
• It is visible under which contract and for what date the price was applied: resolving a disputed invoice does not require digging up correspondence.
• Changing terms for a dealer is one operation in the reference book instead of a package of edits across the catalog and open orders.

Checking the result is simple: compare the share of orders with manual price correction before implementation and a month after.

Methods for distributing individual price lists: comparison of approaches

Each approach relies on its own core mechanism: user groups, the counterparty card, scheduled exchange, or separate portal roles.

The choice is determined by three things — how many dealers you have, who forms the price list, and whether the dealer needs to work with orders independently.

In practice, the options are combined: prices come from the accounting system, group assignment sets the base level, and individual terms are placed on the counterparty card.

It is important to set the application priority — otherwise the base price surfaces in the cart instead of the contractual one, and this is the first thing the dealer will see.

Implementation stages: from audit of rules to handover of regulations

Contract prices in Bitrix are not a separate module, but a combination of price types and priority rules by which the cart selects a price for a specific customer group.

That is why we proceed sequentially: from describing the current rules to the scheme, data, and checks on real orders.

1. Audit of pricing rules. We export price lists, contract matrices, and discounts, mark where the price is set manually and where it is calculated by a formula, and record discrepancies between the contract and what the catalog returns.

2. Price type scheme. We design the base, contract, and service types, set the priority order and the behavior when an item has no price: whether the base one is inserted or the product is hidden.

3. Setting up roles and access rights. We delineate managers, dealers, and the administrator: who sees only their own price type, who edits, who reads. We check that other parties' prices do not leak out through the catalog, search, and exports.

4. Exchange and data transfer. We determine which prices come from the accounting system and which live on the site, how a conflict during desync is resolved, and by which key items are matched.

5. Checking order scenarios. We run edge cases: a product without a contract price, changing the customer group in the cart, a mixed order, minimum batch, checkout with partial stock.

6. Handover of documentation. The policy for maintaining price types, instructions for managers, the rights scheme and a verification checklist after catalog updates, training of responsible staff, and the support period.

Access policies and price lists in Bitrix for dealers

The dealer price list in 1C-Bitrix rests not on a single field, but on a combination: price type, counterparty, user group, and visibility rule.

Such a combination does not document itself — when work is handed over, it leaves together with the contractor, and the next assortment edit turns into parsing the logic from logs.

That is why we hand over the setup as a set of artifacts that can be checked and passed to a new engineer.

• Price types and counterparty links — which price bases are created, how the counterparty is matched with the account, and what happens when the details differ.
• User groups and rights — the role matrix: what is available to a wholesale dealer, what to a retail manager, and where the purchase column is closed.
• Price list access policies — visibility rules by catalog sections, filters by brands and warehouses, and cart behavior when the group changes.
• Personal price lists — the conditions by which an individual selection is built, and the method for exporting it in the format the dealer is used to.
• Price update policy — what is transferred from the accounting system, at what frequency, and which report confirms that the price reached all groups.
• Instructions for managers — step-by-step guides: create a counterparty, change the group, check the price list after loading.
• Change log and rollback point — who and when edited the visibility rule, and how to return to the previous version of the setting.

Case: how the catalog stopped showing retail terms to dealers

At the start, the dealer catalog was assembled from the same data as the retail storefront. A manager manually selected items, inserted the contractual price, and sent a file — a large request took up to two business days.

Some orders still went out with retail terms, and the discrepancy surfaced already when the invoice was issued.

Metrics before and after

We measured together with the client on the same set of dealers — before implementation and three months after.

“Price lists stopped being a separate job for the manager,” — head of the client's sales department.

What was changed: in 1C, separate price types were created for each contract and linked to user groups on the 1C-Bitrix side.

The catalog and cart calculate the price by group, the page cache is separated by groups — storefront speed did not drop, and inserting other parties' terms became impossible.

The transition was phased: first one product group, reconciliation with accounting, then the rest. When supplier terms change, one price type is edited, not the entire catalog — rollback is also reduced to switching a group.

How does a separate price list differ from a discount for a counterparty?

The difference shows up at the moment of calculation. A discount is a coefficient on top of the base that already exists in the catalog: the price is taken from the general price list, multiplied by the customer group percentage, and the order shows a derived value.

A separate price list changes the base itself: the item is linked directly to the counterparty, and the order is calculated from it, not from the catalog price with a coefficient.

For the client, this means that in the first case individual terms always depend on how current the general price is, while in the second they live independently.

Next, the exchange requirements diverge. A discount for a customer group is configured once as a rule and arrives correctly with the exchange if the counterparty is in the right group and it is synchronized.

A separate price list requires its own price type and a full export across all items: if a line did not make it into the exchange package, the order will insert the base price or fail.

This is more reliable from the standpoint of independence, but it adds volume to the exchange and a mandatory check of export completeness.

Partial shipments amplify the difference. When a line is split between warehouses or batches, the price is recalculated for each part, and rounding accumulates across lines.

The discount is applied to each fragment separately, so the total may differ from the arithmetic for the whole item — the discrepancy surfaces already in the invoice. A separate price list stores a once-calculated amount, and partial shipment does not recalculate it.

There is also a third layer — caching. The customer group rule is pulled dynamically, and it can be changed without re-exporting the catalog, but at large volumes this puts load on the calculation on every request.

A separate price type goes into the cache as static content and is served quickly, but any change requires a repeated exchange.

The practical choice is this: a discount is appropriate when terms are described by a matrix and a single catalog must remain the source of truth.

A separate price list is used when the price cannot be derived by a coefficient from the general one — its own items, its own recalculation, fixed contractual terms.

On a project this is not a one-time switch, so we first calculate how exchange, rounding, and partial shipments will behave in your configuration, and only then choose the scheme.

Complex cases: cache, exchange with the accounting system, access rights

Personal terms break the usual caching scheme: the catalog page is one, but the price in it depends on who opened it.

While the catalog has one retail price list, everything works normally; when a counterparty with its own grid appears, one has to separate static output and user-bound data.

Below are four situations that most often surface during the implementation of contract prices and after launch.

Can several price lists be maintained for one counterparty?

Yes — by warehouse, direction, or delivery period. Each agreement has its own priority and validity period, so when terms overlap the system selects the price list by rule, not by load order. Previous grids are archived, but remain visible in order history.

Exchange overwrites manual edits — how do we separate this?

We divide areas of responsibility: prices and stock come from the accounting system, while fields that the exchange does not touch are edited manually.

We fix the list of exported fields in advance and keep a discrepancy log — if a value on the site differs from the accounting one, it is visible in the report rather than being clarified in correspondence.

Will the cache show someone else's price?

This is the main risk: a page with a personal price must not be cached in full. The static part of the catalog is served from the cache, and the price block is assembled for the current session.

We check on accounts from different groups — after cache reset and under load, each customer sees only their own grid.

Let's discuss your dealer terms scheme and come back with a plan

So that the estimate for setting up contract prices in Bitrix is based on your scheme rather than averaged assumptions, it is enough to gather a few things for the conversation. Below is the minimum after which we return with a work plan for price setup, stages, and checkpoints.

• Access to the catalog and accounting system. A test environment of the site and a separate user in the accounting system with read-only rights to items and price types — a working administrator is not needed for the estimate.
• Examples of price lists. Two or three real export files with SKUs, supplier columns, and price levels: they show how items are matched and where positions diverge.
• Roles and customer groups. Who receives contract terms — dealer, distributor, partner; the price is linked to a group or to a specific contract.
• Priority and calculation rules. Which price wins in a conflict (individual, group, base), how rounding works, and what to show if there is no price for the group.
• Exchange point. What is considered the source of truth — the site catalog or the accounting system, in which direction and at what frequency the export goes, and how discontinued items are handled.
• Special cases. Regional markups, VAT included in the price or added on top, several warehouses, restrictions by quantity and the dealer's purchase history.

With this input data, we check the scheme on the test environment and come back with an estimate: what is configured with standard tools, what requires exchange improvements, and where it is enough to change the calculation rules.