Обсудить задачу
Автоматизация

Skirbo +
АКРИТ: Экспорт на порталы

Согласовать складской остаток, торговые предложения CMS и профиль выгрузки, а для редакции «+ API» — проверить путь заказа из выбранного кабинета до физического исполнения. Это проектирование, готовность коннектора Skirbo не подтверждена.

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

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

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

ОперацияНаправлениеСостав и готовность
Доступное количество и товарный вариантSkirbo → согласованный интерфейс CMS → профиль АКРИТ → площадкаОбсудим в составе подключения

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

Каталог и преобразование полей1С-Битрикс → профиль АКРИТ → товарный файл/поддержанный каналОбсудим в составе подключения

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

Заказ выбранного кабинета, только «+ API»Площадка → плагин acrit.exportproplus → CMS → SkirboНужна проверка

Нужны внешний ID, профиль, строки, коммерческий допуск и отдельный подтверждённый вход склада.

Физический результат, отмена и возвратSkirbo ↔ CMS/ответственный продавца ↔ конечный каналНужна проверка

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

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

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

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

Одна тема для линейки «АКРИТ: Экспорт на порталы» с явным различением acrit.exportpro и acrit.exportproplus. Она полезна продавцу с магазином на 1С-Битрикс и фулфилменту, который обслуживает его физический склад. Модуль используется в канале CMS; он не заменяет складскую приёмку и не означает уже доступное подключение Skirbo.

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

Подтверждены профили товарной выгрузки и, для «+ API», отдельная синхронизация заказов площадок с CMS. Файл, интерфейс площадки и вход внешней WMS различаются; универсальный REST API АКРИТ для Skirbo не установлен.

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

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

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

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

Складской остаток в товарной выгрузке CMS

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

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

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

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

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

  • Универсальный публичный API АКРИТ для внешней WMS не подтверждён. Способ Skirbo → CMS и право изменять количество определяются в проекте.

Заказ площадки через «+ API» и CMS на склад

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

Когда начинается: Плагин заказов редакции acrit.exportproplus получил заказ разрешённой площадки и создал либо обновил связанный заказ CMS.

  1. Проверяют установленный модуль, версию, конкретный плагин, кабинет продавца и модель исполнения. Этот процесс не применяется к младшей acrit.exportpro только из-за наличия пункта «Заказы» в меню.
  2. Сохраняют внешний ID заказа, место его хранения в CMS, профиль и кабинет. Существующее XML_ID или выбранное свойство рассматривают вместе с областью продавца; совпадающий номер другого кабинета не является тем же заказом.
  3. Согласованным интерфейсом CMS или операторским реестром передают в Skirbo заголовок, физические строки, количество, вариант, разрешённый склад и текущий коммерческий допуск. Неизвестное поле не подменяют по названию.
  4. Сверяют внешнюю строку с товаром/торговым предложением CMS и SKU владельца. Если один код найден у нескольких вариантов, оператор разрешает конфликт до резервирования.
  5. Skirbo принимает одну версию задания, резервирует, комплектует и фиксирует фактическую партию. Отдельно учитываются недостача, изменение заказа и товары, которые не требуют физической сборки.
  6. Факт исполнения возвращают в согласованный контур CMS, сохраняя ключ заказа, строку и партию. Передачу статуса, трека или этикетки на площадку включают только после проверки нужного плагина; иначе ответственный фиксирует результат через разрешённый кабинет.
  7. Перечитывают связанный заказ CMS и подтверждение конечного канала. Успешная запись промежуточного статуса не закрывает неподтверждённую отгрузку. Повтор синхронизации сверяется с принятой версией и существующей партией.

Результат: Маркетплейс, заказ CMS и складская партия имеют проверяемую связь и ответственного за обратный результат.

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

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

Повтор синхронизации и поздняя отмена

Задача: Восстановить пропуск заказа и не отменить физический факт одним повторным сообщением.

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

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

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

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

  • Автоматическое exactly-once, полнота восстановления и порядок событий платформой не подтверждены; это требования проектируемого контура.

Возврат и повторная публикация годного остатка

Задача: Разделить отмену, денежную компенсацию и физическую приёмку товара.

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

  1. Связывают возврат с кабинетом, исходным заказом площадки, заказом CMS, строкой и складской партией. Финансовый статус сам по себе не увеличивает физический запас.
  2. Склад принимает товар и фиксирует вариант, количество, комплектность и состояние. Неопознанный SKU либо повреждённая единица остаются отдельно до решения владельца.
  3. Продавец подтверждает финансовый результат по договору площадки. Фулфилмент подтверждает осмотр и количество, пригодное к продаже; обе записи имеют своих ответственных.
  4. После приёмки владелец запаса пересчитывает доступное количество. В CMS и профиль АКРИТ попадает уже согласованное значение, а не слепое увеличение на сумму refund.
  5. Проверяют результат выгрузки и принятие нового значения площадкой. Повтор сообщения по возврату сверяют с тем же ключом приёмки, исключая второе увеличение остатка.

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

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

  • API возвратов, финансового refund и документов отдельной площадки не подтверждён общей документацией модуля.

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

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

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

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

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

  • Код установленного модуля, редакция, версия, состояние лицензии и точное имя плагина/формата.
  • Сайт 1С-Битрикс, инфоблоки и торговые предложения, кабинет площадки и разрешённые роли без передачи ключей в публичной форме.
  • Один владелец доступного количества и карта SKU клиента ↔ торговое предложение ↔ идентификатор товара площадки.
  • Согласованный способ обмена Skirbo с CMS; он не следует автоматически из наличия модуля АКРИТ.
  • Обезличенные примеры: два варианта одного товара, нулевой остаток, заказ с изменением, повтор, частичная приёмка и возврат.
  • Ответственные за администрирование CMS, складской факт, коммерческое решение и проверку конечного приёма.
Границы сценария

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

  • Младшая acrit.exportpro и старшая acrit.exportproplus различаются; товарный фид не подтверждает обработку заказов, доставку или API возвратов.
  • В прочитанных документах нет подтверждённого универсального публичного WMS API модуля. Способ связи со Skirbo оценивается отдельно.
  • Сгенерированный файл или успешная задача профиля не доказывают, что площадка приняла нужный вариант и количество.
  • У общей инструкции заказов и сравнительной таблицы различается описание обратной синхронизации; нужна проверка конкретного плагина и версии.
  • Нельзя обещать мгновенность, exactly-once, SLA, полный набор маркетплейсов или срок подключения по общей странице продукта.
  • Для Казахстана, Узбекистана и других стран отдельно проверяют кабинет, договор, валюту и документы площадки; российские кассовые и маркировочные требования не переносятся автоматически.
Стоимость и запуск

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

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

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

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

У нас уже установлен «Экспорт на порталы». Этого достаточно для заказов Ozon или WB?

Сначала сверяем код модуля. Для acrit.exportpro подтверждена товарная выгрузка; заказной контур относится к acrit.exportproplus. Внутри старшей редакции проверяется конкретный плагин и нужная схема работы площадки.

Надпись «+ API» означает готовый API для подключения Skirbo?

Такой вывод не подтверждён. В этом контексте речь об обмене плагинов с площадками; способ доступа внешнего склада к CMS или модулю нужно определить отдельно.

Кнопка проверки показала правильные товары. Они уже появились на площадке?

Предпросмотр ещё не передаёт файл. В предлагаемой схеме отдельно фиксируются фактическая выгрузка и приём контрольных товаров конечным каналом.

Можно сопоставить товары по одинаковому названию?

Для складской сборки этого недостаточно. Согласуем устойчивую пару торгового предложения CMS и SKU клиента; размеры, цвета и единицы должны определяться однозначно.

Повторная синхронизация не создаст вторую сборку?

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

Статус «Отменён» автоматически возвращает товар на остаток?

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

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

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

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

Изучаем возможность: описана предметная схема согласования склада, CMS и профиля АКРИТ. Подключение Skirbo, принятый пилот и сроки не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

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

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

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

Весь каталог →
Изучаем возможность

Автоматизация

Albato

Связка внешних приложений со складским процессом через согласованный сценарий.

Сценарий подключения
Изучаем возможность

Автоматизация

Boomi Integration

Связь корпоративного интеграционного контура с операциями фулфилмента и контролем результата.

Сценарий подключения
Ваш процесс → следующий шаг

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

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

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

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

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

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

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

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

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

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

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

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