Developing a Customizable B2B Showroom for Dealers on 1C-Bitrix

Developing a Customizable B2B Showroom for Dealers on 1C-Bitrix

We regularly face the task of building a B2B showroom for dealers on 1C-Bitrix. A dealer is not a retail customer: they need their own price list with personal prices, the ability to place orders on behalf of an end client, see warehouse stock, and export data to their accounting system. The standard Bitrix online store showroom does not cover any of these scenarios without serious customization. Our goal is to build a B2B section that works in parallel with the retail store on the same product infoblock.

Multisite vs. Section: Which to Choose?

Two approaches to separating retail and dealers.

Multisite — a separate site in Bitrix (s2) with its own domain (dealer.myshop.by). The dealer site uses the same catalog infoblock but its own price type and template. Advantage: complete isolation of design, cart settings, and order processing. Disadvantage: duplication of component templates. In 80% of projects, we choose multisite — it provides clean separation of business logic without conditional constructs.

Section on the main site — /dealer/ with a check of the user belonging to the "Dealers" group. Catalog components use the same infoblock but show the dealer price type via the PRICE_CODE parameter. Easier to maintain but harder to isolate order processing logic. Multisite wins over section by 2 times in ease of maintenance when dealing with a large number of dealers.

How to Implement Personal Prices?

Bitrix supports up to 8 price types in the standard license and unlimited in "Business" and above. For a dealer showroom, we create a separate price type (e.g., DEALER_PRICE) linked to the "Dealers" user group.

Personalization per dealer is implemented through additional price types — one for each major dealer — or through catalog discounts tied to the user group. The first option scales up to 20–30 dealers; beyond that, management becomes unwieldy. The second works with any number but lacks the flexibility of "any price for any item."

For individual price lists with thousands of items, we use a custom order property with a price calculated on the fly from the base dealer price and a personal coefficient. The coefficient is stored in a user UF field (UF_DEALER_DISCOUNT), and the price is recalculated in the OnGetOptimalPrice handler. For a distributor with 30 dealers, this approach eliminated manual price updates, reducing management overhead by 60%.

How to Display Warehouse Stock to Dealers?

A retail customer sees "In stock / Out of stock." A dealer needs exact numbers per warehouse.

The catalog.store module stores stock in the b_catalog_store_product table (fields PRODUCT_ID, STORE_ID, AMOUNT). Warehouses are in b_catalog_store. The catalog.store.amount component displays stock, but its standard template is not suitable for B2B — no grouping by region, no filtering by warehouses accessible to a specific dealer.

Solution: a custom template of the component that filters warehouses by a user UF field UF_AVAILABLE_STORES (array of warehouse IDs). A dealer from Minsk sees "Minsk-1" and "Minsk-2" warehouses, while a dealer from Gomel sees "Gomel-central."

How to Place an Order on Behalf of a Client?

The dealer places an order and specifies the end recipient. In the sale module, this is implemented via order properties of type "End Client" — a group of properties (PERSON_TYPE) for the dealer payer type.

We create a payer type "Dealer" with fields: dealer details (auto-filled from profile) + a "End Recipient" block (name, address, phone). In the OnSaleOrderBeforeSaved handler, we check that the dealer cannot place an order using the retail payer type.

How to Set Up Data Export for Dealers?

Dealers request price lists in Excel/CSV for import into their 1C. We implement this via a custom page /dealer/export/ that generates a file based on \Bitrix\Catalog\PriceTable::getList() filtered by the dealer price type. Excel format uses the PhpSpreadsheet library (installed via Composer).

For automatic export, we provide the dealer with an API endpoint authorized by token. The endpoint returns JSON with products, prices, and stock — the dealer fetches it via cron. According to the official CommerceML documentation, this approach ensures compatibility with 1C.

Scope of Work

Timelines

Our experience in 1C-Bitrix development spans over 7 years, with more than 50 B2B projects for dealers. Contact us for a project assessment. Get a consultation on architecture and timelines.