Обсудить задачу
Интернет-магазины

Skirbo +
Shop2YOU

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

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

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

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

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

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

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

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

Доступность вариантаSkirbo → Shop2YOUНужна проверка

Исключить перезапись наличия вторым модулем 1С или МойСклад.

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

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

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

Shop2YOU — платформа интернет-магазина, которую рассматриваем вместе с реально включёнными модулями обмена клиента. Польза для продавца и фулфилмента — один маршрут заказа через существующий учёт и сопоставление товарных вариантов без повторного резервирования.

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

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

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

  1. Инвентаризируем активные модули и выбираем источник складской команды: сам магазин либо существующий учётный контур. Второй маршрут остаётся сверочным и не создаёт заданий.
  2. Получаем разрешённую редакцию заказа с исходными строками, вариантами, количеством и доставкой через подтверждённый модуль либо операторскую ведомость.
  3. Сопоставляем код товара и опцию с SKU клиента фулфилмента; номер заказа дополняем идентификатором магазина. Не определяем вариант по одному отображаемому названию.
  4. Skirbo резервирует на выбранном складе, собирает и записывает фактические строки. Менеджер отдельно отвечает за оплату и коммерческое согласование замены.
  5. Отправляем результат по тому же согласованному маршруту, сохраняя исходные строки и номер отправления. Если ERP владеет заказом, магазин получает результат через неё.
  6. Проверяем отражение отгруженного количества и трека в авторитетной системе; оператор может подтвердить принятую ведомость, пока автоматический метод не проверен.
  7. При повторном импорте обновляем связь, а при новой редакции после отбора передаём расхождение оператору. Уведомление покупателю не считается подтверждением фактической отгрузки.

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

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

Один путь заказа при уже работающем учётном обмене

Задача: Не собрать заказ дважды из магазина и ERP.

Когда начинается: Заказ Shop2YOU допущен менеджером или согласованным правилом оплаты к исполнению.

  1. Инвентаризируем активные модули и выбираем источник складской команды: сам магазин либо существующий учётный контур. Второй маршрут остаётся сверочным и не создаёт заданий.
  2. Получаем разрешённую редакцию заказа с исходными строками, вариантами, количеством и доставкой через подтверждённый модуль либо операторскую ведомость.
  3. Сопоставляем код товара и опцию с SKU клиента фулфилмента; номер заказа дополняем идентификатором магазина. Не определяем вариант по одному отображаемому названию.
  4. Skirbo резервирует на выбранном складе, собирает и записывает фактические строки. Менеджер отдельно отвечает за оплату и коммерческое согласование замены.
  5. Отправляем результат по тому же согласованному маршруту, сохраняя исходные строки и номер отправления. Если ERP владеет заказом, магазин получает результат через неё.
  6. Проверяем отражение отгруженного количества и трека в авторитетной системе; оператор может подтвердить принятую ведомость, пока автоматический метод не проверен.
  7. При повторном импорте обновляем связь, а при новой редакции после отбора передаём расхождение оператору. Уведомление покупателю не считается подтверждением фактической отгрузки.

Результат: Существующий обмен магазина и новая складская ветка работают без двойной сборки.

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

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

Вариант товара и публикуемый остаток

Задача: Сохранить размер, цвет и владельца запаса при обмене.

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

  1. Проверяем, какой код выдаёт установленный модуль для варианта и какие атрибуты только описательные.
  2. Формируем соответствие вариант–SKU–склад и публикуем рассчитанное свободное количество через одного владельца наличия.
  3. Сверяем конкретный вариант на витрине; отсутствующие коды исключаем из автоматического обновления до разбора.

Результат: Остаток размера не попадает в соседний вариант.

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

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

Частичная отправка и изменение доставки

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

Когда начинается: Собрана только часть разрешённых строк или изменён перевозчик.

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

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

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

  • Возможность нескольких отправлений в API/модуле нужно подтвердить примером.

Проверка CommerceML2 перед подключением склада к существующему учёту

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

Когда начинается: В магазине включён плагин 1С/МойСклад, и владелец решил добавить складское исполнение через действующую учётную систему.

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

Результат: Действующий обмен магазина и учёта получает проверенный состав данных, а новый складской процесс не дублирует его команды.

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

  • CommerceML2 плагина не объявляется готовым протоколом Skirbo; запись частичной отгрузки и нескольких отправлений всё ещё требует актуального контракта и примера.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиShop2YOU либо связанная ERP по выбранной схемеНазначается один источник команд, остальные стороны только получают его состояние.
SKU и вариантыУчёт клиента и каталог магазинаКод варианта проверяется на реальной выгрузке, описательные опции не создают SKU автоматически.
Остатки и резервНазначенный складской учётРезерв не вычитают независимо два подключённых модуля.
СтатусыМагазин для коммерции, Skirbo для физического этапаСтатус оплаты, отгрузки и вручения не объединяются.
ДокументыERP/кассовый сервис клиентаПодключённый модуль документов не означает автоматический документооборот Skirbo.
ВозвратыМенеджер и принимающий складВозврат получает связь с исходной строкой и отдельное решение по годности.

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

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

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

  • Список включённых модулей Shop2YOU и подтверждённый канал экспорта/импорта заказов.
  • Пример заказа с вариантами товара и изменением состава.
  • Единый владелец остатков и ответственный за статусы оплаты.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Для CommerceML2 — обезличенная контрольная выгрузка с внешними кодами, журнал тестового импорта, выбранный режим наличия и статусы выгрузки заказов.
Границы сценария

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

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

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

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

Как работать, если магазин уже связан с МойСклад?

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

Как работать, если магазин уже связан с МойСклад?

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

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

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

Что включить в контрольный заказ перед запуском?

Два физических варианта, частичную отправку и правку состава после передачи. Так проверяются карта SKU, обратный маршрут и защита от повторной команды существующего модуля.

Трек уже появился в магазине — заказ можно считать доставленным?

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

Почему товар с нулевым количеством может выглядеть доступным после импорта?

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

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

Нет. Она подтверждает направление заказа в 1С/МойСклад. Обратное исполнение, несколько отправлений и их подтверждение проверяются отдельно для установленного модуля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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