При B2B-продаже на Яндекс Маркете реквизиты покупателя лучше получать по конкретному заказу и в допустимом статусе. Попытка заполнить документы заранее данными из старой продажи создаёт риск перепутать юридическое лицо, подразделение или адрес. Разберём, где в процессе интеграции должен стоять запрос этих сведений.

Когда доступны сведения

Метод getOrderBusinessBuyerInfo возвращает ИНН, КПП, название организации и юридический адрес. Документация разрешает получение данных для заказов в статусах PROCESSING, DELIVERY, PICKUP и DELIVERED. В запрос передаются campaignId магазина и orderId заказа. Для покупателя — физического лица предусмотрен другой метод.

Поэтому отсутствие данных до перехода в разрешённый статус не следует автоматически трактовать как ошибку покупателя. Сначала проверьте сам этап заказа. У новых B2B-продаж есть отдельная последовательность действий, разобранная в материале о первом заказе FBS от бизнеса.

Где поставить проверку в учётной системе

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

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

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

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

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

Как проверить передачу в документы

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

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

Руководство подготовлено по API-документации, проверенной 21 октября 2026 года. Это дата редакционной проверки, а не дата появления B2B-метода. Вопросы юридической корректности конкретных документов решаются отдельно от технического получения реквизитов.