Расхождения отчётов по дням часто возникают из-за разных часовых поясов и разных временных полей. Одна система группирует оплату по моменту события, другая — по времени загрузки или местным суткам пользователя. Для сверки нужно закрепить единый смысл даты, способ хранения времени и календарь каждого управленческого отчёта.
Выберите событие, которое измеряете
У сделки есть время создания, изменения этапа, выставления счёта и получения оплаты. Они могут относиться к разным дням даже при одинаковом часовом поясе. Поэтому сначала согласуйте, какое событие входит в показатель.
Отдельно храните время возникновения и время поступления в аналитическую систему. Ночная загрузка вчерашней оплаты не превращает её в сегодняшнюю продажу. Задержку поступления можно измерять самостоятельным показателем, сохраняя исходную бизнес-дату.
Различайте момент и календарную дату
Момент времени можно привести к общей шкале и затем показать в нужном часовом поясе. Календарная дата, например согласованный день доставки без часа, имеет другой смысл. Присвоение ей полуночи с последующим пересчётом способно сдвинуть её на соседний день.
В схеме данных полезно явно разделить поля «момент оплаты», «плановая дата доставки» и «рабочая смена». Названия вроде date1 и date2 скрывают различие и создают ошибки на этапе построения отчёта. Правило преобразования должно находиться в описании источника, а не только внутри SQL.
Зафиксируйте границы периода
Для отчётного дня удобно использовать интервал от начала суток включительно до начала следующих суток исключительно. Это позволяет избежать двойного учёта событий ровно на границе. Аналогичное правило применяют к неделям и месяцам.
Укажите, в чьём календаре считаются сутки: центрального офиса, филиала или места исполнения заказа. Для сводного отчёта можно выбрать единый пояс, но локальные оперативные отчёты могут законно использовать другой. В заголовке или паспорте метрики это различие должно быть видно.
Условный пример вечерней оплаты
Предположим, событие произошло в 22:30 UTC. В московском календаре это уже 01:30 следующего дня. Один отчёт группирует исходное UTC-время, другой предварительно переводит его в московское. Оба показывают одинаковую оплату, но в разных дневных строках.
Если файл поступил ещё позднее, добавляется третья дата — загрузки. Проверка за отдельный день покажет расхождение, а сумма за более широкий период может совпасть. Это важный диагностический признак, однако он не доказывает причину без просмотра исходных временных полей конкретной операции.
Учитывайте рабочее время отдельно
Время нахождения на этапе можно считать в календарных или рабочих часах. Для рабочего расчёта нужен календарь подразделения, праздники, график смен и правило пауз. Простое вычитание дат не отвечает на вопрос, сколько рабочего времени ждал клиент.
Не меняйте исторический календарь молча, если это пересчитывает показатели прошлых месяцев. Сохраняйте версию правил и объяснение изменения. Для руководителя важно понимать, выросла ли реальная задержка или изменился способ её измерения. Связанные показатели рассмотрены в статье об отчёте руководителя продаж.
Проверка перед публикацией отчёта
Подготовьте операции до полуночи, ровно на границе, после неё и с задержанной загрузкой. Добавьте календарную дату без времени и пример из другого подразделения. Для каждой строки вручную определите ожидаемый отчётный день.
Приёмка требует совпадения строк и итогов, отсутствия двойного учёта на границах и явного обозначения часового пояса. Если источник передаёт время без зоны, неопределённость следует устранить в договоре данных; угадывание по настройкам компьютера аналитика не даёт устойчивого результата.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.