Предыстория

При внедрении электронных перевозочных документов столкнулся с довольно неприятным сценарием в 1С:Управление нашей фирмой 3.0.14.140.

Необходимо было сформировать электронное поручение экспедитору, ЭПЭ, где грузоотправителем выступает иностранная организация.

В рассматриваемом случае это была китайская компания:

SMARTGEN (ZHENGZHOU) TECHNOLOGY CO., LTD

В карточке контрагента были заполнены:

Страна регистрации: КИТАЙ
Код страны: 156
Регистрационный номер: 9141010074923612XG
ИНН РФ: не заполнен

То есть это обычный иностранный контрагент, не состоящий на учете в российских налоговых органах.

При попытке сформировать электронный документ возникала ошибка проверки обязательных реквизитов.

Первоначально система требовала:

//Файл/Документ/СодИнфКлнт/СвГруз/СвГО/ИдСв/СвЮЛУч/ИННЮЛ

Что уже само по себе выглядело подозрительно.

Для иностранной организации должен использоваться не узел российского юридического лица:

СвЮЛУч

а структура:

СвИнНеУч

После исправления определения страны последовательно проявились следующие ошибки:

//Файл/Документ/СодИнфКлнт/СвГруз/СвГО/ИдСв/СвИнНеУч/Наим

а затем:

//Файл/Документ/СодИнфКлнт/СвГруз/СвГО/ИдСв/СвИнНеУч/ИдСтат

Именно после этого пришлось разбирать цепочку формирования ЭПЭ практически до XDTO.

---

Где находится проблема

Основной интерес представляет общий модуль:

ОбменСГИСЭПД

и функция:

ПолучитьРеквизитыУчастника

Типовая логика примерно следующая.

Сначала создается структура сведений об участнике:

СведенияОбУчастнике = ЭлектронноеВзаимодействие.СтруктураДанныхЮрФизЛица();

Затем вызывается:

ЭлектронноеВзаимодействиеПереопределяемый.ПолучитьДанныеЮрФизЛица(
    Участник,
    СведенияОбУчастнике);

После этого конфигурация пытается определить страну регистрации:

СтранаРегистрации = Неопределено;
СведенияОбУчастнике.Свойство(
    "СтранаРегистрации",
    СтранаРегистрации);

И далее принимает принципиальное решение.

Если страна заполнена и отличается от России, участник считается иностранным:

ИнострЛицоБезУчета...

В противном случае он попадает в российскую ветку:

ЮЛНаименование
ЮЛ_ИНН
ЮЛ_КПП
ЮЛ_ОГРН

И именно здесь обнаружилась первая проблема.

---

Ошибка №1. Теряется СтранаРегистрации

Отладчиком было установлено следующее.

После выполнения:

ЭлектронноеВзаимодействиеПереопределяемый.ПолучитьДанныеЮрФизЛица(...)

переменная:

СтранаРегистрации

оставалась:

Неопределено

Хотя прямое чтение реквизита контрагента:

ОбщегоНазначения.ЗначениеРеквизитаОбъекта(
    Участник,
    "СтранаРегистрации")

возвращало:

КИТАЙ

Причина оказалась в структуре данных.

ПолучитьДанныеЮрФизЛица() получает сведения о контрагенте и затем переносит их в переданную структуру через механизм наподобие:

ЗаполнитьЗначенияСвойств(...)

Но если соответствующее свойство отсутствует в целевой структуре, оно туда не попадает.

В результате страна присутствует в карточке контрагента, но до ПолучитьРеквизитыУчастника() фактически не доходит.

Из-за этого условие:

Если ЗначениеЗаполнено(СтранаРегистрации)
    И СтранаРегистрации <> Россия Тогда

не выполняется.

Иностранная компания уходит в российскую ветку, после чего XML закономерно требует российский ИНН.

---

Исправление определения иностранного участника

Самый простой вариант исправления состоит в том, чтобы после штатной попытки получить страну из СведенияОбУчастнике добавить резервное чтение непосредственно из объекта контрагента.

Логика:

Если СтранаРегистрации не заполнена
    И участник является контрагентом Тогда

    СтранаРегистрации =
        значение реквизита Контрагент.СтранаРегистрации;

КонецЕсли;

После этого типовая ветка начинает работать правильно.

В нашем случае система перестала формировать:

СвЮЛУч

и начала формировать:

СвИнНеУч

Это уже принципиально важный результат.

---

Ошибка №2. Для СвИнНеУч недостаточно двух реквизитов

Штатный код иностранной ветки в рассматриваемом релизе фактически формировал только часть данных:

ИнострЛицоБезУчетаСтрана
ИнострЛицоБезУчетаИдентификатор

Но для формирования XML ЭПЭ этого оказалось недостаточно.

Понадобились также:

ИнострЛицоБезУчетаНаименование
ИнострЛицоБезУчетаКодСтраны
ИнострЛицоБезУчетаСтатусИО_ИГ

Наименование можно получить из:

СведенияОбУчастнике.ПолноеНаименование

Код страны:

ОбщегоНазначения.ЗначениеРеквизитаОбъекта(
    СтранаРегистрации,
    "Код")

Для Китая это:

156

Статус определяется по типу иностранного лица.

Для иностранной организации:

ИО

Для иностранного гражданина:

ИГ

После этого структура участника уже содержит полный набор данных иностранного лица.

Казалось бы, на этом проблема должна закончиться.

Но нет. Здесь начинается самая интересная часть.

---

Ошибка №3. Данные сформированы, но ИдСтат все равно отсутствует

После заполнения:

ИнострЛицоБезУчетаСтатусИО_ИГ = ИО

ошибка:

СвИнНеУч/ИдСтат

не исчезла.

Поэтому пришлось разбирать следующий этап.

В ЭПЭ данные грузов хранятся внутри структуры:

ТитулЗаказчикаГрузы

У строки груза существует поле:

ГрузоотправительИнострЛицоБезУчетаИдентификацияСтатуса

Однако макет соответствия XML ожидает другое имя:

ГрузоотправительИнострЛицоБезУчетаСтатусИО_ИГ

То есть фактически имеем рассинхронизацию двух частей механизма.

Форма и структура данных работают с:

...ИдентификацияСтатуса

а XML-сопоставление ожидает:

...СтатусИО_ИГ

Поэтому значение существует логически, но до узла:

СвИнНеУч/ИдСтат

не доходит.

Это удалось подтвердить отладчиком непосредственно при обходе структуры строки груза.

---

Как строится итоговый XML

Еще одна важная функция:

ДанныеРеквизитовЭПД

Она читает сохраненные значения ЭПД из регистра:

РегистрСведений.ЗначенияРеквизитовДокументовЭПД

и формирует структуру данных примерно следующего вида:

ТитулЗаказчикаГрузы
    Строка 1
        СсылкаГрузоотправитель
        Грузоотправитель...
        ...

После этого:

ДвоичныеДанныеДокументаЭПД

берет эту структуру и сопоставляет каждый реквизит с XML-узлом через макет:

СоответствиеИменРеквизитов

Ключевой момент здесь следующий.

Если имя реквизита строки груза отсутствует в макете или отличается от ожидаемого, значение просто не участвует в построении XDTO.

Поэтому проблема ИдСтат находилась уже не в карточке контрагента и даже не в функции получения сведений об участнике.

Она находилась на стыке:

структура формы
        U95;
ДанныеРеквизитовЭПД
        U95;
СоответствиеИменРеквизитов
        U95;
XDTO
        U95;
XML ЭПЭ

---

Вариант исправления без изменения типовой конфигурации

Я реализовал исправление расширением.

Концептуально оно состоит из двух частей.

Первая часть дополняет штатную ПолучитьРеквизитыУчастника.

После получения страны добавляется резервное чтение:

Контрагент.СтранаРегистрации

Если страна иностранная, дополнительно заполняются:

ИнострЛицоБезУчетаНаименование
ИнострЛицоБезУчетаКодСтраны
ИнострЛицоБезУчетаСтатусИО_ИГ

Идентификатор берется из регистрационного номера, который типовой механизм уже передает через ОГРН.

Вторая часть работает уже перед формированием XML.

Перехватывается:

ДанныеРеквизитовЭПД

через механизм:

&Вместо("ДанныеРеквизитовЭПД")

Сначала обязательно выполняется штатная функция:

Результат = ПродолжитьВызов(...);

То есть штатное получение данных не переписывается.

После этого дополнительно анализируется:

ТитулЗаказчикаГрузы

Для каждой строки определяется:

СсылкаГрузоотправитель

Если грузоотправитель иностранный, повторно получаются его сведения.

Далее в структуру строки добавляются значения под именами, которые ожидает XML-макет:

ГрузоотправительИнострЛицоБезУчетаИдентификатор

ГрузоотправительИнострЛицоБезУчетаНаименование

ГрузоотправительИнострЛицоБезУчетаСтрана

ГрузоотправительИнострЛицоБезУчетаКодСтраны

ГрузоотправительИнострЛицоБезУчетаСтатусИО_ИГ

Дополнительно можно заполнить и фактическое поле формы:

ГрузоотправительИнострЛицоБезУчетаИдентификацияСтатуса

После этого дальнейший механизм остается полностью типовым.

То есть мы не создаем XML самостоятельно, не работаем вручную с XDTO и не подменяем схемы.

Схема остается такой:

штатные данные ЭПЭ
        U95;
точечное дополнение структуры
        U95;
штатный макет СоответствиеИменРеквизитов
        U95;
штатный XDTO
        U95;
штатный XML

На мой взгляд, для расширения это наиболее безопасный вариант.

---

Почему в исправлении есть повторное получение данных контрагента

В тестовой копии оказалось достаточно дополнить ПолучитьРеквизитыУчастника.

Но на рабочем сервере была обнаружена интересная особенность.

Через журнал регистрации было видно:

Страна=КИТАЙ
Идентификатор=9141010074923612XG
Код=
Статус=
Наименование=

То есть часть реквизитов до следующего этапа не дошла.

Чтобы окончательное формирование XML не зависело от промежуточной структуры, в финальном варианте был добавлен fallback непосредственно перед формированием ЭД.

Если какое-либо значение отсутствует, оно восстанавливается заново.

Страна:

Контрагент.СтранаРегистрации

Код:

СтраныМира.Код

Наименование:

ПолноеНаименование

Идентификатор:

ОГРН / регистрационный номер

Статус:

ИО либо ИГ

Получается небольшой слой нормализации данных перед передачей их штатному XML-генератору.

---

Что получилось после исправления

После установки расширения тот же иностранный грузоотправитель формируется в ЭПЭ следующим образом:

Сведения об иностранной организации,
не состоящей на учете в налоговом органе

Идентификация статуса:
ИО

Код страны:
156

Наименование страны:
КИТАЙ

Наименование:
SMARTGEN (ZHENGZHOU) TECHNOLOGY CO., LTD

Идентификатор:
9141010074923612XG

Также корректно сформировались:

Страна происхождения груза: 156 / КИТАЙ

Адрес приема груза:
156 / КИТАЙ / Чжэнчжоу

После исправления документ успешно прошел внутреннюю проверку заполнения и открылся как сформированный электронный документ без ошибок ИННЮЛ, Наим, ИдСтат и КодСтр.

---

Что проверялось

Исправление проверялось на:

1С:Управление нашей фирмой
редакция 3.0
релиз 3.0.14.140

Проверялись два окружения:

копия рабочей базы
рабочая серверная база

 

---

Важный момент по совместимости

Это не тот случай, где я бы обещал работу расширения на всех будущих релизах УНФ.

В решении используется:

&ИзменениеИКонтроль("ПолучитьРеквизитыУчастника")

Следовательно, если 1С изменит текст типовой функции, платформа может потребовать восстановить соответствие метода.

Кроме того, исправление использует текущие внутренние имена:

ТитулЗаказчикаГрузы
СсылкаГрузоотправитель
СоответствиеИменРеквизитов

Если в следующих версиях Библиотеки интеграции ГосИС механизм будет переработан, расширение необходимо перепроверить.

Поэтому корректная формулировка совместимости:

Разработано и протестировано на УНФ 3.0.14.140. На других релизах необходимо выполнить проверку применимости расширения и соответствия изменяемых методов.

---

Можно ли реализовать исправление самостоятельно

Да.

Для программиста, знакомого с расширениями 1С, после приведенного выше разбора достаточно:

1. Расширить общий модуль ОбменСГИСЭПД.
2. В ПолучитьРеквизитыУчастника восстановить СтранаРегистрации непосредственно из контрагента.
3. Для иностранного лица дополнить структуру наименованием, кодом страны и статусом ИО/ИГ.
4. Перехватить ДанныеРеквизитовЭПД.
5. После ПродолжитьВызов() обработать массив ТитулЗаказчикаГрузы.
6. По СсылкаГрузоотправитель получить иностранного контрагента.
7. Добавить в строку груза алиасы, соответствующие макету СоответствиеИменРеквизитов.
8. Передать структуру дальше штатному генератору XML.

Сам XML формировать вручную не требуется.

---

Зачем тогда приложено расширение

Статья содержит весь технический разбор, достаточный для самостоятельной реализации.

Готовое расширение приложено скорее как вариант:

«Не хочу тратить час на создание расширения, перенос типового метода, #Вставка, проверку ИзменениеИКонтроль и тестирование».

В расширении нет привязки к конкретной организации и контрагента.

Данные берутся непосредственно из карточки грузоотправителя.

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

При этом фактически протестирован сценарий именно иностранной организации со статусом ИО.

Логика ИГ для иностранного гражданина предусмотрена, но отдельный реальный кейс с иностранным физическим лицом мной не проверялся.

---

Итог

Проблема оказалась составной.

Сначала УНФ теряла:

СтранаРегистрации

из-за чего иностранная организация ошибочно попадала в ветку российского юридического лица.

После исправления страны проявилось отсутствие обязательных реквизитов иностранного участника.

А после их заполнения обнаружилась еще одна проблема: имя поля формы:

ИдентификацияСтатуса

не совпадало с именем, которое использовал макет формирования XML:

СтатусИО_ИГ

В итоге решение пришлось сделать на двух уровнях:

получение реквизитов участника

+

нормализация структуры строки груза перед формированием XML

После этого штатный XDTO формирует корректный блок:

СвИнНеУч

со статусом, страной, наименованием и идентификатором иностранной организации.

И это тот редкий случай, когда одна маленькая ошибка ИдСтат оказалась верхушкой вполне приличного айсберга