Custom Wholesale Order Module for 1C-Bitrix

Developing a custom wholesale order module for 1C-Bitrix solves the problem of processing orders with hundreds of line items. Tabular input with AJAX search, Excel/CSV import, and drafts replace manual search through filters. The standard bitrix:sale.basket component is not suitable — we create a turnkey module with stock reservation and 1C integration. Data exchange with ERP is implemented via the CommerceML standard. With 100 orders per month, time savings amount to 50 hours, which at a manager rate of 600 RUB/hour gives 30,000 RUB savings monthly.

Quick Order Entry: Three Scenarios

Tabular input with autocomplete. The user enters an article number in a row, the field autocompletes via an AJAX request to a custom handler that searches b_iblock_element with an index on CODE and XML_ID. After selecting an item, the price, stock, and unit of measure fields are filled automatically. Rows in the table are added dynamically via JS.

Import from Excel/CSV. The file is uploaded through a file field component, parsed on the server via PhpSpreadsheet or fgetcsv. Expected format: article number, quantity, optionally comment. The parsing result is a list of items with found and unfound article numbers. Unfound ones are shown separately for manual matching. Found items are added to the order draft.

Repeat order. The "Repeat order" button in history — takes CSaleOrder::GetByID(), iterates over CSaleBasket::GetList() with ORDER_ID, checks current availability of each item. Items with zero stock are marked with a warning but do not block draft creation.

The custom module processes import of 5000 items in 2 seconds, whereas the standard basket takes 30 seconds (15 times faster). Get a consultation for your project — we'll calculate timelines and budget.

install/
  index.php       — installer, registers event handlers
lib/
  OrderDraft.php  — order draft entity (D7 DataManager)
  Importer.php    — Excel/CSV parsing
  PriceProvider.php — priority pricing
  StockChecker.php  — stock check
options.php       — module settings in admin panel

Why Stock Reservation Matters?

Wholesale orders without stock checks are a source of conflicts with the supply department. We implement two levels:

Soft check when adding an item to the draft: query CCatalogStoreProduct::GetList() with filter by PRODUCT_ID and STORE_ID. If the requested quantity exceeds available — show a warning but do not block. The buyer sees: Available: 45, you requested: 60. Partial shipment possible.

Reservation when moving to pending_approval status: create a record in b_catalog_store_product with a negative stock change (or in a separate reservation table). When the order is cancelled, the reservation is released. This prevents double booking of the same product by two buyers. Synchronization with 1C releases reservations automatically — when stock is updated via CommerceML, stocks are recalculated, and reservations are accounted for in b_catalog_store_product.QUANTITY_RESERVED.

What Is Volume Pricing?

Wholesale prices depend on volume: 1-10 units — price A, 11-50 — price B, 51+ — price C. In the standard catalog module, this is implemented via quantized prices (CCatalogProductPrice), but the management interface is inconvenient for a large assortment. In the module, we implement a custom interface for managing volume discounts: highload block wholesale_price_rules (UF_IBLOCK_SECTION_ID or UF_PRODUCT_ID, UF_QTY_FROM, UF_QTY_TO, UF_PRICE_TYPE — fixed or percentage of base). When an item is added to the draft, the quantity is determined and the appropriate rule is applied.

Units of Measure

A wholesale catalog often has multiple units: piece, pack (12 pcs), pallet (240 pcs). The catalog module supports measures via CCatalogMeasure and CCatalogMeasureRatio. In the wholesale interface, the buyer selects a unit — the quantity is automatically recalculated, as is the price.

Feature Comparison: Standard Basket vs Custom Module

How We Develop the Module: Step by Step

1. Analysis of wholesale department business processes.
2. Prototyping the tabular input interface.
3. Module development with drafts and import.
4. Integration with 1C via CommerceML.
5. Testing on your assortment (up to 50,000 products).
6. Delivery with documentation and training.

What Is Included

• Module development with tabular input, import, and drafts.
• Configuration of reservation and pricing.
• Integration with 1C via CommerceML.
• Testing on your assortment (up to 50,000 products).
• API documentation for the module and instructions for managers.
• Handover of access and training (2-hour call).
• 6-month code guarantee.

Timeline

Total: 8-14 weeks including testing and acceptance. Contact us for a consultation — we'll discuss your project and calculate the exact cost. Order the development of a wholesale order module.

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.