A reverse-engineered map of TronSoft, a Brazilian restaurant/retail ERP built on Firebird, documented entirely from observation — no vendor documentation, no source code access.
📖 Full write-up: I Reverse-Engineered a Restaurant ERP With No Documentation
This repo documents the structure and behavior of a live TronSoft/Firebird installation, built up over months of direct observation, snapshot diffing, and trial-and-error integration work.
- 390 tables mapped across roughly 40 functional modules
- 514 foreign keys identified without access to any vendor schema reference
- Notes on Firebird-specific behavior that isn't obvious from general SQL knowledge:
GEN_IDgenerator synchronization, composite primary key conflicts, transaction/autocommit visibility timing, and Firebird dialect quirks (FIRST 1vsLIMIT) - Observed write sequences for core operational flows — comanda closing, NFC-e fiscal document emission, and kitchen display integration — reconstructed by diffing Firebird's
MON$monitoring tables before and after manual actions in the vendor UI
TronSoft has no public API reference or schema documentation. Running production automation against it safely meant understanding not just the tables, but the exact behavioral contract the vendor's own software expects — down to specific NULL-value patterns — so that other services (like fiscal emission) treat programmatic writes as legitimate.
This research underpins AutoPag5, a PIX payment reconciliation and comanda-closing automation system built directly against this schema, replacing an earlier, fragile screen-automation approach with direct, safe database writes.
Ongoing. This is a living document — new modules and flows get added as they're mapped.
If you're working with an undocumented legacy ERP and want to compare notes, feel free to open an issue or reach out.