Development of customizable dealer storefront in 1C-Bitrix
Dealer doesn't work as retail buyer. Needs own price list with personal prices, ability to order on behalf of end customer, see stock by warehouses and export data to their accounting system. Standard Bitrix e-shop storefront covers none of these scenarios without serious rework. Task — build B2B section running parallel to retail shop on same product infoblock.
Architecture: multi-site or section
Two approaches to separate retail and dealers:
Multi-site — separate site in Bitrix (s2) with own domain (dealer.myshop.by). Dealer site uses same catalog infoblock but own price type and template. Advantage: full design, cart settings, and checkout isolation. Disadvantage: template duplication.
Section on main site — /dealer/ with user group "Dealers" membership check. Catalog components use same infoblock but show dealer price type via PRICE_CODE parameter. Easier to maintain but harder to isolate checkout logic.
For most projects multi-site is the right choice. It provides clean business logic separation without conditionals in templates.
Personal prices and price types
Bitrix supports up to 8 price types in standard license and unlimited in "Business" and above. Dealer storefront gets separate price type (e.g., DEALER_PRICE) bound to "Dealers" user group.
Personalization by dealer implemented via additional price types — one per major dealer — or via catalog discounts bound to user group. First variant scales to 20–30 dealers, then management becomes unmanageable. Second works for any quantity but lacks "any price for any product" flexibility.
For individual price lists with thousands of items use custom order property with price calculated on-the-fly from base dealer price and personal coefficient. Coefficient stored in user UF-field (UF_DEALER_DISCOUNT), price recalculated in OnGetOptimalPrice handler.
Stock by warehouses
Retail customer sees "In stock / Out of stock". Dealer needs exact warehouse numbers.
Module catalog.store stores stock in b_catalog_store_product table (fields PRODUCT_ID, STORE_ID, AMOUNT). Warehouses in b_catalog_store. Component catalog.store.amount outputs stock but its standard template doesn't fit B2B — no regional grouping, no filtering by dealer-available warehouses.
Solution: custom component template filtering warehouses by user UF-field UF_AVAILABLE_STORES (warehouse ID array). Minsk dealer sees "Minsk-1" and "Minsk-2", Gomel dealer sees "Gomel-central".
Order on behalf of customer
Dealer places order and specifies end recipient. In sale module implemented via order properties type "End Customer" — property group (PERSON_TYPE) for dealer payer type.
Create "Dealer" payer type with fields: dealer requisites (auto-filled from profile) + "End Recipient" block (name, address, phone). In OnSaleOrderBeforeSaved handler check that dealer can't order as retail payer type.
Data export
Dealers request price list in Excel/CSV for loading into their 1С. Implemented via custom page /dealer/export/ generating file from \Bitrix\Catalog\PriceTable::getList() filtered by dealer price type. Excel format via PhpSpreadsheet library (installed via Composer).
For automatic export give dealer API endpoint with token authorization. Endpoint returns JSON with products, prices, stock — dealer fetches it via cron.
Timeline
| Component | Duration |
|---|---|
| Multi-site + base catalog with dealer prices | 3–4 days |
| Personal coefficients + stock by warehouses | 3–4 days |
| Order on behalf + export | 2–3 days |
| Testing and permission debugging | 1–2 days |
| Total | 1–2 weeks |