Как перехватить программную запись справочника в 1С 7.7?

В архитектуре платформы 1С 7.7 существует известное ограничение: предопределенная процедура ПриЗаписи() существует только в модуле формы и отрабатывает исключительно при интерактивном сохранении элемента пользователем. Если в коде вызывается метод Записать(), он обращается напрямую к ядру платформы, минуя событийную модель. Перехватить это стандартными средствами платформы невозможно. Разберем подробнее, какими способами можно отследить и проконтролировать программные изменения объектов, например, справочника цен.

Изменение архитектуры: переход на документы

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

1. Снимаем права на интерактивное редактирование справочника цен или периодического реквизита у всех пользователей.
2. Создаем специальный документ (например, "Установка цен").
3. Даем права на проведение этого документа только определенным лицам.
4. Цены (в периодические реквизиты справочника или в отдельный регистр) пишутся только при проведении этого документа.

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

Обертка через глобальную процедуру (Рефакторинг кода)

Если менять бизнес-логику и переходить на документы нельзя, проанализируем программный метод. Мы можем перехватывать вызовы искусственно:

1. Выполняем глобальный поиск по конфигурации всех конструкций вида .Записать() для целевого справочника.
2. Заменяем их на вызов собственной экспортной процедуры глобального модуля (например, глЗаписатьСправочникЦен(ОбъектСправочника)).
3. Внутри этой функции мы реализуем все необходимые проверки, логирование, рассылку оповещений об изменении цен, и лишь затем вызываем физическое сохранение элемента.

Для запрета интерактивного изменения при этом используются штатные права или процедура ПриЗаписи() в модуле формы.

Триггеры на уровне СУБД (SQL Server)

Если ваша база работает на SQL-версии 1С, мы можем гарантированно отлавливать 100% изменений, инициированных откуда угодно. Создаются триггеры AFTER INSERT, UPDATE непосредственно на физическую таблицу справочника (таблицы с префиксом SC...).

Посмотрим на пример создания собственной SQL-таблицы для хранения надежной истории (с правильным кластерным индексом), в которую никто мимо системы ничего не запишет:

CREATE TABLE История (
    Владелец char(9) not Null,
    Дата DateTime not Null,
    Цена Numeric(19, 2) not Null
)
CREATE UNIQUE CLUSTERED INDEX История_И1 ON История(Владелец, Дата)

Внутри триггера на основной таблице 1С логика будет фиксировать изменения или обновлять данные в нашей служебной таблице.

Использование внешних компонент (FormEx и 1С++)

Разберем возможности популярных внешних компонент для 1С 7.7:

1. FormEx: Компонента предоставляет событие ПриНачалеБлокировкиОбъекта(Объект). Его можно использовать для логирования и проверок, так как перед записью (даже программной) объект обычно блокируется. Однако стоит учитывать, что этот метод может не ловить некоторые специфичные виды блокировок.
2. 1С++: С помощью возможностей этой компоненты разработчики создают классы-обертки (ООП) над стандартными справочниками. В коде используется не штатный агрегатный тип, а пользовательский класс, реализующий собственный метод записи через прямые запросы. Это дает полный контроль над логикой сохранения.

Анализ журнала регистрации (SYSLOG)

Любая программная запись объекта фиксируется в системном Журнале регистрации (если в Конфигураторе включено логирование для данного справочника). Вместо перехвата самого момента записи можно организовать периодическое чтение системного лога (файла 1cv7evt.txt) с помощью объекта Текст. Парсинг этого файла позволяет точно выяснить причину изменения, отследить, какой элемент был изменен, когда и под каким пользователем.

Использование механизма УРБД

Интересный нестандартный подход — использование механизма компоненты УРБД с авторегистрацией изменений. Настраиваем план обмена, где регистрируется только справочник цен. При любом изменении (программном или интерактивном) система автоматически помечает объект как измененный. Периодически анализируя таблицу регистрации изменений или выгруженный файл обмена, мы используем это как флаг для запуска рассылки оповещений или синхронизации.