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

Skirbo +
TotalCRM

Предлагаем оставить TotalCRM владельцем заказов каналов и публикации их статусов, а Skirbo — выбранного складского исполнения. Сначала проверим один процесс и роли, затем оценим доступный контракт обмена без двойного резерва или повторной отгрузки.

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

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

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

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

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

Складское исполнениеSkirbo → уполномоченный процесс TotalCRMОбсудим в составе подключения

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

Этикетка и поставкаTotalCRM → рабочее место упаковки / сверка SkirboОбсудим в составе подключения

Сверить заказ и стикер, а также открытость поставки; место фактической печати выбирается в проекте.

Расхождение, отмена и возвратTotalCRM / Skirbo → ответственный селлераОбсудим в составе подключения

Разобрать состояние заказа и физический факт, сохранив исходную поставку.

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

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

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

TotalCRM рассматривается как единое окно заказов/поставок и интеграций каналов. Заказ, строка, стикер, поставка и физическое складское движение имеют разные значения. Наличие функций упаковки не подтверждает готовую связь со Skirbo. Отдельный маршрут 1С-Битрикс не является универсальным API сторонней WMS.

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

Для TotalCRM подтверждены операторские процессы заказов и упаковки, отдельный CommerceML маршрут 1С-Битрикс и тарифное условие доступа к собственному API. Автоматический обмен со Skirbo оценивается после получения спецификации аккаунта. До этого возможен проверяемый операторский этап с явным регламентом и сверкой, без заявления готового коннектора.

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

  1. Селлер выбирает один канал и склад TotalCRM для первого процесса. Заказы площадок остаются в TotalCRM; ответственным за публикацию их статусов назначают только эту систему, чтобы Skirbo не отправлял параллельные команды в тот же кабинет.
  2. Через согласованный интерфейс, а на этапе проверки — уполномоченным оператором, получают один допущенный заказ: кабинет, организацию, номер, строки, количества, способ доставки и склад. Состав фиксируют до начала исполнения.
  3. Сопоставляют внешние товарные ключи, варианты, штрихкоды и единицы с SKU Skirbo; отдельно связывают ID заказа TotalCRM, номер площадки, клиента фулфилмента и склад. Неоднозначную строку отправляют на уточнение.
  4. Кладовщик выполняет физический подбор и упаковку в одном выбранном процессе. Если физический факт ведёт Skirbo, его не создают повторно как независимое движение в другом складском контуре.
  5. Уполномоченный оператор TotalCRM получает проверенный результат. Внутренний этап «На сборке» отделяют от действия «Отгрузить», которое по инструкции затрагивает маркетплейс и получение этикетки; автоматическая замена этого действия будущим API требует отдельной приёмки.
  6. Сверяют номер заказа и стикер, полный состав и связь с поставкой. Для заказа с несколькими единицами частичный подбор не считается полной упаковкой; сбой печати не создаёт новый заказ.
  7. После готовности поставку закрывают, сохраняют передаточные документы и физически передают коробки перевозчику, ПВЗ или СЦ. Поздний заказ не добавляют в уже закрытую поставку; принятие на стороне площадки проверяют отдельно.
  8. Если возникло состояние «Спорные», потерян ответ или статус площадки расходится, оператор сопоставляет существующие заказ и поставку с фактом Skirbo. Повтор не создаёт вторую отгрузку, не перезаписывает принятую отмену и не подменяет физическую приёмку.

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

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

Заказ TotalCRM → физическая сборка → поставка и приёмка

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

Когда начинается: Селлер выбирает один канал и склад TotalCRM для первого процесса. Заказы площадок остаются в TotalCRM; ответственным за публикацию их статусов назначают только эту систему, чтобы Skirbo не отправлял параллельные команды в тот же кабинет.

  1. Селлер выбирает один канал и склад TotalCRM для первого процесса. Заказы площадок остаются в TotalCRM; ответственным за публикацию их статусов назначают только эту систему, чтобы Skirbo не отправлял параллельные команды в тот же кабинет.
  2. Через согласованный интерфейс, а на этапе проверки — уполномоченным оператором, получают один допущенный заказ: кабинет, организацию, номер, строки, количества, способ доставки и склад. Состав фиксируют до начала исполнения.
  3. Сопоставляют внешние товарные ключи, варианты, штрихкоды и единицы с SKU Skirbo; отдельно связывают ID заказа TotalCRM, номер площадки, клиента фулфилмента и склад. Неоднозначную строку отправляют на уточнение.
  4. Кладовщик выполняет физический подбор и упаковку в одном выбранном процессе. Если физический факт ведёт Skirbo, его не создают повторно как независимое движение в другом складском контуре.
  5. Уполномоченный оператор TotalCRM получает проверенный результат. Внутренний этап «На сборке» отделяют от действия «Отгрузить», которое по инструкции затрагивает маркетплейс и получение этикетки; автоматическая замена этого действия будущим API требует отдельной приёмки.
  6. Сверяют номер заказа и стикер, полный состав и связь с поставкой. Для заказа с несколькими единицами частичный подбор не считается полной упаковкой; сбой печати не создаёт новый заказ.
  7. После готовности поставку закрывают, сохраняют передаточные документы и физически передают коробки перевозчику, ПВЗ или СЦ. Поздний заказ не добавляют в уже закрытую поставку; принятие на стороне площадки проверяют отдельно.
  8. Если возникло состояние «Спорные», потерян ответ или статус площадки расходится, оператор сопоставляет существующие заказ и поставку с фактом Skirbo. Повтор не создаёт вторую отгрузку, не перезаписывает принятую отмену и не подменяет физическую приёмку.

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

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

  • Действие «Отгрузить» не повторяется вслепую после тайм-аута.
  • Неизвестный SKU или чужой склад останавливает передачу до исправления.

Недостача, многопозиционный заказ и сбой печати

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

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

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

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

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

  • Доступный в интерфейсе ручной перевод статуса не заменяет фактическую проверку комплектности.

Спорный статус, отмена или возврат

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

Когда начинается: Ответственный получает расхождение статусов либо запрос отмены, связывает его с заказом и существующей поставкой.

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

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

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

  • Наличие API не устанавливает бизнес-право отмены на каждом этапе площадки.

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

ДанныеОтветственный источникПравило обмена
Заказ канала и внешний номерTotalCRM / исходная площадкаСохранять одновременно внутреннюю и внешнюю идентичность, кабинет и организацию.
Товар, вариант и единицаНазначенный мастер-каталог клиентаВнешний код или артикул проверяется на уникальность в контексте канала и SKU.
Резерв и физическое исполнениеОдна выбранная складская системаВ предлагаемой связке факт ведёт Skirbo; не создавать второй независимый резерв.
Статусы площадки и доступный остаток каналаНазначенный publisher; в первом сценарии TotalCRMSkirbo возвращает факт владельцу, не отправляет параллельные изменения.
Стикер и поставкаTotalCRM / соответствующий каналЗаказ и поставка различаются; каждый стикер сверяется с заказом.
Физическая передача и приёмкаСклад / перевозчик / площадкаСмена внутреннего статуса не заменяет подтверждение принимающей стороны.
Спорный заказ и возвратОтветственный селлера; склад подтверждает фактКлиентская отмена, внешнее разрешение и физическое поступление — разные события.

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

  • Кто единственный отправляет статусы и остатки в каждый кабинет?
  • Какая система владеет резервом, подбором и упаковкой в выбранном процессе?
  • Какие методы API читают строки и записывают факт без побочного создания поставки?
  • Как сопоставляются внутренний заказ, номер площадки, этикетка и поставка?
  • Кто принимает решение при «Спорные», поздней отмене и недостаче?
Перед оценкой

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

  • Указать кабинет TotalCRM, организацию, канал продаж, способ доставки и один склад для первого сценария.
  • Получить действующий доступ к API и спецификацию методов, ролей, событий, лимитов и подтверждений; коммерческое право доступа само по себе не раскрывает контракт.
  • Предоставить обезличенный заказ с несколькими строками, вариантами, единицами и номером площадки, а также его поставку и этикетку.
  • Назначить единственного владельца публикации статусов/остатков в каждый кабинет и владельца резервов; согласовать отключение дублирующих действий в проекте.
  • Выбрать, где выполняются подбор, упаковка и печать; подтвердить права оператора и ответственного за спорные/отменённые заказы.
Границы сценария

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

  • Методы собственного API, авторизация, пагинация и гарантии событий не установлены по доступному входу документации; endpoint и поля не выдумываются.
  • Статус готовности к отгрузке и получение этикетки не доказывают, что товар физически передан и принят площадкой.
  • Частично обработанный заказ нельзя объявить полностью упакованным; перенос остатка и повторная печать — разные операции.
  • Два независимых владельца резервов или статусов одного заказа создают риск двойного исполнения; архитектура выбирается до подключения.
  • Инструкция CommerceML относится к конкретной связке с 1С-Битрикс; не подтверждает готовый обмен Skirbo или универсальную семантику всех складских документов.
  • Маркетинговые показатели скорости/точности и список исторических перевозчиков не приняты как гарантии текущего подключения.
Стоимость и запуск

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

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

Выберите один канал и покажите цепочку «заказ — сборка — стикер — поставка — приёмка»; согласуем владельцев и точные методы для первого обмена со Skirbo.

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

Чем «На сборке» отличается от «На отгрузке»?

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

Закрытая поставка уже принята маркетплейсом?

Нет. После закрытия ещё требуется физическая передача. Принятие заказов площадкой проверяют отдельно; в закрытую поставку новые заказы не добавляются.

Можно оставить TotalCRM и одновременно подключить Skirbo напрямую к тому же кабинету?

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

Что делать, если заказ упакован, но принтер не выдал этикетку?

Сначала сверить сохранённое состояние заказа. В инструкции есть отдельная повторная печать стикера; ошибка печати не является основанием создавать новую отгрузку.

Раз доступ к API есть в PRO, можно сразу обещать подключение?

Нет. Нужно прочитать конкретные методы и права аккаунта, проверить строки заказа, переходы и восстановление ошибок. Тарифное указание подтверждает условие доступа, а не готовность коннектора Skirbo.

Как обработать возврат после отгрузки?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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