Длинные платёжные сообщения приходится разбирать вручную.
C:\SUDO_AI\CASES\FINLOG
Finlog Bot
Платёжное сообщение из Telegram превращается в операцию Finolog и связывается со сделкой Bitrix24.
Проблема процесса
Какие боли закрывает система
Расход не всегда связан со сделкой.
Дубли обнаруживаются после закрытия периода.
Архитектура
Контур решения
TelegramпарсерFinolog APIBitrix dealмаржа
Технологический контур:Telegram Bot / Finolog API / Bitrix24 / Reports / Duplicate detection
Состав системы
Модули и контрольные точки
Каждый модуль имеет вход, проверяемый результат и обработку исключений.
парсинг платежеймаппинг справочниковпоиск сделкипоиск дублейрасчёт маржиконтрольные отчёты
Операция создаётся с проектом, категорией и контрагентом.
Расход связывается с нужной сделкой.
Отчёт показывает сделки и расходы без связей.
Технический разбор
Как устроен проект
Практическая схема выбора, внедрения и эксплуатации без обещаний «магии одной кнопки».
Архитектура кейса
Платёж разбирается по схеме и связывается с экономикой сделки
Парсер выделяет сумму, валюту, контрагента, проект, категорию и назначение из сообщения Telegram. Значения сопоставляются со справочниками Finolog, а повторная операция проверяется по набору признаков до вызова API.
Поиск сделки Bitrix24 использует доступные идентификаторы и контекст платежа. Несвязанные расходы остаются в контрольном отчёте, чтобы маржа не считалась по неполному набору операций.
- payment schema
- справочники Finolog
- duplicate detection
- Bitrix deal link
- margin report
FAQ.txt
Вопросы до старта
Коротко о границах, сроках, данных и экономике проекта.
Что происходит, если сделка не найдена?
Операция сохраняется с контролируемым статусом, а отчёт показывает расход без связи для ручной проверки.
Начнём с одного процесса
Опишите текущую работу, системы и ограничения. Вернёмся с техническими вопросами и форматом первого этапа.