Configuring Individual B2B Prices in 1C-Bitrix: Group vs Highload-Block

Imagine: two clients order the same product but see different prices—because each has their own contract. We know this is a standard B2B scenario that Bitrix solves with price types. However, incorrect configuration leads to clients seeing wrong prices or none at all. This article explains how to avoid mistakes and build a flexible system of individual price lists.

Price Type Mechanism in the Catalog Module

In Bitrix, each product can have multiple prices—one per price type (b_catalog_group). A price type is simply a named price level: "Retail", "Wholesale", "VIP", "Contract". For each type, you specify which user groups (b_user_group) can see it.

Configuration in the control panel: Store → Settings → Price Types. Create types for each price level. In "Buyer groups", assign which group sees which type.

Individual Prices: Two Approaches

Approach 1 — Group per Client. Each B2B client gets its own user group and its own price type. The client belongs to that group and sees their prices. Works until you have dozens of clients. With hundreds, management becomes cumbersome: each new client requires creating a group and a price type, plus uploading prices.

Approach 2 — Highload-block for Contract Prices. More scalable (10x better for 50+ clients). Create a Highload-block b2b_contract_prices with fields: UF_COMPANY_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. When requesting a product price, first check for a contract price for the client's company, then fall back to group price, then base price. The logic is implemented via a custom price provider.

How to Set Price Type Priority?

The order in which the system searches for a price for a specific user is set in the price type settings—field "Sort". Lower number = higher priority. An individual contract price should have sort 1, retail base price 100. This ensures the client sees their agreed price, not the general one.

What to Do with a Large Number of Clients?

If you have more than 50 clients, using a Highload-block is the only reasonable path. We recommend it: our experience (10+ years in the market, 500+ catalog configurations) shows that the group approach breaks down under scaling. Contract prices can be loaded manually via the admin interface or through a CommerceML exchange with 1C.

Loading Prices from 1C

When using CommerceML exchange with 1C, prices are synchronized automatically per price type. In the exchange file, the price type is identified by the ТипЦены field—mapped to CATALOG_GROUP_ID in Bitrix. Contract prices not in the standard price list are exported as a separate file and loaded into the Highload-block via the OnSuccessCatalogImport1C event handler.

Work Process

1. Analysis – Review current pricing scheme, client count, and groups.
2. Design – Choose the approach (groups or HL-block), design price type structure.
3. Implementation – Configure price types, create Highload-block, write custom provider.
4. Testing – Verify each client sees their prices, cache works, permissions are correct.
5. Deployment – Move to production server, set up 1C exchange.

What's Included

• Configuration of price types and their priorities
• Creation of Highload-block for contract prices (if needed)
• Writing a custom price provider
• Setting up price import from 1C (including contract handler)
• Testing scenarios: authorized/unauthenticated users, different groups
• Documentation on changing prices and adding new clients

Estimated Timelines

Cost is calculated individually. Contact us to evaluate your project and propose the optimal solution. Place an order to get a transparent individual pricing system without errors.

What to Check After Setup

• Authorized user in "Wholesale" group does not see "Retail" price and vice versa
• Unauthenticated user does not see B2B prices at all (if the catalog is closed)
• Price cache invalidates on change—via tagged cache or CCatalogProduct::clearCacheProductPrice()

Setting up price types and groups for a standard scheme (up to 5 price types, no contract Highload): 3-5 days. Developing a contract price provider with Highload-block: 1-2 weeks.

Comparison of Approaches: Which to Choose?

If you have up to 20 clients and prices change rarely, use the group approach. If you have more clients or individual prices, the Highload-block provides 10x better scalability and flexibility. Our experience guarantees you won't face issues as your business grows.

B2B Portal Development on 1C-Bitrix

A dealer in Krasnoyarsk enters 50 SKUs, needs an instant invoice with his own price, credit limit, and delivery from the nearest warehouse. A retail catalog won’t cut it. We build such portals on 1C-Bitrix — with personalized price matrices, dealer cabinets, and real-time 1C integration. Over 50 B2B portals launched, 12-month warranty, certified 1C-Bitrix specialists with 10+ years in development. Submit a request for a free audit of your current pricing system — we will analyze your structure and propose a tailored architecture.

How does pricing work in a B2B portal?

Retail has one price. B2B has a matrix: price types in b_catalog_price multiplied by user groups, cumulative discounts, currency conversions, contractual conditions. A mistake here sinks the project.

Price types and user groups. Bitrix sets types via CCatalogGroup. Standard set: retail, small wholesale, wholesale, dealer, distributor. Each counterparty belongs to a user group, the group to a price type. Reality is more complex: one dealer may see wholesale prices for electronics and distributor prices for accessories. That requires custom logic in the OnSaleBasketItemBeforePriceSave handler.

Discounts — progressive by volume (from 100 pieces → minus 5%, from 500 → minus 12%), cumulative over a period, seasonal, category-based. Combined through priorities in b_sale_discount. With 20+ rules, debugging becomes a quest.

Credit limits. The counterparty gets a shipping credit threshold. Current debt syncs from 1C via the register РасчетыСКонтрагентами (Settlements with Counterparties). Exceeding the limit blocks order placement.

Contract prices — the price list is tied to a specific contract: validity period, number, prolongation conditions. Expiration switches prices to base ones automatically. Implemented through order custom fields and the OnSaleComponentOrderProperties handler.

Currency — mandatory for foreign trade. Conversion at the Central Bank rate (CCurrencyRates::ConvertCurrency()) or a fixed contract rate.

Compare CommerceML and REST for price sync: CommerceML is simpler but 4x slower on catalogs over 10,000 items, and it can’t handle credit limits. REST API via 1C HTTP service is 3x faster and fully flexible but requires 1C-side modifications. According to the 1C-Bitrix Developer's Guide, real-time sync of directories and balances is critical for B2B portals.

What does the dealer cabinet include?

• Orders — full history with filtering by statuses, dates, amounts. Repeat previous order in one click — saves hours for regular purchases.
• Finances — balance of mutual settlements, reconciliation statement, payment history. No more waiting three days for accounting — data available instantly, pulled from 1C via REST or CommerceML.
• Documents — invoices, waybills, sales invoices, UPD, certificates. Generated in 1C, PDF pushed to the portal via integration. One-click download.
• Dealer employee management — admin creates accounts with role permissions: purchasing manager places orders, accountant sees only finances, director sees the big picture. Extended standard Bitrix user groups.

Quick order: SKU + quantity = invoice

A B2B client doesn’t browse beautiful cards. They need a form: SKU, quantity, next line.

• Quick order form — auto-suggest of name and price when entering SKU. AJAX search by b_iblock_element.XML_ID or PROPERTY_ARTICLE. 50 items in 3 minutes.
• Import from Excel/CSV — client exports from their system, uploads to the portal. Auto-matching of SKUs, availability check, order generation. Parsing via PHPExcel or PhpSpreadsheet.
• Basket with full information — weight, volume, number of packages, estimated delivery cost before checkout.

Why is 1C integration critical for a B2B portal?

Without up-to-date data from 1C, the portal is useless. Manager changed the price of nails — in 15 minutes a dealer in Krasnoyarsk sees the new price.

We often use a hybrid: CommerceML for catalog, REST for prices, stocks, and documents.

EDI: legally significant paperless exchange

For large B2B projects:

• Providers — Kontur.Diadoc, SBIS, Kaluga Astral. Invoices, certificates, waybills in electronic form with legal force.
• CEP — qualified electronic signature. The counterparty signs right in the cabinet.
• Roaming between operators — without it, half of partners with a different EDI operator are left out.

Multi-branch operation

• Regional warehouses — client sees stock of the nearest warehouse and can choose the shipping one. Product available in Novosibirsk but not in Moscow → portal shows both options with different lead times.
• Automatic manager assignment — dealer from Krasnodar works with Ivan, from Yekaterinburg with Marina. Based on UF_REGION in the counterparty card.
• Local conditions — minimum order amount, delivery terms, lead times — differ by region.

B2B Portal Development Process

B2B portal development includes five stages.

What is included in the work

• Complete project documentation (terms of reference, architecture diagram, integration protocols)
• Server environment setup and deployment (On-Premise or cloud)
• Migration of all user data and configurations
• Portal administrator training (2 online sessions)
• Warranty support for 12 months with response within 4 hours

After launch — technical support and development. A B2B portal is a living system that evolves with the business.

Average time savings for a manager on order processing — up to 20 hours per week, which translates to approximately $15,000 annual savings per dealer. A self-built portal typically takes 6 months to develop, while a Bitrix-based solution is ready in 2 months.

Typical mistakes to avoid at the start

1. Verify price types and user groups before going live.
2. Keep discount rules to a minimum (3–4) — 20+ rules cause debugging nightmares.
3. Test 1C integration on real data during pilot.
4. Grant dealer access only after load testing with 50 concurrent users.

Contact us to discuss your project — we will prepare a preliminary estimate and propose the optimal solution. Get your free audit of pricing mechanics today.