К концу месяца сервисная компания собирает абонентскую плату, дополнительные часы и согласованные скидки из нескольких таблиц. Клиент спрашивает, откуда взялась сумма. Менеджер находит другой файл с прежним тарифом, исполнитель вспоминает отменённую работу, а бухгалтерия уже получила итог.
Расчётный сервис полезен, когда каждое начисление можно восстановить по исходным событиям и действовавшим условиям. Его задача шире умножения количества на цену, но уже всей финансовой системы компании. Сначала определяют правила объёма, периода и изменений, затем решают, какой инструмент их поддержит.
Начисление, документ и оплата — разные сущности
Начисление показывает результат применения условий к подтверждённому объёму. Расчётный документ оформляет согласованный результат в принятой форме. Оплата отражает поступление денег. Эти события связаны, но не должны подменять друг друга.
Если клиент ещё не оплатил, расчёт не становится неверным. Если сумма пересчитана, прежний документ не должен незаметно менять содержание. Если поступили деньги без понятного основания, они не доказывают выполнение конкретной услуги.
Определите границу сервиса: какие вычисления он выполняет, кто согласует результат и куда передаёт данные. Требования к учётным документам и отражению операций обсуждаются с ответственными специалистами отдельно. Наличие экрана биллинга не заменяет бухгалтерскую систему.
Опишите оплачиваемую единицу
До разработки договоритесь, что считается объёмом. Для одной компании это завершённый выезд, для другой — подтверждённый час, обработанная единица или обслуживание конкретного объекта.
У события должны быть устойчивый идентификатор, клиент, объект, вид услуги, дата, количество и состояние подтверждения. Отменённая или отклонённая работа не должна попадать в расчёт только потому, что существует в журнале.
Если несколько сотрудников участвовали в одном выезде, решите, оплачивается выезд целиком или труд каждого. Если повторная работа входит в обязательства компании, определите, как её отличать от новой платной услуги. Не оставляйте эти решения на усмотрение разработчика.
Учебный пример месячного начисления
Рассмотрим вымышленную компанию обслуживания оборудования. Это пример правил, не кейс ExtentLab. По условной модели ежемесячная базовая плата составляет 30 000 рублей и включает десять подтверждённых часов стандартных работ.
В расчётном месяце подтверждены четырнадцать часов. Четыре часа сверх включённого объёма оплачиваются по 2 000 рублей: 8 000 рублей. Отдельный согласованный выезд стоит 3 000 рублей и не входит в часы. Предоставлена корректировка в пользу клиента на 2 000 рублей.
Итог: 30 000 + 8 000 + 3 000 − 2 000 = 39 000 рублей. Все суммы примера заданы в одной согласованной базе; налоговые правила здесь не рассчитываются.
В расшифровке видны десять включённых часов, четыре дополнительных, основание выезда и основание корректировки. Нельзя начислить все четырнадцать часов сверх базы: это дало бы двойной учёт включённого объёма.
Правила должны иметь версии и даты
Тариф может меняться, но прошлый расчёт должен оставаться воспроизводимым. Сохраняйте версию условий и период их применения. Одного поля «Текущая цена» в карточке клиента недостаточно.
Уточните, какая дата выбирает тариф: выполнение работы, подтверждение, начало периода или другое согласованное событие. Если условия меняются посреди месяца, нужен отдельный порядок применения базовой платы и включённого объёма.
Не придумывайте автоматическое деление по календарным дням, если стороны его не согласовали. У одной модели база неделима, у другой считается пропорционально, у третьей меняется только со следующего периода.
В первой версии можно ограничить изменения началом месяца. Это допустимое сокращение объёма проекта, если соответствует реальной работе и явно зафиксировано.
Поздние сведения и перерасчёты
После согласования результата обнаружены ещё два подтверждённых часа, относящихся к тому же периоду. По условиям примера они увеличивают дополнительный объём на два часа и сумму на 4 000 рублей. Новый итог — 43 000 рублей.
Система должна показать, что изменилось относительно 39 000 рублей: добавленные события, применённое правило и разницу. Прежний результат сохраняется. Простая перезапись суммы лишает сотрудников объяснения, почему клиент получил другое значение.
Порядок оформления и передачи корректировки зависит от состояния документов и принятого учёта. Расчётный сервис может подготовить разницу и основание, а ответственное лицо выбирает согласованный дальнейший процесс. Не следует автоматически создавать второй полный счёт вместо корректировки без определённого правила.
Повторный запуск не должен удваивать результат
Расчёт часто запускают несколько раз: после уточнения работ, исправления данных или сбоя. Повтор тех же исходных данных и условий должен давать тот же результат, а не ещё одно начисление за тот же объём.
Для этого различают предварительный расчёт, согласованную версию и переданный результат. Каждая передача имеет идентификатор, по которому принимающая система может распознать повтор. Если подтверждение обмена потерялось, оператор видит неопределённый исход и проверяет его, а не отправляет новую независимую операцию вслепую.
Корректность такого поведения проверяют отдельно. Красивый итоговый отчёт не доказывает защиту от дублей при повторном обмене.
Какие условия часто забывают
Составьте список исключений до оценки разработки:
- неполный месяц обслуживания;
- приостановка услуги по согласованному основанию;
- работа отменена после подтверждения;
- включённый объём не использован полностью;
- объём переносится между объектами или периодами;
- минимальная плата и округление;
- индивидуальная скидка;
- исправление клиента или объекта у события.
Для каждого нужен пример с ожидаемым результатом. Особенно важно указать порядок округления: по строке, по группе или после суммирования. Эти варианты могут давать разные суммы.
Если условия ещё спорные, пометьте их как нерешённые. Программа не устранит разногласие, а лишь будет регулярно воспроизводить выбранную кем-то трактовку.
Где достаточно готового инструмента
При простой базе и нескольких дополнительных позициях расчёт может поддерживаться действующей учётной или сервисной системой. Сначала проверьте настройку тарифов, историю условий и расшифровку.
Заказной сервис стоит обсуждать, когда сложность возникает из подтверждённых событий разных систем, особого включённого объёма, нескольких уровней правил или необходимости воспроизводить прошлые расчёты. Иногда разумнее выделить только расчётный модуль, оставив документы и платежи в действующем учёте.
Сравнивайте решения на одном месяце с перерасчётом. Проверьте не только итог, но и возможность объяснить каждую строку, повторить вычисление и найти основание изменения. Количество поддерживаемых тарифов в рекламе не заменяет эту проверку.
Первая версия и её приёмка
Ограничьте запуск одним видом услуги, одной валютой и несколькими утверждёнными моделями условий. Нужны импорт подтверждённого объёма, версии правил, предварительный расчёт, согласование, передача результата и корректировки.
Подготовьте небольшой независимый набор ожидаемых сумм. Включите нулевой объём, точное попадание в лимит, превышение, отменённую работу, позднее событие и повтор обмена. Расчёт должен совпасть не только в общей сумме, но и по составу строк.
Формулировать такие проверки поможет статья о критериях приёмки. В ExtentLab можно принести обезличенное начисление за месяц и историю одного перерасчёта. На этом материале можно обсудить применимость готовых средств, границы отдельного расчётного сервиса и неизвестные, влияющие на оценку разработки.