После обновления конфигураций «1С:Комплексная автоматизация 2» или «1С:ERP Управление предприятием» до релизов 2.5.20.80, 2.5.20.85 и смежных версий многие пользователи сталкиваются с критической ошибкой. Проблема проявляется не только при попытке выполнить синхронизацию данных с «1С:Бухгалтерией 3.0», но и при обычном перепроведении документов СчетФактураВыданный.
В этой статье мы подробно разберем причины возникновения этой ошибки, выясним, почему она блокирует повседневную работу пользователей, и рассмотрим несколько способов её решения: от официальных патчей до написания собственного расширения.
Проанализируем текст ошибки, который выдает система. Основная проблема кроется в обработчике правил регистрации объектов. В стеке вызовов мы видим обращение к общему модулю ОбменДаннымиСобытияУТ:
{ОбщийМодуль.ОбменДаннымиСобытияУТ.Модуль(324)}:Если ДокументОснование.Статус = Перечисления.СтатусыРеализацийТоваровУслуг.КПредоплате Тогда
Разберем ситуацию подробнее. Когда в системе включена Синхронизация данных, при записи любого объекта срабатывают правила регистрации (ПРО). Эти правила определяют, должен ли объект попасть в очередную выгрузку. В новых релизах разработчики добавили проверку статуса документа-основания для счета-фактуры.
Проблема заключается в том, что в коде прописано прямое обращение к реквизиту Статус через точку от ДокументОснование. Если основанием счета-фактуры является Реализация товаров и услуг, код отрабатывает корректно. Однако, если основанием выступает Акт выполненных работ или другой документ, в метаданных которого нет реквизита Статус, система закономерно выдает исключение Поле объекта не обнаружено (Статус).
Так как правила регистрации срабатывают непосредственно в транзакции записи документа, любая ошибка в них приводит к невозможности провести или даже просто пометить документ на удаление.
Поскольку проблема носит массовый характер и признана разработчиками 1С как программная ошибка, первым делом нам следует проверить наличие официального исправления. Рассмотрим, как это сделать:
СинхронизацияДанныхЧерезУниверсальныйФормат или ошибка в ОбменДаннымиСобытияУТ. Обычно код патча начинается на EF_0018....Это самый быстрый и безопасный способ, не требующий вмешательства в код конфигурации.
Если патч по каким-то причинам недоступен или вы работаете в сильно кастомизированной базе, мы можем исправить ошибку самостоятельно, создав расширение. Нам нужно модифицировать логику обращения к реквизиту Статус, сделав её более безопасной.
Разберем, как реализовать проверку наличия реквизита программно. Вместо прямого обращения мы будем использовать функцию ОбщегоНазначения.ЕстьРеквизитОбъекта. Проанализируем пример кода, который следует разместить в расширении для метода ДокументСчетФактураВыданныйПередОбработкойПРО:
&Вместо("ДокументСчетФактураВыданныйПередОбработкойПРО")
Процедура Ипр_ДокументСчетФактураВыданныйПередОбработкойПРО(Объект, Отказ, ИмяПланаОбмена)
// Проверяем наличие реквизита "ДокументОснование"
Если ОбщегоНазначения.ЕстьРеквизитОбъекта("ДокументОснование", Объект.Метаданные()) Тогда
Основание = Объект.ДокументОснование;
// Безопасная проверка наличия реквизита "Статус" у документа-основания
Если ЗначениеЗаполнено(Основание)
И ОбщегоНазначения.ЕстьРеквизитОбъекта("Статус", Основание.Метаданные()) Тогда
// Только если реквизит существует, выполняем типовую логику
Если Основание.Статус = Перечисления.СтатусыРеализацийТоваровУслуг.КПредоплате Тогда
// Ваша логика или возврат к типовому поведению
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Используя конструкцию ЕстьРеквизитОбъекта, мы гарантируем, что система не обратится к несуществующему полю Статус у Акта выполненных работ, и транзакция проведения завершится успешно.
Иногда ошибка кроется не в самом программном коде модулей, а во вложенных правилах регистрации, которые хранятся в XML-виде внутри базы. Выясним, как их обновить без обновления всей конфигурации:
ExchangeRegistrationRules.xml из папки SyncFiles, которая идет в составе дистрибутива обновления КА 2.5.После обновления правил регистрации рекомендуется очистить кэш на сервере и клиенте, так как правила могут кэшироваться в памяти для ускорения работы обмена.
Рассмотрим ситуацию, когда ошибка продолжает возникать даже после исправлений. В этом случае проанализируем состояние плана обмена:
/ClearCache.Регистрация изменений для обмена данными. Это позволит провести документ, но помните, что его придется перегрузить в бухгалтерию вручную позже.Подводя итог, можно сказать, что данная проблема является классическим примером «жесткого» кодинга в правилах регистрации 1С. Использование безопасных методов обращения к реквизитам через ОбщегоНазначения позволяет избежать подобных ситуаций при работе с разнородными документами-основаниями.