В процессе ведения учета в программе 1С:Бухгалтерия (и других конфигурациях на платформе 1С:Предприятие 8.3) нередко возникает ситуация, когда нумерация документов внезапно сбивается. При детальном анализе выясняется, что кто-то из пользователей создал или провел документ (например, Расходный кассовый ордер) задним числом — скажем, три месяца назад. При этом в самой системе дата документа, его период в регистре бухгалтерии и момент времени указывают на ту самую «прошлую» дату. Стандартные отчеты не показывают, когда физически была совершена эта операция и кто за ней стоит.
В этой статье мы подробно разберем, как найти виновника и выяснить реальные дату и время проведения документа. Мы рассмотрим пять надежных методов решения этой задачи: от стандартных инструментов до глубокого анализа уникальных идентификаторов в базе данных.
Самый простой, быстрый и штатный способ расследовать инцидент — воспользоваться системным Журналом регистрации. Но если просто открыть его и прокрутить до даты документа (трехмесячной давности), мы ничего не найдем. Документ был записан недавно, а значит, и искать событие нужно в логах за последние дни.
Рассмотрим по шагам, как правильно настроить фильтрацию в Журнале регистрации, чтобы быстро локализовать проблему:
Расходный кассовый ордер и укажем конкретную ссылку на наш проблемный документ.Данные.Добавление (создание документа), Данные.Изменение (редактирование) и Данные.Проведение.После применения отбора система покажет точные записи. Мы увидим колонку Дата/Время (это реальное астрономическое время транзакции на сервере), колонку Пользователь (имя учетной записи, под которой вошли в систему) и колонку Событие, отражающую суть операции.
Важное предупреждение: Журнал регистрации может быть очищен администратором или злоумышленником для скрытия следов. Если вы не обнаружили записей, проверьте на сервере наличие архивных файлов журнала регистрации (файлы формата .lgp или база данных SQLite .lgd в каталоге srvinfo вашего сервера 1С).
Что делать, если Журнал регистрации был очищен, урезан или отключен? Существует продвинутый и очень элегантный способ, которым пользуются опытные программисты. Мы можем извлечь реальное время создания ссылки на документ прямо из его уникального идентификатора (GUID/UUID).
Платформа 1С по умолчанию генерирует идентификаторы по стандарту RFC 4122 (Version 1, time-based). Структура такого идентификатора содержит в себе точное количество 100-наносекундных интервалов, прошедших с начала Григорианского календаря (с 15 октября 1582 года). Зная это, мы можем дешифровать временную метку.
Проанализируем алгоритм и напишем код, который позволит извлечь эту информацию. Нам понадобится консоль кода или внешняя обработка:
Функция ПолучитьРеальнуюДатуИзСсылки(СсылкаНаОбъект) Экспорт
УИД = Строка(СсылкаНаОбъект.УникальныйИдентификатор());
// Очищаем строку УИД от дефисов
СтрокаУИД = СтрЗаменить(УИД, "-", "");
// Проверяем версию UUID. В 1С версия v1 должна содержать единицу в определенной позиции
Если Сред(СтрокаУИД, 13, 1) <> "1" Тогда
ВызватьИсключение "Идентификатор документа не относится к типу Time-Based (v1). Извлечь дату невозможно.";
КонецЕсли;
// Перегруппировываем символы для получения шестнадцатеричного представления таймстемпа
// Берем 3-ю часть (символы 14-16), затем 2-ю часть (символы 9-12), и в конце — 1-ю часть (символы 1-8)
ТаймстемпHEX = Сред(СтрокаУИД, 14, 3) + Сред(СтрокаУИД, 9, 4) + Лев(СтрокаУИД, 8);
// Переводим HEX-строку в десятичное число
ЧислоИнтервалов = HexToDec(ТаймстемпHEX);
// Переводим 100-наносекундные интервалы в секунды
ВсегоСекунд = ЧислоИнтервалов / 10000000;
// Начальная точка отсчета по стандарту RFC 4122 — 15 октября 1582 года
ДатаНачала = Дата(1582, 10, 15, 0, 0, 0);
// Рассчитываем итоговую дату по UTC
ДатаUTC = ДатаНачала + ВсегоСекунд;
// Добавляем смещение вашего часового пояса (например, +3 часа для Москвы)
СмещениеВСекундах = 3 * 3600;
Возврат ДатаUTC + СмещениеВСекундах;
КонецФункции
Функция HexToDec(Знач HexЗначение)
Разрядность = СтрДлина(HexЗначение);
Результат = 0;
Для Позиция = 1 По Разрядность Цикл
Символ = ВРег(Сред(HexЗначение, Позиция, 1));
ЗначениеСимвола = Найти("0123456789ABCDEF", Символ) - 1;
Если ЗначениеСимвола < 0 Тогда
Продолжить;
КонецЕсли;
Результат = Результат * 16 + ЗначениеСимвола;
КонецЦикла;
Возврат Результат;
КонецФункции
Ограничения этого метода:
Если в вашей информационной базе включена встроенная подсистема версионирования БСП (Библиотеки стандартных подсистем), то задача решается буквально в несколько кликов с абсолютной точностью.
Посмотрим, как проверить, ведется ли история изменений для кассовых документов:
Расходный кассовый ордер. Там должно быть указано версионирование (например, "Версионировать при записи" или "При проведении").Если версионирование включено, мы можем открыть сам документ РКО, нажать на кнопку Еще в правом верхнем углу формы документа и выбрать пункт История изменений. Система покажет подробную таблицу:
Обратите внимание: Если эта настройка была выключена, то включать её сейчас для расследования прошлого инцидента бесполезно — история изменений начинает записываться только с момента включения опции.
В типовой конфигурации 1С:Бухгалтерия 3.0 на уровне метаданных практически у каждого документа присутствует реквизит Ответственный (в некоторых других конфигурациях он называется Автор или Создал). Этот реквизит автоматически заполняется при создании документа текущим авторизованным пользователем.
Рассмотрим, как его проверить, если визуально на форме документа вы его не видите:
Расходный кассовый ордер.Ответственный (или Автор) и установим напротив него флажок видимости, после чего нажмем ОК. Поле появится на форме.Ответственный и сделаем отбор по нашему документу.Предостережение: Реквизит Ответственный обычно доступен для редактирования пользователям с определенными правами. Нарушитель мог вручную изменить это поле, выбрав другого сотрудника, чтобы отвести от себя подозрения. На 100% доверять этому реквизиту в спорных ситуациях нельзя.
В самых критических ситуациях, когда Журнал регистрации очищен, версионирование выключено, а реквизит Ответственный переписан, на помощь приходит анализ резервных копий базы данных. Этот метод требует времени, но гарантирует результат.
Проанализируем стратегию поиска методом «двоичного поиска» (дихотомии) по цепочке бэкапов:
Для оперативного поиска виновных всегда в первую очередь используйте Журнал регистрации с точечным отбором по конкретному документу и без ограничения периода. Чтобы защитить базу от подобных инцидентов в будущем, мы рекомендуем заранее выполнить следующие действия: