There is no manual for TronSoft.
No API reference, no schema diagram, no forum thread explaining why a comanda refuses to close.
If you want to understand it, you open the database and start pulling threads until something makes sense.
That's exactly what I did — for months, on top of my actual job.
The problem nobody wrote down I'm the Operations Manager at a restaurant in Itaúna, a mid-sized town in Minas Gerais, Brazil.
I'm also the only person there who writes software.
Not because I was hired to — because the restaurant runs on a Brazilian ERP called TronSoft, built on a Firebird database, and Firebird doesn't come with the kind of ecosystem you get around Postgres or MySQL.
No Stack Overflow flood of answers.
No official docs beyond a thin operator manual.
Vendor support exists, but it's slow, and it doesn't scale to "I want to automate this specific internal workflow at 11pm on a Tuesday." So when I needed to automate payment reconciliation, close out comandas without touching the vendor's fragile UI, and trigger fiscal document emission (NFC-e) reliably, I didn't have a spec to follow.
I had a live production database and a lot of curiosity.
Learning a system by watching it think I started the way you'd expect: opening tables, guessing at relationships, breaking things in a test environment until I understood why they broke.
Over time that turned into something more systematic — I ended up documenting 390 tables and 514 foreign keys across roughly 40 functional modules, entirely from observation.
No vendor documentation, no source code access.
Just structure, inference, and a lot of trial and error.
Some of what I learned only reveals itself under pressure: Firebird's SQL dialect has its own quirks — instead of , for one.
Small thing, but it breaks every query you copy-paste from a Postgres tutorial.
Primary keys aren't auto-incrementing in the way you'd assume.
They're driven by generators (), and if you write a record without syncing the generator correctly, you get silent, confusing collisions later.
Composite primary keys meant that inserting a row "correctly" by every visible rule could still conflict in ways that only showed up once real concurrent traffic hit the system.
Transactions don't behave the way you expect until you understand exactly how autocommit visibility works in this specific setup — I've had records that existed, technically, but weren't visible yet to the process that needed them.
The hardest part wasn't the SQL.
It was reverse-engineering behavior — the exact sequence of writes that happens when a human closes a comanda through the official interface, so that my automation could replicate it precisely enough for the fiscal emission service to recognize it as legitimate.
I ended up watching Firebird's internal monitoring tables () in real time, diffing snapshots before and after manual actions, essentially instrumenting a black box to learn its own rules.
Why this mattered more than "just automating a task" The first version of my automation used screen automation — literally driving the mouse and keyboard through TronSoft's UI to close comandas, because that was the only interface I had confidence in.
It worked, but it was fragile.
A window in the wrong position, a dialog that opened a half-second late, and the whole thing broke.
The real turning point was when I stopped treating TronSoft as a UI to automate and started treating it as a database to understand.
Once I could write directly and safely to , , and the tables around fiscal emission — replicating the exact NULL patterns and field conventions the vendor's own software expected — the automation became something closer to a real integration than a hack.
It's been running in production since, quietly closing out transactions and triggering fiscal documents without anyone touching a mouse.
What I'd tell another self-taught developer staring at an undocumented system I don't have a computer science degree from a top university.
I'm self-ta