Рассмотрим весьма распространенную ситуацию: кто-то из пользователей внес изменения в уже проведенные кассовые документы (например, изменил суммы), и теперь нам необходимо выяснить, какие именно значения там были изначально. Проанализируем, почему типовой журнал регистрации не дает ответа на этот вопрос, и разберем по шагам, как правильно настроить отслеживание изменений в базах на платформе 1С.
Если мы заглянем в стандартный журнал регистрации 1С, то увидим лишь сам факт события: кто, когда и с какого компьютера создал, изменил или провел объект. Типовой механизм не записывает состояния конкретных реквизитов (например, что сумма изменилась с 10 000 на 5 000).
Данные в информационной базе при записи физически перезаписываются. Вытащить предыдущее значение исключительно из стандартного журнала регистрации технически невозможно, так как эта информация там попросту не хранится.
Выясним причину, по которой мы не можем восстановить данные «на лету». Если история изменений заранее не велась, восстановить предыдущую сумму из самой базы 1С уже нельзя. В этом случае единственным реальным способом выяснить, какая сумма была в документах до редактирования, является разворачивание резервной копии базы данных (бэкапа), которая была сделана до момента изменения документа. Только так мы сможем посмотреть старые значения.
Чтобы избежать подобных проблем в будущем, включим механизм Библиотеки стандартных подсистем (БСП) под названием ВерсионированиеДанных. Разберем по шагам, как это сделать в конфигурации «Бухгалтерия предприятия КОРП»:
Обратите внимание: типовое версионирование часто сохраняет полную копию документа в виде XML-файла при каждом его изменении. Если документы «тяжелые» или их много, информационная база может начать быстро расти в объеме. Поэтому настраивать версионирование следует точечно.
Посмотрим на более современную альтернативу. Начиная с версии платформы 8.3.11, пользователям доступен глубокий платформенный механизм — ИсторияДанных. В отличие от версионирования БСП, платформенная история работает на уровне ядра 1С и хранит только «дельту» — то есть фиксирует исключительно те реквизиты, которые были изменены.
Это значительно экономит место на жестком диске и позволяет системе работать быстрее. Выбор между версионированием БСП и Историей данных зависит от конкретной архитектуры вашей конфигурации и требуемой детализации отчетов.
Разберем вариант, когда нам не хочется перегружать базу стандартными тяжелыми механизмами логирования. На профильных ресурсах существует множество готовых расширений и конфигураций (например, «Внешний журнал регистрации»).
Они работают по следующему принципу программного сравнения: в момент записи документа (обычно в обработчике ПередЗаписью) система сравнивает старую версию документа, которая хранится в базе, и новую версию, введенную пользователем. Рассмотрим пример логики, по которой работают такие расширения:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если Не ЭтотОбъект.ЭтоНовый() Тогда
СтарыеДанные = ЭтотОбъект.Ссылка;
Если ЭтотОбъект.СуммаДокумента <> СтарыеДанные.СуммаДокумента Тогда
// Формируем запись в кастомный регистр сведений или пишем в текстовый лог:
// "Реквизит Сумма изменен с " + СтарыеДанные.СуммаДокумента + " на " + ЭтотОбъект.СуммаДокумента
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Преимущества таких расширений: они не требуют снятия базы с поддержки, позволяют гибко отслеживать только нужные документы и конкретные реквизиты, не перегружая базу полным версионированием. Однако следует помнить, что они начнут собирать данные только после их установки, и прошлые изменения, сделанные до внедрения расширения, они не вернут.