← На главную

В процессе разработки систем аудита или логирования изменений в 1С:Предприятие 7.7 перед программистами часто встает задача идентификации полей метаданных. В отличие от современных версий платформы, где существуют уникальные идентификаторы (GUID), архитектура «семерки» опирается на иерархию имен в файле 1Cv7.MD. Рассмотрим подробнее, как получить доступ к идентификаторам реквизитов и организовать систему контроля изменений.

Понимание архитектуры метаданных в 1С 7.7

Важно понимать, что штатная модель 1С 7.7 не предоставляет прямого метода для вывода «ID» реквизита в коде встроенного языка. Система оперирует именами, заданными в конфигураторе. Однако, если задача требует создания системы контроля версий данных, отличной от штатного журнала регистрации, нам необходимо выйти за рамки стандартных возможностей.

Использование библиотеки 1C++

Наиболее профессиональным и надежным способом работы с метаданными является использование внешней компоненты 1CPP. Она предоставляет объект MetaDataWork, который позволяет программно анализировать структуру конфигурации в памяти.

Разберем, как это работает на практике:

1. Подключите компоненту 1CPP к вашей конфигурации.
2. Инициализируйте объект для работы с метаданными.
3. Используйте методы этого объекта для перебора справочников и их реквизитов.

Этот метод предпочтителен тем, что вам не нужно вручную анализировать текстовые файлы. 1CPP дает возможность обращаться к метаданным динамически, что значительно упрощает разработку универсальных отчетов и инструментов контроля.

Анализ файла метаданных через GComp

Если задача носит разовый характер или требует статического анализа структуры, мы рекомендуем использовать утилиту gcomp. Это стандарт де-факто для работы с файлами 1Cv7.MD.

Шаги по работе с gcomp:

1. Декомпилируйте файл 1Cv7.MD в текстовый вид с помощью gcomp.
2. Полученный текстовый файл представляет собой полное описание метаданных.
3. Найдите нужный справочник и его реквизит в этом дереве. Вы увидите внутренние идентификаторы, которые движок 1С использует для связи данных.

Такой подход полезен при разработке внешних парсеров, которые могут считывать структуру базы и строить на ее основе таблицы соответствия для вашего справочника «ИсторияРеквизитов».

Рекомендации по реализации логирования

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

• Производительность: Запись данных в процедуре ПриЗаписи может значительно замедлить работу пользователей. Если база данных интенсивно используется, лучше рассмотреть вариант записи логов через внешние компоненты или триггеры на уровне SQL-сервера.
• Необходимость данных: Анализируйте, действительно ли нужно хранить историю для каждого реквизита. Опыт показывает, что часто полезнее логировать только критически важные изменения (например, ИИН, ФИО, банковские счета), используя для этого Журнал Регистрации или специализированные системы контроля прав доступа.
• Альтернативный метод: Для идентификации объектов можно использовать метод ЗначениеВСтрокуВнутр(). Хотя он не выдает «ID реквизита», он позволяет получить уникальное строковое представление ссылки, что полезно при создании связей в ваших собственных регистрах логирования.

Заключение

Итак, для решения задачи идентификации реквизитов мы рекомендуем использовать 1CPP как основной инструмент для доступа к метаданным «на лету». Если же требуется глубокий анализ структуры, используйте gcomp. Помните, что создание «велосипедных» систем логирования в 7.7 требует тщательного контроля производительности, чтобы избежать замедления бизнес-процессов.

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