При организации обмена данными между конфигурациями «1С:Управление торговлей, ред. 11» и «1С:Бухгалтерия предприятия, ред. 3.0» пользователи часто сталкиваются с неприятной ситуацией: документы «Поступление товаров и услуг» (или «Приобретение товаров и услуг») переносятся корректно, но поля «Номер накладной» и «Дата накладной» остаются пустыми. Это критично для бухгалтерского учета, так как отсутствие этих данных делает невозможным корректное формирование книги покупок и отчетности по НДС.
В рамках данной статьи мы разберем причины возникновения этой технической ошибки, проанализируем механизмы обмена EnterpriseData и рассмотрим пошаговые инструкции по устранению проблемы.
Проанализируем техническую сторону вопроса. Проблема кроется в использовании формата обмена EnterpriseData версии 1.6. В определенный момент разработчики платформы изменили структуру XML-пакета, переместив реквизиты ДанныеВходящегоДокумента (куда входят номер и дата) в секцию КлючевыеСвойства. По логике платформы, ключевые свойства используются для идентификации объекта при поиске, но программный код загрузки в «1С:Бухгалтерии» не был вовремя адаптирован для извлечения этих значений из данного узла и записи их непосредственно в реквизиты документа.
Эта ошибка официально зарегистрирована в реестре под номером 00-00200777. Она связана с некорректной сериализацией XDTO в составе Библиотеки стандартных подсистем (БСП). В результате, при чтении XML-файла программой-приемником, данные просто игнорируются, и поля в базе данных остаются NULL или пустыми строками.
Самый правильный и надежный способ решения проблемы — обновление обеих конфигураций. Разработчики выпустили исправления, начиная с версии БСП 3.0.1.434. Рассмотрим, как правильно выполнить это действие:
Если по техническим причинам вы не можете оперативно обновить конфигурации (например, из-за большого объема кастомизации и доработок), существует проверенный обходной путь (workaround). В версии формата 1.5 структура данных отличается: номер и дата входящего документа передаются в основном теле сообщения, а не в ключевых свойствах, что позволяет Бухгалтерии успешно их считывать.
Разберем по шагам, как изменить версию формата:
Важно: При использовании версии 1.5 некоторые новые возможности и реквизиты, появившиеся в более свежих версиях формата, могут быть недоступны, однако для базового переноса поступлений этот способ работает безотказно.
Иногда возникает предположение, что данные заполнены, но просто не отображаются на форме документа. Чтобы развеять сомнения, проанализируем ситуацию с помощью встроенных инструментов разработчика. Для этого воспользуемся обработкой «Групповое изменение реквизитов»:
НомерВходящегоДокумента и ДатаВходящегоДокумента.Если в этих колонках пусто, значит, проблема действительно на этапе загрузки XML. Если же данные там присутствуют, но на форме их нет, то причина может быть в расширениях или программных скрытиях элементов формы (что при данной ошибке встречается крайне редко).
Если вы опытный специалист и вам нужно исправить проблему «здесь и сейчас» без глобальных обновлений, можно вмешаться в процесс парсинга данных. Рассмотрим пример логики, которую можно внедрить через расширение конфигурации в модуле менеджера или в обработчиках загрузки данных XDTO:
// Пример извлечения данных из ключевых свойств в обработчике
Если СвойстваXDTO.Свойство("КлючевыеСвойства") Тогда
Ключи = СвойстваXDTO.КлючевыеСвойства;
Если Ключи.Свойство("НомерВходящегоДокумента") Тогда
Объект.НомерВходящегоДокумента = Ключи.НомерВходящегоДокумента;
КонецЕсли;
Если Ключи.Свойство("ДатаВходящегоДокумента") Тогда
Объект.ДатаВходящегоДокумента = Ключи.ДатаВходящегоДокумента;
КонецЕсли;
КонецЕсли;
Такой подход позволяет принудительно «подтянуть» данные, которые платформа считает ключами поиска, и записать их в физические реквизиты объекта ДокументОбъект.ПриобретениеТоваровУслуг.
Мы выяснили, что отсутствие номера и даты — это следствие эволюции формата EnterpriseData и временного лага в обновлении механизмов его обработки. Для стабильной работы системы рекомендуем придерживаться следующего алгоритма:
Своевременное исправление этой ошибки позволит бухгалтерии корректно отражать входящий НДС и избавит от необходимости ручного ввода данных в сотни документов после каждой синхронизации.