Как проверить в 1С, когда создан документ

Задача узнать, когда именно был создан документ в 1С, возникает регулярно: при разборе расхождений в учёте, проверке действий сотрудников, аудите перед закрытием периода или расследовании ошибок в проводках. Проблема в том, что дата документа, которая отображается в списке, — это не дата создания, а учётная дата, которую пользователь может менять вручную. Реальный момент создания хранится иначе, и способ его узнать зависит от конфигурации и настроек базы.

В типовых и самописных конфигурациях доступно несколько методов: стандартные реквизиты в управляемых формах, журнал регистрации, механизм версионирования объектов, технический журнал и программные запросы. Ниже разобран каждый способ с условиями применения и ограничениями, чтобы вы могли выбрать рабочий вариант под свою ситуацию.

Почему дата документа не равна дате создания

В 1С у любого документа есть стандартный реквизит «Дата», который определяет позицию документа в учёте: по нему строятся проводки, итоги, последовательности. Пользователь вправе указать любую дату — например, провести реализацию «задним числом» в прошлом месяце. Поэтому по этому полю невозможно понять, когда документ физически появился в базе.

Момент фактического создания — это отдельная информация. В платформе она фиксируется в журнале регистрации (событие добавления объекта), а в типовых конфигурациях на БСП — в механизме версионирования объектов, если он включён. В некоторых конфигурациях дополнительно есть служебные реквизиты вроде «Дата создания» или «Автор», но их наличие зависит от конкретной конфигурации.

Способ 1. История изменений (версионирование объектов)

В конфигурациях на базе Библиотеки стандартных подсистем (УТ 11, ERP, БП 3.0, ЗУП и других) есть механизм версионирования. Если он включён для нужного вида документов, откройте документ и найдите команду «История изменений» — обычно в меню «Ещё» формы документа или в панели навигации. В таблице версий первая строка — это и есть момент создания: видно дату, время и пользователя, который создал документ.

Если команды «История изменений» нет, проверьте настройки: Администрирование → Общие настройки → История изменений (в разных конфигурациях путь может немного отличаться). Там включается версионирование по видам объектов. Важный нюанс: механизм начинает фиксировать версии только с момента включения, задним числом историю по старым документам он не восстановит.

1. 1
   Откройте нужный документ в базе
2. 2
   В меню «Ещё» выберите «История изменений»
3. 3
   Найдите самую первую (нижнюю) версию в списке
4. 4
   Посмотрите колонки «Дата» и «Пользователь» — это момент создания и автор
5. 5
   Если команды нет — включите версионирование в настройках администрирования

Способ 2. Журнал регистрации

Журнал регистрации — штатный инструмент платформы, который работает всегда, независимо от настроек конфигурации. Откройте его через Администрирование → Обслуживание → Журнал регистрации (в режиме предприятия) или через конфигуратор: Администрирование → Журнал регистрации. Нужны права администратора или права на просмотр журнала.

Настройте отбор: укажите период, событие «Данные. Добавление» и при необходимости пользователя. В колонке «Данные» будет представление созданного объекта. Минус способа — искать конкретный документ среди тысяч записей неудобно, а представление объекта в журнале не всегда позволяет однозначно его идентифицировать. Поэтому журнал регистрации эффективен, когда вы знаете примерное время создания или пользователя.

Учтите, что журнал регистрации имеет ограниченную глубину хранения и может сворачиваться (настраивается в параметрах). Если база ведётся давно и журнал периодически очищался, события создания старых документов могут быть уже удалены.

Способ 3. Стандартные реквизиты и запросы

В ряде конфигураций у документов есть явные служебные реквизиты: «Автор», «Дата создания», «Кто создал». Проверьте форму документа — иногда эти поля скрыты и доступны через «Ещё» → «Изменить форму». Если реквизит существует, его можно вывести в список документов через настройку списка или посмотреть в универсальном отчёте.

Для массовой проверки удобен запрос в консоли запросов (если она есть в базе или у вас есть доступ к конфигуратору). Пример простого запроса по реквизиту автора:

ВЫБРАТЬ
	Реализация.Ссылка КАК Документ,
	Реализация.Дата КАК ДатаДокумента,
	Реализация.Автор КАК Автор
ИЗ
	Документ.РеализацияТоваровУслуг КАК Реализация
ГДЕ
	Реализация.Дата МЕЖДУ &Начало И &Конец

Если явного реквизита даты создания нет, программно можно обратиться к версионированию (регистр сведений «Версии объектов») — там хранятся дата и автор каждой версии, включая первую. Это самый надёжный программный источник при включённом версионировании.

Способ 4. Косвенные признаки, когда точных данных нет

Если версионирование выключено, а журнал регистрации очищен, точное время создания восстановить невозможно. Но можно сузить диапазон по косвенным признакам. Номер документа присваивается в момент записи: документы с соседними номерами обычно созданы близко по времени, и по документам с известной историей можно оценить границы периода.

Дополнительные зацепки: связанные объекты (счёт-фактура, созданный на основании реализации, появился не раньше неё), комментарии пользователей, данные обменов с другими системами, где фиксируется время выгрузки. В файловых базах время модификации файла базы ничего не скажет о конкретном документе, а вот в клиент-серверном варианте технический журнал СУБД иногда позволяет администратору восстановить хронологию — но это задача для специалиста, а не для пользователя.

Как настроить контроль на будущее

Чтобы вопрос «когда создан документ» больше не был проблемой, включите версионирование для ключевых видов документов: реализации, поступления, кассовые и банковские документы, начисления зарплаты. Это делается в разделе администрирования и не требует доработок конфигурации в типовых решениях на БСП.

Дополнительно проверьте настройки журнала регистрации: уровень регистрации событий и политику хранения. Для баз с повышенными требованиями к аудиту имеет смысл настроить регулярную выгрузку журнала в отдельное хранилище, чтобы свёртка рабочего журнала не уничтожала историю. Также полезно ограничить права на изменение документов прошлых периодов через даты запрета изменения данных — это снизит количество ситуаций, где документ появляется «задним числом» незаметно для учёта.

Типичные ошибки и ограничения

Самая частая ошибка — принимать дату документа за дату создания и делать выводы о действиях сотрудника на этом основании. Второй типичный промах — искать историю изменений там, где версионирование никогда не включалось, и считать отсутствие записей доказательством, что документ «не менялся». Отсутствие версий означает лишь отсутствие наблюдения.

Ещё одна ловушка — работа с копиями баз. Если вы разбираете ситуацию в тестовой копии, сделанной позже интересующего периода, журнал регистрации в копии может отличаться от рабочей базы. Всегда проверяйте данные аудита именно в продуктивной базе или в её актуальной резервной копии за нужный период.

Частые вопросы