Проверка YML-фида: характеристики, цена и наличие до выгрузки

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

Проверка YML-фида должна дать не общий вердикт «всё хорошо», а список по каждому offer: что проверено, какое правило нарушено, кто исправляет источник и можно ли отправлять строку повторно. При этом успешный HTTP-ответ подтверждает передачу данных, а не размещение всего каталога.

Какую задачу решает этот процесс

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

Процесс проверки должен остановить известные ошибки до отправки и сохранить понятный протокол:

1. Экспортёр сформировал XML в ожидаемой кодировке.
2. Структура XML разбирается без синтаксической ошибки.
3. Каждый offer проверен по контракту конкретного приёмника.
4. Значения сопоставлены с источниками каталога, цен и доступности.
5. После загрузки ответ площадки и статус предложения проверены отдельно.

Граница материала — контракт выгрузки и техническая валидация. Здесь мы не генерируем товарные описания, не пишем карточки и не проектируем ответы покупателям. Смежный процесс общения с клиентом разобран в материале про чат-бота для статуса заказа.

Какие данные и правила подготовить

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

Ниже — короткие синтетические учебные данные, а не клиентский файл и не результат запуска на площадке:

Такой фрагмент можно проверить на трёх уровнях. Сначала XML-парсер должен разобрать дерево и согласовать содержимое с encoding. Затем поля проверяют по контракту выбранного канала. После этого значения сравнивают с бизнес-источниками. Корректный синтаксис XML сам по себе не делает файл корректным YML для конкретного приёмника.

Что проверить до отправки фида

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

Затем примените согласованную схему или набор правил принимающего канала:

• присутствуют требуемые элементы;
• нет неподдерживаемых элементов;
• значения имеют ожидаемые типы;
• идентификаторы уникальны в области, которую определяет канал;
• ссылки и изображения относятся к тому же предложению;
• цена, валюта и доступность согласованы между собой и с источниками.

Схема формата зависит от приёмника. Нельзя взять правила одной торговой или рекламной площадки и объявить их универсальным стандартом YML. Например, документация Яндекс Товаров отдельно называет отсутствие offer, неправильный формат фида, неверную стоимость, недоступную страницу и расхождение сведений о товаре. Это подтверждает необходимость разных классов проверки именно для этого канала, но не задаёт полный контракт других систем.

Хороший отчёт валидатора ссылается не только на строку XML, но и на правило: «повтор ID в согласованной области», «поле отсутствует по контракту версии X» или «цена не совпала с источником на момент формирования». Тогда сотрудник исправляет причину, а не маскирует сообщение.

Как сопоставить каталог и предложения

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

Отдельно согласуйте единицу продажи. Цена одной штуки, комплекта и партии — разные значения. Нельзя механически изменить число, чтобы оно прошло проверку: коммерческий специалист должен подтвердить цену и единицу в исходной системе. В документации Яндекс Товаров, например, отдельно описана ошибка, когда передана цена единицы при обязательном заказе партии. Такое условие применимо к указанному каналу и не переносится автоматически на остальные.

Не объединяйте три разных состояния:

• пустое поле означает, что значение не передано;
• ноль — переданное числовое значение, допустимость которого определяет канал;
• отсутствие offer означает, что предложения нет в текущей выгрузке, но последствия для ранее принятой позиции зависят от приёмника.

То же относится к available. Значение должно отражать согласованный источник доступности, а не предположение экспортёра. Если маркетолог не знает, означает ли нулевой остаток запрет публикации, предзаказ или иной статус, правило остаётся неизвестным до проверки документации и настроек канала.

Варианты товара, состояние бывшего в употреблении или уценённого товара и оптовую цену описывают только по правилам выбранного приёмника. Для Яндекс Товаров документация различает сведения об уценённом или бывшем в употреблении товаре и указывает элементы condition и quality; это не доказательство такой же структуры в другом канале.

Как читать ошибки загрузки и повторять публикацию

Разделите наблюдение на три этапа.

1. Локальная проверка. Файл разбирается как XML, а строки проходят известные технические и бизнес-правила.
2. Ответ площадки. Канал получил запрос или файл и вернул технический либо построчный результат обработки.
3. Фактическое появление. Принятый offer получил ожидаемый статус и появился там, где его должен увидеть пользователь.

HTTP 2xx означает успешный транспортный обмен в пределах соответствующего способа загрузки. Он не подтверждает, что площадка приняла каждую строку, завершила модерацию или разместила товар. Даже сообщение о принятом файле нужно сопоставить с построчным отчётом и фактическим статусом предложений.

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

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

Учебный пример: путь от входных данных до результата

Рассмотрим синтетический пример. Все названия, идентификаторы и суммы условны; это не клиентский кейс и не отчёт о реально выполненной загрузке.

В отдельном учебном реестре уже занят ID DEMO-100. В новую выгрузку входят три предложения:

• DEMO-100, условный товар «Лампа A», цена 1490 рублей — конфликтует с реестром ID;
• DEMO-200, условный товар «Лампа B», цена −250 рублей — содержит отрицательное значение;
• DEMO-300, условный товар «Лампа C», цена 990 рублей — проходит показанные локальные проверки.

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

Сводка строится по строкам, а не по числу сообщений. Новых предложений N = 3. Конфликтов ID E_id = 1, ошибок цены E_price = 1. Всего строк с найденными ошибками: E = 1 + 1 = 2. Без найденных ошибок осталась V = 3 − 2 = 1 строка.

Для этого условного набора доля строк с ошибками равна 2 / 3 × 100 = 66,7%, а доля прошедших показанную локальную проверку — 1 / 3 × 100 = 33,3%. Эти доли описывают только три учебные строки и не прогнозируют качество реального каталога.

Исправление DEMO-100 требует заменить ID на DEMO-101 во всех связанных строках, журнале ошибок и повторной выгрузке. Значение −250 нельзя автоматически превратить в 250: человек сначала сверяет источник цены. Если оба исправления подтверждены, ожидаемый результат повторной учебной проверки — три из трёх строк допущены к отправке. Это ожидаемый результат последовательности, а не выполненный тест и не подтверждение размещения.

Как проверить результат перед запуском

Перед рабочим запуском оформите две независимые квитанции. Первая показывает, что XML разобран и технические поля проверены. Вторая фиксирует бизнес-правила: соответствие ID, категории, цены, валюты, доступности, URL и изображений их источникам и контракту канала.

Для нормального пути задайте три контрольные точки:

Для исключения предусмотрите отдельный сценарий: площадка приняла часть строк и вернула построчные ошибки. Ожидаемый результат — сохранены перечни принятых и отклонённых ID. Сигнал — конкретные сообщения по строкам. Человек исправляет первичный источник, формирует новую версию фида и повторяет загрузку только по правилам канала. HTTP-ответ не записывают как доказательство размещения.

Генерация товарных описаний в эту проверку не входит. Если требуется автоматически создавать тексты карточек, это отдельный процесс со своими источниками, ограничениями и критериями приёмки.

Что согласовать для внедрения

Готовый валидатор подходит, если он поддерживает нужный формат, версию правил и способ запуска, а его отчёт можно связать с offer_id. До выбора проверьте область правил, обновление схемы, работу с большими файлами, хранение данных и формат выгрузки ошибок. Наличие слова YML в описании инструмента не подтверждает совместимость с вашим каналом.

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

Switch On AI может разработать ИИ-помощника, бота или обычную интеграцию для операции «проверка технических и смысловых ошибок фида до отправки». Формат зависит от действия: интеграция запускает фиксированные проверки и обмен данными; бот помогает сотруднику запросить статус; ИИ-помощник может разбирать текстовые сообщения об ошибках в пределах согласованных источников, но не должен сам придумывать правила канала.

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

Посмотреть возможные форматы можно на странице услуг Switch On AI. Следующий шаг — обсудить автоматическую проверку вашей выгрузки: разобрать одну операцию, согласовать входные данные, исключения и прототип. Прототип проверяет понимание сценария и не равен полному внедрению; эффект, срок и совместимость нельзя обещать до проверки требований.