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

Skirbo +
Microsoft Dynamics 365 Business Central

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

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

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

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

ОперацияНаправлениеСостав и готовность
Заказ продажиBusiness Central → SkirboОбсудим в составе подключения

Выбрать допущенный документ нужной company и строки физических товаров.

Фактическая отгрузкаSkirbo → Business CentralНужна проверка

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

Сверка номенклатуры и наличияBusiness Central ↔ SkirboОбсудим в составе подключения

Связать item, вариант, единицы и location; зафиксировать источник каждого значения.

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

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

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

Microsoft Dynamics 365 Business Central — учётный контур, отличный от Dynamics 365 Sales. Рассматриваем заказ продажи в конкретной company/environment и его физическое исполнение на складе. Проведение учётного документа имеет отдельные последствия и не запускается автоматически по факту упаковки.

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

Проверить online/on-premises, API-enabled и права в company. Используем документированный доступ приложения текущей версии; роль чтения заказа не означает право ShipAndInvoice. Стандартная страница Extensible=false требует проверки custom AL-контракта для дополнительных полей.

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

  1. Определяем tenant/environment/company и читаем заказ выбранным API-контрактом. Сохраняем Id и внешнюю ссылку, а видимый номер не используем как глобальный ключ всех компаний.
  2. Проверяем коммерческий допуск и строки, затем сопоставляем item, вариант, единицу и location с SKU клиента и физическим складом. Коэффициенты единиц утверждает учёт.
  3. Skirbo резервирует и комплектует фактические количества; частичная партия фиксируется отдельно от заказанного объёма.
  4. Передаём факт по согласованному интерфейсу учёта с исходными строками и единицами. Не вызываем ShipAndInvoice только потому, что упаковка завершена.
  5. Уполномоченный процесс Business Central проверяет допустимость проведения, дату, количества и документы. Если нужен другой способ частичного исполнения, его API/AL-контракт подтверждается отдельно.
  6. Склад получает ссылку на принятый учётный результат и сверяет строки/количества. Принятие факта и проведение документа сохраняются как два разных подтверждения.
  7. При закрытом периоде, конфликте единиц, отсутствии location или ошибке проведения физическая партия не создаётся повторно. Расхождение разбирает ответственный за учёт, а отправка товара фиксируется независимо.

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

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

Заказ продажи и фактическая складская партия

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

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

  1. Определяем tenant/environment/company и читаем заказ выбранным API-контрактом. Сохраняем Id и внешнюю ссылку, а видимый номер не используем как глобальный ключ всех компаний.
  2. Проверяем коммерческий допуск и строки, затем сопоставляем item, вариант, единицу и location с SKU клиента и физическим складом. Коэффициенты единиц утверждает учёт.
  3. Skirbo резервирует и комплектует фактические количества; частичная партия фиксируется отдельно от заказанного объёма.
  4. Передаём факт по согласованному интерфейсу учёта с исходными строками и единицами. Не вызываем ShipAndInvoice только потому, что упаковка завершена.
  5. Уполномоченный процесс Business Central проверяет допустимость проведения, дату, количества и документы. Если нужен другой способ частичного исполнения, его API/AL-контракт подтверждается отдельно.
  6. Склад получает ссылку на принятый учётный результат и сверяет строки/количества. Принятие факта и проведение документа сохраняются как два разных подтверждения.
  7. При закрытом периоде, конфликте единиц, отсутствии location или ошибке проведения физическая партия не создаётся повторно. Расхождение разбирает ответственный за учёт, а отправка товара фиксируется независимо.

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

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

  • Точный контракт partial shipment и влияние расширений подлежат проверке; standard salesOrders не гарантирует всю нужную складскую семантику.

Единицы, варианты и несколько company/location

Задача: Не смешать учёт разных организаций и площадок.

Когда начинается: Появился новый item/variant либо меняется единица продажи.

  1. Карта включает company, item, variant, unit of measure и location, а также владельца товара в Skirbo.
  2. Пересчёт количества и допустимость неполной упаковки подтверждаются учётом до первого заказа.
  3. Контрольная партия сверяет единицы и остаток по выбранной location; совпадение номера товара в другой company не объединяет запас.

Результат: Фулфилмент корректно обслуживает несколько организаций и складов.

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

  • Наличие стандартного API не означает доступ всех перечисленных объектов без дополнительных страниц.

Возврат с отдельным учётным решением

Задача: Связать осмотр товара с корректным документом возврата.

Когда начинается: Продавец согласовал возврат ранее отгруженной строки.

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

Результат: Возврат не сводится к отрицательной отгрузке или произвольному изменению invoice.

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

  • Нужный API возврата и права проведения проверяются отдельно от salesOrders.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиBusiness Central companyКоммерческий и учётный заказ принадлежит конкретной компании/среде.
SKU и вариантыBusiness Central item/variant/UOM и карта клиентаСклад не меняет коэффициенты единиц по предположению.
Остатки и резервСогласованный учёт location и физический складФизический факт, резерв и проведённое движение различаются.
СтатусыBusiness Central и SkirboФактическая сборка, отгрузка и бухгалтерское проведение подтверждаются отдельно.
ДокументыBusiness Central/уполномоченный учётный сотрудникShipAndInvoice имеет последствия для отгрузки и проведённого счёта; склад не назначается владельцем этого решения автоматически.
ВозвратыУчёт и склад осмотраДокумент возврата и фактическая годность имеют отдельные подтверждения.

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

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

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

  • Deployment online/on-premises, environment/company и доступные API-страницы.
  • Карта item, вариантов, единиц, locations и используемых расширений.
  • Правило допуска заказа и способ проверки проведённого результата отгрузки.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

  • API могут отличаться из-за расширений и настроек on-premises.
  • Количество, собранное складом, и проведённый учётный документ имеют разные моменты подтверждения.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
Стоимость и запуск

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

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

Зачем указывать company, если номер заказа уже известен?

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

Зачем указывать company, если номер заказа уже известен?

Документы и справочники относятся к конкретной компании. Внешнее соответствие должно исключить передачу заказа и остатка другой юридической сущности.

Будет ли склад сразу проводить документ в учёте?

Это отдельное проектное решение. Сначала согласуем документ, проверку строк и права, затем определим автоматическое или ответственное проведение.

Business Central и Dynamics 365 Sales — одна интеграция?

Нет. Здесь рассматривается учёт, продажи и проведение документов Business Central. Dynamics 365 Sales работает в CRM-процессе Dataverse и имеет отдельную карточку.

Почему нельзя подтвердить сборку действием ShipAndInvoice?

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

Флаг partialShipping уже решает частичную отгрузку?

Он описывает предпочтение заказа. Для складского факта нужен проверенный способ передачи частичного количества и отдельное решение о проведении.

В ответе 204 нет номера документа. Чем закрывать обмен?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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