Dealer Portal on 1C-Bitrix: Roles, Prices, 1C Integration

If you have 80 dealers, managers spend half a day distributing price lists. That's a bottleneck we eliminate. A portal addresses three tasks: independent dealer order placement, individual terms for each partner, and automatic 1C synchronization without human intervention. We can estimate your project in one day—contact us for a free consultation.

The key difference between a dealer portal and a regular B2B is the hierarchy: manufacturer → dealer → sub-dealer. One dealer may have multiple outlets and employees with different permissions. The standard Bitrix user group model (b_user_group) is insufficient—it doesn't store the "user belongs to company" relationship.

We implement this using D7 ORM: we create the DealerCompany entity (table b_dealer_company) with fields for 1C identifier, status, dealer type, and region. The user-company link is via the b_dealer_company_user table with a role field. Roles: owner, manager, accountant—each with different rights to create orders, view documents, and manage employees. Authorization through bitrix:system.auth.form is supplemented with a custom handler. On user login, we determine their company and dealer type, caching in the session. All subsequent requests for prices and catalog take dealer_type into account.

How to configure pricing for different dealer types?

Dealer pricing is the most complex part. A typical scheme:

• Base price list (public or private)
• Dealer discount by type (silver, gold, platinum)—percentage off base price
• Individual contract items—specific SKUs at fixed prices
• Promotional conditions with validity dates

The standard CATALOG_GROUP_ID mechanism in b_catalog_price covers the first two levels. For contract items, a Highload block dealer_contract_prices is needed with structure: UF_DEALER_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. When querying a price, we first check contract items, then dealer type, then base price.

Price priority logic is implemented via the OnBeforeSaleOrderDoFinalAction event or a custom price provider implementing Bitrix\Catalog\v2\Price\BasePriceProvider. The second option is cleaner—it won't break on sale module updates. According to Bitrix documentation, BasePriceProvider ensures compatibility with future updates. A custom Bitrix solution offers better pricing flexibility than a ready-made CRM module.

Catalog and stock

Dealers often work with a limited assortment—not the entire manufacturer's catalog is available to every partner. Assortment restriction is implemented via:

• Filtering by infoblock property: add a property AVAILABLE_FOR_DEALER_TYPES (list type), specify dealer types. In the bitrix:catalog.section component, add filter PROPERTY_AVAILABLE_FOR_DEALER_TYPES = current dealer type.
• Highload block assortment: for flexible settings—table dealer_assortment (UF_DEALER_ID, UF_IBLOCK_SECTION_ID). The dealer only sees catalog sections listed in their records.

Stock information comes from the standard catalog module, table b_catalog_store_product. For a dealer portal, it's important to show stock at specific warehouses available to the dealer (e.g., warehouse in their region). The dealer-warehouse link is stored in a Highload block; in the component, the query to b_catalog_store_product is overridden.

Document workflow and finances

Dealers constantly request documents—invoices, waybills, reconciliation statements. Storing them in Bitrix is redundant if they already exist in 1C. The workflow:

1. The portal requests a list of dealer documents via the 1C REST service (or uploads to an intermediate table)
2. Documents are cached in a Highload block dealer_documents: UF_DEALER_ID, UF_DOC_TYPE, UF_DOC_NUMBER, UF_DATE, UF_AMOUNT, UF_FILE_URL
3. Synchronization via cron every 2 hours using a main module agent (CAgent::AddAgent)
4. PDF files are fetched on demand, cached in /upload/dealer/docs/ for 24 hours

Debt and credit limit—similarly: Highload block dealer_credit (UF_DEALER_ID, UF_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE). If the limit is exceeded or there is overdue debt, order placement is blocked via the OnBeforeSaleOrderAdd event handler.

What happens if a dealer exceeds the credit limit?

Each time an order is created, the OnBeforeSaleOrderAdd handler fires: it checks the current debt from dealer_credit. If the limit is exceeded or there is overdue debt, the order is blocked, and the dealer receives a notification. This eliminates payment risks and automates control.

Notifications and communication

A portal without notifications is half the work. We configure:

• Email events (CEventType, CEvent::Send): order status change, approaching payment deadline, new price list
• Push notifications via the pull module (if a mobile app is present)
• Activity feed in the dealer's cabinet—Highload block dealer_events with read/unread markers

Integration with CRM

If the manufacturer uses Bitrix24, the dealer portal syncs with CRM:

• New dealer registration → creates a company in CRM (crm.company.add)
• Dealer order → deal in CRM linked to the company
• Deal status change → order status change on the portal via webhook

The connection is implemented via the Bitrix24 REST API, storing CRM entity IDs in custom company fields.

What's included in the work

• Analysis and design: prototype, technical specification
• Development of role system and authorization
• Pricing at all levels (discounts, contract prices, promotions)
• Dealer personal account with order history and documents
• Integration with 1C via CommerceML or REST
• Testing and deployment to production server
• Employee training and access handover
• 6-month warranty support

Timelines

Total: 14–24 weeks. The variance is determined by the depth of 1C integration and the number of custom business rules in pricing. We can estimate your project in one day—contact us for a consultation.

Order dealer portal development and get a free audit of your current processes. This will help accurately estimate the timeline and scope of work.