Часто перед программистами или администраторами базы данных встает задача отфильтровать кассовые чеки по времени их пробития на кассе. Например, необходимо получить список всех чеков за две недели, которые были оформлены строго после 17:00. При попытке получить время документа стандартными средствами 1С, мы можем обнаружить странную картину: время чеков идет с разницей ровно в одну секунду (например, 12:57:02, 12:57:03, 12:57:04 и так далее). Очевидно, что физически кассиры не могли набивать чеки ежесекундно с такой математической точностью.
Давайте подробно разберем эту ситуацию, выясним причину такого поведения платформы 1С 7.7 и проанализируем способы получения реального времени пробития чеков.
Проанализируем механику работы 1С с документами при массовой загрузке. Такая картина со временем типична для пакетной загрузки чеков из касс, работающих в режиме Offline, или из сторонних фронт-офисных программ (например, Frontol). Чеки в таких системах накапливаются локально на кассе, а затем целым пакетом (потоком) выгружаются в учетную систему.
При массовом автоматическом программном создании и проведении документов платформа 1С 7.7 применяет встроенный защитный механизм. Система автоматически сдвигает время каждого последующего загружаемого документа на 1 секунду. Это заложено в архитектуру системы для того, чтобы:
Именно поэтому стандартная дата и время документа в 1С не отражают реального времени операции на кассе. Использовать эти данные для аналитики моветон, так как документ физически может быть "подвинут" по оси времени куда угодно при перепроведении или восстановлении последовательности.
Важно понимать, что физически реальное время пробития чека на кассе не теряется безвозвратно. Если чеки загружаются в 1С через обмен, то в исходном файле выгрузки из контрольно-кассовой машины (обычно это текстовый файл, лог транзакций или Z-отчет в форматах АТОЛ или Штрих-М) всегда присутствует отдельная колонка с точным фактическим временем совершения операции.
Также точное время фиксируется в данных Оператора Фискальных Данных (ОФД), куда касса передает электронные чеки в режиме онлайн.
Если перед нами стоит разовая задача (например, собрать статистику за прошлые две недели), и чеки уже находятся в базе с искаженным временем, не стоит пытаться извлечь время из самой 1С — его там просто нет. Выполним следующие шаги:
Для постоянной работы этот метод неудобен, поэтому рассмотрим способы автоматизации.
Чтобы в дальнейшем мы могли без проблем строить отчеты и фильтровать чеки по времени, нам потребуется внести небольшие изменения в конфигурацию и обработку загрузки данных. Разберем два основных варианта.
Вариант А: Добавление специального реквизита (Безопасный и предпочтительный метод)
Самый надежный способ — сохранять реальное время кассы как справочную информацию, не вмешиваясь в стандартную ось времени документов 1С.
ВремяЧека (тип: Строка, длина 8 символов).
ДокЧек = СоздатьОбъект("Документ.ЧекККМ");
ДокЧек.Новый();
// ... заполнение остальных реквизитов ...
// Записываем реальное время из файла обмена
ДокЧек.ВремяЧека = ТекстВремяИзФайла;
ДокЧек.Записать();
Теперь мы сможем легко фильтровать документы, обращаясь к реквизиту ВремяЧека, при этом логика проведения документов и Точка Актуальности останутся в безопасности.
Вариант Б: Установка реального времени документа (Сложный метод)
Если бизнес-логика требует, чтобы сами документы стояли на оси времени 1С точно в момент пробития на кассе, можно применить встроенный метод УстановитьВремя(). Однако этот подход требует осторожности.
В коде обработки при создании нового документа мы можем распарсить время из файла обмена на часы, минуты и секунды, а затем передать их в метод платформы:
// Предположим, мы получили значения из файла
Часы = 17;
Минуты = 35;
Секунды = 15;
ДокЧек = СоздатьОбъект("Документ.ЧекККМ");
ДокЧек.Новый();
ДокЧек.УстановитьВремя(Часы, Минуты, Секунды);
// ... заполнение реквизитов
ДокЧек.Записать();
Важно: При использовании метода УстановитьВремя внутри дня, особенно если документы загружаются "задним числом" (прошлым временем относительно текущей ТА), платформа 1С 7.7 будет вынуждена переносить Точку Актуальности назад и пересчитывать итоги. При большом потоке чеков это может критически замедлить работу системы и процесс загрузки обмена. Именно поэтому вариант с отдельным реквизитом (Вариант А) является более предпочтительным для высоконагруженных баз.
Подводя итог, помните: стандартное время документа в 1С при пакетном обмене — это технический реквизит для поддержания ссылочной целостности и последовательности проведения, а не хронометраж работы кассира. Для аналитики продаж всегда опирайтесь на данные исходного кассового ПО, сохраняя их в отдельные текстовые или числовые реквизиты документа.