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

Skirbo +
2can — товароучёт

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

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

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

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

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

Подтверждены чтение списка и деталей; области базы и склада сопоставляются.

Товарные соответствия2can → справочник интеграцииОбсудим в составе подключения

product_id, external_id, SKU и единицы служат проверяемыми ключами.

Складской статусSkirbo → 2canОбсудим в составе подключения

Предлагается mzs_id после фактического события и проверки разрешённого перехода.

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

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

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

Рассматривается my2can Inventory API: заказы и товарный справочник из официальной wiki. Это товароучётный контур 2can, а не универсальный API карточного эквайринга. Примеры исторические; схемы создания заказа и временных фильтров имеют расхождения, которые нужно проверить.

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

Подтверждён HTTP API с token в заголовке. Для первого проекта выбран контур чтения заказов/товаров и согласованного статуса; создание операций не переносится из противоречивых примеров без дополнительной проверки.

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

  1. Получить согласованный список заказов, затем детали нужного ID. Сохранить базу, клиента, store_id и внешнюю связь; список сам по себе не всегда содержит полный состав.
  2. Сопоставить product_id, SKU/штрихкод и единицу. Услуга, скидка и комплект не превращаются в обычную единицу отбора; состав комплекта проверяется отдельно.
  3. Склад резервирует и собирает реальные товары по своему регламенту. Неизвестный вариант, размер или коэффициент упаковки останавливает строку, а не списывает похожий SKU.
  4. После завершения этапа выбрать согласованный mzs_id из действующего справочника. Статус «собран» и физически «отправлен» требуют разных событий склада.
  5. Передать обновление статуса, проверить успешный ответ с ID и перечитать состояние по согласованному правилу. Только подтверждённое соответствие закрывает передачу результата.
  6. При отмене или более новом состоянии сверить фактическую стадию и не вернуть заказ назад запоздалым сообщением. При потере ответа проверить состояние до повторного изменения.

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

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

Собрать заказ и подтвердить статус в 2can

Задача: Отразить складское выполнение, не создать фиктивный товарный приход из общих параметров API.

Когда начинается: В 2can появился заказ, который должен выполнить выбранный склад.

  1. Получить согласованный список заказов, затем детали нужного ID. Сохранить базу, клиента, store_id и внешнюю связь; список сам по себе не всегда содержит полный состав.
  2. Сопоставить product_id, SKU/штрихкод и единицу. Услуга, скидка и комплект не превращаются в обычную единицу отбора; состав комплекта проверяется отдельно.
  3. Склад резервирует и собирает реальные товары по своему регламенту. Неизвестный вариант, размер или коэффициент упаковки останавливает строку, а не списывает похожий SKU.
  4. После завершения этапа выбрать согласованный mzs_id из действующего справочника. Статус «собран» и физически «отправлен» требуют разных событий склада.
  5. Передать обновление статуса, проверить успешный ответ с ID и перечитать состояние по согласованному правилу. Только подтверждённое соответствие закрывает передачу результата.
  6. При отмене или более новом состоянии сверить фактическую стадию и не вернуть заказ назад запоздалым сообщением. При потере ответа проверить состояние до повторного изменения.

Результат: Состояние 2can соответствует проверенному этапу работы конкретного склада.

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

  • Наличие признака оплаты или отгрузки в примере не заменяет согласованный словарь состояний клиента.

Обновить справочник без потери вариантов

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

Когда начинается: Изменился каталог 2can.

  1. Получить изменения товаров, проверить external_id и признаки удаления.
  2. Сопоставить единицы и коэффициенты с базовой единицей Skirbo; неоднозначные записи вынести в разбор.
  3. Обновить таблицу соответствий после контрольной проверки заказов.

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

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

  • count/limit и временной фильтр в примерах расходятся; пагинацию сначала проверить.

Разобрать отмену после сборки

Задача: Не трактовать статус как автоматический возврат товара.

Когда начинается: Из 2can пришло отменённое состояние.

  1. Проверить, остаётся ли заказ на складе или уже передан.
  2. До передачи снять задание и резерв по регламенту; после передачи открыть процесс фактического возврата.
  3. Возвратить в 2can подтверждённый результат только после решения ответственного.

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

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

  • Отдельный API физического возврата и финансовых операций этой статьёй не подтверждён.

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

ДанныеОтветственный источникПравило обмена
Заказ и торговые условия2can / продавецИзменение состава согласуется до выдачи.
SKU и тип позиции2can / справочник клиентаУслуга и скидка не физический товар.
Остаток, резерв, факт выдачиSkirbo / выбранная учётная системаОдин владелец движения; автоматический приход из общих примеров не используется.
Статус2can и складской результатСловарь mzs_id согласуется с действующей базой.
Документы и возвратыПродавец / складЧтение заказа не подтверждает методы фискализации и возврата средств.
Доступ, версии и разбор ошибокНазначенные владельцы платформы, учёта и складаВладелец базы подтверждает область токена и разрешённые методы; интегратор ведёт соответствия base_id/store_id и версии товара; оператор склада подтверждает физическое событие. Права изменения оплаты и денежного возврата в эту оценку не включены.

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

  • Как сопоставлены статусы и какие переходы разрешены после выдачи?
  • Какие единицы и варианты встречаются в реальном заказе?
  • Как согласуются сводные типы 1–5 с digital product type=8 и stock_control в действующей базе?
Перед оценкой

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

  • API token, база, склад и проверенный словарь статусов.
  • Контрольные товары: обычный, услуга, комплект и вариант с единицей упаковки.
  • Проверка временного фильтра, пагинации и политики удаления.
  • Назначить владельца базы 2can и таблицы base/store/SKU/единица; сохранить одобренную версию соответствий для каждого принятого заказа.
  • Отдельно согласовать разрешённые читающие методы и обновление mzs_id; публичные примеры token не являются учётными данными проекта.
Границы сценария

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

  • Wiki содержит исторические примеры, не текущие лимиты или SLA.
  • Описание timestamp говорит о миллисекундах, пример похож на секунды; точную единицу необходимо проверить.
  • Параметры создания заказа и пример различаются; контур записи операций исключён до проверки.
  • Чтение по HTTP GET не гарантирует отсутствие записи: вспомогательные методы скидок/аванса из wiki исключены из первоначального контура.
  • Тип digital product=8 встречается в параметрах создания вне сводной таблицы Product types; правила импорта такого типа требуют отдельного подтверждения.
Стоимость и запуск

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

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

Какая база 2can, склад и набор статусов должны соответствовать вашему процессу сборки?

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

Это интеграция с эквайрингом 2can?

Нет. Исследован my2can Inventory API для заказов и товаров. Денежные операции требуют другого подтверждённого контракта.

Можно поставить статус «отправлен» сразу после сборки?

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

Любая позиция каталога — товар для отбора?

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

Можно копировать пример создания заказа?

До проверки не следует: таблица параметров и JSON-пример расходятся, а общий параметр autoprihod описывает автоматическое пополнение при нехватке. Он не должен создавать фиктивный запас склада.

Можно разрешить любые GET-запросы как безопасное чтение?

Нет: сохранённая wiki описывает создание отсутствующей скидки или аванса некоторыми GET helpers. Для первой связи выбирают только проверенные чтение заказа, списка и товарной карточки; остальные действия оценивают отдельно.

Что делать, если изменилась упаковочная единица уже принятого заказа?

Сохранить исходное сопоставление принятой строки и остановить спорную новую версию. Владелец справочника согласует коэффициент и количества; склад не пересчитывает уже выданный товар автоматически.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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