Обсудить задачу
Платежи

Skirbo +
aQsi

Сопоставить складские SKU и магазины с МойСклад/aQsi, сохранить один мастер товаров и сверять розничные возвраты с физическим поступлением на склад.

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

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

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

ОперацияНаправлениеСостав и готовность
Карточки товаровМойСклад → aQsiОбсудим в составе подключения

Подтверждённое направление; Skirbo связывает SKU с выбранным master.

Продажи, смены и возвратыaQsi → МойСкладОбсудим в составе подключения

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

Физические движенияSkirbo ↔ учётный контурОбсудим в составе подключения

Проектная сверка, исключающая повторное списание/приход.

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

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

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

Рассматривается документированная интеграция aQsi с МойСклад. Товары идут из МойСклад в aQsi, а смены, продажи и возвраты — в обратную сторону. Связь со Skirbo предлагается через уже выбранный учётный контур, чтобы не появилось два независимых источника карточек и движений. У aQsi также описан отдельный внешний API. Он рассматривается как альтернативный маршрут после проверки контракта, а не как второй параллельный редактор уже работающего справочника.

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

Основной сценарий опирается на документированную связь aQsi ↔ МойСклад. Прочитанная справка внешнего API подтверждает возможность отдельного прямого маршрута, но его полная схема не получена. Перед выбором одного пути фиксируются владельцы товаров и движений; готовность Skirbo не установлена.

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

  1. Определить master справочника в МойСклад и сопоставить его товар/модификацию с SKU Skirbo. Старые локальные карточки aQsi сначала инвентаризировать, не удалять автоматически по рекомендации из инструкции.
  2. Проверить привязку магазина aQsi к organization, warehouse и shop. Одинаковые названия складов не заменяют проверку ID и клиентской организации.
  3. Дождаться появления нужной карточки из МойСклад в aQsi и сверить контрольные SKU/штрихкоды. Склады комплектуют товар по согласованному справочнику.
  4. Кассир оформляет реальную продажу; результат возвращается в МойСклад по существующей интеграции. Склад отдельно фиксирует физическую выдачу и связывает её с продажей.
  5. Ответственный сверяет товарные строки, количество, организацию и склад результата. Только подтверждённое соответствие закрывает задачу передачи, а не сам факт закрытия смены.
  6. При отсутствии позиции в отчёте проверить происхождение карточки и связку. Повторная продажа или повторное складское списание не используются для исправления справочника.

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

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

Провести продажу с единым товарным соответствием

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

Когда начинается: Продавец готовит выдачу товара через кассу aQsi.

  1. Определить master справочника в МойСклад и сопоставить его товар/модификацию с SKU Skirbo. Старые локальные карточки aQsi сначала инвентаризировать, не удалять автоматически по рекомендации из инструкции.
  2. Проверить привязку магазина aQsi к organization, warehouse и shop. Одинаковые названия складов не заменяют проверку ID и клиентской организации.
  3. Дождаться появления нужной карточки из МойСклад в aQsi и сверить контрольные SKU/штрихкоды. Склады комплектуют товар по согласованному справочнику.
  4. Кассир оформляет реальную продажу; результат возвращается в МойСклад по существующей интеграции. Склад отдельно фиксирует физическую выдачу и связывает её с продажей.
  5. Ответственный сверяет товарные строки, количество, организацию и склад результата. Только подтверждённое соответствие закрывает задачу передачи, а не сам факт закрытия смены.
  6. При отсутствии позиции в отчёте проверить происхождение карточки и связку. Повторная продажа или повторное складское списание не используются для исправления справочника.

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

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

  • Изменения товарных позиций в aQsi не считаются автоматически переданными обратно в МойСклад.

Принять кассовый возврат физически

Задача: Не восстановить товарный остаток дважды в двух системах.

Когда начинается: В aQsi оформлен возврат продажи.

  1. Найти возвратный результат в учётной системе и связать его с исходной продажей.
  2. Склад принимает фактический товар, проверяет количество и состояние.
  3. Согласованный владелец учёта выполняет движение; другой контур отражает результат без повторного прихода.

Результат: Возвратный чек и складской осмотр согласованы.

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

  • Возврат в кассе не означает товар, пригодный к продаже.

Перевести старый ассортимент на единый мастер

Задача: Сохранить историю продаж при устранении дублей.

Когда начинается: У клиента есть товары, созданные непосредственно в aQsi.

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

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

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

  • Удаление по инструкции требует отдельного решения; оно не автоматизировано между продуктами.

Разобрать повтор результата без второго движения

Задача: Сохранить кассовую историю и не задвоить складской остаток.

Когда начинается: Учётная связка повторно показала продажу или возврат после восстановления связи.

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

Результат: Повтор виден в истории, а движение остаётся единственным.

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

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

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

ДанныеОтветственный источникПравило обмена
Заказ и ценыПродавец / учётная системаКассовый состав согласуется с выдачей.
Товар и модификацияМойСкладВ описанной связке создание и редактирование выполняются у master.
Остаток и резервОдин выбранный учётный контур / SkirboПравило движения определяют до включения возвратов.
Кассовые событияaQsiСмены, продажи и возвраты — источник для сверки в МойСклад.
Документы и физический возвратУчётная система и складДокументный и физический результат подтверждаются раздельно.

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

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

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

  • Рабочая связка aQsi–МойСклад, токен с согласованной областью и точные ID трёх объектов.
  • Таблица SKU, модификаций и штрихкодов, план старых локальных карточек.
  • Один владелец складского движения и процедура проверки кассовых строк.
  • Для прямого API администратор aQsi должен проверить создание отдельной внешней интеграции и область ключа. Сам ключ передаётся только в защищённой настройке.
  • Выбрать один маршрут записи товаров и один источник складского движения; не запускать одновременно независимые редакторы в aQsi и МойСклад.
Границы сценария

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

  • Это подтверждение интеграции aQsi с МойСклад, не готовности Skirbo.
  • Удаление товаров не распространяется автоматически; массовое удаление в этой работе не выполняется.
  • Скорость синхронизации, частичный возврат и точная схема API требуют проверки.
  • Наличие справки внешнего API не подтверждает полную схему документов, правила повторов и частичные возвраты. Полный API-портал требует дальнейшего чтения.
  • Для описанной связки organization — организация, warehouse — склад, shop — точка продаж МойСклад. Их одинаковые названия не делают ID взаимозаменяемыми.
Стоимость и запуск

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

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

Кто сейчас ведёт товарный справочник и как связаны организация, склад и точка продаж в aQsi?

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

Можно вести товары одновременно в aQsi и МойСклад?

Инструкция для этой связки предписывает единый мастер в МойСклад. Два редактора могут создать позиции, не совпадающие в отчётах.

Нужно удалить все старые товары сразу?

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

Удаление в МойСклад уберёт товар с кассы?

Источник прямо указывает, что это не автоматизировано. Нужен отдельный контролируемый порядок.

Возврат в aQsi можно сразу добавить на склад?

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

Можно подключить прямой API, оставив запись товаров из МойСклад?

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

Кто выдаёт доступ к внешнему API?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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