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

Skirbo +
SAP Business One

Предлагаем передавать разрешённые складские задания и возвращать по строкам фактические количества, серии или партии, если они нужны, с подтверждением принятого документа Business One.

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

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

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

ОперацияНаправлениеСостав и готовность
Документ-основание и строкиSAP Business One → SkirboОбсудим в составе подключения

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

Физическое исполнениеSkirbo → SAP Business OneОбсудим в составе подключения

Факт и связь с исходной строкой; конкретный API-объект уточняется.

Подтверждение учётаSAP Business One → журнал обменаОбсудим в составе подключения

ID принятого документа и предметные ошибки.

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

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

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

SAP Business One рассматривается отдельно от SAP S/4HANA. Выбор интерфейса зависит от конкретной версии, базы компании, feature package и локализации; Service Layer, DI API и UI API не взаимозаменяемы автоматически.

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

Официальный портал перечисляет Service Layer и DI API. Конкретный объект, операция и способ доступа выбираются после чтения справки установленной версии; наличие справочника таблиц не является разрешением на прямую запись в БД.

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

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

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

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

Основание Business One → выдача → принятый документ

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

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

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

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

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

  • Названия полей основания, строк и документа нельзя переносить из другой версии SAP без проверки API.

Партия или серия при приёмке

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

Когда начинается: Клиент определяет, какие SKU требуют серийного либо партионного учёта и в каких единицах.

  1. Клиент определяет, какие SKU требуют серийного либо партионного учёта и в каких единицах.
  2. Склад фиксирует идентификатор, количество и состояние в процессе приёмки; неполная идентификация исключает автоматический допуск спорной строки.
  3. Учётная команда принимает факт через подтверждённый объект и сверяет распределение по складам и партиям.

Результат: Складская партия не теряется при передаче в ERP.

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

  • Наличие руководства Serial/Batch не определяет настройки конкретного товара или API-формат распределения.

Возврат и исправление после закрытия периода

Задача: Разобрать физический приход без переписывания исторической выдачи.

Когда начинается: Учётная команда согласует возврат к исходной отгрузке и доступный документ текущего периода.

  1. Учётная команда согласует возврат к исходной отгрузке и доступный документ текущего периода.
  2. Склад принимает и осматривает товар, разделяет пригодные и спорные единицы.
  3. Возвратный факт проходит самостоятельное подтверждение Business One; финансовая корректировка и дальнейшая доступность товара утверждаются отдельно.

Результат: История первичной выдачи сохраняется, а возврат получает собственное основание.

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

  • Правила периодов и корректировок устанавливаются учётной политикой клиента; материал не задаёт их за ERP.

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

ДанныеОтветственный источникПравило обмена
ЗаказSAP Business One/владелец учётаСклад исполняет согласованную версию основания.
SKUСправочник клиента в ERPКоды, единицы и режим партий сопоставляются явно.
ОстаткиSkirbo — физика; Business One — учётСверка выполняется по компании, складу и партии.
СтатусыERP — документ; склад — операцияПринятие API и физическая выдача различаются.
ДокументыSAP Business OneПроведение и корректировка принадлежат учётному контуру.
ВозвратыERP — основание; склад — осмотрВозврат не стирает первоначальное исполнение.

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

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

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

  • Версия, feature package, SQL Server/HANA и локализация.
  • Выбранный API и схема разрешённых объектов.
  • Карта компаний, складов, единиц и партий.
  • Процедура ошибки периода и подтверждения документа.
Границы сценария

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

  • API SAP S/4HANA нельзя использовать как контракт Business One.
  • UI API не считается серверным каналом складского обмена без отдельного обоснования.
  • Не подтверждены методы, лимиты, лицензии и доступность конкретного Service Layer в среде клиента.
  • Прямая запись в таблицы БД не предлагается.
Стоимость и запуск

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

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

Подготовьте версию Business One, документ-основание с двумя строками и пример партии — определим интерфейс и доказательство учётного принятия.

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

Подойдёт один коннектор для SAP Business One и S/4HANA?

Это разные продукты и контракты. Возможна общая бизнес-модель обмена, но интерфейсы и приёмка проверяются отдельно.

Почему важны SQL Server/HANA и feature package?

Прочитанный портал сам разделяет варианты продукта. Перед разработкой нужно выбрать документацию, соответствующую установленной системе, и проверить нужные объекты.

Что делать, если склад отгрузил, а ERP отклонила документ?

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

Почему хранить DocEntry, если есть печатный номер?

В проекте ключ связывают с базой компании и типом документа. DocEntry и DocNum в справочнике разделены; номер на печатной форме не подменяет внутреннее соответствие.

Можно ли просто повторить запрос после нового Login?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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