Часто в работе системного администратора или программиста 1С возникает задача выяснить, кто и когда изменил данные в информационной базе. Типичный пример: у клиента внезапно сменился основной менеджер или торговый представитель, и необходимо найти «автора» этого изменения. Рассмотрим подробно, как правильно использовать Журнал регистрации для этих целей, какие подводные камни существуют в конфигурации Управление торговлей 11.4 и почему стандартный поиск по наименованию часто не дает результатов.
Прежде всего, проанализируем структуру данных в 1С:Управление торговлей 11. В этой конфигурации разделены понятия управленческого учета (справочник Партнеры) и юридического учета (справочник Контрагенты). Это критически важный момент для поиска в журнале регистрации, особенно если вам необходимо реализовать поиск по ИНН и рабочему наименованию контрагента в справочнике «Партнеры», так как в последнем реквизит ИНН отсутствует.
Разберем, почему это важно:
Справочник.Контрагенты, а менеджер был изменен в карточке партнера, система выдаст «0 результатов».Рассмотрим пошагово, как эффективно найти событие изменения, если стандартный поиск не помогает. Совместно пройдем путь от простого фильтра к глубокому анализу.
Шаг 1: Определение метаданных
Выясним, какой именно объект изменяется. В случае с торговыми представителями в УТ 11.4 нам нужно смотреть события по справочнику Партнеры. В фильтре журнала регистрации (раздел «События») выберем «Данные — Изменение», а в поле «Метаданные» укажем Справочник.Партнеры.
Шаг 2: Поиск по уникальному идентификатору (GUID)
Поиск по текстовому представлению («Иванов», «Сидоров») крайне ненадежен. Если объект был переименован, журнал может не найти его по старым записям. Проанализируем ситуацию: лучше всего найти GUID партнера и вставить его в поле поиска «Данные». Если вы не хотите писать код, можно использовать готовое решение для получения ГУИД объекта любой конфигурации.
Для получения GUID программно можно использовать следующий код:
СсылкаНаОбъект = Справочники.Партнеры.НайтиПоНаименованию("Иванов");
УникальныйИдентификатор = Строка(СсылкаНаОбъект.УникальныйИдентификатор());
Сообщить(УникальныйИдентификатор);
Полученную строку идентификатора вставляем в фильтр журнала регистрации. Это гарантирует, что мы увидим все записи, связанные именно с этим элементом. Для удобства работы с большим объемом данных может пригодиться журнал регистрации по объекту за последние 3 года как печатная форма, что значительно упрощает аудит.
Если мы настроили фильтры правильно, но результатов всё равно нет, проанализируем техническое состояние самого журнала регистрации. Рассмотрим основные причины «пустоты» логов:
1Cv8Log). При переустановке ОС или сервера 1С в 2022 году, как в нашем случае, старые файлы могли быть просто удалены или не перенесены в новую директорию..lgd. Если при переносе базы формат конвертировался, часть истории могла быть обрезана.Разберем ситуацию: журнал регистрации фиксирует только факт изменения (событие «Изменено»), но он не показывает, что именно изменилось внутри объекта. Вы не увидите в ЖР, что менеджер «Сидоров» превратился в менеджера «Петрова».
Для решения таких задач мы рекомендуем использовать типовой механизм Версионирования объектов или специализированный анализ внесенных изменений в справочники, который позволяет просматривать правки реквизитов даже в последних версиях систем (УТ 11.5, КА 2.5, ERP 2.5).
Партнеры и Контрагенты (режим «При записи»).После этого в карточке клиента появится кнопка «История изменений», где можно провести детальный анализ работы пользователей в 1С, наглядно сравнить две версии объекта и увидеть, кто именно изменил реквизит ОсновнойМенеджер.
Если вы подозреваете, что данные были изменены, но ЖР молчит, проанализируем дополнительные варианты:
1. Групповое изменение реквизитов. Проверьте, не запускалась ли обработка «Групповое изменение реквизитов». В журнале регистрации такие события будут выглядеть как массовое изменение объектов под одной учетной записью за короткий промежуток времени. В этом случае полезна статистика по документам пользователя с версионированием по дате, помогающая увидеть активность конкретных сотрудников.
2. Тестовое изменение. Проведем эксперимент под своей учетной записью: изменим менеджера у любого тестового партнера и сразу проверим журнал регистрации. Если запись появилась — значит, механизмы логирования работают исправно, и искомое изменение действительно произошло либо до начала ведения логов, либо объект был изменен напрямую в обход стандартных механизмов 1С (например, через SQL-запрос, хотя это крайне не рекомендуется).
3. Проверка самописных модулей. Выясним, как работает ваш самописный модуль по дебиторке. Если он использует Регистры сведений для хранения связей «Клиент — Менеджер», то искать нужно изменения не в справочниках, а в соответствующих регистрах. В фильтре журнала регистрации укажите РегистрСведений.ИмяВашегоРегистра.
Подводя итог, отметим: эффективный аудит в 1С требует комплексного подхода — сочетания правильных фильтров по GUID в журнале регистрации и включенного версионирования для критически важных данных.