Внешняя обработка проставляет номера сертификатов и деклараций из типового учета 1С в карточки товаров Яндекс Маркета через Partner API: сначала заводит документ в кабинете, потом привязывает его номер к товарам.
Решение рассчитано на 1С:Управление торговлей 11.5, 1С:Комплексная автоматизация 2.5 и 1С:ERP 2.5. Конфигурация не изменяется, расширение не устанавливается. Источник данных - типовой справочник сертификатов номенклатуры и регистр областей действия.
Чем Яндекс отличается от Ozon
Файл документа через Partner API не передается: метода для этого нет вовсе. Зато у товара есть поле со списком номеров, и работа сводится к двум шагам, которые обработка делает сама.
- Документ заводится в кабинете. Номер, вид и даты берутся из карточки сертификата 1С. Яндекс проверяет номер по реестру и присваивает статус.
- Номер привязывается к товарам. Набор номеров у товара перезаписывается целиком, поэтому обработка отправляет старые номера вместе со своим и ничего не затирает.
Без первого шага карточка помечает номер красным: "Нет документа с таким номером". Это проверено на живом товаре: сначала номер лег в карточку с красной меткой, после заведения документа статус стал "Действует".
Что делает обработка
- проверяет Api-Key безопасным запросом чтения и сама находит идентификатор бизнеса по кампаниям;
- сохраняет подключение для текущего пользователя базы только по отдельной команде;
- заполняет товары по данным 1С, при необходимости только с положительным остатком;
- учитывает срок действия документа и отсекает отметки, которые номером не являются;
- сопоставляет артикул 1С с offerId товара кабинета точечным запросом, а не перебором каталога;
- показывает, какие номера уже стоят у товара, и какие документы уже заведены в кабинете;
- различает действия "Записать", "Уже записан", "Завести документ", "Не отправлять";
- приводит номер ЕАЭС к виду реестра, иначе площадка отвечает отказом;
- не заводит документ повторно, если он в кабинете уже есть;
- разбирает отказ Яндекса построчно: код 200 у него не означает "принято";
- ведет журнал с результатом каждого шага и итоговыми счетчиками;
- формирует отдельный табличный документ "Товары без сертификатов" без обращения к кабинету.
Как выглядит рабочий сценарий
- В кабинете откройте "Настройки - Доступ к API" и создайте ключ. Нужен именно Api-Key.
- Вставьте ключ и нажмите "Проверить подключение": идентификатор бизнеса обработка подставит сама. Затем "Сохранить подключение".
- Нажмите "Заполнить товары". При необходимости включите отбор по положительному остатку.
- Проверьте таблицу. Колонка "Сейчас в кабинете" показывает номера, которые уже стоят у товара.
- Оставьте отметку "Отправить" только у нужных строк и выполните тестовый прогон.
- Для боевой записи снимите тестовый режим и нажмите "Отправить через API". Обработка запросит подтверждение.
- Проверьте колонку результата и журнал операций.
Что видно до отправки
Каждая строка получает план и пояснение, а таблица различает две разные вещи: номер у товара и документ в кабинете. Это не одно и то же, и именно на этом ломается ручная сверка.
| Вердикт | Что это значит |
|---|---|
| Записать | номера у товара нет, он будет добавлен к тем, что уже стоят |
| Уже записан | номер у товара есть, и документ с таким номером в кабинете заведен |
| Завести документ | номер у товара стоит, а документа в кабинете нет: карточка светится красным. Обработка заведет документ, номера не трогая |
| Не отправлять | артикула нет среди товаров кабинета, в поле номера стоит не номер, или у товара уже шесть номеров |
| Ошибка | площадка отклонила порцию, текст отказа стоит в строке и в журнале |
Строки без артикула, с истекшим документом или с отметкой вместо номера к отправке не предлагаются. Причина выводится рядом с товаром, поэтому исходные данные правятся в 1С до обращения к API.
Номер документа: буквы имеют значение
Номер ЕАЭС набирается двумя алфавитами сразу: "ЕАЭС" и код органа по-русски, код страны латиницей. В базах в этих местах регулярно стоят латинские C и B вместо кириллических С и В, и на глаз строка неотличима. Яндекс проверяет номер формально и отвечает отказом "Unsuitable document number".
Обработка приводит к виду реестра только номера, начинающиеся с "ЕАЭС", и пишет подмену в журнал. Тем же написанием номер уходит и в карточку товара, чтобы документ и товар ссылались на одну строку. Свидетельства о государственной регистрации и отказные письма не трогаются: у них другой формат.
Тестовый режим
При открытии формы тестовый режим включен. Обработка читает кабинет, сопоставляет артикулы, проверяет документы и строит вердикты, но не вызывает методы записи. Тестовый прогон не меняет вердикт строки, поэтому сразу после него можно снять режим и отправить те же строки.
Рекомендуемый первый запуск - один товар с действующим документом. После отправки нажмите "Заполнить товары" еще раз: строка должна стать "Уже записан". Это и есть доказательство, что номер в кабинете.
Каталог читается точечно
Кабинет на 23 431 товар постранично не читается: обход обрывается на потолке, и нужный артикул получает вердикт "не найден". Обработка спрашивает кабинет списком артикулов, до 200 за запрос, и раздел документов списком номеров, до 100 за запрос. Для одного товара это один запрос вместо двух с лишним сотен страниц.
Если раздел документов прочитать не удалось, обработка говорит об этом в журнале и оставляет вердикты по номерам у товаров. Пустой ответ и неудавшийся запрос выглядят одинаково, но означают противоположное, и молча считать "документов нет" она не станет.
Скан документа
Скан через Partner API не передается: метода нет ни в каком виде. При этом на проверенном товаре скан и не потребовался - Яндекс сверил номер сам и поставил документу статус "Действует". Если документа в реестре нет, статус будет другим: "проверяется", "ждет исправлений", "не найден в реестре". Статус приходит в ответе и попадает в пояснение строки и в журнал, то есть виден сразу после отправки.
Требования к данным
- артикул номенклатуры в 1С должен совпадать с offerId товара в кабинете;
- сертификат должен быть связан с номенклатурой через типовой механизм области действия;
- у документа должны быть заполнены номер, вид и даты: из них заводится документ в кабинете;
- для обращения к Яндексу нужен Api-Key Partner API с правами на товары и карточки;
- старые токены Яндекс ID вида y0_... не подходят: площадка их не принимает ни одним способом.
Важные ограничения
- Яндекс принимает не больше шести номеров на товар. Если их уже шесть, обработка ничего не затирает, а помечает строку "Не отправлять".
- Два документа одного вида на один товар площадка не принимает, и обработка отклоняет такую пару с понятной причиной, а не отправляет наугад.
- Если номер уже стоял у товара в другом написании, обработка правит написание только своего номера, соседние не трогает.
- Самописные справочники сертификатов не поддерживаются, для них нужна адаптация источника данных.
- Юридическую применимость документа к категории обработка не проверяет: она показывает наличие действующего документа в учетной системе.
- Изменения выполняются только в кабинете Яндекс Маркета. Данные сертификатов в 1С обработка не переписывает.
Безопасность подключения
Api-Key передается только на сервер Яндекса, в форме он отображается как пароль. Настройки не сохраняются автоматически: для этого есть отдельная команда. Проверка подключения выполняется запросом чтения и ничего не создает.
Проверка полного цикла
Маршрут пройден на реальном товаре тестовой УТ 11.5 и живом кабинете на 23 431 товар. Сначала тестовый прогон, затем боевая отправка одной строки: заведен документ, номер привязан к товару, ошибок ноль. Повторное заполнение определило строку как "Уже записан", а карточка товара в кабинете показала документ со статусом "Действует".
Что входит в поставку
- внешняя обработка
.epf; - встроенная HTML-справка по заполнению сертификатов в УТ и работе с кабинетом;
- исходный код обработки открыт.
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.22.67
Вступайте в нашу телеграмм-группу Инфостарт