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

Skirbo +
Платформа КБ / Клиентская база

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

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

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

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

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

Схема определяется ID пользовательских таблиц и полей.

Фактическое исполнениеSkirbo → КБОбсудим в составе подключения

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

Основания документовSkirbo → процесс документов КБОбсудим в составе подключения

Передавать факт и связи; не обещать подписанный ЭДО-документ.

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

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

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

Рассматривается конкретная конфигурация Платформы КБ. Таблица «Заказы» и её поля могут быть созданы заказчиком; названия в интерфейсе нельзя считать фиксированными API-именами.

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

Для оценки доступны документированные операции API 2.0. Сначала сверяют ревизию и Pro-лицензию, затем права отдельного пользователя, ID таблиц/полей и чтение результата. Наличие API не подтверждает готовый коннектор Skirbo.

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

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

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

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

Запись заказа → связанные строки → сборка

Задача: Превратить настраиваемую CRM-запись в однозначное складское задание.

Когда начинается: Ответственный переводит запись КБ в согласованный статус допуска и фиксирует версию её состава.

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

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

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

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

Частичное исполнение и остаток заказа

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

Когда начинается: Склад подтверждает выполненную часть с привязкой к исходным строкам КБ.

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

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

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

  • Номер строки должен быть устойчивым при сортировке и редактировании таблицы.

Возврат и связанные документы

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

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

  1. Менеджер заводит согласованную запись возврата со ссылкой на исходную поставку.
  2. Склад проверяет пришедший товар и возвращает фактическое количество/состояние.
  3. КБ формирует или дополняет документ в рамках настроенного процесса; ответственный подтверждает корректность.

Результат: Возврат прослеживается по связанным записям.

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

  • Формирование файла не подтверждает его подписание или приёмку контрагентом.

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

ДанныеОтветственный источникПравило обмена
ЗаказЗапись КБ и её связанные строкиВерсия состава фиксируется до передачи.
SKUНазначенный каталог клиентаСвязь по ID, а не отображаемому названию поля.
ОстатокSkirboCRM-формула не изменяет физическое наличие.
СтатусыКБ — согласование; Skirbo — складНужна таблица допустимых переходов.
ДокументыНастроенный процесс КБ/учётная системаОтветственный утверждает значения и подпись.
ВозвратыСвязанная запись КБ + факт SkirboНедопоставка и возврат различаются.
Контакт и получательВыделенная таблица клиента КБCRM отвечает за актуальный контакт и согласованный адрес; склад получает минимальный снимок для конкретного исполнения.
Сделка и коммерческий допускОтветственный менеджер КБСогласование версии заказа, скидок и условий не выполняется складской записью результата.

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

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

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

  • Схема связанных таблиц с ID полей, типами и формулами.
  • Обезличенная запись заказа и пример частичного исполнения.
  • Роль технического пользователя с разрешёнными полями.
  • Ответственный за изменения пользовательской конфигурации.
  • Владелец аккаунта КБ, клиент фулфилмента и разрешённые склады зафиксированы раздельно; токен одного аккаунта не обслуживает чужие заказы.
  • Проверка чтения и обратной записи выделенной ролью, включая отказ доступа к чужой строке, выполняется до запуска.
Границы сценария

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

  • Прочитана документация API 2.0; применимость к ревизии, лицензии и пользовательским таблицам конкретного клиента ещё проверяется.
  • Формулы и события таблиц могут иметь побочные действия — их проверяют до записи.
  • Пользовательская таблица «Склад» не автоматически является владельцем физического остатка.
Стоимость и запуск

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

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

Покажите структуру таблиц «заказ — строки — товары» и нужные поля результата — подготовим карту обмена под вашу конфигурацию.

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

Почему недостаточно названий колонок?

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

Нужно переделать нашу CRM?

Цель первого сценария — использовать существующую структуру и добавить контролируемое соответствие. Если нет устойчивых строк заказа, это ограничение нужно устранить до автоматизации.

Можно вернуть статус в поле, где работает формула?

Только после проверки владельца и поведения формулы. Лучше выделить поля складского факта, чтобы не запустить циклическую перезапись.

Если токен читает таблицу, можно сразу писать складской результат?

Нет: чтение и запись проверяются отдельно на согласованной результатной записи. Администратор подтверждает права, действие формул и чтение записанного значения; расширять доступ на весь аккаунт ради одного отказа не следует.

Как обработать два одинаковых товара в разных строках?

Сохранить ID каждой исходной строки, её единицу и количество. Совпадение SKU не даёт права слить строки: у них могут различаться назначение, цена и документ возврата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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