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

Skirbo +
Финтабло

Начать с согласованной статьи ОПиУ по услугам одного клиента: вручную проверить модель, затем оценить API-передачу утверждённых сумм и контроль итоговой записи.

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

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

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

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

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

Признанные услуги и расходыSkirbo → ФинтаблоОбсудим в составе подключения

Рассмотреть запись в согласованную модель ОПиУ; событие признания и тип объекта утверждает финансист.

Обязательство по услуге или поставщикуРасчётный контур → ФинтаблоОбсудим в составе подключения

Связать основание, контрагента, срок и сумму; не объявлять обязательство выполненной оплатой.

Денежная операция и контрольФинансовый источник → Финтабло; сверка с расчётомОбсудим в составе подключения

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

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

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

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

Финтабло — управленческий финансовый контур. Статьи ОПиУ, обязательства, сделки и операции ДДС отражают разные стороны финансов; их наличие не подтверждает складское исполнение, налоговое отражение или бухгалтерскую проводку. Финансовая модель каждой организации согласуется отдельно.

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

Открытый API заявлен предметной справкой. Ссылка на подробную спецификацию при чтении вернула оболочку без извлечённых методов; URL операций и поля не изобретаются. Для оценки нужен официальный читаемый контракт. До этого проверяется ручной реестр и финансовая модель, без обещания автоматического импорта.

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

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

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

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

Складские услуги → согласованная статья ОПиУ

Задача: Показать выручку фулфилмента за услуги отдельно от стоимости клиентского товара.

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

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

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

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

  • Готовность API-передачи не объявляется до проверки схемы и аккаунта.
  • Плановая сумма не становится признанной выручкой только из-за загрузки.

Расход на упаковку и обязательство поставщику

Задача: Разделить использование упаковки, признание расхода и оплату поставщику.

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

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

Результат: У расхода есть проверенное основание; долг и платёж учитываются раздельно.

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

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

Перерасчёт услуг и возврат оплаты

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

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

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

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

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

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

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

ДанныеОтветственный источникПравило обмена
Факты услуг и расхода материаловSkirbo и ответственный за складПередают утверждённые объёмы и первичное основание расчёта.
Статьи, направления и признаниеФинансист в ФинтаблоВыбирает финансовый смысл записи и период, отделяет выручку от оплаты.
Стоимость услуг и корректировкиОтветственный за договор клиентаУтверждает тариф, исключения и перерасчёт до передачи.
Операции ДДСНазначенный финансовый источникОдна реальная оплата учитывается одним механизмом импорта.
Обязательства и срокиФинансовая службаОпределяет задолженность и её погашение; связь с оплатой проверяет отдельно.
Принятая запись и повторЖурнал интеграцииСвязывает расчёт, его версию, вид записи и ID Финтабло; при неизвестном исходе автоматическую запись останавливает.

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

  • Какой объект Финтабло отражает первый согласованный процесс?
  • Какой актуальный API-контракт, заголовок авторизации и права действуют в аккаунте?
  • Как получить ID и подтверждение принятой записи и безопасно обработать потерянный ответ?
  • Каковы квоты, пагинация и правила изменения закрытого периода?
Перед оценкой

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

  • Вручную собрать пример ОПиУ по одному клиенту и периоду, определить статьи дохода и расходов.
  • Получить читаемую официальную API-спецификацию и подтвердить тариф, права пользователя и способ выдачи ключа.
  • Согласовать один тип записи и направление передачи: ОПиУ, обязательство, сделка или ДДС.
  • Назначить владельца банковского импорта, чтобы склад не создавал вторую денежную операцию.
  • Подготовить утверждённый реестр услуг, пример корректировки и идентификаторы финансовых разрезов без секретов.
  • Определить, какой ID и какое чтение доказывают приём записи; согласовать квоты и журнал повторов.
Границы сценария

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

  • Подробная схема API не извлечена; методы, заголовок авторизации, пагинация, квоты и гарантии повторов остаются конкретными вопросами.
  • Обзор CRUD-возможностей не подтверждает доступ каждой операции на тарифе клиента.
  • Условия из инструкции Bitrix24 нельзя автоматически считать полным контрактом собственной интеграции.
  • Свободный ввод выручки не означает поступление денег, а обязательство не означает оплату.
  • Шаблон финансовой статьи не должен смешивать товар клиента с выручкой фулфилмента за услуги.
  • Налоговые решения и российские бухгалтерские правила не выводятся из управленческого отчёта; для другой страны их проверяют отдельно.
Стоимость и запуск

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

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

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

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

Зачем сначала собирать ОПиУ вручную?

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

Можно ли по завершённой отгрузке записать поступление денег?

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

Почему не указаны готовые адреса методов?

Справка подтвердила объекты API, но подробная спецификация при чтении не раскрылась. До получения актуального контракта адреса и поля не предполагаются.

Достаточно API-ключа для старта?

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

Как не задвоить оплату из банка?

Заранее назначить единственный источник денежных записей и сохранять соответствие с расчётом услуг. Повторное получение суммы не должно создавать новую операцию ДДС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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