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

Skirbo +
1C:Drive

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

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

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

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

ОперацияНаправлениеСостав и готовность
Номенклатура и единицы1C:Drive → SkirboОбсудим в составе подключения

UUID связывается с SKU клиента; коэффициент упаковки согласуется отдельно.

Допущенный заказ1C:Drive → SkirboОбсудим в составе подключения

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

Факт отгрузки и приёмки возвратаSkirbo → 1C:DriveОбсудим в составе подключения

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

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

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

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

1C:Drive — отдельный продукт семейства 1С для учёта бизнеса. Материал относится к конкретной базе 1C:Drive, её версии и локализации; конфигурации УТ, УНФ и ERP оцениваются отдельно.

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

В изученном руководстве описан подход к REST-обмену и регистрации изменений. Конкретные HTTP-сервисы, их публикация, авторизация и состав документов определяются конфигурацией; готовые адреса методов здесь не заявляются.

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

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

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

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

Заказ учётной базы → сборка → подтверждение

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

Когда начинается: Менеджер в 1C:Drive допускает согласованную версию заказа к исполнению; неоплаченный или несогласованный документ не становится заданием автоматически.

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

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

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

  • Отмена до выдачи освобождает согласованный резерв; после выдачи требуется отдельный возвратный процесс.

Изменение карточки без пересоздания SKU

Задача: Обновлять реквизиты и сохранять историю движений.

Когда начинается: Ответственный меняет товар в 1C:Drive и фиксирует, какие свойства разрешено передавать складу.

  1. Ответственный меняет товар в 1C:Drive и фиксирует, какие свойства разрешено передавать складу.
  2. По устойчивому UUID находят существующий SKU; изменение имени не создаёт новый товар.
  3. Обновляют разрешённые поля, подтверждают принятую версию и отдельно разбирают удаление или изменение единицы.

Результат: История приёмок и отгрузок остаётся у прежнего SKU.

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

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

Возврат с физической проверкой

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

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

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

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

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

  • Ожидаемый возврат не увеличивает доступный остаток.

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

ДанныеОтветственный источникПравило обмена
Заказ и коммерческие условия1C:DriveСклад исполняет только допущенную версию.
SKU и базовая единица1C:Drive + таблица соответствийUUID не подменяется названием.
Физический остаток и резервSkirbo для обслуживаемого складаУчётные и доступные остатки сверяются, не суммируются.
СтатусыКаждая система для своего этапаСобрано, отгружено и проведено различаются.
Документы1C:DriveСклад возвращает факты, бухгалтер утверждает проведение.
Возвраты1C:Drive — разрешение; Skirbo — приёмкаФинансовая корректировка отдельно от качества товара.

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

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

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

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

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

  • Примеры REST-путей в руководстве нельзя использовать как готовую спецификацию.
  • Exchange Plans требуют настройки; их наличие не обещает включённый обмен.
  • Физический остаток, бухгалтерское количество и доступное к продаже количество имеют разный смысл.
  • Локальные формы документов и правила маркировки для РФ, Казахстана и Узбекистана проверяются отдельно.
Стоимость и запуск

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

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

Подготовьте обезличенный заказ 1C:Drive, выгрузку соответствий товаров и пример частичной отгрузки — по ним оценим первый складской процесс.

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

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

Артикул может измениться или повториться у разных клиентов. Нужны UUID исходной карточки, владелец товара и проверенная таблица соответствий.

Можно передать весь каталог заново?

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

1C:Drive — то же самое, что УНФ?

Нет. Для оценки нужны именно версия и схема конкретной базы 1C:Drive. Контракт соседней конфигурации не доказывает совместимость.

Кто оформляет возврат денег?

Учётная сторона. Skirbo должен передать факт приёмки и состояние товара; сам приход не является финансовым возвратом.

Есть ли в 1C:Drive готовые webhook из этого FAQ?

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

Когда можно отметить изменение обработанным?

В предлагаемом процессе — после устойчивой записи результата принимающей стороной. Конкретное подтверждение и очистка регистрации изменений определяются контрактом базы, а не названием Exchange Plans.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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