Перенос табличных частей в правилах конвертации XML (КД 2)

В чем сложность переноса табличных частей в правилах КД 2?

С документами в КД 2 всё обычно начинается бодро. Шапка переносится, дата едет, номер на месте, организация нашлась — кажется, победа. А потом открываешь документ-приёмник, и там табличная часть пустая. Или, что хуже, заполнена «почти правильно». А «почти правильно» в обменах — это уже ошибка.

И вот тут важно понять простую вещь: табличная часть в правилах конвертации — это не довесок к документу. Это отдельный кусок логики со своими правилами, своими реквизитами, своими ссылками и, если надо, своей болью. Новички часто пытаются перенести строки «по остаточному принципу», мол, шапка работает — и строки подтянутся. Не подтянутся. Их надо описывать явно, аккуратно и без надежды на магию.

Поэтому если вы переносите документ, то мысленно делите задачу на две части: сначала объект, потом его строки.

Основные термины КД 2

• ПКО - правило конвертации объекта
• ПКГС - правило конвертации группы свойств (как раз их нужно создавать для переноса табличных частей)
• ПКС - правило конвертации свойств

С чего начинается правильный перенос документа со строками

Правильный перенос документа начинается не с табличной части, а с понимания структуры данных. Нужно заранее ответить на три вопроса: что переносим, куда переносим и что должно происходить со строками. Не «примерно», а прямо по полочкам.

Допустим, вы переносите Реализацию товаров и услуг из одной базы в другую. В шапке — контрагент, договор, склад. В строках — номенклатура, количество, цена, сумма. Уже здесь видно, что шапка и строки живут разной жизнью. Контрагент ищется по одному правилу, номенклатура — по другому. И если шапка загрузится, а номенклатура в строках не найдётся, документ всё равно получится кривой.

Поэтому сначала создаётся ПКО для документа, а уже внутри него описываются табличные части, для каждой свое ПКГС (правило конвертации группы свойств) нужно создавать. Это базовая дисциплина. Без неё обмены начинают «работать через раз». А такие вещи, если честно, хуже полного падения.

Где именно описываются табличные части в КД 2

Теперь к практике. Табличные части в КД 2 описываются не где попало, а в правилах конвертации группы свойств — то есть в ПКГС для объекта. И вот тут у многих начинается путаница: разработчик создал ПКО на документ, описал шапку, а строки не появились. Почему? Потому что табличная часть — это тоже свойство объекта. Только составное.

Если говорить совсем по-простому, документ в КД 2 — это контейнер. А табличная часть — коллекция строк внутри него. Значит, её надо не просто «перенести», а отдельно указать, как брать строки из источника и как заполнять ими строки в приёмнике.

На рисунке показали кнопку для создания ПКГС. Именно так начинают разработку алгоритмов переноса данных табличных частей документа.

Обычно это выглядит так:

в ПКО документа создаётся ПКС для табличной части, а уже внутри этого соответствия настраиваются поля строки. То есть не «Номенклатура документа», а «Номенклатура строки табличной части». Это разные уровни. Очень разные.

И если этот момент упустить, обмен будет выглядеть так, будто всё настроено правильно. Но не будет.

Как правильно описывать табличную часть в ПКО и ПКС

Теперь — самый важный кусок. Если хотите, вот это и есть «рабочий центр» всей статьи.

Для документа у вас есть ПКО, например:

Документ.РеализацияТоваровУслуг → Документ.РеализацияТоваровУслуг

Внутри него создаются обычные ПКС на шапку:

• Дата
• Номер
• Организация
• Контрагент
• Склад

А затем создаётся ПКГС для табличной части, например:

Товары → Товары

И вот уже внутри этого соответствия вы описываете поля строки:

• Номенклатура
• Характеристика
• Количество
• Цена
• Сумма
• СтавкаНДС

То есть логика такая:

ПКО документа
→ ПКГС табличной части
→ ПКС реквизитов строки (для ссылочных объектов)

Это важно запомнить буквально как формулу. Потому что очень часто новички пытаются перенести поля строки прямо на уровень документа. Например, добавляют «Номенклатура» в список свойств самого документа. Формально это можно сделать. Практически — это тупик.

Строка должна жить в строке. Не в шапке. Не рядом. Именно в строке.

Почему строки не переносятся, хотя всё вроде настроено

А вот теперь про типичную ловушку. Самую частую.

Вы создали ПКГС для табличной части. Указали имя. Настроили поля строки. Запускаете обмен — и табличная часть всё равно пустая. В этот момент обычно начинают подозревать КД 2, платформу, XML, луну в Козероге — всё подряд. Но причина обычно банальная.

КД 2 должен получить коллекцию строк из источника. Если в источнике имя табличной части отличается, если используется нестандартный объект, если данные собираются через код, а не напрямую — строк он просто не увидит. А если не увидит, то и переносить нечего.

Значит, первое, что надо проверить:

• Совпадает ли имя табличной части в источнике.
• Правильно ли выбрано свойство именно табличной части.
• Нет ли переопределения через обработчики.
• Не обнуляется ли коллекция перед записью.

Да, иногда ошибка оказывается совсем смешной: табличная часть называется не Товары, а, например, Материалы. И всё. Полдня улетело.

Такое бывает чаще, чем хотелось бы.

Как переносить несколько табличных частей и не запутаться

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

Разберем справочник Спецификации в УНФ. В нем есть:

• Состав
• Операции
• Дополнительные реквизиты

Смотрите рисунок. Каждая из этих частей должна быть описана отдельным ПКГС. Не одной общей логикой, не «универсальным переносом строк», а отдельным соответствием. Потому что у каждой табличной части свой набор реквизитов. У товаров есть количество и цена. У услуг может не быть склада. У тары — свои особенности учёта.

Рассмотрим перенос спецификаций в справочник Ресурсные спецификации в 1С:ERP:

Правильный подход такой:

• отдельно настраиваем Состав → МатериалыИУслуги
• отдельно настраиваем Операции → Трудозатраты
• отдельно настраиваем ДополнительныеРеквизиты → Дополнительные реквизиты

И еще дополнительно заполним входящие данные таблицей значений с единственной строкой, чтобы продукцию которая в УНФ хранится в шапке спецификации, перенести в строку табличной части Выходные изделия (ERP).

И только потом внутри каждой части описываем её поля. Да, это чуть дольше. Зато потом не приходится ловить баги из серии «услуга внезапно приехала в товары». А такие сюрпризы КД 2, кстати, умеет подкидывать. Ещё как.

Что делать, если структура строк в источнике и приёмнике отличается

Вот здесь уже начинается взрослая разработка. Потому что в реальных проектах редко бывает так, что строки совпадают один в один. Обычно в источнике одна структура, а в приёмнике — уже слегка «допиленная». Или сильно.

Например, в источнике в строке есть:

• Номенклатура
• Количество
• Цена

А в приёмнике ещё нужны:

• ЕдиницаИзмерения
• Коэффициент
• СчетУчета

Что это значит? Это значит, что одного прямого соответствия мало. Нужно добавлять логику в обработчики, заполнять недостающие поля программно, а иногда и искать значения по связанным объектам.

Например:

• единицу можно брать из карточки номенклатуры;
• коэффициент — из упаковки;
• счёт учёта — из настроек учётной политики или регистра. Причем, иногда из исходной базы 1С, а иногда - из базы 1С - приемника данных.

И здесь очень полезное правило:

если строка требует бизнес-логики — не пытайтесь решить всё только настройкой ПКС.

КД 2 хороша, но не экстрасенс. Иногда ей нужно помочь кодом. Либо написать содержимое обработчика ПередВыгрузкойОбъекта, где, например, обратиться к базовой единице измерения номенклатуры, либо сделать программное дозаполнение реквизитов в обработчике ПослеЗагрузки в ПКО документа, который переносили.

Как корректно переносить ссылки внутри строк таблиц документов

Теперь переходим к самому неприятному и самому полезному одновременно — ссылкам внутри строк табличных частей.

Почти каждая строка документа содержит ссылочные поля:

• Номенклатура
• Характеристика
• Серия
• Склад
• ЗаказПокупателя
• СчетУчета
• СтатьяЗатрат

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

Например, в XML выгрузилась номенклатура. Но если в базе-приёмнике эта номенклатура не найдена, строка либо не заполнится, либо заполнится частично, либо вообще вызовет ошибку при записи документа. И всё — документ «поехал».

Поэтому правило жёсткое:

все ссылки внутри строк должны иметь свои правила поиска и переноса.

Не «может быть найдутся». Не «скорее всего уже есть». А именно должны.

Обычно это решается так:

• на Номенклатуру есть своё ПКО;
• на ХарактеристикуНоменклатуры есть своё ПКО;
• на Склад — своё;
• на прочие ссылки — тоже.

И только когда эти правила существуют и реально работают, строка становится надёжной.

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

Вот здесь часто хочется срезать угол. Очень хочется.

Кажется логичным: если номенклатура называется одинаково в обеих базах, давайте искать по наименованию. Быстро, удобно, красиво. И на тесте оно даже срабатывает. А потом в боевой базе находится две позиции «Кабель HDMI 2м», и начинается цирк.

Поиск ссылок по строкам должен быть устойчивым. Лучше использовать:

• Код
• Артикул
• Внешний идентификатор
• GUID
• или комбинацию полей

То есть искать надо по тому, что действительно уникально. По-настоящему уникально.

Особенно это критично для строк. Потому что, если в шапке неверно определился контрагент — это уже плохо. Но если в строке неверно определилась номенклатура, документ может провести совсем не ту хозяйственную операцию. А это уже не «технический баг». Это учётная проблема.

И бухгалтер, как правило, не оценит ваш креатив.

Как отлаживать перенос табличных частей

Самая плохая стратегия при настройке КД 2 — запускать полный обмен и надеяться, что «сейчас всё поедет». Нет. Так только тратится время.

Гораздо эффективнее проверять перенос строк пошагово:

• сначала один документ;
• потом одна табличная часть;
• потом одна строка;
• потом одно ссылочное поле в строке.

Да, медленно. Зато быстро.

Очень помогает временный вывод диагностической информации в обработчиках. Например:

• сколько строк найдено в источнике;
• какая номенклатура пришла;
• что не нашлось по поиску;
• на каком поле развалилось соответствие.

И вот это уже настоящая рабочая привычка: не «чинить на ощущениях», а смотреть, где именно теряется значение. Потому что в КД 2 ошибка редко сидит «где-то». Обычно она сидит в одном конкретном месте. Просто её надо поймать.

Вообще, КД 2 очень быстро наказывает за спешку. Поспешил с поиском — получил дубль. Поспешил со строками — потерял ссылки. Поспешил с «универсальным правилом» — через неделю переписываешь всё заново. Поэтому хороший обмен почти всегда выглядит скучно. И это, честно говоря, отличный признак.

Практический шаблон: как я бы настраивал перенос строк с нуля

Если собрать всё в рабочую последовательность, то для начинающего разработчика я бы рекомендовал такой порядок:

Шаг 1. Создать ПКО на документ

Сначала настраиваем сам документ как объект переноса. Только шапку. Без строк.

Шаг 2. Создать свои ПКО для всех ссылочных объектов

В правилах в момент настройки переноса свойств документы уже должны быть созданы ПКО для ссылочных элементов.

Шаг 3. Настроить все ссылочные объекты

Контрагенты, номенклатура, склады, характеристики, договоры и прочее. Всё, что может встретиться в шапке и строках.

Шаг 4. Добавить ПКС на каждую табличную часть

Каждую — отдельно. Без попыток «обобщить».

Шаг 5. Описать реквизиты строки

Для каждой табличной части настраиваем соответствия её полей.

Шаг 6. Проверить загрузку одного документа

Не всего массива. Не периода. Одного документа.

Шаг 7. Проверить повторную загрузку

Убедиться, что строки не дублируются и не «нарастают».

Если пройти эти семь шагов спокойно, без рывков, перенос табличных частей перестаёт быть страшным. Остаётся только работа. Нормальная, понятная, инженерная.

Как сэкономить время при разработке переносов данных XML?

Главная возможность сэкономить время - это приобрести готовые правила переноса данных. Компания MoscowSoft специализируется на переносах данных 1С. Почти для каждой ситуации у нас есть готовые правила обмена.

Многие специалисты 1С приобретают готовые правила переноса данных 1С и выполняют проект переноса данных самостоятельно. Экономия времени составляет от 2 до 4 недель работы на целый день. А бюджет на приобретение инструмента предоставляет заказчик.

Выбирайте готовые правила обмена 1С: