1C-Bitrix Price Types: Retail, Wholesale, Dealer Setup
Imagine: you launch an online store on 1C-Bitrix. You have retail customers, wholesalers, and dealers. Each needs their own price for the same product. Without proper price type configuration, you risk showing everyone the same price or getting logical errors when calculating the cart. We have encountered projects where, due to incorrect user group binding, prices broke with every exchange with 1C. Let's break down how to configure price types competently to avoid such issues.
What problems does price type configuration solve?
Priority confusion. In Bitrix, one user can belong to multiple groups. Which price should be shown? By default, the type with the lowest SORT field value is applied. If SORT is not set, the order is undefined. We recommend explicitly setting SORT for each type: BASE = 10, wholesale = 20, dealer = 30. Otherwise, VIP customers might see the wholesale price instead of a special offer.
Import from 1C. Standard exchange via CommerceML passes prices in the PriceType property. Many developers mistakenly try to set prices through CIBlockElement::SetPropertyValues — this does not work. The only correct way is through CCatalogProduct::SetPrice or D7 API. Official documentation. Also useful to study the CommerceML format on Wikipedia.
Price type caching. If tagged caching is enabled, after changing prices or group bindings, the information block cache must be cleared. Otherwise, users will see old prices. We configure automatic cache clearing via agents when prices are updated from 1C.
How we do it: a case from our practice
Recently, a client came to us — a wholesale supplier of building materials. Catalog of 15,000 products, three price types (retail, small wholesale, large wholesale) linked to groups. The main pain: after hourly exchange with 1C, prices would break — some products would go to zero, others would duplicate. It turned out that 1C had 4 price types, while Bitrix had 3, and the mapping was incomplete. We:
- Created a fourth type "Special Offer" linked to the "VIP" group.
- Configured the OnBeforePriceUpdate event to check for duplicates and prevent zero prices.
- Added an agent to clear tagged cache every 59 minutes (slightly less often than the exchange). Result: prices stable, users see their types, exchange works without failures. The client saved up to 40% of the budget by avoiding downtime and manual price corrections.
Process of working on your project
We don't just create price types in the admin panel. Stages:
- Analytics — study your group structure, types from 1C, currencies. Collect all scenarios.
- Design — determine SORT, bindings, base type. Decide if multi-currency is needed.
- Implementation — create types, write code for import (if non-standard), integrate with 1C via CommerceML or API.
- Testing — check each user group, each type, scenarios with zero prices.
- Deployment — roll out to production, clear cache, monitor for a couple of days.
How does multi-currency work?
For different currencies, separate price types are created (e.g., "Price RUB", "Price USD"). In the type settings, the currency is specified. Then the types are linked to the same groups. In the catalog template, the selection of the required type is implemented depending on the current currency. We refine the logic via the OnGetOptimalPrice event.What is included in the result
After completion, you receive:
- Configured price types with correct user group bindings.
- Integration with 1C (if required) — type mapping, duplicate handlers.
- Documentation on the price scheme and recommendations for changes.
- Training for your administrator on working with price types.
- One month of free support in case of questions.
Comparison: professional setup vs DIY
| Criteria | DIY | Order from us |
|---|---|---|
| Setup time for 2-3 types | 4–8 hours | 2–4 hours |
| Risk of import errors | high (duplicates, zeros) | low (handlers + tests) |
| Multi-currency | difficult, need to dig into API | ready solution in 1 day |
| Stability guarantee | none | 1 month support |
Professional setup is 3 times faster than DIY and avoids typical errors that can lead to losses.
How to avoid errors when importing prices from 1C?
Typical errors and their solutions:
- Deleting the BASE type or creating multiple BASE types — leads to unpredictable catalog behavior. Never delete the base type.
- Setting prices via
CIBlockElement::SetPropertyValues— prices won't save. Use onlyCCatalogProductor D7. - Ignoring caching — users will see old prices. Configure automatic cache clearing.
- Binding a type to only one group — if a user belongs to multiple groups, you won't get the expected price. Bind types to all relevant groups.
| Error | Consequence | Solution |
|---|---|---|
| No SORT for types | Undefined priority | Explicitly set SORT |
| Incomplete mapping from 1C | Some prices not loaded | Create missing types |
| No duplicate handler | Multiple price entries | Use OnBeforePriceUpdate |
Timing and how to order
Basic setup of 2-3 price types with group bindings takes 2 to 4 hours. If complex import or multi-currency is needed, it takes 4 to 16 hours. Cost is calculated individually after analyzing your project. Contact us — we'll evaluate your case for free and propose a solution. Order price type setup today and get a month of support as a gift.
We guarantee correct price operation for all user groups — even with hourly exchange with 1C. Experience with Bitrix: over 7 years, dozens of projects with various price types. We have certificates and a development license.