Обсудить задачу
CRM

Skirbo +
Microsoft Dynamics 365 Sales

Не отправлять товар по одной только выигранной сделке. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

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

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

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

ОперацияНаправлениеСостав и готовность
Допущенная продажаDynamics 365 Sales → SkirboОбсудим в составе подключения

Определить, создаёт задание заказ, сделка или отдельная согласованная таблица.

Товарные строкиDynamics 365 Sales → SkirboНужна проверка

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

Результат склада для менеджераSkirbo → Dynamics 365 SalesОбсудим в составе подключения

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

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

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

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

Microsoft Dynamics 365 Sales рассматриваем как CRM-процесс на Dataverse. Выигранная opportunity не является складским заказом сама по себе. Для менеджера и фулфилмента полезен явный коммерческий допуск физических строк и обратная связь в связанном CRM-объекте. Эта тема не описывает Microsoft Dynamics 365 Business Central.

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

Описан Dataverse Web API, но OAuth/роль и business-unit область конкретного клиента проверяются по документации его environment. Роль должна разрешать нужные таблицы, строки и поля; CRUD на платформе не означает доступ всех данных Sales.

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

  1. Команда клиента определяет таблицу Sales/Dataverse, обязательные поля и явный признак коммерческого допуска. Opportunity, quote и order не считаются взаимозаменяемыми.
  2. Получаем запись и связанные товарные строки разрешённой ролью. Проверяем получателя, доставку, оплату по правилу клиента и полноту физических количеств.
  3. Сопоставляем product/variant или согласованный внешний код с SKU владельца товара и складом; услуги и свободный текст требуют отдельного решения и не попадают в подбор автоматически.
  4. Skirbo принимает одно задание на допущенную редакцию, резервирует и комплектует фактический объём. Изменение менеджером адреса после отбора не переписывает готовую посылку молча.
  5. Возвращаем строки результата и ссылку на отправление в согласованные поля либо связанную таблицу Dataverse. Не меняем стадию сделки или финансовое состояние без установленного бизнес-правила.
  6. Читаем принятое состояние CRM и проверяем, что серверные плагины/автоматизации не отклонили или не изменили смысл записи. Менеджер получает наблюдаемое подтверждение по исходной продаже.
  7. При повторном событии обновляем связь, при неизвестном SKU или конфликте редакций создаём задачу разбора в существующем процессе команды. Отмена после отправки становится процессом возврата, а не простым снятием галочки.

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

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

Явно допущенная продажа в складское задание

Задача: Не отправлять товар по одной только выигранной сделке.

Когда начинается: Менеджер утвердил выбранный CRM-документ и физические строки для передачи на склад.

  1. Команда клиента определяет таблицу Sales/Dataverse, обязательные поля и явный признак коммерческого допуска. Opportunity, quote и order не считаются взаимозаменяемыми.
  2. Получаем запись и связанные товарные строки разрешённой ролью. Проверяем получателя, доставку, оплату по правилу клиента и полноту физических количеств.
  3. Сопоставляем product/variant или согласованный внешний код с SKU владельца товара и складом; услуги и свободный текст требуют отдельного решения и не попадают в подбор автоматически.
  4. Skirbo принимает одно задание на допущенную редакцию, резервирует и комплектует фактический объём. Изменение менеджером адреса после отбора не переписывает готовую посылку молча.
  5. Возвращаем строки результата и ссылку на отправление в согласованные поля либо связанную таблицу Dataverse. Не меняем стадию сделки или финансовое состояние без установленного бизнес-правила.
  6. Читаем принятое состояние CRM и проверяем, что серверные плагины/автоматизации не отклонили или не изменили смысл записи. Менеджер получает наблюдаемое подтверждение по исходной продаже.
  7. При повторном событии обновляем связь, при неизвестном SKU или конфликте редакций создаём задачу разбора в существующем процессе команды. Отмена после отправки становится процессом возврата, а не простым снятием галочки.

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

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

  • Имена таблиц, статусов, полей и action не выдумываются; они определяются metadata и настройками конкретной среды.

Изменение адреса после начала сборки

Задача: Согласовать обещание менеджера с реальной посылкой.

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

  1. Сравниваем новую редакцию с принятой складом и фактическим этапом комплектации.
  2. До упаковки применяем разрешённую правку; после передачи перевозчику менеджер согласует переадресацию или возврат отдельным процессом.
  3. Решение и складской ответ записываются в связанный CRM-объект без автоматического изменения коммерческого исхода сделки.

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

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

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

Возврат и обращение менеджера

Задача: Показать фактический приход товара, не закрывая финансовое решение автоматически.

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

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

Результат: CRM, склад и учёт сохраняют разные роли при возврате.

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

  • Закрытие обращения или сделки не используется как доказательство финансового возврата.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиВыбранная таблица/процесс SalesКоммерческий допуск задаётся явно; выигранная opportunity его не заменяет.
SKU и вариантыCRM-каталог и учёт клиентаСвободные строки и product references проверяются на физический SKU.
Остатки и резервSkirbo/учёт складаCRM не назначается владельцем физического запаса без отдельного проекта.
СтатусыSales для коммерции, Skirbo для физического этапаСкладской результат пишется в согласованный объект без произвольной смены стадии сделки.
ДокументыERP/учёт продавцаDataverse-запись не заменяет проведение учётного документа.
ВозвратыCRM-обращение, склад и учётРазрешение, осмотр, документы и деньги имеют отдельные подтверждения.
Контакт и accountВладелец CRM-данных SalesСвязь заказчика, получателя и организации подтверждается в нужном environment; общий email не объединяет клиентов фулфилмента.
Opportunity и коммерческое решениеКоманда продаж SalesСтадии, согласование цены и признание продажи остаются в CRM; результат склада имеет отдельное основание и автора.

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

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

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

  • Среда Dataverse, выбранные таблицы Sales и права интеграционной роли.
  • Модель товарных строк и событие согласования на склад.
  • Поля результата и ответственный за коммерческий этап сделки.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Карта environment, tenant, business unit, организации продавца и разрешённых складов; области контактов и заказов проверяются независимо.
  • Metadata выбранных таблиц и схема результата, включая поддержку конкурентной записи; нельзя выводить разрешение из одного успешного чтения.
Границы сценария

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

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

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

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

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

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

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

Только если для этого этапа проверены состав, адрес и допуск. Часто нужен отдельный заказ или явное разрешение менеджера после коммерческого согласования.

Завершится ли сделка автоматически после отправки?

Лишь по отдельно согласованному правилу. Факт склада должен отражаться в полях исполнения, а коммерческий результат остаётся у владельца CRM.

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

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

Как обрабатывать строку без товарного идентификатора?

Свободное описание сначала сопоставляет ответственный. Услуга или текстовая строка не становится физическим SKU автоматически; до проверки сборка этой строки блокируется.

Почему ID товара не заменяет ID строки заказа?

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

Что делать при конфликте одновременных изменений?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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