Тарифы, подписки и счета в B2B SaaS: чтобы биллинг не стал отдельным проектом
Тариф клиента, его лимиты и счёт считаются из одного источника, а смена плана не ломает уже выставленный счёт
Проверяется: контрольные сценарии смены тарифа и сверка со счетами
SaaS и продуктыРаботаем по NDA
Продукт продаётся по подписке организациям. Сначала хватало двух тарифов, потом появились индивидуальные скидки, дополнительные пользователи, лимиты по операциям и отсрочки. Тарифы лежат в таблице у менеджера, счета и акты выставляет бухгалтерия вручную, а лимиты в продукте включают и выключают по просьбе в чате.
Что съедает срок и бюджет на самом деле
Биллинг выглядит простым, пока не начинаются исключения. Вот где он ломается.
Нет единого источника тарифа
продукт, менеджер и бухгалтерия знают три разные версии условий клиента. Спор о сумме тогда решается перепиской.
Смена тарифа посреди периода
нужно решить, как пересчитывать остаток, и записать правило. Без правила каждый случай считают руками.
Счета и акты для юрлиц
документы, нумерация и закрывающие бумаги регулируются требованиями учёта. Система должна готовить данные, а выпуск и подпись остаются в учётной системе.
Лимиты ломают пользователей
отключение при превышении без предупреждения вызывает обращения. Нужны предупреждения, льготный период и журнал решений.
Ограничение, которое определяет решение
Бухгалтерский и налоговый учёт ведёт учётная система, а не продукт: счета, акты и документы формируются в 1С или другой системе, продукт передаёт туда данные о тарифе и использовании. Приём оплаты идёт через уже подключённый у вас эквайринг или банковские платежи. Мы не принимаем платежи от вашего имени.
Как проверить, что работа сделана
Контрольные сценарии: набор заранее записанных случаев (смена тарифа в середине периода, добавление пользователя, превышение лимита, возврат), для каждого указана ожидаемая сумма, и система считает ровно так.
Сверка со счетами: за закрытый период суммы в продукте и в учётной системе сравниваются по клиентам, расхождения разбираются по каждому.
Поведение лимитов: при превышении клиент получает предупреждение, льготный период и запись в журнал, а не молчаливое отключение.
О чём спросить любого подрядчика
- Где хранится тариф клиента и кто его меняет.
- Как считается смена плана в середине периода и где это записано.
- Какие данные уходят в учётную систему и как сверяются суммы.
- Что происходит при превышении лимита.
- Как заводятся индивидуальные условия, не превращаясь в код.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Инвентаризация условийСобираем действующие тарифы и исключения по клиентам. Результат: реестр условий и список правил, которые стали исключениями.
- Модель тарифаОписываем тарифы данными, а не кодом: план, лимиты, надбавки, скидки, периоды. Результат: схема и правила пересчёта.
- Учёт использованияСчитаем операции и пользователей, показываем клиенту остаток лимитов. Результат: счётчики на стенде.
- Передача в учётНастраиваем выгрузку в 1С и сверку. Результат: протокол сверки за период.
- Пробный период с одним клиентомВключаем на нескольких клиентах, смотрим расхождения, расширяем. Передаём код и регламент.
Как это обычно устроено внутри
Типовая схема: тарифы и условия клиентов хранятся данными с датами действия, события использования пишутся в журнал, расчёт периода воспроизводим из журнала. В учётную систему по расписанию уходят агрегаты, обратно приходит статус оплаты. Лимиты проверяются на сервере с мягким порогом и предупреждением.
- PostgreSQL
- Журнал событий
- HTTP-сервисы 1С
- REST API
- Очередь задач
- Автоматические тесты
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.