Development of a 1C-Bitrix dealer account module

Development of Dealer Cabinet Module for 1C-Bitrix

A dealer who calls a manager to check order status or request an invoice — that's a call that costs money. Multiplied by 200 dealers and 10 orders monthly each — we get 2000 unnecessary manager calls per month. A dealer cabinet closes this load automatically.

What's Included: Minimum Scope

Dealer cabinet — not a storefront and not a CMS page. It's a functional tool with its own access logic and partner-specific data. Minimum set of sections:

• Orders — list with filtering by status, date, amount. Detailed card with items, repeat option, document download
• Price list — current price with dealer rates, Excel export
• Documents — invoices, packing lists, reconciliation statements from 1C
• Finance — current balance, credit limit, overdue debt
• Company Profile — requisites, delivery addresses, contacts

Module Architecture

Located in local/modules/project.dealer_cabinet/. Module registers its own components in project namespace:

local/modules/project.dealer_cabinet/
  install/index.php           — installer
  lib/
    DealerContext.php         — current dealer context (singleton)
    Repository/
      OrderRepository.php     — order retrieval with dealer filter
      DocumentRepository.php  — documents from 1C / Highload
      FinanceRepository.php   — credit limit, debt
    Service/
      PriceExporter.php       — price export to Excel
      DealerAccessControl.php — access control

DealerContext — central object. On each request reads dealer company ID and type from session. All repositories receive this context and apply corresponding filters. This excludes dealer A seeing dealer B's orders — all data access goes through one point.

Order Management in Cabinet

Order history taken from CSaleOrder::GetList() with filter by custom field UF_DEALER_COMPANY_ID. All company orders — not just those created by current user. If dealer has multiple managers, each sees all company orders (by role: manager sees all, purchaser — own only).

Order detail card: items via CSaleBasket::GetList(), delivery statuses via CSaleDelivery, documents — by ORDER_ID from Highload document block (synced with 1C). "Download invoice" button requests PDF from 1C via REST or serves cached file from /upload/dealer/docs/.

Order repeat — iterates through previous order items, checks current stock and prices, creates draft. Items not in stock flagged as warning. Dealer decides whether to remove or keep with wait.

Price Export

Dealers regularly download price for their customers or for loading in own systems. Export implemented via PriceExporter:

1. Get catalog items filtered by dealer-available categories
2. Apply dealer prices from b_catalog_price by dealer CATALOG_GROUP_ID
3. Apply contract prices from Highload block (if exists, with priority)
4. Generate Excel via PhpSpreadsheet or serve CSV

Format: SKU, name, unit, stock (optional), price. File generated on the fly, not cached — prices must be current at request time. Large catalog (10K+ items) — generate in background via agent, give link to ready file.

Finance Block

Credit limit and debt data not stored in Bitrix — live in 1C. Sync via agent every 2 hours: calls 1C REST service, result written to Highload block dealer_finances:

UF_DEALER_ID       — dealer company ID
UF_CREDIT_LIMIT    — maximum limit
UF_USED_LIMIT      — used limit
UF_OVERDUE_AMOUNT  — overdue debt
UF_OVERDUE_DAYS    — overdue days
UF_UPDATED_AT      — last sync time

In cabinet data shown with note "Current as of {time}". If overdue > 0 — show warning, exceeding allowed threshold — block new order creation via OnBeforeSaleOrderAdd handler.

Access Control Within Company

Different users in one dealer company have different rights. Table b_dealer_user_roles:

Permission check — via DealerAccessControl::can($action) before each action. Centralized, not in templates.

Timeline

Total: 10-17 weeks. Main variable — complexity of 1C integration for documents and finance.