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.

B2B Portal Development on 1C-Bitrix

A dealer in Krasnoyarsk enters 50 SKUs, needs an instant invoice with his own price, credit limit, and delivery from the nearest warehouse. A retail catalog won’t cut it. We build such portals on 1C-Bitrix — with personalized price matrices, dealer cabinets, and real-time 1C integration. Over 50 B2B portals launched, 12-month warranty, certified 1C-Bitrix specialists with 10+ years in development. Submit a request for a free audit of your current pricing system — we will analyze your structure and propose a tailored architecture.

How does pricing work in a B2B portal?

Retail has one price. B2B has a matrix: price types in b_catalog_price multiplied by user groups, cumulative discounts, currency conversions, contractual conditions. A mistake here sinks the project.

Price types and user groups. Bitrix sets types via CCatalogGroup. Standard set: retail, small wholesale, wholesale, dealer, distributor. Each counterparty belongs to a user group, the group to a price type. Reality is more complex: one dealer may see wholesale prices for electronics and distributor prices for accessories. That requires custom logic in the OnSaleBasketItemBeforePriceSave handler.

Discounts — progressive by volume (from 100 pieces → minus 5%, from 500 → minus 12%), cumulative over a period, seasonal, category-based. Combined through priorities in b_sale_discount. With 20+ rules, debugging becomes a quest.

Credit limits. The counterparty gets a shipping credit threshold. Current debt syncs from 1C via the register РасчетыСКонтрагентами (Settlements with Counterparties). Exceeding the limit blocks order placement.

Contract prices — the price list is tied to a specific contract: validity period, number, prolongation conditions. Expiration switches prices to base ones automatically. Implemented through order custom fields and the OnSaleComponentOrderProperties handler.

Currency — mandatory for foreign trade. Conversion at the Central Bank rate (CCurrencyRates::ConvertCurrency()) or a fixed contract rate.

Compare CommerceML and REST for price sync: CommerceML is simpler but 4x slower on catalogs over 10,000 items, and it can’t handle credit limits. REST API via 1C HTTP service is 3x faster and fully flexible but requires 1C-side modifications. According to the 1C-Bitrix Developer's Guide, real-time sync of directories and balances is critical for B2B portals.

What does the dealer cabinet include?

• Orders — full history with filtering by statuses, dates, amounts. Repeat previous order in one click — saves hours for regular purchases.
• Finances — balance of mutual settlements, reconciliation statement, payment history. No more waiting three days for accounting — data available instantly, pulled from 1C via REST or CommerceML.
• Documents — invoices, waybills, sales invoices, UPD, certificates. Generated in 1C, PDF pushed to the portal via integration. One-click download.
• Dealer employee management — admin creates accounts with role permissions: purchasing manager places orders, accountant sees only finances, director sees the big picture. Extended standard Bitrix user groups.

Quick order: SKU + quantity = invoice

A B2B client doesn’t browse beautiful cards. They need a form: SKU, quantity, next line.

• Quick order form — auto-suggest of name and price when entering SKU. AJAX search by b_iblock_element.XML_ID or PROPERTY_ARTICLE. 50 items in 3 minutes.
• Import from Excel/CSV — client exports from their system, uploads to the portal. Auto-matching of SKUs, availability check, order generation. Parsing via PHPExcel or PhpSpreadsheet.
• Basket with full information — weight, volume, number of packages, estimated delivery cost before checkout.

Why is 1C integration critical for a B2B portal?

Without up-to-date data from 1C, the portal is useless. Manager changed the price of nails — in 15 minutes a dealer in Krasnoyarsk sees the new price.

We often use a hybrid: CommerceML for catalog, REST for prices, stocks, and documents.

EDI: legally significant paperless exchange

For large B2B projects:

• Providers — Kontur.Diadoc, SBIS, Kaluga Astral. Invoices, certificates, waybills in electronic form with legal force.
• CEP — qualified electronic signature. The counterparty signs right in the cabinet.
• Roaming between operators — without it, half of partners with a different EDI operator are left out.

Multi-branch operation

• Regional warehouses — client sees stock of the nearest warehouse and can choose the shipping one. Product available in Novosibirsk but not in Moscow → portal shows both options with different lead times.
• Automatic manager assignment — dealer from Krasnodar works with Ivan, from Yekaterinburg with Marina. Based on UF_REGION in the counterparty card.
• Local conditions — minimum order amount, delivery terms, lead times — differ by region.

B2B Portal Development Process

B2B portal development includes five stages.

What is included in the work

• Complete project documentation (terms of reference, architecture diagram, integration protocols)
• Server environment setup and deployment (On-Premise or cloud)
• Migration of all user data and configurations
• Portal administrator training (2 online sessions)
• Warranty support for 12 months with response within 4 hours

After launch — technical support and development. A B2B portal is a living system that evolves with the business.

Average time savings for a manager on order processing — up to 20 hours per week, which translates to approximately $15,000 annual savings per dealer. A self-built portal typically takes 6 months to develop, while a Bitrix-based solution is ready in 2 months.

Typical mistakes to avoid at the start

1. Verify price types and user groups before going live.
2. Keep discount rules to a minimum (3–4) — 20+ rules cause debugging nightmares.
3. Test 1C integration on real data during pilot.
4. Grant dealer access only after load testing with 50 concurrent users.

Contact us to discuss your project — we will prepare a preliminary estimate and propose the optimal solution. Get your free audit of pricing mechanics today.