B2B Deferred Payment Setup on 1C-Bitrix: Turnkey Automation

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.
Showing 1 of 1All 1626 services
B2B Deferred Payment Setup on 1C-Bitrix: Turnkey Automation
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1356
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • 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
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    828
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1073

Why Configure Deferred Payment in 1C-Bitrix?

A B2B client places an order, but the "Pay" button must be hidden — an invoice is issued with a delayed date. Without this feature, the company loses control over accounts receivable, and managers manually track hundreds of orders. Our experience shows that automating deferred payment in 1C-Bitrix cuts overdue by 2–3 times. The system automatically calculates dates, sends reminders, and blocks payment until the due date. For a company with 500 orders per month, automation saves up to $15,000 annually by reducing overdue and manual labor costs. Over a decade, we have implemented more than 50 B2B projects on Bitrix with deferred payment, and each solution is backed by complete documentation.

How to Store Payment Terms

Payment terms are stored in 1C per contract with counterparties. In Bitrix, we duplicate them in a Highload-block b2b_payment_terms:

Field Type Description
UF_COMPANY_ID int Company ID
UF_PAYMENT_DELAY_DAYS int Number of days deferred (0 = no deferral)
UF_PAYMENT_TYPE enum prepay, deferred, mixed (partial prepayment)
UF_PREPAY_PERCENT int Prepayment percentage for mixed
UF_ACTIVE_FROM, UF_ACTIVE_TO date Term validity period

Synchronization from 1C on contract changes is done via agent or webhook. We use CommerceML for seamless exchange.

Order Processing Logic

When an order is created, the OnSaleOrderSaved handler reads the company's payment terms:

  • prepay — standard logic, card or invoice payment available
  • deferred — an invoice is automatically created with payment date = order date + UF_PAYMENT_DELAY_DAYS, online payment button hidden
  • mixed — an invoice for prepayment (X% of amount) is issued, the remainder is deferred to the due date

The payment due date is recorded in the order custom field UF_PAYMENT_DUE_DATE. It is displayed clearly in the client's account order section.

How to Configure Payment Due Reminders?

An agent running daily checks orders with status "Awaiting Payment" where UF_PAYMENT_DUE_DATE is approaching:

  • 3 days before — email reminder to the client via CEvent::Send() with template B2B_PAYMENT_REMINDER
  • On the due date — repeat email plus a task for the manager in Bitrix24 (if integrated)
  • One day after deadline — log entry for overdue, flag in b2b_credit_status

Integration with Delivery and Payment Methods

For clients with deferred payment, during order placement we filter payment methods (b_sale_pay_system) via the OnSalePaySystemHandlerList handler — remove "Pay by Card" and "Yandex.Checkout", leave only "Issue Invoice".

How Does Synchronization with 1C Work?

Data from 1C is loaded on a schedule. An agent checks for contract updates in the CommerceML export every hour. If deferral days or payment type change — the HL-block record is updated. This ensures terms are always current, even if a manager forgets to update data in Bitrix.

Common Implementation Mistakes
  • Missing duplicate check in HL-block (multiple records for one company)
  • Forgetting the mixed type — the remainder isn't deferred, client pays twice
  • Not configuring currency check: deferral may work only for rubles

We avoid these issues at the design stage — code proven in 50+ projects.

Why Our Solution Is Better Than Standard Modules?

Off-the-shelf modules from the marketplace often overlook B2B specifics: different deferral types, mixed payment, flexible notifications. We write logic tailored to your 1C — giving full control and no limitations. In practice, this approach reduces rework time by 4 times.

What Is Included in the Work

  • Documentation of data schema and order logic
  • Setup of HL-blocks, custom fields, and agents
  • Integration with 1C via CommerceML or REST
  • Testing of all scenarios (prepay, deferred, mixed)
  • Handover of access and training for your developers
  • Post-release support for 2 weeks

Our Work Process

  1. Analysis — Review current contract terms, payment types, and 1C integration.
  2. Design — HL-block schema, event model, agents.
  3. Development — Coding in PHP 8.1+, components 2.0, tagged caching.
  4. Testing — Unit tests, integration scenarios, load testing.
  5. Deployment — Rollout to production, error monitoring via logs.
Stage Duration Result
Analysis 1–2 days Data schema, requirements
Development 3–10 days Ready functionality, tests
Testing 1–2 days Protocol, fixes
Deployment 1 day Working on production

Timelines and Cost

Basic deferral (deferred only) — from 3 to 5 days. Full implementation with notifications, synchronization, and mixed payment — from 1 to 2 weeks. Exact cost is determined after analysis of your 1C integration complexity. Reach out for a project consultation — we'll evaluate in one day.

Experience and Guarantees

With extensive experience in the market, we have implemented more than 50 B2B projects on Bitrix with deferred payment. We provide a code guarantee: free fixes for bugs found within one month after delivery. All solutions come with licensed documentation.

Contact us to set up deferred payment for your B2B catalog turnkey.

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

  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.