Please elaborate more, my friend! Let's say that I was^W am a programmer who is seduced by the plain-text accounting / one-database-is-all-you-need notion and I think my needs will be simple, as I can keep the business of my bodega all in the RAM of my brain... Or at least I think I can.
How can this go wrong? What are some of the needs that compel the bodega owner to move on to more sophisticated tools? Is it because of calculating things like taxes and hourly rates and the like?
Imagine it’s the year 1890 at Standard Oil and they have a building full of filing clerks.
It’s run by the great John D Rockefeller, of which you can read more in the fantastic biography Titan. He’s a stickler for accurate accounting at all times.
Now they decide to buy a batch of barrels for all their oil.
- one clerk runs down to the cabinet with a file for all the items SO buys.
- another cross-references each item and fetches the files of the vendors for each of those items
- another cross-references with past invoices to get the most recent price for each item
- another gets a list of locations SO uses to store barrels
Now the purchasing manager looks at all this and decides which barrels to buy, from which vendor, how many, and where its getting delivered. So he writes out a purchase order / PO.
So back to the clerks:
- one runs along to file the PO in the PO filing cabinet. Remember, uncle John is watching and he wants to go to any cabinet or any manager at any time and get up-to-date details of what's going on.
- another one goes to the Items cabinet, finds the barrels we ordered, and notes on them that a PO was issued for this many barrels on such and such a date.
- one actually sends a copy of the PO to the vendor.
Skipping over some steps for simplicity, the barrels arrive one day with their invoice attached.
An Invoice! Now the army of clerks swing back into action. They get their guy at the warehouse to send them the original invoice that came stapled to the barrels. Then:
- one runs to the PO cabinet, finds the PO that was issued, marks it as done, and writes the invoice number on it.
- another one runs to the accounting department. There they make the double-entry bookkeeping entries to account for the money that is now owed to the vendor, and for the inventory value that has gone up.
- another one runs to the vendor cabinet and records the purchase on their file
- another one goes to the inventory cabinet and files a record updating the inventory balance for the barrel item
- someone files a copy of the invoice for future reference
Eventually we pay the invoice:
- a clerk keeps an eye on the payment terms for this and other vendors and calculates how much cash we have to send to each vendor each month
- another runs around to each paid invoice marking them as paid
- another one actually writes the cheques and mails them off
- someone has to tell the accounting department how much money we just paid, to which vendors, out of which bank accounts
Things get fun when these barrels eventually get sent to a production facility and filled with oil. Now the clerks have to do the correct filings to destroy the barrel items along with a quantity of oil, and create a new filled-barrel item. The cost of this depends on all of the cost of the barrel item, the oil, the labour, and some other things, all of which is determined using past entries.
This is a toy example and the complexity spirals from here. For example another invoice can arrive from the people who transported the barrels. Depending on your CFO, or the current accounting laws, you might want to include that in the cost of the barrels, or record it as a business expense.
You might have different departments who do their accounting separately, so now each transaction has to be split correctly. You might want to track the hourly rates of each employee and factor that into the cost of each finished-barrel item, and also tracking what everybody should get paid.
Add to this any idiosyncratic business rules stemming from management decisions, laws, unique physical constraints, or whatever.
An ERP system is all of these cabinets and their rules put into a relational database with a front-end.
Thank you for the excellent reply! I think I understand now... Once a business starts transacting in things other than a single type of money (say durable goods, consumables, services, or say other types of money) it becomes necessary to reconcile these non-money-denominated accounts. And for that, you need more than a single database, or single spreadsheet. You need a suite of persons or softwares that can __account__ for these stocks and flows, and the rules that come along with them.
And that is called ERP, of which "simple" money accounting is but one component of.
So root commenter's objection was more along the lines of: "those are some bold claims for mere money-accounting program. if you used a _real_ accounting program (as in an ERP) then you'd understand how complex peoples' needs can be". And the tone they phrased it elicited the downmods :)
I guess I understand. I still admire the OP and the frustration that fueled their desire to create a tool that works for them. And the tone of the readme is very endearing, it reminds me of the things my IRC friends would say to kick-off a lively discussion...
To add to your point, there's also other complexities like multiple currencies, keeping track of tax owed, and probably the biggest one: multiple people of all skill levels entering data into the system at the same time.
How can this go wrong? What are some of the needs that compel the bodega owner to move on to more sophisticated tools? Is it because of calculating things like taxes and hourly rates and the like?