Обсудить задачу
Таблицы и обмен

Skirbo +
ApiDQ

Предложить контроль адреса между оформлением заказа и складской выдачей, сохранив введённый покупателем текст и согласованное исправление.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Адресный запросМагазин / адаптер → ApiDQОбсудим в составе подключения

Текст адреса и страна в подтверждённых методах; состав ответа уточняется.

Вариант адресаApiDQ → оператор / магазинОбсудим в составе подключения

Кандидат для сопоставления с исходным текстом, не автоматическая замена реквизитов.

Разрешение выдачиСистема заказа → SkirboОбсудим в составе подключения

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

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

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

Как организовать обмен

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

Предлагаемый порядок работы

  1. Сохранить исходный адрес, ID заказа, клиента и выбранный способ доставки. Адрес ПВЗ с кодом не отправлять как обычный квартирный адрес без отдельного правила.
  2. Передать допустимый адресный текст и страну в согласованный метод ApiDQ; секрет стандартизации остаётся на сервере интеграции.
  3. Сопоставить ответ с версией адреса. Оператор сверяет населённый пункт, улицу, дом и данные получателя; изменение квартиры или корпуса нельзя принимать по сходству строк.
  4. Склад комплектует заказ, но спорную посылку оставляет в зоне ожидания адреса. Исправление утверждает продавец или уполномоченный оператор по согласованию с покупателем.
  5. Утверждённый адрес возвращается в систему заказа. Её подтверждение записи и последующее принятие адреса службой доставки разрешают подготовить финальную этикетку.
  6. При таймауте или неоднозначном ответе сохраняют исходные данные и задачу разбора. Если адрес менялся во время запроса, поздний ответ не заменяет новую версию.
  7. Для каждого повторного запроса сохранить версию входа, время и итог разбора. Сетевой успех, пригодность адреса, решение оператора и разрешение выдачи фиксировать разными событиями.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Проверить адрес до печати перевозочной этикетки

Задача: Снять адресную неоднозначность, пока посылка ещё на складе.

Когда начинается: Заказ принят магазином и направляется на комплектацию.

  1. Сохранить исходный адрес, ID заказа, клиента и выбранный способ доставки. Адрес ПВЗ с кодом не отправлять как обычный квартирный адрес без отдельного правила.
  2. Передать допустимый адресный текст и страну в согласованный метод ApiDQ; секрет стандартизации остаётся на сервере интеграции.
  3. Сопоставить ответ с версией адреса. Оператор сверяет населённый пункт, улицу, дом и данные получателя; изменение квартиры или корпуса нельзя принимать по сходству строк.
  4. Склад комплектует заказ, но спорную посылку оставляет в зоне ожидания адреса. Исправление утверждает продавец или уполномоченный оператор по согласованию с покупателем.
  5. Утверждённый адрес возвращается в систему заказа. Её подтверждение записи и последующее принятие адреса службой доставки разрешают подготовить финальную этикетку.
  6. При таймауте или неоднозначном ответе сохраняют исходные данные и задачу разбора. Если адрес менялся во время запроса, поздний ответ не заменяет новую версию.
  7. Для каждого повторного запроса сохранить версию входа, время и итог разбора. Сетевой успех, пригодность адреса, решение оператора и разрешение выдачи фиксировать разными событиями.

Результат: Исправление адреса прослеживается до заказа, решения человека и фактически использованной этикетки.

Если возникло исключение

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

Подсказка во время оформления

Задача: Снизить число ручных исправлений до поступления заказа.

Когда начинается: Покупатель вводит адрес в магазине.

  1. Показать полученные варианты как выбор, сохраняя введённый текст.
  2. После выбора подтвердить недостающие реквизиты у покупателя; подсказка не должна подменять авторизацию адресата.
  3. Передать в заказ именно выбранный вариант и версию адреса.
  4. Если пользователь продолжил ввод, поздний список не заменяет уже выбранный адрес. Пустой список и технический отказ различают; число и область подсказок настраивают по согласованному интерфейсу.

Результат: Склад получает согласованный адрес.

Если возникло исключение

  • Недоступность подсказок не выдаётся за отсутствие адреса в реальности.

Проверить адрес склада отправления

Задача: Разделить проблему пункта отправления и проблему адреса покупателя.

Когда начинается: Добавлен новый склад клиента.

  1. Ответственный сверяет адрес склада отдельно от адресов доставки.
  2. Фиксирует подтверждённое соответствие склада и адреса отправителя.
  3. Проверяет его принятие каждым нужным перевозчиком до массовых отгрузок.
  4. Адрес отправления и адрес возврата получают отдельные роли и версии, даже если сегодня совпадают. Изменение одного не переписывает исторические этикетки другого.

Результат: Справочник отправителей не меняется из-за одного покупательского заказа.

Если возникло исключение

  • ApiDQ не подтверждает договор перевозчика или часы работы склада.

Изменить адрес после подготовки этикетки

Задача: Не выдать со склада посылку с устаревшим адресом и не создать второе отправление из-за повтора.

Когда начинается: Покупатель подтвердил исправление, когда упаковка или перевозочная этикетка уже подготовлены.

  1. OMS фиксирует новую версию адреса и автора изменения; склад получает запрет выдачи именно для этой посылки до сверки.
  2. Адаптер отправляет новый адрес в согласованный адресный метод ApiDQ. Оператор проверяет спорные части, сопоставляя исходную строку, результат и решение покупателя.
  3. Продавец подтверждает изменение, OMS сохраняет его и возвращает подтверждение записи. Ответ на прежний запрос остаётся в истории и не меняет новую версию.
  4. Ответственный отдельно проверяет у перевозчика возможность изменения или отмены уже созданного отправления. При неопределённом результате сначала выясняет состояние существующего отправления по его ID, затем выполняет согласованное действие.
  5. При необходимости новая этикетка связывается с новой версией адреса и прежней посылкой. Старую этикетку изымают; перед выдачей склад сверяет, какой документ действителен.
  6. Если посылка уже покинула склад, продавец согласует переадресацию либо обратную доставку с перевозчиком. Адрес склада возврата подтверждают отдельно; физический возврат завершается только после приёмки и сверки SKU, количества и состояния.

Результат: В заказе, задании склада и действующей перевозочной этикетке используется одна подтверждённая версия адреса; повтор обработки не создаёт лишнее отправление.

Если возникло исключение

  • ApiDQ не отменяет отправления и не подтверждает вручение: эти операции зависят от перевозчика и его договора.
  • Если перевозчик уже не разрешает изменение, склад не выпускает новую этикетку по одному успешному ответу стандартизации.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ и адрес получателяМагазин / OMS клиентаСистема заказа хранит исходный и подтверждённый адрес с версиями; ApiDQ предлагает результат проверки, а изменение подтверждает продавец.
SKUКаталог / учётная система клиентаКоды и состав заказа сопоставляются с клиентским каталогом. Адресная проверка не меняет товарные идентификаторы.
Физический остаток и складской резервSkirboФактическое количество и резерв меняются по складским событиям. Исправление адреса не меняет остаток или доступность товара.
Статус проверки адресаApiDQ — ответ проверки; контур продавца — решениеОтвет сервиса, решение оператора и подтверждение записи магазином — разные состояния. Успешная нормализация не доказывает доступность тарифа перевозчика.
Документы и перевозочная этикеткаУчётная система клиента; перевозчик — транспортный документУчётный владелец подтверждает документы заказа; этикетку перевозчика формируют по окончательному адресу после его принятия. ApiDQ не становится источником документов.
ВозвратПродавец — разрешение; Skirbo / склад — физический фактОбратную доставку согласуют отдельно. Исправление адреса не доказывает возврат: склад фиксирует фактически принятые SKU, количество и состояние.

Что обсудить перед пилотом

  • Какие ошибки чаще встречаются: город, корпус, индекс или адрес ПВЗ?
  • Кто имеет право принять исправление и когда нужно перепечатать этикетку?
  • Какие сочетания качества адреса блокируют выдачу, кто разбирает очередь и за какое время?
  • Как OMS подтверждает сохранение новой версии и кто сверяет уже созданное отправление перед повтором?
  • Какие поля выбранной редакции ответа обязательны, включая написание полного адреса дома и обработку пустых значений?
Перед оценкой

Что нужно уточнить

  • Примеры адресов, схема подтверждения исправлений и правила обработки ПВЗ.
  • Корпоративные токены ApiDQ и согласованный серверный контур стандартизации.
  • Владелец адреса и связь каждого запроса с клиентом, заказом и версией.
  • Матрица решений по качеству адреса: какие исправления допустимы автоматически, какие требуют покупателя, а какие останавливают выдачу.
  • Реестр связи tenant, заказа, версии адреса, посылки и ID отправления; право на изменение адреса отдельно от права печати этикетки.
  • Согласованные правила хранения адресных запросов, журналов и доступа операторов; секретные значения не включают в диагностику.
Границы сценария

Что учесть заранее

  • Вводный документ не подтверждает координаты, обязательный справочник идентификаторов, показатели качества ответа или покрытие всех стран.
  • Стандартизация не заменяет проверку зоны доставки и доступности ПВЗ.
  • У вводного документа остаётся указанная выше ограниченная область. Дополнительная текущая документация описывает адресные поля и качество; координаты зависят от справочника, а точное написание и обязательность полей проверяют для выбранной редакции API.
  • Общая таблица ошибок не подтверждает численные квоты, бесплатность повторов или подключение конкретной страны к учётной записи.
  • Методы поиска по координатам, поиска по ID, ФИО и телефонов находятся за пределами описанного обмена; наличие ссылок на них в меню не расширяет подтверждённый сценарий.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

На каком этапе адрес становится окончательным и кто подтверждает его изменение?

Вопросы о подключении

Можно исправлять адрес без человека?

Только после проверки схемы ответа и согласованного правила для конкретного класса исправлений. Неоднозначный дом, корпус или населённый пункт требует решения ответственного.

Нужен ли секрет в браузере?

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

Поддерживаются Казахстан и Узбекистан?

Прочитанный пример содержит RU. Поддержку других стран и справочников нужно проверить отдельно; по названию международного адреса она не предполагается.

Сервис гарантирует доставку?

Нет такого подтверждения. Ответ помогает разобрать адрес, а возможность вручения и тариф проверяет перевозчик.

Координаты в ответе разрешают сразу печатать этикетку?

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

Как отличить недоступную подсказку от неверного адреса?

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

Что происходит с возвратом из-за ошибочного адреса?

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

Интеграция уже готова?

Изучаем возможность связи со Skirbo. Рабочий коннектор и сроки подключения не подтверждены; сначала согласуем описанный ниже процесс и проверим доступный интерфейс. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

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

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.