Частичные оплаты и возвраты лучше учитывать отдельными событиями, связанными с заказом. Одно поле «сумма сделки» не показывает, сколько согласовано, получено и возвращено. Для управленческой отчётности эти величины разделяют, а смысл выручки согласуют с финансовым владельцем данных.
Разведите стоимость и движение денег
Стоимость заказа отражает согласованные условия. Поступления показывают фактически полученные деньги. Возвраты уменьшают чистое поступление, но сами по себе не объясняют, изменился ли объём обязательств. Долг зависит ещё и от действующей суммы заказа и правил расчёта.
Не называйте любое поступление выручкой без определения. Признание выручки и денежный поток могут относиться к разным событиям. Здесь рассматривается проектирование управленческих данных CRM; применяемую финансовую методику утверждает соответствующий специалист компании.
Создайте модель платежного события
Для события нужны устойчивый идентификатор, заказ, тип, сумма, валюта, дата и подтверждающий источник. Для возврата сохраните связь с исходным поступлением либо объяснённую связь с заказом. Исправление ошибочного события также должно быть прослеживаемым.
Укажите систему, которая считается основной по факту оплаты, и порядок получения изменений. При повторной загрузке существующее событие обновляется по правилу, а не создаётся заново. Общие вопросы обмена рассмотрены в статье об интеграции CRM и 1С.
Разберите условный заказ по событиям
Предположим, согласованная стоимость заказа составляет 100 000 рублей. В мае поступил аванс 40 000, в июне — ещё 60 000. В июле клиенту вернули 10 000 рублей после согласованного изменения состава.
Таблицу можно прокрутить вправо →
| Событие | Сумма, рублей | Чистое накопленное поступление |
|---|---|---|
| Аванс в мае | +40 000 | 40 000 |
| Доплата в июне | +60 000 | 100 000 |
| Возврат в июле | −10 000 | 90 000 |
Если итоговая стоимость после изменения также стала 90 000 рублей, остаток к оплате равен нулю по этой условной модели. Если стоимость осталась 100 000, причина возврата и дальнейшие обязательства требуют отдельного решения. Нельзя автоматически делать одинаковый вывод только из отрицательного события.
Определите временные отчёты
Отчёт движения денег покажет суммы по датам событий: май, июнь и июль. Отчёт результата заказа может пересчитать чистые поступления по его когорте. Оба представления полезны, но отвечают на разные вопросы.
Сохраните дату факта и дату загрузки. Если возврат внесли позже, закрытый период может потребовать пересмотра согласно принятой политике. Пользователь должен видеть, почему прошлое значение изменилось, а не обнаруживать новое число без объяснения.
Проверьте сложные случаи
Включите один платёж за несколько заказов, несколько платежей одного заказа, переплату, отменённое поступление и неизвестное назначение. Для распределения общей суммы нужен явный механизм и контроль, что распределённая часть не превышает исходную.
Не считайте неизвестную связь нулевой оплатой. Покажите нераспределённые события отдельной очередью. Если суммы в разных валютах, определите правила представления и пересчёта до агрегирования. Сложение чисел без учёта валюты не даёт осмысленного финансового результата.
Примите расчёт сверкой
Сначала сравните события с финансовым источником, затем итоги по заказам и периодам. Проверьте повторную загрузку, изменение статуса и возврат после успешного закрытия сделки. Историческая продажа не должна незаметно исчезать из журнала из-за исправления текущей карточки.
Критерии приёмки: каждое событие идентифицируется, возврат объясним, суммы не дублируются, остатки воспроизводимы, нераспределённые деньги видны. После этого показатели рекламы и продаж можно строить на согласованной денежной основе, сохраняя различие между стоимостью заказа, поступлениями и принятой методикой выручки.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.