Перейти к содержимому
Все проекты

ERP-аналитика · Алгоритмы

Аналитика денежных потоков для Logo Tiger ERP

Аналитический сервис поверх базы Logo Tiger ERP компании, который восстанавливает, откуда пришли деньги и какие проекты они профинансировали — по движениям кассы, банка, текущих счетов и склада.

Моя роль
Backend-разработчик. Реализовал логику связывания и распределения, пакетную обработку и интерфейс отчётов.
Стек
  • Go
  • Echo
  • GORM
  • MSSQL
  • Logo Tiger
  • WebSocket

Задача

В ERP деньги проходят через кассы, банки, текущие счета, переводы и склад, и каждый документ знает только своего непосредственного соседа. Руководству нужны были ответы на уровне проектов: какой доход на самом деле профинансировал какой проект и на какую сумму.

Архитектура

Аналитика денежных потоков для Logo Tiger ERP — Схема архитектурыLogo TigerMSSQL movementsLinkingvirman · ref · FIFOAttributiongraph traversalWeb UIWebSocket progressResultsMSSQLWriter pool4 workers · batchesExcelreports
Сервис читает движения из MSSQL-базы ERP через GORM и собственные представления, связывает документы в цепочки движения денег, обходит их в ширину, распределяя суммы по проектам, и пакетами записывает результаты. Интерфейс с серверным рендерингом (Echo + HTML-шаблоны) показывает деревья потоков и стримит прогресс расчёта через WebSocket; результаты выгружаются в Excel.

Ключевые решения

  1. 01Несколько стратегий связывания вместо одного правила

    Почему
    В реальных данных ERP документы связаны по-разному — переводами между счетами, родительскими ссылками и ссылками на источник или вовсе без явной связи. Для каждого случая своя стратегия, а распределение по FIFO — запасной вариант.
    Компромисс
    Больше правил, которые нужно держать согласованными, и результат зависит от качества данных в ERP.
  2. 02Распределение по узкому месту цепочки

    Почему
    Деньги, прошедшие через несколько шагов, не могут профинансировать больше наименьшей суммы на своём пути, поэтому обход несёт этот минимум вдоль цепочки и распределяет только его.
  3. 03Ограниченная параллельность при записи

    Почему
    Результаты записываются многострочными INSERT по 1 000 строк фиксированным пулом из 4 воркеров, а первая ошибка отменяет остальные через context. Запись идёт быстрее, а нагрузка на базу ERP остаётся предсказуемой.

Что я сделал

  • Чтение таблиц движений Logo Tiger и собственных SQL-представлений в MSSQL
  • Четыре стратегии связывания: вирманы, родительская ссылка, ссылка на источник и распределение по FIFO
  • Обход графа, распределяющий суммы по цепочкам движения денег по их узкому месту
  • Ограниченный пул воркеров для массовой записи: пачки по 1 000 строк, 4 воркера, отмена при первой ошибке
  • Прогресс долгих расчётов в реальном времени через WebSocket; деревья потоков и выгрузка в Excel