Настройка обмена взаиморасчётами 1С и 1С-Битрикс
Взаиморасчёты в личном кабинете клиента — функциональность, востребованная в B2B интернет-магазинах и оптовых порталах. Покупатель должен видеть текущий долг перед поставщиком, историю платежей, задолженность по конкретным заказам. Все эти данные живут в 1С — и их нужно передавать в Битрикс.
Данные взаиморасчётов: что хранится в 1С
В 1С (УТ, КА, ERP, БП) взаиморасчёты с контрагентами хранятся в регистре накопления ВзаиморасчётыСКонтрагентами. Ключевые данные:
- Текущая дебиторская задолженность — сколько контрагент должен организации
- Кредиторская задолженность — если организация должна контрагенту (переплата, возврат)
- Просроченная задолженность — задолженность сверх кредитного лимита или срока
- История платежей — когда и сколько платил
- Документы-основания — счета, заказы, по которым есть задолженность
Стандартный CommerceML-обмен не передаёт взаиморасчёты. Это нужно реализовывать отдельно.
Архитектура решения
Для передачи взаиморасчётов в Битрикс используется один из двух подходов:
Подход 1: HTTP-сервис 1С. В 1С создаётся HTTP-сервис, который по запросу возвращает взаиморасчёты по конкретному контрагенту. Битрикс вызывает этот сервис при открытии страницы «Мой баланс» в личном кабинете.
// Запрос взаиморасчётов из Битрикс
$response = file_get_contents(
"https://1c.example.com/ut/hs/balance/get?counterparty_id={$guid}&key={$apiKey}"
);
$balance = json_decode($response, true);
Преимущество: данные всегда актуальные. Недостаток: зависимость от доступности сервера 1С.
Подход 2: Периодическая синхронизация. Регламентное задание в 1С формирует файл с данными взаиморасчётов и передаёт в Битрикс (через FTP, API, или прямой запрос к скрипту). Битрикс сохраняет данные в своей БД и показывает клиенту.
Преимущество: независимость от доступности 1С в момент загрузки страницы. Недостаток: данные с задержкой (равной интервалу синхронизации, обычно 30–60 минут).
Реализация в Битрикс: структура данных
Для хранения взаиморасчётов в Битрикс рекомендую создать HighloadBlock — например, ContractorBalance:
| Поле | Тип | Описание |
|---|---|---|
| UF_CONTRACTOR_XML_ID | Строка | GUID контрагента в 1С |
| UF_BITRIX_USER_ID | Целое | ID пользователя Битрикс |
| UF_DEBT | Decimal | Текущий долг (руб.) |
| UF_OVERDUE_DEBT | Decimal | Просроченный долг |
| UF_CREDIT_LIMIT | Decimal | Кредитный лимит |
| UF_LAST_PAYMENT_DATE | Дата | Дата последнего платежа |
| UF_LAST_PAYMENT_SUM | Decimal | Сумма последнего платежа |
| UF_UPDATED_AT | Datetime | Время последнего обновления |
Для истории платежей — отдельный HighloadBlock ContractorPayments с записями по каждому платежу.
Привязка контрагента к пользователю Битрикс
Главная техническая задача: знать, какой пользователь Битрикс соответствует какому контрагенту в 1С. Варианты:
-
По XML_ID пользователя. При регистрации на сайте создаётся контрагент в 1С (через REST API), его GUID сохраняется в профиле пользователя Битрикс (поле
UF_1C_CONTRACTOR_ID). -
По ИНН. Пользователь при регистрации вводит ИНН, система ищет контрагента в 1С по ИНН.
-
Ручное сопоставление. Администратор в Битрикс вручную привязывает пользователя к контрагенту. Подходит для B2B с небольшим количеством клиентов.
Кредитный лимит и запрет заказа
Популярный сценарий: если у контрагента просроченная задолженность — запрещать оформление новых заказов на сайте. Или: если долг превышает кредитный лимит — показывать предупреждение.
Реализация через событие Битрикс 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(
'Оформление заказа недоступно: есть просроченная задолженность'
));
}
}
Кейс: оптовый портал стройматериалов
B2B-портал: 300 активных контрагентов, каждый с кредитным лимитом. Задача: показывать в личном кабинете баланс и запрещать заказы при превышении лимита.
Использовали подход с HTTP-сервисом 1С для получения текущего долга в реальном времени. Кешировали ответ на 10 минут (Redis). При оформлении заказа — всегда свежий запрос, без кеша.
Дополнительно: на странице личного кабинета выводили детализацию — список открытых счётов с суммами и датами оплаты. Данные из HighloadBlock, обновляемого раз в час.
Результат: менеджеры перестали вручную информировать клиентов о долгах. Клиенты сами видят задолженность и самостоятельно оплачивают до оформления нового заказа. Количество звонков «почему не могу заказать» сократилось.