Обсудить задачу
Учётные системы

Skirbo +
SAP S/4HANA

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

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

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

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

ОперацияНаправлениеСостав и готовность
Бизнес-событиеSAP S/4HANA → интеграционный контурОбсудим в составе подключения

Сигнал к чтению объекта; не готовая складская команда.

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

Актуальная версия и согласованные корпоративные коды.

Факт исполнения и приёмкаSkirbo → ERP → журналОбсудим в составе подключения

Отдельный контракт, документ и подтверждение.

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

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

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

Область — SAP S/4HANA и конкретная редакция/развёртывание клиента. Пример бизнес-событий не переносится автоматически на Business One или на любую инсталляцию S/4HANA.

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

В первичном примере требуется communication arrangement для системы, технического пользователя и API-сценариев. Доступ к обратной записи складского факта и конкретные документы ещё должны быть подтверждены для редакции клиента.

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

  1. SAP формирует предусмотренное проектом событие создания или изменения Sales Order.
  2. Получатель идентифицирует tenant и объект, затем через разрешённый API читает актуальный заказ; проверяет коммерческий допуск, строки, единицы и назначенный склад.
  3. После сопоставления корпоративных кодов с клиентом и складом Skirbo принимается одно задание нужной версии. Оператор выполняет физическую сборку.
  4. Skirbo возвращает фактические количества и идентификатор исполнения через отдельный согласованный контракт обратной связи.
  5. ERP подтверждает приём конкретного результата; это подтверждение хранится отдельно от получения события и успешного чтения заказа.
  6. Дубликат события, недоступный API или новая версия заказа не запускают повторную выдачу. Событие остаётся на разборе/повторном чтении, пока не определён принятый бизнес-результат.

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

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

Бизнес-событие → чтение заказа → подтверждённое исполнение

Задача: Не выполнять складскую команду по одному факту доставки уведомления.

Когда начинается: SAP формирует предусмотренное проектом событие создания или изменения Sales Order.

  1. SAP формирует предусмотренное проектом событие создания или изменения Sales Order.
  2. Получатель идентифицирует tenant и объект, затем через разрешённый API читает актуальный заказ; проверяет коммерческий допуск, строки, единицы и назначенный склад.
  3. После сопоставления корпоративных кодов с клиентом и складом Skirbo принимается одно задание нужной версии. Оператор выполняет физическую сборку.
  4. Skirbo возвращает фактические количества и идентификатор исполнения через отдельный согласованный контракт обратной связи.
  5. ERP подтверждает приём конкретного результата; это подтверждение хранится отдельно от получения события и успешного чтения заказа.
  6. Дубликат события, недоступный API или новая версия заказа не запускают повторную выдачу. Событие остаётся на разборе/повторном чтении, пока не определён принятый бизнес-результат.

Результат: Событие приводит к одному разрешённому исполнению с проверенным учётным ответом.

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

  • Пример SAP подтверждает чтение заказа, но не выбранный endpoint записи отгрузки Skirbo.

Изменение заказа во время сборки

Задача: Согласовать корпоративную версию с уже начатой физической операцией.

Когда начинается: Приходит новое событие по тому же Sales Order.

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

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

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

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

Новый склад и отдельные разрешения

Задача: Подключить ещё один склад без расширения доступа на все объекты.

Когда начинается: Корпоративная команда определяет организацию, коды мест хранения и область API для нового маршрута.

  1. Корпоративная команда определяет организацию, коды мест хранения и область API для нового маршрута.
  2. Таблица соответствий ограничивает новый склад разрешённым клиентом, а технический пользователь проверяется на нужные операции.
  3. На контрольном заказе подтверждают прямую передачу, обратный результат и отказ на чужую организацию.

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

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

  • Communication arrangement разрешает API, но не заменяет прикладную проверку владельца заказа.

Возврат после учётной отгрузки

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

Когда начинается: Владелец заказа разрешил возврат конкретной строки ранее принятого исполнения.

  1. ERP назначает разрешённую строку и количество возврата, исходный документ и ответственное юридическое лицо.
  2. Интеграционный контур сопоставляет товар, единицу, владельца и склад приёмки; маршрут определяется согласованным контрактом.
  3. Skirbo создаёт ожидаемую приёмку; само разрешение не увеличивает фактический или доступный остаток.
  4. Сотрудник принимает поступивший товар, сверяет количество, фиксирует повреждение и годность.
  5. Факт с отдельным ID возврата передаётся через выбранный контракт ERP; его API и права проверяются отдельно от чтения Sales Order.
  6. Учётная сторона подтверждает принятый документ; при потере ответа перед повтором проверяется уже созданная запись.
  7. Расхождение количества, карантин и финансовую корректировку разрешают назначенные владельцы; исходная отгрузка остаётся в истории.

Результат: Один возвратный факт имеет собственное учётное подтверждение и связан с исходным исполнением.

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

  • Спецификация возврата пока не прочитана; при отсутствии API возможен только отдельно согласованный операторский этап.

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

ДанныеОтветственный источникПравило обмена
ЗаказSAP S/4HANAАктуальный объект читается после события.
SKUКорпоративный справочникМатериал/вариант и единица сопоставляются с физическим SKU.
ОстаткиSkirbo — факт; ERP — корпоративный учётОбласти складов и владельцев задаются отдельно.
СтатусыERP и склад каждый в своём процессеПолучение события не означает принятие заказа складом.
ДокументыSAP/корпоративный ЭДООбратная запись и проведение требуют своих полномочий.
ВозвратыERP — решение; склад — осмотрВозвратный документ и физическая приёмка не смешиваются.

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

  • Какой объект читается после события?
  • Что разрешает заказ к физическому исполнению?
  • Как ERP подтверждает обратный факт склада?
Перед оценкой

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

  • Редакция, версия и способ развёртывания S/4HANA.
  • Communication arrangement и разрешённые сценарии API.
  • Контракт события, чтения заказа и обратного результата.
  • Карта организаций, материалов, единиц и мест хранения.
Границы сценария

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

  • SAP_COM_0121 и SAP_COM_0109 приведены в конкретном официальном примере; их наличие у клиента не предполагается.
  • Доставка события, его порядок и право записи отгрузки не доказаны прочитанной страницей.
  • Не установлены числовые квоты, SLA, сроки внедрения и лицензии.
  • Критические учётные изменения требуют согласованного владельца процесса.
Стоимость и запуск

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

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

Предоставьте редакцию S/4HANA, выбранный communication scenario и обезличенные событие/заказ — определим разрешённое чтение и контракт учётного ответа.

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

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

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

Communication arrangement уже даёт доступ ко всему SAP?

Нет. В примере он связывает конкретную систему, пользователя и API-сценарии. Прикладные права и нужные объекты проверяются отдельно.

Почему обратная запись ещё не описана endpoint?

Прочитанная страница подтверждает чтение Sales Order. Метод складского исполнения зависит от редакции и процесса клиента; выдавать неподтверждённый endpoint было бы неверно.

Возврат можно провести через тот же API, который читает Sales Order?

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

Позднее уведомление изменит уже собранный заказ?

В предлагаемом процессе сначала перечитывают заказ и сравнивают его с принятой версией. После физической выдачи изменение согласует владелец ERP; старое событие не создаёт повторную выдачу и не стирает складской факт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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