Imagine: a dealer calls a manager to check order status or request an invoice. Now multiply that by 200 dealers and 10 orders per month — that's 2000 unnecessary calls wasting time and money. We develop turnkey dealer cabinet modules on 1C-Bitrix that automate these processes and reduce manager workload by 70%. Our experience includes over 30 successful projects where savings reached 200,000 rubles per month for clients.
Dealers constantly face outdated prices, delays in order processing, and manual document reconciliation. Our module unifies orders, pricelists, documents, and finances in a single interface with automatic synchronization from 1C. This cuts order processing time from 30 minutes to 2 minutes and eliminates input errors.
What's included in the dealer cabinet module: minimal set
The dealer cabinet is a functional tool with its own access logic and data specific to each partner. The minimal set of sections includes:
- Orders — list with filtering by status, date, amount. Detailed card with items, repeat option, and document download.
- Pricelist — up-to-date list with dealer prices, export to Excel.
- Documents — invoices, waybills, reconciliation reports from 1C.
- Finances — current balance, credit limit, overdue debt.
- Company profile — details, delivery addresses, contact persons.
This covers basic dealer needs without unnecessary calls.
Module architecture
Located in local/modules/project.dealer_cabinet/. The module registers its own components in the project namespace:
local/modules/project.dealer_cabinet/
install/index.php — installer
lib/
DealerContext.php — current dealer context (singleton)
Repository/
OrderRepository.php — order queries with dealer filtering
DocumentRepository.php — documents from 1C / Highload
FinanceRepository.php — credit limit, debt
Service/
PriceExporter.php — export pricelist to Excel
DealerAccessControl.php — permission checks
DealerContext is the central object. On each request, it reads the dealer company ID and dealer type from the session. All repositories receive this context and apply corresponding filters. This prevents dealer A from seeing dealer B's orders — all data access goes through a single point.
Order management in the cabinet
Order history is fetched via CSaleOrder::GetList() with a filter on the user field UF_DEALER_COMPANY_ID. All orders of the company — not just those created by the current user. If a dealer has multiple managers, each sees all company orders (role-dependent: manager sees all, purchaser sees only their own).
Detailed order card: items via CSaleBasket::GetList(), delivery statuses via CSaleDelivery, documents — by ORDER_ID from the document Highload block (synchronized with 1C). The 'Download waybill' button requests PDF from 1C via REST or returns a cached file from /upload/dealer/docs/.
Order repeat — iterates over previous order items, checks current stock and prices, creates a draft. Items not in stock are marked with a warning. The dealer decides whether to remove them or leave with a wait.
Pricelist export
Dealers regularly download pricelists for their clients or for loading into their own systems. Export is implemented via PriceExporter:
- Get catalog products filtered by categories available to the dealer.
- Apply dealer prices from
b_catalog_price by the dealer's CATALOG_GROUP_ID.
- Apply contract prices from the Highload block (if any, with priority).
- Generate Excel via
PhpSpreadsheet or output CSV.
Format: SKU, name, unit, stock (optional), price. File is generated on the fly, not cached — prices must be current at the time of request. If the catalog is large (10K+ items) — generate in the background via an agent and provide a link to the ready file.
Finance block
Credit limit and debt data are not stored in Bitrix — they live in 1C. Synchronization via an agent every 2 hours: calls the REST service of 1C, writes the result to the 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 — days overdue
UF_UPDATED_AT — last sync time
In the cabinet, data is displayed with the note 'Current as of {time}'. If overdue > 0, show a warning; when the allowable threshold is exceeded, block new order creation via the OnBeforeSaleOrderAdd handler.
How to ensure data security in the cabinet?
All requests go through the dealer context, which verifies data ownership. Access rights are checked centrally through DealerAccessControl. Financial data is not permanently stored in Bitrix but synchronized from 1C, eliminating sensitive information leakage. For additional protection, HTTPS and authorization tokens are used. The custom module processes requests 3 times faster than typical solutions due to the absence of extra checks at the core level.
Access rights within a company
Within a single dealer company, different users have different rights. Table b_dealer_user_roles:
| Role |
Orders |
Documents |
Finances |
User management |
owner |
All |
All |
Yes |
Yes |
manager |
Own |
Own |
No |
No |
accountant |
All (read) |
All |
Yes |
No |
Permission checking — via DealerAccessControl::can($action) before every action. Centralized, not in templates.
Why is a custom module more profitable than a ready-made solution?
A ready-made module from the Marketplace often fails to consider specific 1C integration, unique discounts, and roles. A custom module, like ours, is fully adapted to your business processes. For example, the architecture with a single DealerContext reduces access permission check time by 3 times compared to typical implementations. Integration with 1C via REST allows updating prices and stock without delays, saving up to 5 hours of manager time per day.
Timeline
| Block |
Duration |
| Module architecture, roles, context |
2-3 weeks |
| Order management |
2-3 weeks |
| Documents and 1C synchronization |
2-4 weeks |
| Finance block |
1-2 weeks |
| Pricelist export |
1-2 weeks |
| Testing |
2-3 weeks |
Total: 10-17 weeks. Main variable — complexity of 1C integration for documents and finances.
We provide a 12-month warranty on the module from delivery. Order dealer cabinet module development and get a consultation on 1C integration — contact us for a project assessment; we will prepare a quote and timeline individually. If you're looking to evaluate your specific needs, simply reach out to us without obligation.
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.
| Data |
Direction |
Mechanism |
| Catalog, characteristics |
1C → Portal |
CommerceML or REST, 15–60 min |
| Prices by type and counterparty |
1C → Portal |
REST API, by event or schedule |
| Stock balances by warehouse |
1C → Portal |
REST, 5–15 min or real-time via 1C HTTP service |
| Orders |
Portal → 1C |
REST, real-time |
| Statuses, shipments |
1C → Portal |
By event |
| Mutual settlements |
1C → Portal |
1–2 times per day |
| Documents (PDF) |
1C → Portal |
By event |
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.
| Stage |
Timeline |
Result |
| Process audit |
1–2 weeks |
Business process diagram, integration map |
| Design |
2–3 weeks |
Architecture, prototypes, 1C exchange specification |
| Development |
4–8 weeks |
Cabinets, pricing mechanics, integrations, document flow |
| Testing |
1–2 weeks |
Functional, integration, load testing on real data |
| Pilot |
2–3 weeks |
5–10 dealers, feedback, refinements |
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
- Verify price types and user groups before going live.
- Keep discount rules to a minimum (3–4) — 20+ rules cause debugging nightmares.
- Test 1C integration on real data during pilot.
- 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.
