An analytics service on top of a company's Logo Tiger ERP database that reconstructs where money came from and which projects it funded — across cash, bank, current-account and stock movements.
My role
Backend developer. Built the linking and attribution logic, batch processing and the reporting UI.
Stack
Go
Echo
GORM
MSSQL
Logo Tiger
WebSocket
The problem
In the ERP, money moves through cash desks, banks, current accounts, transfers and stock, and every document only knows its immediate neighbor. Management needed project-level answers: which income actually financed which project, and how much.
Architecture
The service reads movements from the ERP's MSSQL database through GORM and custom views, links documents into money-flow chains, walks those chains breadth-first to attribute amounts to projects and writes the results back in batches. A server-rendered UI (Echo + HTML templates) shows flow trees and streams calculation progress over WebSocket; results export to Excel.
Key decisions
01Several linking strategies instead of one rule
Why
Real ERP data links documents in different ways — inter-account transfers, parent and source references, or no explicit link at all. Each case has its own strategy, with FIFO allocation as the fallback.
Trade-off
More rules to keep consistent, and results depend on data quality in the ERP.
02Bottleneck attribution along the chain
Why
Money passing through several hops can't fund more than the smallest amount on its path, so the traversal carries that minimum along each chain and attributes only it.
03Bounded concurrency for writes
Why
Results are written as 1,000-row multi-row inserts by a fixed pool of 4 workers, and the first error cancels the rest through a context. Writes get faster while the load on the ERP database stays predictable.
What I built
Reads Logo Tiger movement tables and custom SQL views in MSSQL
Four linking strategies: transfers (virman), parent reference, source reference and FIFO allocation
Graph traversal that attributes amounts along money-flow chains by their bottleneck
Bounded worker pool for bulk writes: 1,000-row batches, 4 workers, cancel on first error
Live progress over WebSocket during long calculations; flow trees and Excel export