Developing a dealer portal using 1C-Bitrix

1C-Bitrix Dealer Portal Development

A dealer network of 80 companies and a manager who manually sends price lists via email every Monday—that's not a process, it's a bottleneck. A dealer portal on Bitrix solves three things at once: dealer self-service ordering, individual conditions for each partner, and automatic 1C synchronization without manager involvement.

Access Architecture: Dealer as Entity

The main difference between a dealer portal and a regular B2B—hierarchy "manufacturer → dealer → sub-dealer". One dealer can have multiple retail points and multiple employees with different rights. Standard Bitrix user group model (b_user_group) is insufficient here—it doesn't store "user belongs to company" link.

Implementation via D7 ORM: create DealerCompany entity (table b_dealer_company) with fields for 1C identifier, status, dealer type, region. User-company link—via intermediate b_dealer_company_user table with role field. Roles: owner, manager, accountant—with different rights for order creation, document viewing, employee management.

Authorization via bitrix:system.auth.form enhanced with custom handler: on user login, determine their company and dealer type, cache in session. All subsequent price and catalog requests account for dealer_type.

Dealer Pricing

Dealer pricing is the most complex part. Typical scheme:

• Base price (public or closed)
• Dealer discount by type (silver, gold, platinum)—percent of base price
• Individual contract items—specific SKUs at fixed price
• Promo conditions with dates

Standard CATALOG_GROUP_ID mechanism in b_catalog_price covers first two levels. For contract items, need Highload block dealer_contract_prices with structure: UF_DEALER_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. When requesting price, check contract item first, then dealer type, then base.

Price priority logic embedded via OnBeforeSaleOrderDoFinalAction event or via custom price provider implementing Bitrix\Catalog\v2\Price\BasePriceProvider. Second approach cleaner—doesn't break with module updates.

Catalog and Inventory

Dealers often work with limited assortment—not all manufacturer catalog available to each partner. Assortment restriction implemented via:

• Filtering by infoblock property: add AVAILABLE_FOR_DEALER_TYPES property (list type), specify dealer types. In bitrix:catalog.section component add filter PROPERTY_AVAILABLE_FOR_DEALER_TYPES = current dealer type
• Assortment Highload block: for flexible setup—dealer_assortment table (UF_DEALER_ID, UF_IBLOCK_SECTION_ID). Dealer has access only to catalog sections listed in their records

Inventory—via standard catalog module, b_catalog_store_product table. For dealer portal important to show inventory at specific warehouses available to dealer (warehouse in their region). Dealer-warehouse link stored in Highload block, component overrides b_catalog_store_product query.

Document Flow and Finances

Dealers constantly request documents—invoices, shipping papers, reconciliation statements. Storing them in Bitrix excessive if they already in 1C. Work scheme:

1. Portal requests dealer document list via 1C REST service (or intermediate table export)
2. Documents cached in Highload block dealer_documents: UF_DEALER_ID, UF_DOC_TYPE, UF_DOC_NUMBER, UF_DATE, UF_AMOUNT, UF_FILE_URL
3. Sync via cron every 2 hours via main module agent (CAgent::AddAgent)
4. PDF files requested on demand, cached in /upload/dealer/docs/ for 24 hours

Debt and credit limit—similar: Highload block dealer_credit (UF_DEALER_ID, UF_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE). When exceeding limit or having overdue—order placement forbidden implemented via OnBeforeSaleOrderAdd event handler.

Notifications and Communication

Portal without notifications—half the work. Configure:

• Email events (CEventType, CEvent::Send): order status change, payment deadline approaching, new price list
• Push notifications via pull module (if mobile app exists)
• Event feed in dealer cabinet—Highload block dealer_events with events marked as read

CRM Integration

If manufacturer has Bitrix24, dealer portal syncs with CRM:

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

Link implemented via Bitrix24 REST API, CRM entity IDs stored in company custom fields.

Timeframes

Total: 14-24 weeks. Range determined by depth of 1C integration and number of custom business rules for pricing.