Comment by zie

Nice start!

There are a few other OSS implementations, a list on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_accounting_softw...

As someone who has helped write and manage one used internally at a thousands of active employee organization I have some thoughts:

Most of these skip over authorization of transactions, which is very important in many organizations. I.e. Tootie wants to buy a new widget. Her supervisor probably has to approve it along with someone from budget/accounting to confirm we actually have the cash to pay for said widget, etc.

These authorization/workflow systems can get stupidly complex. Ours is rule/action based via regex matches against columns in the DB, and we support a _rules view on said table, to help achieve our goals and allow customization for each "module" or type of transaction that needs authorization.

The other thing often missing is auditing. We have auditors show up once or twice a year and pour over our transactions, audit and access logs. We record every I/U/D that happens against any table in the DB and have kept this information forever. We also have a support ticket system with integrated VCS that we use religiously to help handle the why, that also never erases information.

The next big thing often missing is reporting. We have thousands of reports. Every employee basically needs a few different ones. The key people(The accounting, payroll, AP and budget departments, tend to get dozens of reports per employee).

We perhaps overly abuse use PostgreSQL's access controls. Every user gets a login, and we use row and column level access controls. This way all of the above features are tied into access control. So if we make a generic report(say a birthday list), we can make it available for everyone, but a supervisor can only see their own employees and say the main manager at a particular location can only see records pertaining to their location.

Lastly, these systems do not live in isolation, we are often the first and last source for information. We import and export data automatically against a wide range of various systems, from SSO to random one-off messes some employee managed to get installed somewhere. Having a sane way to deal with IO is essential. Our current best method is for every system we have to two-way sync with(which almost always happens if the product lives past the first year), we keep a separate world-view of what we think their data is. This way when stuff inevitably breaks, we can easily track down if it's an us or them problem and get it routed appropriately. Since we keep both our world-view AND their world-view in our PostgreSQL database, we can replicate any previous state(due to keeping both world-views and precise auditing).