Почему маркетплейс не принимает ваш УПД

Наш клиент — разборка автомобилей. Продаёт запчасти, в том числе через крупный маркетплейс автозапчастей. Электронный документооборот (Диадок) у клиента уже настроен, электронные накладные тоже. И вот приходит письмо от маркетплейса: поставщики, которые выполнят два условия, получат приоритет в заказах, а поставщики на бумаге уйдут в конец очереди. К письму приложены инструкция и пример файла заказа. Клиент прочитал, ничего не понял и переслал нам: «Что они от нас хотят?»

Перевод с языка ЭДО на русский

Требование первое — простое: отправить маркетплейсу приглашение к обмену документами через Диадок по идентификатору их оператора ЭДО. У клиента Диадок уже есть, так что это пять минут.

Требование второе — то, ради которого всё затевалось: в каждой строке УПД должен быть номер заказа. Не в шапке документа, а в каждой товарной позиции. Номер берётся из файла заказа, который присылает маркетплейс, — из защищённого столбца с надписью «НЕ УДАЛЯТЬ!». В XML документа это выглядит так:

<СведТов НомСтр="1" НаимТов="Фара левая" КолТов="1" ЦенаТов="4500.00" ...>
  <ДопСведТов ... />
  <ИнфПолФХЖ2 Идентиф="ИдентификаторЗаказаКлиента" Значен="A7F3-1029-55"/>
</СведТов>

Элемент ИнфПолФХЖ2 — это «информационное поле»: формат УПД разрешает добавлять в строку произвольные пары «название — значение». Маркетплейс использует его, чтобы автоматически сопоставить отгрузку с заказом без участия человека.

Почему 1С сама этого не сделает

Типовая 1С выгружает УПД по стандартным правилам и про номер заказа маркетплейса ничего не знает. Поэтому нужна доработка в три шага:

1. В документ реализации добавляется реквизит для идентификатора заказа (через расширение, чтобы не ломать обновления типовой конфигурации).
2. Реквизит заполняется при загрузке заказа из Excel-файла маркетплейса — из того самого столбца «НЕ УДАЛЯТЬ!».
3. В правилах выгрузки УПД для ЭДО добавляется ИнфПолФХЖ2 в каждую строку.

Типичная ловушка: порядок элементов

Самое коварное место такой доработки — порядок элементов. Формат УПД задан схемой XSD от ФНС, и в схеме строго определено, какой элемент за каким идёт внутри СведТов. Если программист 1С добавит ИнфПолФХЖ2 «в конец, где удобнее», документ станет невалидным. Диадок или получатель отклонит его с сообщением, по которому неспециалист не поймёт, что не так. Визуально в документе всё правильно, номер заказа на месте.

Проверить файл по схеме перед отправкой можно десятком строк на Python:

from pathlib import Path
from lxml import etree

def check_upd(xml_path: str, xsd_path: str) -> list[str]:
    raw = Path(xml_path).read_bytes()
    problems = []

    # 1. ФНС ждёт windows-1251, и это должно быть указано в заголовке
    header = raw[:120].decode("ascii", "replace").lower()
    if "windows-1251" not in header:
        problems.append("в заголовке XML не указана кодировка windows-1251")

    doc = etree.fromstring(raw)

    # 2. Имя файла обязано совпадать с атрибутом ИдФайл
    file_id = doc.get("ИдФайл")
    if file_id and Path(xml_path).stem != file_id:
        problems.append(f"имя файла не совпадает с ИдФайл ({file_id})")

    # 3. Структура и порядок элементов — по схеме ФНС
    schema = etree.XMLSchema(etree.parse(xsd_path))
    if not schema.validate(etree.ElementTree(doc)):
        problems += [f"строка {e.line}: {e.message}" for e in schema.error_log]

    return problems


for p in check_upd("ON_NSCHFDOPPR_....xml", "схема_УПД_ФНС.xsd"):
    print("⚠", p)

Три проверки — кодировка, имя файла и схема — ловят большинство «необъяснимых» отказов.

Из этой истории вырос наш инструмент

Таких историй у наших клиентов набралось достаточно: УПД для маркетплейса, электронные экспедиторские расписки от транспортной компании, которые не принимает получатель, файлы после ручной правки бухгалтером. И мы сделали ЭДО-санитар — инструмент, который проверяет XML-документы форматов ФНС перед загрузкой в Диадок и исправляет то, что можно исправить безопасно: порядок элементов по схеме, кодировку, имя файла, лишние пробелы.

Главное правило, которое мы в него заложили: инструмент никогда не трогает данные. ИНН, суммы, даты, количества — неприкосновенны. Если ошибка в данных, санитар показывает, где она, но не исправляет её «по своему разумению». Исправлять форму можно автоматически, исправлять содержание — только человеку.

Чтобы быть уверенными, что это правило не нарушается ни в каком случае, мы написали больше тысячи автоматических тестов. Часть из них генерирует случайные корректные документы, «портит» в них форму и проверяет, что после исправления все данные остались байт в байт. Обе реальные ошибки, с которых всё началось, воспроизводятся в тестах и исправляются.

Попутно про электронные накладные

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

Что из этого вынести

Если контрагент прислал требования к ЭДО, которые непонятно как выполнить, — это обычно не «невозможно», а «нужна небольшая доработка 1С и аккуратность с форматом». Мы переводим такие письма на человеческий язык, делаем обработки 1С и проверяем документы до того, как их отклонит получатель.