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

Skirbo +
ПланФакт

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

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

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

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

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

Связать организацию, проект клиента/склада, контрагента и статью с актуальными ID, активностью и доступом.

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

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

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

Определить один источник денежной операции, исключить дубли при банковском импорте и распределить части по проектам.

Контроль принятой записиПланФакт → журнал обменаОбсудим в составе подключения

Сохранить operationId и проверить части, суммы, дату и признаки подтверждения после изменения.

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

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

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

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

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

HTTPS API с X-ApiKey. Конкретные операции и справочники выбирают по задаче. Чтение документации не является проверкой аккаунта; параметры записи сверяются перед пилотом. События Skirbo и график сверки — проектное решение, готовые webhooks здесь не заявляются.

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

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

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

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

Услуга фулфилмента → управленческое начисление

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

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

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

Результат: Утверждённые услуги отражены в согласованном финансовом периоде, оплата остаётся отдельным событием.

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

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

Оплата с разнесением по клиентам и складам

Задача: Свести деньги и аналитику без дубля банковской операции.

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

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

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

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

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

Перерасчёт услуги после закрытия отчётного периода

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

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

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

Результат: Новая финансовая версия связана с исходным расчётом и подтверждённым решением.

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

  • Проект не открывают автоматически ради записи.
  • При расхождении readback автоматический повтор прекращают до разбора.

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

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

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

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

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

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

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

  • Физическая отгрузка сама по себе не является подтверждённой оплатой или бухгалтерской проводкой.
  • Из ответа с ограниченными правами нельзя выводить финансовый итог всего бизнеса.
  • Квоты одного тарифа нельзя публиковать как универсальные; тариф и дополнительные условия проверяют на аккаунте.
  • Успешный HTTP-ответ и isSuccess не исключают семантического расхождения принятой даты или частей.
  • Стандартный open не извлёк apidoc.planfact.io; для редких write-полей нужен актуальный контракт. Официальный agent-kit прочитан на закреплённой версии.
  • Наблюдения автора agent-kit о фильтрах и стенде требуют проверки применимости к аккаунту клиента.
Стоимость и запуск

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

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

Выберите одну услугу фулфилмента, проект клиента и правило признания дохода; по обезличенному расчёту и правам API оценим запись и контроль результата.

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

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

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

Можно использовать API-ключ сотрудника с ограниченными проектами?

Можно оценить его доступ для выбранного сценария, но выборка будет относиться только к разрешённой области. Для сверки всего бизнеса нужны соответствующие права и явная граница отчёта.

Что важнее для начисления: дата оплаты или дата услуги?

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

Почему после успешного ответа нужна сверка?

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

Где взять точные ограничения API?

Владелец проверяет тарифный доступ и текущие месячные и минутные лимиты в разделе API. План загрузки учитывает также сверку и повторные чтения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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