Автоматизація B2B-відстрочки в 1С-Бітрікс

Чому варто налаштувати відстрочку платежу?

B2B-клієнт оформлює замовлення, але кнопка «Оплатити» має бути прихована — рахунок виставляється з відкладеною датою. Якщо цього не реалізувати, компанія втрачає контроль над дебіторською заборгованістю, а менеджери вручну відстежують сотні замовлень. Наш досвід показує: автоматизація відстрочки платежу в 1С-Бітрікс скорочує прострочення в 2–3 рази, що втричі ефективніше за ручне відстеження. При цьому система сама розраховує дати, надсилає нагадування та блокує оплату до настання терміну. Для компанії з 500 замовленнями на місяць автоматизація дає економію до 1 200 000 грн на рік — за рахунок зниження прострочень і витрат ручної праці. Також скорочуються адміністративні витрати: у середньому на 200 000 грн на рік. За час роботи (7 років на ринку B2B-рішень) ми реалізували понад 50 B2B-проєктів на Бітрікс із відстрочкою платежу, і кожне рішення супроводжується повною документацією.

Як зберігати умови відстрочки

Умови відстрочки зберігаються в 1С у розрізі договорів із контрагентами. У Бітрікс дублюємо в Highload-блок b2b_payment_terms:

Синхронізація з 1С при зміні умов договору — через агент або вебхук. Використовуємо CommerceML для безшовного обміну.

Логіка оформлення замовлення

При створенні замовлення обробник OnSaleOrderSaved читає умови оплати компанії:

• prepay — стандартна логіка, доступна оплата карткою або за рахунком
• deferred — автоматично створюється рахунок з датою оплати = дата замовлення + UF_PAYMENT_DELAY_DAYS, кнопка онлайн-оплати прихована
• mixed — виставляється рахунок на передоплату (X% від суми), решта — на дату з відстрочкою

Дата оплати записується в користувацьке поле замовлення UF_PAYMENT_DUE_DATE. У кабінеті клієнта в розділі замовлень ця дата відображається явно.

Як налаштувати сповіщення про термін оплати?

Агент, що запускається щоденно, перевіряє замовлення зі статусом «Чекає оплати», у яких UF_PAYMENT_DUE_DATE наближається:

• За 3 дні — email-нагадування клієнту через CEvent::Send() з шаблоном B2B_PAYMENT_REMINDER
• У день оплати — повторний лист + завдання менеджеру в Бітрікс24 (якщо інтеграція налаштована)
• На наступний день після дедлайну — запис у лог прострочень, прапорець у b2b_credit_status

Інтеграція зі способами доставки та оплати

Для клієнтів з відстрочкою при оформленні замовлення у списку способів оплати (b_sale_pay_system) фільтруємо через обробник OnSalePaySystemHandlerList — прибираємо «Оплата карткою» та «Яндекс.Каса», залишаємо лише «Виставити рахунок».

Як працює синхронізація з 1С?

Дані з 1С завантажуються за розкладом. Агент раз на годину перевіряє оновлення договорів у CommerceML-вивантаженні. Якщо змінилися дні відстрочки або тип оплати — запис у HL-блоці оновлюється. Це гарантує, що умови завжди актуальні, навіть якщо менеджер забув оновити дані в Бітрікс.

Типові помилки при впровадженні:

• Відсутність перевірки на дублі в HL-блоці (кілька записів для однієї компанії)
• Забувають про змішаний тип — залишок не переноситься, клієнт платить двічі
• Не налаштована перевірка валюти: відстрочка може працювати лише для гривні

Ці граблі ми обходимо на етапі проєктування — код перевірено в 50+ проєктах.

Чому наше рішення краще за стандартні модулі?

Готові модулі з маркетплейсу часто не враховують специфіку B2B: різні типи відстрочки, змішану оплату, гнучкі сповіщення. Ми пишемо логіку під вашу 1С — це дає повний контроль і відсутність обмежень. На практиці такий підхід скорочує час на доробки в 4 рази.

Що входить у роботу

• Документація схеми даних та логіки замовлення
• Налаштування HL-блоків, користувацьких полів та агентів
• Інтеграція з 1С через CommerceML або REST
• Тестування всіх сценаріїв (prepay, deferred, mixed)
• Передача доступів та навчання ваших розробників
• Пост-релізна підтримка на 2 тижні

Процес роботи

1. Аналітика — розбираємо поточні умови договорів, типи оплати, інтеграцію з 1С.
2. Проєктування — схема HL-блоків, подійна модель, агенти.
3. Реалізація — кодинг на PHP 8.1+, компонентах 2.0, тегованому кешуванні.
4. Тестування — юніт-тести, інтеграційні сценарії, навантажувальне тестування.
5. Деплой — викатка на прод, моніторинг помилок через лог.

Терміни виконання

Базова відстрочка (тільки deferred) — від 3 до 5 днів. Повна реалізація зі сповіщеннями, синхронізацією та змішаною оплатою — від 1 до 2 тижнів. Точний термін залежить від складності інтеграції з вашою 1С. Отримайте консультацію по вашому проєкту — оцінимо за один день.

Досвід і гарантії

Ми маємо 7 років досвіду у B2B-рішеннях на Бітрікс, реалізували понад 50 B2B-проєктів із відстрочкою платежу. Даємо гарантію на код: безплатно виправляємо помилки, виявлені протягом місяця після здачі. Всі рішення супроводжуються ліцензійною документацією.

Зв'яжіться з нами — налаштуємо відстрочку платежу для вашого B2B-каталогу під ключ.

B2B-портали на 1С-Бітрікс

Наша спеціалізація — розробка B2B-порталів на 1С-Бітрікс. Не просто «інтернет-магазинів для оптовиків». Тут інший всесвіт: у кожного контрагента свій прайс, свій кредитний ліміт, свій набір документів і свій менеджер у Краснодарі. Роздрібний покупець обирає за картинкою та відгуками. Оптовик вбиває 50 артикулів у форму швидкого замовлення і чекає рахунок через 30 секунд.

У нас 10+ років досвіду в цій ніші, понад 50 проектів впровадження. Гарантія на роботи — 12 місяців. Сертифіковані спеціалісти 1С-Бітрікс. Зв'яжіться з нами — ми проаналізуємо вашу поточну структуру цін і запропонуємо архітектуру порталу під ваш бізнес.

Як влаштоване ціноутворення в B2B-порталі?

Якщо в роздробі одна ціна для всіх, то в B2B — матриця. Типи цін в b_catalog_price множаться на групи контрагентів, накопичувальні знижки, валютні перерахунки та договірні умови. Саме тут проект або злітає, або тоне в багах.

Типи цін і прайс-листи. У Бітрікс типи цін задаються через CCatalogGroup. Стандартний набір: роздрібна, дрібнооптова, оптова, дилерська, дистриб'юторська. Кожен контрагент прив'язаний до групи користувачів, група — до типу ціни. Але реальність складніша: один дилер може бачити оптові ціни на електроніку та дистриб'юторські на аксесуари. Це вже не штатний механізм — потрібна кастомна логіка через обробник OnSaleBasketItemBeforePriceSave.

Знижки — прогресивна шкала за обсягом (від 100 штук — мінус 5%, від 500 — мінус 12%), накопичувальні за період, сезонні, за категоріями. Знижки комбінуються через пріоритети в b_sale_discount. Порядок застосування — окремий головний біль: знижка може бути до або після фіксованої; пріоритети налаштовуються в «Правилах роботи з кошиком». При 20+ правилах налагодження перетворюється на квест.

Кредитні ліміти. Контрагенту встановлюється поріг відвантаження в кредит. Поточна заборгованість синхронізується з 1С через регістр РасчетыСКонтрагентами. Перевищення ліміту → блокування оформлення замовлення. Без цього менеджери відвантажують у борг, а бухгалтерія потім розгрібає дебіторку.

Договірні ціни — прайс прив'язаний до конкретного договору: терміни дії, номер, умови пролонгації. Договір закінчився — ціни перемикаються на базові автоматично. Реалізується через користувацькі властивості замовлення та обробник OnSaleComponentOrderProperties.

Валюта — для ЗЕД обов'язково. Перерахунок за курсом ЦБ (парсинг cbr.ru через CCurrencyRates::ConvertCurrency()) або фіксований курс контракту.

Що входить до дилерського кабінету?

Замовлення — повна історія з фільтрацією за статусами, датами, сумами. Повтор попереднього замовлення в один клік — для регулярних закупівель це економить години. Шаблони замовлень для типових позицій.

Фінанси — сальдо взаєморозрахунків, акт звірки, історія оплат. Все, що бухгалтер зазвичай запитує по email і чекає три дні — в кабінеті миттєво. Дані тягнуться з 1С через REST або CommerceML.

Документи — рахунки, накладні, рахунки-фактури, УПД, акти. Формуються в 1С, PDF пушиться на портал через інтеграцію. Завантаження одним кліком. Жодного «надішліть повторно, загубилося в пошті».

Управління співробітниками дилера — адміністратор створює обліковки з розмежуванням прав. Менеджер із закупівель формує замовлення, бухгалтер бачить лише фінанси, керівник — загальну картину. Реалізується через розширення стандартних груп користувачів Бітрікс.

Швидке замовлення: артикул + кількість = рахунок

B2B-клієнт знає, що йому потрібно. Каталог з красивими картками йому не потрібен — потрібна форма: артикул, кількість, наступний рядок.

• Форма швидкого замовлення — автопідстановка найменування та ціни при введенні артикула. Використовуємо AJAX-пошук по b_iblock_element.XML_ID або PROPERTY_ARTICLE. 50 позицій за 3 хвилини
• Імпорт з Excel/CSV — клієнт вивантажив зі своєї системи, завантажив на портал. Автоспівставлення артикулів, перевірка наявності, формування замовлення. Парсинг через PHPExcel або PhpSpreadsheet
• Кошик з повною інформацією — вага, об'єм, кількість місць, орієнтовна вартість доставки до оформлення

Чому інтеграція з 1С критична для B2B-порталу?

Без актуальних даних з 1С портал марний. Менеджер Іванов змінив ціну на цвяхи — через 15 хвилин дилер в Красноярську має бачити нову ціну.

CommerceML простіше: штатний модуль обміну, XML-файли, мінімум налаштувань. Але він повільний на великих каталогах і не підтримує кастомні сутності (кредитні ліміти, сальдо). REST API через HTTP-сервіс 1С — гнучкіший, швидший, але потребує доопрацювання на стороні 1С. На практиці часто використовуємо гібрид: CommerceML для каталогу, REST для цін, залишків і документів. Згідно з офіційною документацією 1С-Бітрікс, для B2B-порталів критично налаштувати синхронізацію довідників та залишків у реальному часі. Детальніше про CommerceML та REST API 1С-Бітрікс.

ЕДО: юридично значущий обмін без паперу

Для великих B2B-проектів:

• Провайдери — Контур.Діадок, СБІС, Калуга Астрал. Рахунки-фактури, акти, накладні в електронному вигляді з юридичною силою
• КЕП — кваліфікований електронний підпис. Контрагент підписує акт прямо в кабінеті
• Роумінг між операторами — без цього половина партнерів, у яких інший оператор ЕДО, залишиться за бортом

Багатофілійність

• Регіональні склади — клієнт бачить залишки найближчого складу, може обрати склад відвантаження. Товар є в Новосибірську, але немає в Москві — портал покаже обидва варіанти з різними термінами
• Автоназначення менеджера — дилер з Краснодару працює з Іваном, з Єкатеринбурга — з Мариною. За полем UF_REGION в картці контрагента
• Локальні умови — мінімальна сума замовлення, умови доставки, терміни — відрізняються за регіонами

Процес розробки B2B-порталів

Розробка B2B-порталів включає п'ять етапів. Нижче таблиця з орієнтовними термінами та результатами.

Що входить в роботу:

• Повна проектна документація (ТЗ, архітектурна схема, протоколи інтеграції)
• Налаштування серверного оточення та розгортання (On-Premise або хмара)
• Перенесення всіх користувацьких даних та конфігурацій
• Навчання адміністраторів порталу (2 заняття онлайн)
• Гарантійна підтримка 12 місяців з реакцією до 4 годин

Після запуску — техпідтримка та розвиток. B2B-портал — жива система, яка еволюціонує разом з бізнесом.

Середня економія часу менеджера на обробці замовлень — до 20 годин на тиждень.

На старті перевірте коректність типів цін та груп користувачів, обмежте кількість знижкових правил (не більше 3–4), протестуйте інтеграцію з 1С на реальних даних, видайте дилерам доступи та проведіть навантажувальне тестування на 50 одночасних користувачів.

Замовте розробку B2B-порталу та отримайте консультацію спеціаліста. Зв'яжіться з нами для обговорення вашого проекту — ми підготуємо попередній розрахунок та запропонуємо оптимальне рішення.