При работе с распределенными информационными базами (РИБ) в связке БИТ.Финанс и Бухгалтерия предприятия 3.0 разработчики часто сталкиваются с критическими ошибками при миграции документов Операция (бухгалтерский и налоговый учет). Проблема усугубляется, когда в системе реализованы нетиповые механизмы подавления обратной выгрузки данных, а центральный узел работает в файловом режиме. Разберем по шагам, почему происходит аварийное завершение платформы и как добиться стабильной работы обмена.
Рассмотрим ситуацию, когда в конфигурации доработана процедура ПриОтправкеДанныхПодчиненному. Часто разработчики пытаются избежать «зацикливания» обмена или ненужной передачи данных в подчиненный узел, принудительно удаляя регистрацию изменений прямо в момент обмена. Проанализируем пример такого кода:
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента, СозданиеНачальногоОбраза)
// Удаление регистрации для специфических планов обмена БИТ и типовых
ПланыОбмена.УдалитьРегистрациюИзменений(ПланыОбмена.бит_Полный.НайтиПоНаименованию("Периферия"), ЭлементДанных);
ПланыОбмена.УдалитьРегистрациюИзменений(ПланыОбмена.Полный.НайтиПоНаименованию("Перефирия"), ЭлементДанных);
// Игнорирование отправки самого объекта
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецПроцедуры
Такой подход таит в себе скрытую угрозу для логической целостности базы. В 1С документ («регистратор») и его движения (записи в регистрах) — это разные объекты метаданных. Если мы принудительно игнорируем отправку самого документа, но при этом в пакете обмена остаются зарегистрированные движения (например, по регистру бухгалтерии или регистрам накопления БИТ), то при загрузке в центральную базу система попытается записать набор записей, для которого в базе еще не существует регистратора. Это часто приводит к появлению «битых» ссылок (пустой регистратор () в журнале проводок) и, в худшем случае, к аварийному дампу платформы.
Выясним причину, по которой 1С закрывается без записи в журнал регистрации. В старых версиях платформы 8.3 при попытке записать набор записей регистра бухгалтерии с некорректным или отсутствующим типом регистратора возникала ошибка обращения к памяти (Access Violation). Особенно это актуально для файловых баз. Рассмотрим ключевые факторы:
1cv8.exe._AccntReg может войти в противоречие, провоцируя вылет платформы.Проанализируем ситуацию после обновления платформы. Как правило, в новых релизах 1С разработчики заменили «тихий вылет» на штатное исключение. Ошибка «Запись не верна» при обмене РИБ обычно указывает на валидацию данных в методе ПередЗаписью регистра бухгалтерии или на уровне платформенной проверки типов. Основные причины:
Выясним, как локализовать проблему, если штатный журнал регистрации пуст.
1. Настройка Технологического журнала (ТЖ)
Для диагностики «вылетов» необходимо создать файл logcfg.xml в каталоге установки платформы (или в профиле пользователя). Добавим сбор событий исключений:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<property name="All"/>
</log>
</config>
После сбоя проанализируем файлы логов на наличие строк Access Violation или Exception. Это укажет на конкретный модуль или таблицу СУБД, на которой происходит затык.
2. Замена типа документа
Если ОперацияБух стабильно вызывает проблемы в специфических обменах, рассмотрим возможность использования документа Корректировка записей регистров. Он более гибко обрабатывается платформой и реже вызывает конфликты при загрузке движений, так как его структура менее жестко привязана к регистрам бухгалтерии в части внутренней валидации платформы.
3. Проверка целостности файловой базы
Поскольку центральная база файловая, обязательно выполним проверку утилитой chdbfl.exe. Это исключит физическое повреждение заголовков таблиц, которые часто «сыплются» при аварийных завершениях процесса.
4. Использование пошаговой загрузки
Для отладки сложных пакетов обмена можно воспользоваться внешней обработкой «Чтение сообщений обмена», которая позволяет загружать объекты из XML-файла сообщения по одному. Это позволит точно определить, на какой именно ОперацииБух или на каком наборе записей происходит сбой.
Вместо того чтобы просто удалять регистрацию в процедуре ПриОтправкеДанныхПодчиненному, что приводит к рассинхронизации ссылок, проанализируем более безопасный путь. Если задача стоит в том, чтобы данные из центра не «забивали» периферию, лучше использовать подписки на события ПриЗаписи, где с помощью свойства ОбменДанными.Загрузка можно управлять логикой регистрации.
Если же вы продолжаете использовать ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать, убедитесь, что вы также удаляете регистрацию изменений для всех движений этого документа. Помните: нельзя передавать движения без регистратора, если этот регистратор отсутствует в принимающей базе. Либо передавайте всё (и документ, и движения), либо ничего.
Резюме: Основной способ борьбы с аварийным завершением — обновление платформы до актуальной версии, переход к анализу конкретных ошибок через Технологический журнал и обеспечение ссылочной целостности (загрузка документа-регистратора строго раньше или одновременно с его движениями).