B2B Portal Development Services on 1C-Bitrix

B2B Portals on 1C-Bitrix

A B2B portal isn't just "an online store for wholesalers." It's a different universe: each counterparty has their own price list, their own credit limit, their own set of documents, and their own account manager. A retail buyer chooses by photos and reviews. A wholesale buyer types 50 article numbers into a quick order form and expects an invoice within 30 seconds.

Pricing: Where 80% of B2B Portal Complexity Lives

In retail, there's one price for everyone. In B2B — a matrix. Price types in b_catalog_price multiply by counterparty groups, volume discounts, currency conversions, and contract terms. This is exactly where the project either takes off or drowns in bugs.

Price types and price lists. In Bitrix, price types are set via CCatalogGroup. Standard set: retail, small wholesale, wholesale, dealer, distributor. Each counterparty is linked to a user group, the group — to a price type. But reality is more complex: one dealer may see wholesale prices on electronics and distributor prices on accessories. This is no longer a standard mechanism — it requires custom logic via the OnSaleBasketItemBeforePriceSave handler.

Discounts — progressive volume scales (100+ units — minus 5%, 500+ — minus 12%), cumulative over a period, seasonal, category-based. Discounts combine through priorities in b_sale_discount. Application order is a separate headache: does the percentage discount apply before or after the fixed one? Configured in "Cart Rules," but with 20+ rules, debugging becomes a quest.

Credit limits. A counterparty gets a credit shipment threshold. Current debt is synchronized with 1C via the РасчетыСКонтрагентами register. Limit exceeded → order placement blocked. Without this, managers ship on credit, and accounting then sorts out the receivables.

Contract prices — a price list tied to a specific contract: validity period, number, renewal terms. Contract expired — prices automatically switch to base. Implemented via custom order properties and the OnSaleComponentOrderProperties handler.

Currency — mandatory for international trade. Conversion at central bank rates (parsing cbr.ru via CCurrencyRates::ConvertCurrency()) or a fixed contract rate.

Dealer Portal: Self-Service Without Calling a Manager

Orders — full history with filtering by status, date, amount. Repeat a previous order in one click — for regular purchases, this saves hours. Order templates for standard items.

Finances — settlement balance, reconciliation acts, payment history. Everything the accountant normally requests by email and waits three days for — available instantly in the portal. Data pulled from 1C via REST or CommerceML.

Documents — invoices, waybills, tax invoices, universal transfer documents, acts. Generated in 1C, PDFs pushed to the portal via integration. One-click download. No more "please resend, it got lost in email."

Dealer employee management — the admin creates accounts with role-based access. The procurement manager places orders, the accountant sees only finances, the director — the big picture. Implemented by extending Bitrix's standard user groups.

Quick Order: Article Number + Quantity = Invoice

A B2B client knows what they need. They don't need a catalog with pretty product cards — they need a form: article number, quantity, next line.

• Quick order form — auto-fill of name and price when entering an article number. We use AJAX search by b_iblock_element.XML_ID or PROPERTY_ARTICLE. 50 items in 3 minutes
• Excel/CSV import — the client exports from their system, uploads to the portal. Automatic article matching, availability check, order creation. Parsing via PHPExcel or PhpSpreadsheet
• Cart with full information — weight, volume, number of packages, estimated shipping cost before checkout

1C Integration: The Backbone

Without current data from 1C, the portal is useless. Manager Ivanov changed the price on nails — within 15 minutes, a dealer in another city should see the new price.

CommerceML vs REST API — CommerceML is simpler: a standard exchange module, XML files, minimal setup. But it's slow on large catalogs and doesn't support custom entities (credit limits, balances). REST API via a 1C HTTP service is more flexible and faster, but requires development on the 1C side. In practice, we often use a hybrid: CommerceML for the catalog, REST for prices, stock, and documents.

EDI: Legally Binding Exchange Without Paper

For large B2B projects:

• Providers — Kontur.Diadoc, SBIS, Kaluga Astral. Invoices, acts, waybills in electronic form with legal validity
• Qualified digital signature — the counterparty signs the act right in the portal
• Roaming between operators — without this, half the partners using a different EDI operator are left out

Multi-Branch Operations

• Regional warehouses — the client sees stock at the nearest warehouse, can choose the shipment warehouse. Product is available in Novosibirsk but not in Moscow — the portal shows both options with different timelines
• Auto-assignment of managers — a dealer from one region works with Ivan, from another — with Marina. Based on the UF_REGION field in the counterparty card
• Local terms — minimum order amount, delivery conditions, timelines — vary by region

Timelines

A typical B2B portal — 2–4 months:

1. Process audit (1–2 weeks) — how do you work with dealers now? What price lists, documents, integrations?
2. Design (2–3 weeks) — architecture, portal prototypes, 1C exchange specification
3. Development (4–8 weeks) — portals, pricing mechanics, integrations, document flow
4. Testing (1–2 weeks) — functional, integration, load. On real price lists and data from 1C
5. Pilot (2–3 weeks) — 5–10 key dealers, feedback, refinements

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