A wholesale client on a building materials portal has a debt of 2.5 million rubles, and the sales department spends 10 hours a week on phone calls—a familiar pain. We configure the exchange of mutual settlements between 1C and 1C-Bitrix so that the buyer sees the exact balance in their personal account and the system automatically blocks the order when the credit limit is exceeded. Our integration experience shows: without automating this task, a company loses up to 15% of revenue due to delays, and managers are forced to manually reconcile debts.
Mutual settlements in the personal account are a standard for B2B stores and wholesale portals. The client should see the current debt, payment history, and debt on specific orders. All this data lives in 1C (UT, ERP, KA)—and it needs to be transferred to Bitrix without losses and with acceptable performance. Below we'll break down the solution architecture with an emphasis on reliability and speed. Proper configuration of mutual settlement exchange pays for itself in 2-3 months by reducing delays and speeding up the sales department.
Mutual Settlement Data: What is Stored in 1C
In 1C (UT, KA, ERP, BP), mutual settlements with counterparties are stored in the accumulation register ВзаиморасчётыСКонтрагентами. Key data:
- Current accounts receivable—how much the counterparty owes the organization
- Accounts payable—if the organization owes the counterparty (overpayment, return)
- Overdue debt—debt exceeding the credit limit or term
- Payment history—when and how much was paid
- Source documents—invoices, orders against which there is debt
Standard CommerceML does not transfer mutual settlements. This needs to be implemented separately.
Solution Architecture: How to Transfer Debts?
To transfer mutual settlements to Bitrix, we use one of two approaches—the choice depends on the data freshness requirements.
Approach 1: 1C HTTP Service
In 1C, an HTTP service is created that returns mutual settlements for a specific counterparty on request. Bitrix calls this service when opening the "My Balance" page in the personal account.
Example of calling an HTTP service from Bitrix
$response = file_get_contents( "https://1c.example.com/ut/hs/balance/get?counterparty_id={$guid}&key={$apiKey}" ); $balance = json_decode($response, true); Steps to configure:
- Create an HTTP service in 1C with a
GETmethod to get the balance. - Implement a function that returns the current and overdue debt and credit limit by the counterparty's GUID.
- In Bitrix, configure the service call with an API key, cache the response in Redis for 10 minutes.
- Handle 1C availability errors—show cached data when unavailable.
Advantage: data is always up-to-date. Disadvantage: dependence on 1C server availability. An HTTP service provides real-time data freshness; for critical checks (order placement) it is 6 times faster than periodic synchronization.
Approach 2: Periodic Synchronization
A scheduled task in 1C generates a file with mutual settlement data and transfers it to Bitrix (via FTP, API, or direct request to a script). Bitrix saves the data in its own database and displays it to the client.
Advantage: independence from 1C availability at the moment of page load. Disadvantage: data delayed (equal to the synchronization interval, usually 30-60 minutes). An HTTP service provides greater freshness, but synchronization is more stable—we choose according to the task. For B2B with frequent orders, an HTTP service is preferable; for budget projects, synchronization.
What Is Included in Our Work to Configure the Exchange?
| Stage | Actions | Result for the Client |
|---|---|---|
| Analytics | Study 1C registers, counterparty types, business rules | Working documentation on data and scenarios |
| Design | Choose an approach (HTTP service or synchronization), HighloadBlock structure | Integration diagram approved by the customer |
| Implementation | HTTP service on the 1C side, Bitrix module (HL blocks, event handlers) | Ready code deployed on staging |
| Testing | Check all cases: debt, overdue, credit limit, history | Test protocol with bug fixes |
| Deployment and training | Move to production, configure agents, hand over accesses | Administrator documentation, 2 hours of online training |
After implementation, you get a guarantee of stable synchronization: we leave monitoring for 14 days and promptly fix incidents. Plus a free consultation on improvements after one month of operation.
Implementation in Bitrix: HighloadBlock Structure
To store mutual settlements in Bitrix, I recommend creating a HighloadBlock—for example, ContractorBalance:
| Field | Type | Description |
|---|---|---|
| UF_CONTRACTOR_XML_ID | String | Counterparty GUID in 1C |
| UF_BITRIX_USER_ID | Integer | Bitrix user ID |
| UF_DEBT | Decimal | Current debt (rub.) |
| UF_OVERDUE_DEBT | Decimal | Overdue debt |
| UF_CREDIT_LIMIT | Decimal | Credit limit |
| UF_LAST_PAYMENT_DATE | Date | Last payment date |
| UF_LAST_PAYMENT_SUM | Decimal | Last payment amount |
| UF_UPDATED_AT | Datetime | Last update time |
For payment history—a separate HighloadBlock ContractorPayments with records for each payment.
Linking a Counterparty to a Bitrix User
The main technical challenge: knowing which Bitrix user corresponds to which counterparty in 1C. Options:
-
By user XML_ID. When registering on the site, a counterparty is created in 1C (via REST API), its GUID is saved in the Bitrix user profile (field
UF_1C_CONTRACTOR_ID). -
By TIN (Taxpayer Identification Number). The user enters a TIN during registration, and the system looks up the counterparty in 1C by TIN.
-
Manual mapping. The administrator in Bitrix manually links a user to a counterparty. Suitable for B2B with a small number of clients.
Credit Limit and Order Prohibition
A popular scenario: if the counterparty has overdue debt—prohibit placing new orders on the site. Or: if the debt exceeds the credit limit—show a warning.
Implementation via Bitrix event OnSaleOrderBeforeSaved:
AddEventHandler('sale', 'OnSaleOrderBeforeSaved', 'checkDebtLimit'); function checkDebtLimit(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $userId = $order->getUserId(); $debt = getContractorDebt($userId); $limit = getContractorCreditLimit($userId); if ($debt['overdue'] > 0) { $result = $event->getParameter('RESULT'); $result->addError(new \Bitrix\Main\Error( 'Order placement is not available: there is overdue debt' )); } } This code works for any limit management scenarios.
Case Study: Wholesale Building Materials Portal
B2B portal: 300 active counterparties, each with a credit limit. Task: show the balance in the personal account and prohibit orders when the limit is exceeded. We used the HTTP service approach from 1C to get the current debt in real time. We cached the response for 10 minutes (Redis). When placing an order—always a fresh request, no cache.
Additionally: we displayed a breakdown on the personal account page—a list of open invoices with amounts and payment dates. Data from the HighloadBlock, updated once an hour.
We measured the result after 3 months: managers stopped manually informing clients about debts—the number of calls "why can't I order" dropped by 70%. Clients themselves see the debt and pay before placing a new order. Compare: manual calling took 10 person-hours per week, automation reduced it to 3 hours—3 times faster. Average savings on manager salaries amounted to 30,000 rubles per month. Automation paid for itself in 2 months.
How Long Does It Take to Set Up Mutual Settlement Exchange?
We estimate the project at 2 working days after filling out the brief. Basic setup (one approach, no custom rules) takes from 5 to 10 working days. If complex scenarios are needed (multiple currencies, automatic blocking by credit limit, integration with Bizproc)—we clarify timelines individually. Contact us—get an accurate estimate for your project.
Why Order the Setup from Us?
We have been working with Bitrix and 1C for 10+ years and have completed 50+ integration projects. Our team includes certified 1C engineers and Bitrix developers. We provide a code guarantee—6 months of free support. After implementation, you will be able to manage the data yourself through the administrative interface.
Order the setup today—and start managing debts without manual labor. Get a consultation on the architecture of mutual settlement exchange: we will evaluate your register, choose the optimal transfer method, and implement a turnkey solution with documentation.