Обсудить задачу
Фулфилмент

Skirbo +
Oracle Warehouse Management Cloud

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

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

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

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

ОперацияНаправлениеСостав и готовность
Факты внешнего складаOracle WMS Cloud → SkirboОбсудим в составе подключения

Получать разрешённые данные площадки с привязкой к компании, facility и товару.

Передача задания внешнему складуSkirbo → Oracle WMS CloudНужна проверка

Подтвердить используемый интерфейс входящих заданий и запрет двойного управления одними операциями.

Сверка движения и наличияOracle WMS Cloud → SkirboОбсудим в составе подключения

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

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

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

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

Oracle Warehouse Management Cloud рассматриваем как WMS внешней площадки, где физическими операциями управляет Oracle. Skirbo может связывать эту площадку с продавцами и другими складами; две системы не должны одновременно выдавать задания одному оператору.

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

Подтвердить release tenant, договорный доступ и права на company/facility. Прочитанный GET-раздел не устанавливает полный authentication contract, write scopes и сетевую схему.

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

  1. В проекте закрепляем Oracle владельцем операций площадки и выбираем документированный способ передачи задания. Методы записи ещё подлежат проверке; до этого используем согласованную операторскую передачу.
  2. Связываем внешнее задание с клиентом, company/facility, исходными строками, SKU и единицами. Совпадение артикулов разных клиентов не объединяет их запас.
  3. Oracle выполняет резервирование, отбор и упаковку своими процессами. Skirbo не отправляет параллельные команды кладовщику на ту же площадку.
  4. Интеграция читает доступные по контракту факты и состояние движения, сохраняя идентификаторы внешних объектов и страницу/момент чтения. Порядок страниц не считается порядком физических событий.
  5. В Skirbo отражается подтверждённое исполнение конкретных строк и площадки; клиентский канал получает складской факт по исходному заказу.
  6. Приём исходной команды и фактический результат подтверждаются раздельно: сначала ссылка на принятое задание Oracle, затем сверенное состояние исполнения и принятие результата клиентским каналом.
  7. При пропущенной странице, неизвестном company/facility или расхождении количества останавливаем закрытие заказа и сверяем с оператором Oracle. Повторное чтение не создаёт новые отгрузки.
  8. Частичное исполнение сохранять по исходным строкам и отдельным партиям: сумма подтверждённых фактов сверяется с согласованным количеством, а незавершённая часть остаётся видимой клиенту.
  9. Запрос отмены после начала отбора передать владельцу Oracle-процесса и дождаться подтверждённого решения. Если отгрузка уже состоялась, использовать отдельный процесс возврата без удаления исходного факта.

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

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

Факт исполнения внешней площадки под управлением Oracle

Задача: Дать продавцу проверяемый результат, сохранив одного владельца физического склада.

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

  1. В проекте закрепляем Oracle владельцем операций площадки и выбираем документированный способ передачи задания. Методы записи ещё подлежат проверке; до этого используем согласованную операторскую передачу.
  2. Связываем внешнее задание с клиентом, company/facility, исходными строками, SKU и единицами. Совпадение артикулов разных клиентов не объединяет их запас.
  3. Oracle выполняет резервирование, отбор и упаковку своими процессами. Skirbo не отправляет параллельные команды кладовщику на ту же площадку.
  4. Интеграция читает доступные по контракту факты и состояние движения, сохраняя идентификаторы внешних объектов и страницу/момент чтения. Порядок страниц не считается порядком физических событий.
  5. В Skirbo отражается подтверждённое исполнение конкретных строк и площадки; клиентский канал получает складской факт по исходному заказу.
  6. Приём исходной команды и фактический результат подтверждаются раздельно: сначала ссылка на принятое задание Oracle, затем сверенное состояние исполнения и принятие результата клиентским каналом.
  7. При пропущенной странице, неизвестном company/facility или расхождении количества останавливаем закрытие заказа и сверяем с оператором Oracle. Повторное чтение не создаёт новые отгрузки.
  8. Частичное исполнение сохранять по исходным строкам и отдельным партиям: сумма подтверждённых фактов сверяется с согласованным количеством, а незавершённая часть остаётся видимой клиенту.
  9. Запрос отмены после начала отбора передать владельцу Oracle-процесса и дождаться подтверждённого решения. Если отгрузка уже состоялась, использовать отдельный процесс возврата без удаления исходного факта.

Результат: Физическая площадка управляется одной WMS, а клиент видит прослеживаемое исполнение.

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

  • Подтверждение необходимых методов записи и детализации факта — условие автоматизации этого сценария.

Поставка и запас в пути

Задача: Отделить ожидаемое движение от доступного для продажи остатка.

Когда начинается: По входящей поставке или перемещению появились новые данные.

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

Результат: Продавец не обещает товар до физического допуска к продаже.

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

  • GET конкретного ресурса не доказывает полный баланс пригодного остатка.

Параллельная сверка при переходе между WMS

Задача: Проверить соответствие запасов без двойного управления площадкой.

Когда начинается: Клиент готовит миграцию либо подключение второй системы к существующей площадке.

  1. На согласованный момент получаем доступный снимок и журнал движения в области company/facility.
  2. Сравниваем SKU, единицы, владельца, партии и физические площадки; расхождения классифицируем до любой записи.
  3. Только после согласованного перехода меняется владелец операций, а финальная сверка подтверждает, что открытые задания и резервы учтены.
  4. Зафиксировать открытые задания, резервы и товар в пути вместе с моментом передачи ответственности. До закрытия этих расхождений разрешён только согласованный режим наблюдения, а не два параллельных источника складских команд.

Результат: Миграционный проект имеет проверяемую точку перехода.

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

  • Снимок с пагинацией не считается атомарным без подтверждения контракта.

Принять возврат на внешней Oracle-площадке

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

Когда начинается: Владелец товара согласовал возврат и сообщил ожидаемые позиции внешнему складу.

  1. Согласовать, кто разрешает приёмку и как передаётся ожидаемый возврат: до подтверждения API используется операторский процесс Oracle, а не придуманный метод записи.
  2. Связать ожидание с клиентом, company/facility, исходной отгрузкой, строкой, SKU, количеством и при необходимости партией или серией.
  3. Оператор внешнего склада физически принимает и осматривает товар; недостача, повреждение и неподходящая партия фиксируются отдельно от заявленного количества.
  4. Получить доступный по подтверждённому контракту результат или согласованный отчёт оператора и отразить фактическую приёмку в Skirbo как проекцию Oracle.
  5. Владелец склада подтверждает пригодность и разрешённый статус запаса; продавец принимает результат сверки. Возврат денег и бухгалтерский документ остаются отдельными решениями.
  6. Повтор сообщения сверить с уже зафиксированной приёмкой и осмотром. При несовпадении товара или области company/facility остановить обновление свободного остатка и передать случай ответственному.

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

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

  • Методы создания и подтверждения возврата в конкретной Oracle WMS Cloud не проверены; автоматизация этого участка остаётся условием проекта.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиКлиентский канал и Oracle для задания площадкиИсходный коммерческий заказ связывается с внешним заданием; не заменяет его.
SKU и вариантыУчёт клиента и справочник OracleSKU, единицы и партии сопоставляются в области владельца товара.
Остатки и резервOracle на внешнем складеSkirbo хранит подтверждённую проекцию; запас в пути и свободный запас разделены.
СтатусыOracle для физического процессаКлиентский статус формируется из проверенных фактов, не из факта отправки запроса.
ДокументыERP/учёт владельца товараСкладской факт и финансовое проведение имеют отдельное подтверждение.
ВозвратыOracle-площадка и владелец возвратаФизическая приёмка, карантин и решение о возврате покупателю денег не объединяются.

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

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

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

  • Версия и регион tenant Oracle WMS, договорный доступ к API и тестовая company/facility.
  • Граница владения складом, соответствие SKU, единиц, партий и внешних номеров.
  • Методы записи нужных команд и чтения подтверждений, права интеграционной учётной записи.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Перечень команд, которые разрешены до отбора, после упаковки и после отгрузки; если контракт отмены не подтверждён, нужен ответственный оператор Oracle.
  • Список открытых заданий, резервов, входящих контейнеров и возвратов на момент пробной сверки, чтобы сравнение запасов не потеряло незавершённые операции.
Границы сценария

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

  • Наличие международной документации не подтверждает доступность приобретения и использования в любой стране; условия клиента проверяются отдельно.
  • Руководство 26D нельзя автоматически применять к другой версии; наличие GET не означает поддержку записи того же объекта.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Список поддерживаемых GET-ресурсов не задаёт состав всех строк ответа, порядок физического движения или атомарность снимка. Необходима проверка конкретной сущности и её схемы.
  • Oracle WMS Cloud и Oracle NetSuite — разные продукты; права, объекты и результат учётной операции NetSuite не переносятся на эту страницу.
Стоимость и запуск

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

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

Зачем связывать две системы управления складом?

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

Зачем связывать две системы управления складом?

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

Можно ли считать товар в пути свободным остатком?

Нет. Сначала зададим состояние и площадку движения, а доступность для заказа появится после нужного подтверждения приёмки и проверки ограничений товара.

Можно объединить одинаковый SKU из двух company/facility?

Только по отдельному подтверждённому правилу владения. Одинаковый код может относиться к разным клиентам и площадкам; в карте обмена эти области сохраняются.

Все страницы GET получены — это гарантированно единый снимок?

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

Что делать, если клиент отменил заказ после начала отбора в Oracle?

Запрос отмены сверяется с текущим физическим этапом и решением внешнего склада. До подтверждения соответствующего интерфейса отмена проходит через оператора Oracle. Уже отгруженный товар требует отдельного процесса возврата; повтор команды не должен изображать отмену состоявшейся отгрузки.

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

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

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

По запросу: предлагается индивидуальное проектирование и проверка на среде клиента. Принятый коннектор Skirbo, доступность пилота, срок запуска и SLA не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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