Налаштування обміну договорами контрагентів 1С і 1С-Бітрікс
У B2B інтернет-магазинах і оптових порталах договори — це не просто документи. Договір визначає: за якою ціною працює клієнт, який кредитний ліміт, які умови доставки. Без передачі договорів із 1С в 1С-Бітрікс сайт не може показати коректні ціни та умови для конкретного контрагента.
Роль договору в 1С
В УТ, КА та ERP договір контрагента (ДоговориКонтрагентів) — ключовий об'єкт ціноутворення. З договором пов'язані:
- Вид ціни — який прайс застосовується до цього клієнта
- Знижки — персональні знижки або знижки за договором
- Валюта розрахунків
- Кредитний ліміт та строк кредиту
- Умови оплати (передоплата, постоплата, днів відстрочки)
Якщо в 1С у клієнта є 3 діючих договори (наприклад, роздрібний, оптовий і спеціальний), на сайті він має бачити ціни за потрібним договором і мати можливість вибрати договір при оформленні замовлення.
Передача договорів: архітектура
Стандартний CommerceML не передає договори. Потрібна кастомна синхронізація через HTTP-сервіс 1С або через файловий обмін.
Мінімальний набір даних договору для сайту:
{
"guid": "a1b2c3d4-1234-...",
"number": "Д-2024-0015",
"name": "Договір поставки №15 від 01.03.2024",
"contractor_guid": "контрагент-guid",
"price_type_guid": "вид-ціни-guid",
"price_type_name": "Оптова",
"credit_limit": 500000,
"payment_delay_days": 14,
"currency": "UAH",
"valid_from": "2024-03-01",
"valid_to": "2025-03-01",
"is_active": true
}
У 1С-Бітрікс договори зберігаються в HighloadBlock ContractorContracts. При відкритті каталогу — визначається активний договір користувача, до нього прив'язується тип ціни в торговому каталозі.
Маппінг договору на ціну в 1С-Бітрікс
Ключове завдання: користувач із певним договором має бачити ціни з пов'язаного виду цін.
Реалізація:
- При авторизації користувача — визначаємо його договір(и) з HighloadBlock
- Визначаємо тип ціни за договором (
price_type_guid→ ID типу ціни в 1С-Бітрікс) - Встановлюємо сесійну змінну або параметр користувача
CURRENT_PRICE_TYPE - Компонент каталогу читає цю змінну і виводить ціни потрібного типу
Якщо у користувача кілька договорів — надаємо вибір в особистому кабінеті: «Працювати за договором №...». Вибір зберігається в сесії.
Синхронізація договорів: періодичність
Договори змінюються рідко — новий договір підписується раз на рік, умови переглядаються раз на квартал. Достатньо синхронізувати раз на годину або навіть раз на добу.
Але є критичний сценарій: договір розірвано або закінчився — клієнт не повинен продовжувати бачити оптові ціни. Для цього в логіку авторизації додаємо перевірку valid_to договору. Якщо дата минула — переводимо користувача на базовий тип ціни.
Договір при оформленні замовлення
При передачі замовлення з 1С-Бітрікс у 1С потрібно вказати договір, за яким виставляється замовлення. У XML замовлення:
<ЗначенняРеквізиту>
<Найменування>ДоговірId</Найменування>
<Значення>a1b2c3d4-1234-...</Значення>
</ЗначенняРеквізиту>
В УТ при створенні замовлення покупця договір береться з цього реквізиту. Без договору — замовлення створюється за замовчуванням (перший активний договір контрагента), що може призвести до неправильного ціноутворення в документах 1С.
Кейс: дистриб'ютор з індивідуальними умовами
Дистриб'ютор медичного обладнання: 180 дилерів, у кожного — індивідуальний договір зі своєю ціною (знижка від 5% до 40% від роздробу). Всі ціни ведуться в УТ як окремі види цін на кожного дилера (18 видів цін).
Завдання на сайті: кожен дилер при вході бачить тільки свої ціни, ціни інших дилерів недоступні.
Реалізація:
- Синхронізація договорів з УТ в 1С-Бітрікс — раз на 2 години
- При авторизації — визначається договір, з нього береться GUID виду ціни
- GUID маппується на тип ціни в 1С-Бітрікс (таблиця маппінгу в налаштуваннях)
- Каталог показує ціни потрібного типу
Додатково: у кожного дилера є «менеджер-куратор» в УТ. При створенні замовлення на сайті — в замовлення автоматично додається менеджер (із поля договору ВідповідальнийМенеджер). Менеджер в УТ одразу бачить замовлення свого клієнта.
Строк дії та автоматичне продовження
Якщо договір закінчується — за N днів до закінчення надсилаємо повідомлення відповідальному менеджеру в Бітрікс24 (через REST API). Регламентне завдання в 1С-Бітрікс перевіряє valid_to всіх договорів щодня.
// Агент перевірки строку дії договорів
function checkContractExpiry() {
$soon = date('Y-m-d', strtotime('+30 days'));
$contracts = getContractsExpiringBefore($soon);
foreach ($contracts as $contract) {
notifyManager($contract['manager_id'], $contract);
}
return 'checkContractExpiry()'; // агент перезапускається
}