Внешний номер заказа Маркета: когда передать его, чтобы он попал в документы и штрихкод
Как связать заказ Яндекс Маркета с номером учётной системы: срок передачи externalOrderId, ASCII в штрихкоде и проверка документов до отгрузки.
Содержание статьи
Если склад ищет заказ по номеру своей учётной системы, а ярлык содержит номер Маркета, сотруднику приходится вручную восстанавливать соответствие. Для FBS, Экспресса и DBS API позволяет передать externalOrderId — идентификатор заказа продавца. Передача доступна только один раз и до перехода к READY_TO_SHIP. Инструкция проверена 19 октября 2026 года; это дата проверки документации, а не запуска функции.
Зафиксируйте соответствие до сборки
Документация указывает, что внешний номер используется в акте приёма-передачи, листе сборки и ярлыках. Он относится к заказу, а не к товарному артикулу. Отдельный порядок изменения SKU решает другую задачу и не заменяет связь заказов между системами.
Редакционная рекомендация — создать внутреннюю запись соответствия сразу после импорта заказа. Храните номер Маркета, номер своей системы и магазин, которому принадлежит заказ. Если учётная система присваивает окончательный номер позднее, заранее определите момент фиксации: временная заглушка неудобна, поскольку метод не предназначен для многократного редактирования значения.
Один заказ может появляться в разных внутренних документах: резерве, сборочном задании и реализации. Выберите устойчивый идентификатор самого заказа, а не номер документа, который ещё будет перепроведён. Иначе сотрудники увидят корректно переданный номер, по которому уже нельзя найти действующую запись.
Проверьте символы в штрихкоде
В штрихкоде ярлыка допустимы ASCII-символы. При использовании других символов во внешнем идентификаторе штрихкод будет содержать номер заказа Маркета. Это особенно важно для систем, где номера начинаются с русских букв: видимая подпись и результат сканирования могут различаться.
Не меняйте массово нумерацию действующих заказов ради удобства сканера. Сначала проверьте, умеет ли программа находить одну запись по обоим идентификаторам. Для новых заказов можно согласовать технический формат номера, который совместим с документами, складской программой и печатью. Такое решение относится к настройке интеграции продавца.
Разделите передачу номера и готовность заказа
Переход к готовности должен происходить после сохранения нужного соответствия. Свяжите этот шаг с подготовкой коробок FBS, чтобы печать не опережала окончательное оформление. При этом ожидание внутреннего номера не должно скрывать реальные сроки обработки заказа от ответственного сотрудника.
Если связь оборвалась после отправки запроса, не придумывайте новый номер для повторной попытки. Сначала выясните, был ли первоначальный идентификатор принят. Сохранённое тело запроса и ответ помогают отличить ошибку передачи от ситуации, когда номер уже установлен. Не отправляйте в диагностические сообщения токен доступа.
Примите интеграцию на реальной цепочке документов
Для проверки возьмите согласованный заказ и сопоставьте внутреннюю запись, документ сборки, печатную подпись и результат сканирования. Отдельно проверьте номер с буквенным префиксом. Успешный ответ API подтверждает передачу значения, но не доказывает, что складская программа правильно интерпретирует полученный штрихкод.
Зафиксируйте, как сотрудник действует при неизвестном номере: ищет по второй системе, сверяет магазин и только затем передаёт случай интегратору. Такая процедура сохраняет прослеживаемость заказа без повторного создания карточек, ручной подмены ярлыков и потери связи с исходной покупкой.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы