Development of a wholesale company website using 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Wholesale Company Website Development on 1C-Bitrix

A B2B wholesale site is not a showcase for end consumers, but a working tool for dealers and buyers. Beautiful banners and "bestsellers" not needed. What's required is fast catalog navigation through tens of thousands of SKUs, order loading by SKU, current stock and prices tied to counterparty group. 1C-Bitrix with "Trade Catalog" module and standard 1C integration covers these tasks, but standard B2C store logic requires rebuild.

B2B Catalog: Price Types and Wholesale Rules

Foundation of B2B catalog — multiple price types. In table b_catalog_group, create price groups:

  • Retail — base, visible to unauthorized users (if catalog open).
  • Small wholesale — for category C dealers.
  • Medium wholesale — for category B dealers.
  • Large wholesale — for category A dealers.
  • Special — individual prices for key clients.

Each price type binds to user group via catalog module settings. Authorized dealer from "Large wholesale" group sees their price column — others hidden. Configuration performed in "Trade Catalog" → "Price Types" → "Buyer Groups."

Additional item-level parameters:

  • Minimum order — information block property, numeric. Checked in basket component: cannot order below specified quantity.
  • Order multiplicity — information block property. Basket quantity rounded to nearest multiple (e.g., packing by 12 units).
  • Unit of measure — standard catalog module field (b_catalog_measure): pieces, packs, pallets.

Dealer Authorization and Access Control

Dealer registration not self-service, but via request. Scheme:

  1. On site — request form: INN, company name, contact person, business sphere, estimated purchase volume.
  2. Request goes to CRM or admin (section "Users" → "Registration Requests").
  3. Manager checks counterparty, creates account, assigns group (small/medium/large wholesale).
  4. Dealer gains personal cabinet access and sees catalog with their prices.

Assortment (not just price) separation realized via information block section access rights. For example, "Large wholesale" group sees "Exclusive Collections" section unavailable to small dealers.

Personal Cabinet: Document Management

Dealer personal cabinet extends far beyond standard sale.personal.section. Key sections:

  • Order history — with filtering by date, status, amount. One-click reorder.
  • Invoices — PDF documents generated by sale module or passed from 1C.
  • Reconciliation acts — files uploaded by manager or auto-generated from 1C.
  • Delivery notes and UPD — linked to orders, available for download.
  • Credit limit — display current limit, used amount, available balance.
  • Payment deferment — information on terms and conditions.

Documents stored in Highload block Documents: document type, number, date, file, binding to order and counterparty. Loading from 1C — via REST API on schedule.

Invoice PDF generation on Bitrix side — via mPDF or TCPDF library, connected in OnSaleOrderSaved event handler. Invoice template includes company details, product table, totals, QR code for payment.

Integration with 1C: CommerceML + REST

1C exchange — core of wholesale site. Two channels:

CommerceML (standard exchange):

  • Nomenclature → product information block.
  • Prices by types → b_catalog_price.
  • Stock by warehouse → b_catalog_store_product.
  • Orders: Bitrix → 1C (export) and back (statuses, shipments).

REST API (for operational data):

  • Current stock — request 1C on product card open (with 5–10 minute caching).
  • Counterparty credit limit — request on login and order placement.
  • Documents — export new invoices and acts on schedule.

Deep-dive: B2B Basket with Excel Upload and Price Types

Standard Bitrix basket designed for retail buyer: select product, click "Add to Cart," proceed to checkout. B2B buyer works differently. Arrives with ready list of 50–200 items, wants load in one action.

Quick Order by SKU

On "Quick Order" page — text field for "SKU — quantity" pairs, one per line:

ART-001 24
ART-002 48
ART-003 12

On submit, server handler parses lines, searches products by ARTICLE property in block (via CIBlockElement::GetList with filter), checks availability, adds to basket via \Bitrix\Sale\Basket::addItem(). If SKU not found — line highlighted red with explanation.

Excel File Upload

More advanced option — XLS/XLSX upload. Server handler:

  1. File receipt — via standard Bitrix upload (CFile::SaveFile).
  2. Parsing — PhpSpreadsheet library (connected via Composer). Expected format: column A — SKU, column B — quantity. First row — header (skipped).
  3. Validation — check each row: SKU existence, product availability for user group, minimum order and multiplicity compliance.
  4. Result formation — table with columns:
SKU Name Requested Adjusted Stock Price Sum Status
ART-001 Product A 24 24 150 OK
ART-002 Product B 48 48 30 Partial (30 left)
ART-999 12 Not found
  1. Confirmation — user sees result, adjusts quantity, confirms basket addition.

Price Type Processing in Basket

Product price on basket addition determined automatically by user group. Logic:

  • Determine authorized user group (CUser::GetUserGroupArray()).
  • By group, determine available price type (CCatalogGroup::GetGroupsList()).
  • From b_catalog_price, extract product price for needed type.
  • If product has quantity discounts configured (module "Basket Rules" — sale.discount), applied on recalculation.

Additional logic — threshold discounts: order over certain sum automatically gets extra discount. Configured via basket rules with condition "Basket sum more than N."

Credit Limit on Checkout

At checkout stage, counterparty credit limit checked. Data retrieved from 1C via REST API. If order sum exceeds available limit — warning displayed, but order can submit (manager discretion). Realization — OnSaleOrderBeforeSaved event handler, executing 1C request and recording result in order property.

Technical Summary

Component Solution
Catalog bitrix:catalog with faceted index
Filtering bitrix:catalog.smart.filter + AJAX
Basket Custom component with Excel support
Integration CommerceML (catalog) + REST API (stock, limits)
Documents Highload block + mPDF
Access Control User groups → price types + information block sections

Wholesale site on Bitrix — primarily backend: 1C exchange, price types, rights, document management. Frontend secondary — interface must be functional and fast, not flashy.