Регулярные и абонентские поставки в B2B

Оптовый клиент каждый месяц заказывает одно и то же: тот же ассортимент расходников, ту же партию сырья, тот же набор SKU на свои точки. И каждый месяц кто-то со стороны снабженца вручную собирает корзину, сверяет остатки, звонит менеджеру, ждёт счёт, оплачивает, напоминает про отгрузку. Рутина съедает часы, а любой пропуск оборачивается простоем производства или пустой полкой. Регулярные и абонентские поставки убирают эту рутину: заказ формируется сам по согласованному графику, оплата списывается автоматически, а обе стороны получают уведомления на каждом шаге.

Ниже — практический разбор того, как собрать абонентскую модель поставок в B2B на 1С-Битрикс: какие модели поставок бывают, как устроен график и шаблон заказа, как настроить автосписания и рекуррентные платежи, как выстроить уведомления и что делать со сбоями. Это выжимка из наших проектов по разработке B2B-порталов на 1С-Битрикс — без теории ради теории, с прицелом на реальную эксплуатацию.

Что такое абонентские поставки в B2B

Абонентская (регулярная) поставка — это модель, при которой заказ на повторяющийся набор товаров формируется автоматически по заранее согласованному графику, без ручного оформления на каждый цикл. По сути это перенос логики «подписки» из B2C-сервисов в оптовую торговлю, но с поправкой на специфику B2B: договорные цены, отсрочки платежа, согласование объёмов, обмен документами и учёт в 1С.

Ключевое отличие от разового заказа — наличие двух устойчивых сущностей. Первая — шаблон поставки: что и в каком объёме клиент получает регулярно. Вторая — график: с какой периодичностью и в какие даты эта поставка повторяется. На пересечении шаблона и графика система в нужный момент порождает конкретный заказ, проводит его через оплату и отгрузку и уведомляет участников.

Важно не путать абонентскую поставку с простым «повтором заказа». Повтор — это разовое действие пользователя: нажал кнопку «заказать снова», получил копию корзины. Абонентская модель работает без участия человека в штатном сценарии: пока клиент не отменил или не поставил поставку на паузу, она исполняется сама. Человек подключается только там, где нужно решение — скорректировать объём, разобрать сбой оплаты, подтвердить нестандартную позицию.

Для оптовой торговли это не косметическое удобство, а способ закрепить за собой предсказуемый повторяющийся спрос. Клиент, который перевёл снабжение расходников на абонентскую поставку, гораздо реже уходит к конкуренту: у него уже настроен график, сохранены реквизиты и способ оплаты, отлажены документы. Абонентская модель повышает удержание и делает выручку прогнозируемой.

Зачем это оптовику и поставщику

Абонентская модель выгодна обеим сторонам, но по-разному. Полезно разложить мотивацию явно — это помогает и продавать функцию внутри компании, и правильно расставить приоритеты при внедрении.

Что получает оптовик (покупатель):

• Снятие рутины. Не нужно каждый цикл собирать одну и ту же корзину и держать в голове даты заказа — система напомнит и сформирует заказ сама.
• Защита от простоя. Расходники, сырьё и ходовые позиции приходят вовремя, риск «забыли заказать и встали» уходит.
• Предсказуемый бюджет. Понятный график поставок и оплат упрощает планирование закупок и денежного потока.
• Единая история. Все поставки, документы и оплаты собраны в личном кабинете, а не разбросаны по переписке.

Что получает поставщик (продавец):

• Прогнозируемый спрос. Регулярные заказы делают выручку и загрузку склада предсказуемыми, а планирование закупок — точнее.
• Рост удержания. Настроенная абонентская поставка — это барьер для ухода клиента: переключиться на конкурента становится дороже.
• Меньше нагрузки на менеджеров. Рутинные повторные заказы уходят в автоматику, менеджеры занимаются исключениями и развитием клиента.
• Больше среднего чека во времени. Стабильный поток заказов и допродажи к регулярной поставке увеличивают выручку с клиента на горизонте.

Прогнозируемость спроса — отдельная большая ценность. Когда часть заказов формируется по графику, у вас появляется понятный базовый поток, вокруг которого проще планировать закупки и склад. Эту связку мы подробно разбираем в материале про прогноз спроса и планирование закупок в B2B — абонентские поставки дают ту самую предсказуемую основу, на которую опирается прогноз.

Модели регулярных поставок

«Регулярная поставка» — это зонтичный термин. Под ним скрывается несколько разных бизнес-моделей, и от того, какую из них вы поддерживаете, зависит вся дальнейшая настройка. Разберём основные.

• Фиксированная поставка по графику. Один и тот же состав и объём с жёсткой периодичностью — например, ящик расходников каждый вторник. Самая простая модель: шаблон почти не меняется, задача системы — вовремя сформировать заказ.
• Поставка с корректировкой перед циклом. Состав фиксирован как база, но перед каждой поставкой клиент может увеличить или уменьшить количество, добавить или убрать позиции. Система шлёт напоминание с окном на правки, а по его закрытии фиксирует заказ.
• Поставка «до уровня запаса». Клиент задаёт целевой остаток по позициям, а объём поставки система рассчитывает как разницу между целевым и фактическим уровнем. Требует данных об остатках у клиента — либо через интеграцию, либо через регулярную отчётность.
• Рамочный договор с выборкой. Согласован общий объём на период (квартал, год) и график, по которому он выбирается частями. Система следит за остатком по договору и не даёт выбрать больше согласованного.
• Абонемент/пакет услуг. Регулярная оплата за доступ к условиям (спеццены, приоритетная отгрузка, сервис), а не за конкретный товар. Ближе всего к классической подписке.

На практике у одного поставщика уживается несколько моделей: кто-то из клиентов на жёстком графике, кто-то — на поставке с корректировкой, кто-то на рамочном договоре. Поэтому проектировать стоит не «одну подписку», а гибкий механизм графиков и шаблонов, который покрывает разные сценарии единым ядром.

Архитектура решения на 1С-Битрикс

Чтобы внедрять осознанно, полезно держать в голове слои, из которых собирается абонентская модель. В 1С-Битрикс это не один готовый модуль, а связка штатных механизмов и надстроенной над ними бизнес-логики.

• Шаблон и график поставки. Собственные сущности (обычно highload-блок или отдельные таблицы), где хранятся состав поставки, объёмы, периодичность, даты и статус (активна, на паузе, завершена).
• Агент-планировщик. Агент или задача в cron, которая регулярно проверяет графики и находит поставки, для которых пора формировать заказ.
• Модуль sale. Штатное ядро интернет-магазина: создаёт заказ по шаблону, хранит плательщика, способ оплаты и доставки, ведёт статусы.
• Платёжный слой. Платёжная система с поддержкой рекуррентных списаний либо механизм выставления счёта с отсрочкой для проверенных клиентов.
• Слой уведомлений. Почта, СМС, мессенджеры и сообщения в кабинете, привязанные к событиям жизненного цикла поставки.
• Обмен с 1С. Двусторонний обмен: цены и остатки — из учётной системы для генерации заказа, реализации и счета — обратно в 1С.

Логика проходит через слои по цепочке: агент по расписанию находит «созревшую» поставку, модуль поставок берёт её шаблон, запрашивает актуальные цены и остатки, собирает заказ в sale, инициирует оплату (списание или счёт) и на каждом шаге дёргает слой уведомлений. Понимание этой цепочки сразу подсказывает, где искать проблему: не сформировался заказ — смотрим агент и график, не прошла оплата — платёжный слой, разошлись суммы — обмен цен с 1С.

Отдельно подчеркну: механизм рекуррентных платежей и управление подписками в 1С-Битрикс — тема достаточно большая, чтобы разбирать её отдельно. Как устроены рекуррентные списания, как хранить привязку карты и управлять жизненным циклом подписки, мы подробно описали в статье про подписки и рекуррентные платежи в 1С-Битрикс. Здесь мы опираемся на этот механизм как на готовый платёжный слой абонентской модели.

График поставок: как устроено расписание

График — сердце абонентской модели. Именно он определяет, когда система должна сформировать очередной заказ. Хороший график описывается несколькими независимыми параметрами, а не одним «раз в месяц».

• Периодичность. Раз в неделю, раз в две недели, ежемесячно, по определённым дням недели или месяца, по индивидуальному календарю.
• Опорная дата. Точка отсчёта, от которой считаются последующие поставки: дата старта абонемента или фиксированный день (например, каждое 5-е число).
• Окно корректировки. За сколько дней до формирования заказа клиент может внести правки и получает напоминание.
• Учёт нерабочих дней. Правило переноса поставки, попавшей на выходной или праздник, — вперёд, назад или без переноса.
• Горизонт и завершение. Бессрочно, до даты, до N поставок или до выборки объёма по рамочному договору.
• Пауза. Возможность приостановить график на период (отпуск снабженца, сезонное затишье) без потери настроек.

Технически график удобно хранить не как список конкретных дат, а как правило, из которого даты вычисляются. Тогда изменение периодичности не требует переписывать календарь, а агент-планировщик на каждом запуске просто спрашивает у правила: «есть ли поставка, которую пора формировать в этом окне?». Конкретные даты уже сформированных и предстоящих поставок при этом полезно кэшировать для отображения клиенту в кабинете.

Отдельный нюанс — идемпотентность. Агент может запуститься чаще, чем нужно, или дважды на одном окне (например, после сбоя). Чтобы не создать дубль заказа, каждая поставка в цикле должна иметь уникальный ключ (поставка + дата цикла), и перед созданием заказа система проверяет, не сформирован ли он уже. Это одна из тех деталей, которую легко упустить на демо и больно поймать в проде.

Шаблон поставки: состав, объём, цена

Если график отвечает на вопрос «когда», то шаблон отвечает на вопрос «что». Это сохранённый набор позиций, из которого система собирает конкретный заказ в каждом цикле. И здесь кроется одна из главных проектных развилок: что именно фиксировать в шаблоне.

Правильный принцип — шаблон фиксирует состав и объём, но не цену. Цена подставляется в момент формирования заказа по актуальному прайсу и договорным условиям клиента. Если зашить цену в шаблон, вы неизбежно начнёте отгружать по устаревшим ценам после любого пересмотра прайса, а ручная правка сотен шаблонов — это тупик. Поэтому шаблон хранит артикулы и количества, а стоимость каждый раз рассчитывается заново.

Из этого принципа вытекает несколько практических требований к шаблону:

• Позиции по стабильному идентификатору. Храните ссылку на товар/SKU по внутреннему коду или артикулу, а не по названию — названия и цены меняются, идентификатор остаётся.
• Проверка доступности. При сборке заказа система проверяет, что позиция активна и есть на остатке; выбывшие из ассортимента товары нужно уметь заменять или помечать.
• Гибкость объёма. Для моделей с корректировкой шаблон хранит базовое количество, поверх которого накладываются правки текущего цикла.
• Договорные условия. Персональные цены, скидки за объём и валюта договора должны применяться на этапе расчёта — как в обычном B2B-заказе.

Быстрое наполнение шаблона — отдельная забота о клиенте. Оптовику удобно собрать регулярную поставку не кликами по каталогу, а загрузкой списка артикулов или файла. Механику массового ввода мы разбираем в материале про быстрый заказ по артикулу и загрузку из Excel для B2B — тот же инструмент отлично подходит, чтобы одним движением сформировать или обновить шаблон абонентской поставки.

Автосписания и рекуррентные платежи

Оплата — самый чувствительный узел абонентской модели, потому что здесь замешаны деньги и доверие. В B2B встречаются два принципиально разных сценария, и часто они сосуществуют.

Рекуррентное списание. Клиент один раз привязывает способ оплаты, а система при формировании каждого заказа автоматически списывает сумму. Это удобно для регулярных поставок с предоплатой и небольшими стабильными суммами. Механизм опирается на поддержку рекуррентных платежей платёжной системой: первый платёж сохраняет токен, последующие проходят без участия клиента. Ключевые требования — надёжное хранение привязки, корректная обработка отказов и прозрачные уведомления.

Автоматический счёт с отсрочкой. Для проверенных оптовиков предоплата часто неуместна: работают в отсрочку. Тогда автосписание заменяется автоматическим выставлением счёта при формировании заказа и контролем оплаты по срокам. Система создаёт счёт, отправляет его клиенту, отслеживает поступление и напоминает о приближении срока оплаты. Деньги списываются не с карты, а приходят платёжным поручением, но автоматизация всё равно снимает рутину.

Отдельно нужно продумать сценарий неуспеха. Списание может не пройти по десяткам причин — недостаточно средств, истёк срок карты, отзыв привязки, технический сбой. Правильная реакция — не молчаливая блокировка поставки, а управляемая цепочка:

1. Повторные попытки. Несколько ретраев по расписанию (например, через день, через три дня), а не одна попытка «в лоб».
2. Уведомление сторон. Клиенту и менеджеру сразу уходит сообщение о неуспешном списании с понятным следующим шагом.
3. Статус ожидания. Заказ переводится в «ожидает оплаты», а не отменяется молча — отгрузка держится на паузе, но не теряется.
4. Обновление способа оплаты. Клиенту даётся простой путь обновить карту или оплатить вручную, после чего поставка продолжается.

Грамотно выстроенная обработка сбоев оплаты — это то, что отличает «подписку, которая тихо ломается» от «подписки, которая надёжно работает». Львиная доля оттока в абонентских моделях приходится именно на непройденные платежи, о которых никто вовремя не узнал.

Уведомления для оптовиков

Абонентская модель держится на доверии, а доверие — на прозрачности. Клиент должен всегда понимать, что и когда с ним произойдёт, и иметь возможность вмешаться. Поэтому уведомления в регулярных поставках — не «маркетинговая рассылка», а часть механики.

Работающая цепочка уведомлений привязана к событиям жизненного цикла поставки:

• Напоминание перед формированием. За несколько дней до заказа — с составом, суммой-ориентиром и ссылкой «скорректировать или пропустить». Это главное уведомление: оно открывает окно правок.
• Подтверждение заказа. После формирования — фактический состав, итоговая сумма, дата отгрузки и оплаты.
• Статус оплаты. Успешное списание или выставленный счёт; при неуспехе — понятный призыв к действию.
• Отгрузка и документы. Уведомление об отгрузке с накладными, счётом-фактурой и трек-номером.
• Сервисные события. Пауза, возобновление, скорое завершение абонемента, выбытие позиции из ассортимента.

Каналы стоит давать на выбор: электронная почта как основной документальный канал, СМС и мессенджеры — для срочных статусов, сообщения внутри личного кабинета — для полной истории. Разным ролям на стороне клиента нужны разные уведомления: снабженцу важны напоминания и правки, бухгалтерии — счета и документы, руководителю — сводки. Умение адресовать уведомление роли, а не одному контакту, заметно повышает качество коммуникации.

Главный принцип — каждое уведомление несёт действие или полезный факт. «Напоминаем о себе» без сути раздражает и обучает клиента игнорировать сообщения, а именно эти сообщения потом критично не заметить (например, о непройденной оплате). Держите сигнал высоким.

Разовый заказ против абонентской поставки

Чтобы принять решение о внедрении, полезно наглядно сопоставить разовую и абонентскую модель по ключевым характеристикам.

Настройка абонентских поставок пошагово

1. Определите модели поставок. Зафиксируйте, какие сценарии поддерживаете: жёсткий график, корректировка перед циклом, до уровня запаса, рамочный договор. От этого зависит структура графика и шаблона.
2. Спроектируйте сущности. Заведите хранилище для шаблона (состав и объёмы) и графика (периодичность, опорная дата, окно правок, статус). Разделите их с заказом sale.
3. Настройте агент-планировщик. Создайте агент или cron-задачу, которая регулярно ищет «созревшие» поставки и запускает формирование заказа с проверкой на дубли.
4. Свяжите с модулем sale. Реализуйте сборку заказа из шаблона: подстановка актуальных цен, проверка остатков, применение договорных условий клиента.
5. Подключите оплату. Настройте рекуррентное списание через платёжную систему и/или автоматическое выставление счёта с отсрочкой, плюс сценарий повторных попыток.
6. Соберите уведомления. Привяжите сообщения к событиям поставки: напоминание, подтверждение, статус оплаты, отгрузка. Дайте выбор каналов и адресацию по ролям.
7. Настройте обмен с 1С. Обеспечьте выгрузку актуальных цен и остатков и загрузку реализаций и счетов обратно в учётную систему.
8. Дайте клиенту кабинет управления. Личный кабинет с графиком, составом, историей поставок, кнопками «пауза», «пропустить», «изменить объём», «обновить оплату».
9. Проверьте на боевом сценарии. Прогоните полный цикл на тестовом клиенте: формирование, оплата, сбой оплаты, ретрай, пауза, возобновление, завершение.

Как это выглядит в админке 1С-Битрикс

Настройка абонентской поставки со стороны администратора или менеджера сводится к карточке поставки: клиент, шаблон, график и способ оплаты. Схематично интерфейс выглядит так:

Со стороны платформы за этим стоят конкретные механизмы. Заказы создаются штатным модулем sale — программно через API оформления заказа (\Bitrix\Sale\Order), с корзиной, плательщиком и способами оплаты и доставки. Периодический запуск обеспечивают агенты (CAgent) или задача в cron, дергающая консольный скрипт, — второй вариант надёжнее для тяжёлых операций, потому что не зависит от посещаемости сайта. Хранилище шаблонов и графиков удобно вести на highload-блоках или собственных таблицах модуля. Уведомления отправляются через события и почтовые шаблоны (CEvent), СМС- и мессенджер-провайдеров. Рекуррентные списания реализуются обработчиками платёжной системы с сохранением токена привязки.

Отдельно стоит держать бизнес-логику в собственном модуле, а не в правках ядра. Обработчики событий, агенты и API-вызовы оформляются как отдельный компонент решения — так его проще сопровождать и обновлять платформу без конфликтов. Правки в файлах ядра при следующем обновлении затираются, поэтому весь код абонентской модели должен жить в своём пространстве имён и подключаться штатными точками расширения.

Обмен с 1С: цены, остатки, документы

Абонентские поставки почти всегда завязаны на учётную систему. Регулярные заказы порождают постоянный поток отгрузок, счетов и реализаций, который бессмысленно вести вручную, а данные для генерации заказа — цены и остатки — живут в 1С. Поэтому обмен с 1С здесь не опция, а фундамент.

Что именно ходит в обмене для абонентской модели:

• Цены на момент поставки. Для каждого клиента — его договорные цены и скидки, актуальные на дату формирования заказа. Это защищает от отгрузки по устаревшему прайсу.
• Остатки. Проверка наличия при сборке заказа: нет позиции — перенос на следующий цикл или уведомление менеджеру, а не отгрузка «в минус».
• Реализации и счета обратно в 1С. Каждый сформированный и отгруженный заказ автоматически становится документом в учёте, без ручного дублирования.
• Статусы оплаты. Проведённые оплаты и закрытые счета синхронизируются, чтобы менеджер видел единую картину в обеих системах.

Практический риск обмена — рассинхронизация во времени. Заказ по графику формируется в конкретный момент, и если обмен цен и остатков к этому моменту устарел, заказ соберётся по неверным данным. Поэтому расписание обмена и расписание формирования поставок нужно согласовать: сначала свежий обмен, потом генерация заказов. Обычно это решается порядком запуска ночных задач — обмен идёт раньше, планировщик поставок позже.

Сбойные сценарии и их обработка

Разница между демо и продакшеном — в том, как система ведёт себя, когда что-то идёт не по счастливому пути. В абонентской модели «несчастливых путей» много, и каждый нужно обработать явно.

Общий принцип обработки сбоев — «сделай видимым, не ломай молча». Любой сбой должен переводить поставку в понятный статус и уведомлять ответственного, а не тихо пропадать. Второй принцип — «не теряй намерение»: даже если цикл сорвался, график остаётся, и следующая поставка формируется штатно. Именно предсказуемое поведение при сбоях делает абонентскую модель тем, на что клиент готов положиться.

Метрики и экономика абонентской модели

Абонентские поставки — это не только удобство, но и измеримая экономика. Чтобы управлять моделью, смотрите на набор метрик, а не только на «стало удобнее».

Ключевая метрика на старте — доля непройденных оплат и то, сколько из них удаётся «вернуть» ретраями и уведомлениями. Именно здесь чаще всего утекает выручка абонентской модели: клиент никуда не уходил осознанно, просто платёж не прошёл, а система не отреагировала. Наведите порядок здесь — и удержание вырастет без всякого маркетинга.

Вторая важная метрика — доля выручки, которая приходит с абонементов. Она показывает, насколько бизнес стал предсказуемым. Растущая доля означает, что вокруг стабильного базового потока можно точнее планировать закупки, склад и денежный поток, а сезонные всплески достраивать сверху разовыми заказами.

Частые ошибки при внедрении

• Зашивают цену в шаблон поставки — после пересмотра прайса начинается отгрузка по устаревшим ценам и ручная правка сотен шаблонов.
• Смешивают график с заказом sale — долгоживущую поставку пытаются уместить в разовый заказ, теряя расписание и историю циклов.
• Не делают агент идемпотентным — повторный запуск или сбой порождает дубли заказов на один цикл.
• Молча блокируют поставку при непройденной оплате — без ретраев и уведомлений это прямой отток «по недоразумению».
• Присылают напоминание вместе с уже сформированным заказом — окно правок становится фикцией, клиент не успевает скорректировать объём.
• Не согласуют обмен с 1С и планировщик поставок — заказы формируются по устаревшим ценам и фантомным остаткам.
• Правят ядро вместо своего модуля — при обновлении платформы вся логика абонентских поставок затирается.
• Игнорируют выбытие позиций из ассортимента — шаблон продолжает заказывать снятый с продажи товар, заказ падает или собирается неполным.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность абонентских поставок перед запуском:

1. Модели определены. Зафиксированы поддерживаемые сценарии поставок и требования к графику и шаблону для каждого.
2. Сущности разделены. Шаблон и график живут отдельно от заказа sale; одна поставка порождает много заказов.
3. Шаблон без цены. Хранится состав и объём, цена подставляется на момент формирования по актуальному прайсу и условиям клиента.
4. Планировщик идемпотентен. Агент/cron ищет созревшие поставки и защищён от дублей ключом «поставка + дата цикла».
5. Оплата и сбои настроены. Рекуррент и/или авто-счёт работают, есть ретраи, статус ожидания и уведомления о неуспехе.
6. Уведомления по цепочке. Напоминание до окна правок, подтверждение, статус оплаты, отгрузка; каналы и адресация по ролям заданы.
7. Обмен с 1С согласован. Цены и остатки актуальны к моменту генерации; реализации и счета уходят обратно; порядок задач «обмен → генерация».
8. Кабинет клиента готов. Есть график, состав, история, кнопки паузы, пропуска, изменения объёма и обновления оплаты.
9. Метрики настроены. Отслеживаются доля непройденных оплат, удержание и доля выручки на абонементе.

Вывод

Регулярные и абонентские поставки превращают повторяющийся оптовый спрос в предсказуемый автоматический поток: заказ формируется по графику, оплата проходит сама, а обе стороны видят прозрачную цепочку уведомлений. На 1С-Битрикс это собирается из штатного модуля sale, агентов и обмена с 1С плюс аккуратно спроектированной бизнес-логики графиков и шаблонов. Разделите поставку и заказ, держите цену вне шаблона, сделайте планировщик идемпотентным и обработайте сбои оплаты — и абонентская модель станет тем, на что клиент готов положиться надолго, а вы получите растущее удержание и прогнозируемую выручку.