Как исправить ошибку «Поле объекта не обнаружено (КодПоОКАТО)» при переходе с УТ 10.3 на УТ 11

← На главную

Переход со старых редакций конфигураций 1С на новые — это всегда ответственный и зачастую тернистый путь. Одним из наиболее частых сценариев является миграция с 1С:Управление торговлей редакции 10.3 на современную редакцию 11 (11.4 или 11.5). Несмотря на то, что фирма «1С» предоставляет штатные помощники перехода и готовые правила обмена, в процессе выгрузки данных пользователи нередко сталкиваются с критическими ошибками.

В этой статье мы подробно разберем одну из таких «популярных» ошибок, которая полностью блокирует процесс выгрузки данных из базы-источника. Выясним причину ее возникновения, рассмотрим пошаговый алгоритм локализации проблемы в информационной базе УТ 10.3 и найдем способ ее быстрого исправления.

Суть технической проблемы и анализ лога ошибки

При выполнении выгрузки данных с помощью стандартного помощника перехода на этапе работы обработки УниверсальныйОбменДаннымиXML процесс прерывается, и в журнале регистрации (или в окне сообщений) появляется следующий текст:


Ошибка получения значения свойства объекта (по имени свойства источника)
    ПКО                  =  Организации  (Организации)
    ПКС                  =  2  (КодПоОКАТО --> КодПоОКАТО)
    Объект               =  ООО "Ромашка"  (Контрагенты)
    СвойствоПриемника    =  КодПоОКАТО  (Строка)
    ОписаниеОшибки       =  Поле объекта не обнаружено (КодПоОКАТО)
    ПозицияМодуля        =  Обработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(8284)
    КодСообщения         =  13

Давайте внимательно проанализируем эти строки вместе. Из лога видно следующее:

Правило конвертации свойств (ПКС) пытается передать значение реквизита КодПоОКАТО источника в аналогичный реквизит приемника.
Правило конвертации объектов (ПКО), которое сейчас выполняется, называется Организации. Оно предназначено для обработки элементов справочника Организации.
Самое интересное кроется в строке Объект. В качестве выгружаемого объекта выступает «ООО "Ромашка"», но тип этого объекта — Контрагенты (справочник СправочникСсылка.Контрагенты), а вовсе не Организации!

Таким образом, универсальный обмен данными пытается применить правила выгрузки организации к элементу справочника контрагентов. Так как у контрагентов в метаданных УТ 10.3 отсутствует реквизит КодПоОКАТО (он есть только у организаций), система выдает вполне закономерную ошибку Поле объекта не обнаружено и аварийно завершает работу.

Выясним причину, почему контрагент начинает выгружаться по правилам организации. Это происходит из-за наличия в базе-источнике реквизитов с составным типом данных. Если в каком-то документе или регистре в поле, предназначенном для организации (или ее расчетного счета), ошибочно выбран контрагент (или его расчетный счет), то движок Конвертации данных 2.0 автоматически пытается применить ПКО, соответствующее контексту метаданных приемника, что и приводит к сбою.

Пошаговый алгоритм локализации ошибки

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

Шаг 1. Локализация раздела учета

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

В ходе такого тестирования мы обязательно обнаружим, на каком именно разделе выгрузка падает. Чаще всего этой точкой преткновения оказывается раздел Денежные средства на банковских счетах или расчеты с контрагентами.

Шаг 2. Анализ справочника «Банковские счета»

Справочник БанковскиеСчета в конфигурации «Управление торговлей 10.3» имеет ключевую особенность: его владельцем (реквизитом Владелец) может выступать как элемент справочника Организации, так и элемент справочника Контрагенты. Это классический пример составного типа владельца.

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

Шаг 3. Использование запроса для быстрого поиска ошибки

Чтобы не перебирать тысячи документов вручную, воспользуемся консолью запросов в базе УТ 10.3. Нам необходимо найти платежные документы, в которых реквизиты заполнены некорректно. Напишем и выполним следующий запрос для анализа входящих платежных поручений:


ВЫБРАТЬ
    Платежка.Ссылка КАК Документ,
    Платежка.Организация КАК ОрганизацияДокумента,
    Платежка.БанковскийСчетОрганизации КАК СчетОрганизации,
    Платежка.БанковскийСчетОрганизации.Владелец КАК ФактическийВладелецСчета
ИЗ
    Документ.ПлатежноеПоручениеВходящее КАК Платежка
ГДЕ
    НЕ Платежка.БанковскийСчетОрганизации.Владелец ССЫЛКА Справочник.Организации
    И Платежка.БанковскийСчетОрганизации <> ЗНАЧЕНИЕ(Справочник.БанковскиеСчета.ПустаяСсылка)

Проанализируем этот запрос. Мы выбираем все входящие платежные поручения, у которых в реквизите БанковскийСчетОрганизации выбран счет, владелец которого не является организацией. Если запрос вернул строки, это означает, что мы нашли виновников сбоя! Аналогичные запросы можно написать для документов ПлатежноеПоручениеИсходящее, ПлатежныйОрдерПоступлениеДенежныхСредств и ПлатежныйОрдерСписаниеДенежныхСредств.

Также полезно проверить сам справочник БанковскиеСчета на предмет дублирования наименований и неверно указанных владельцев с помощью простого запроса:


ВЫБРАТЬ
    Счета.Ссылка КАК БанковскийСчет,
    Счета.Владелец КАК Владелец,
    ТИПЗНАЧЕНИЯ(Счета.Владелец) КАК ТипВладельца
ИЗ
    Справочник.БанковскиеСчета КАК Счета
ГДЕ
    Счета.Владелец ССЫЛКА Справочник.Контрагенты
    И Счета.Наименование ПОДОБНО "%Ромашка%"

Способ исправления данных в УТ 10.3

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

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

После исправления всех некорректных ссылок запустим процесс выгрузки данных через помощник перехода заново. Выгрузка должна пройти успешно без возникновения ошибки по свойству КодПоОКАТО.