Show HN: I've Built an Accounting System
github.comIt can create invoices and receive payments.
Not quite production ready, yet.
Only need PostgreSQL installed to try.
I will add support to choose SQLite when they add native support for geography types.
It is a good start but the hubris here is quite high (and maybe not a bad thing). Funny readme but rather harsh. Seems I have been trolled enough to provide a response here...
I am not a fan of "Qwakbooks" and I can't believe I am about to defend it but... it does allow you to enter journal entries manually. In fact, you do not have to use any of the screens overlayed on top of the GL. The additional features are meant to help users do things faster and more efficiently. The details are not hidden at all but most users don't need to see them to be successful.
QuickBooks has all of the same core functionality including a well structured database too. You can interact with the QuickBooks Online API with a few endpoints and achieve the same thing much faster with scalability depending on which features you would like to use. If you don't believe me, just read through the API documentation which is really easy to follow. https://developer.intuit.com/app/developer/qbo/docs/api/acco...
So yes, this is a well structured database for an accounting system but beyond that there isn't much here.
Some other points:
"Due to its wide scope, the system is designed to be incomplete, allowing organizations to finalize the implementation." The customization involved to make this useable would be quite substantial and unaffordable unless you did it yourself (which would be a distraction from core business)
"Companies that adopt my system are far less likely to get audited..." This is false. You might survive an audit with a clean general ledger but it doesn't reduce the likelihood. There is also way more to audits than whether the TB balances - the substance of the transactions is obviously more important. ie. the accountant needs to know accounting otherwise audits with any system go poorly.
At quick glance... both this and QuickBooks do not have purchase order management, capex or prepaid amortization automation, approval workflows, muti-dimension transaction classification (for FP&A), or strong multi-company/currency support. These are all reasons why companies switch to a more robust (and usually more expensive) system. These features are needed for most but not all big companies with hundreds of employees moving around tens of millions of dollars.
> muti-dimension transaction classification
Is there an SMB package that supports this?
In a chart of accounts you might have a Travel/meals/lodging account. The IRS will allow you to write off an employee's meal if it meets certain requirements, but as a company, if your policy is to reimburse employees for meals regardless of the write off, you'd need two sub accounts:
Travel Meals Lodging (IRS Exempt) Travel Meals Lodging (Non IRS Exempt)
Now let's say I get a government contract where I'm contractually allowed to bill certain items to the program, but the contractual definition doesn't overlap with IRS definition, such that I need four categories to track all my expenses:
Travel Meals Lodging (Program Exempt, IRS Exempt) Travel Meals Lodging (Program Exempt, Non IRS Exempt) Travel Meals Lodging (Program Non Exempt, IRS Exempt) Travel Meals Lodging (Program Non Exempt, Non IRS Exempt)
While this technically works, it feels very wrong. I'd love a tool that would let you reconcile the general ledger against more than one Chart of Accounts, or even tag expenses for reporting purposes.
You are correct in your example and yes, it should feel wrong. That workaround is totally fine though and most small companies will do something like how you have described.
In your example, using multidimensional accounting you could book one entry to "Travel Meals Lodging" GL account and have the dimensions "Program", "IRS Exempt", "T&E Subcategory". This creates a one-to-many relationship with the transaction instead of having 4+ GLs. You could book to one GL "Travel Meals Lodging" with the dimension values "Program Non Exempt", "Non IRS Exempt" and "Meals". You could design the dimensions differently, but I am just trying to give you an example.
No, I am not aware of an SMB package that supports this. It probably exists but from what I understand it makes the database more complex (cube?) and everything more compute intensive on the reporting side. Thought I haven't looked into it much - if you find anything, let me know.
I have a couple projects running on GnuCash, but it doesn't support dimensional accounting. Netsuite would work, but anything Oracle is a hard sell in my space.
Do you recommend any resources for implementing dimensional accounting? Articles? Example schemas?
If you are coming from GnuCash, Netsuite is probably overkill and/or out-of-budget. Even if you had the resources, I would probably consider Sage first.
Multidimensional accounting is in effect supplementing the GL with additional data. For each transaction, you could have a database table that adds a column for each new dimension. Or if you don't prefer a relational structure, a json object attached to each transaction. Outside of setting that up, the problem probably becomes the user experience ie. how do you add that information at the same time as posting your entry?
If you wanted an even more "hacky" way, you could embed the data into the memo/description field or another available field. Unfortunately, the off-the-shelf reporting would not be useable because it would not know how to parse the embedded data.
Unfortunately, the multidimensional accounting space is dominated by enterprise accounting system offerings. So I don't know of any resources for implementing it outside of switching to those systems.
One can do this with budget codes, instead of via accounts. Where you can add essentially unlimited extra information into any transaction. Many western governments use this method.
An example from the London School of Economics, in PDF: https://info.lse.ac.uk/staff/divisions/Finance-Division/asse...
I believe Odoo does this. They tag transactions and even if you have a chart of accounts for your reports, the tags allow these kind of customizations IIRC
>muti-dimension transaction classification
Could you explain what this means? I've been using Quickbooks for both myself and clients for many years and never heard this term. Quickbooks does support classes (multiple columns on your P&L and Balance Sheet within the same company file), is that what you mean?
I'm also pretty sure that QB Enterprise supports multiple currencies, purchase orders, and some of the other stuff you mention, but I haven't worked with that version of QB recently. It also has inventory support that is more sophisticated than the basic support in QB Premier.
"muti-dimension transaction classification (for FP&A)" - The data for internal management/operational financial reporting and budgeting/forecasting/modeling (ie. FP&A) may be quite different than those used for GAAP financial reporting and taxes. The multiple dimensions allows for added "tagging" which can be used to enrich a transaction with more information. An example would be using a dimension of "department" to classify a transaction as belonging to a certain team. Yes, QB has one dimension called "class" but more enterprise systems allow for 10+ or even unlimited. As I mentioned, you only get to needing this once the company is quite large or has more complex financial data needs.
I don't know exactly what QB Enterprise has but one of the complaints I hear often that that consolidation with multiple entities and multiple currencies is difficult or not possible without additional tools using QB
Intuit has how many? I am one. Give it time.
That is fair, I can respect that! Keep going!
>GAAP and IFRS compliant implementation of a forward-only double-entry accounting method
You may want to replace well most of your lead image. It sounds like gibberish to accountants. It's the accounting equivalent of saying this is an IPv6 compliant x64 CPU. The words are all from the right field but they're put together in a way that makes no sense to someone familiar with it.
That said accounting software is a fuckin trainwreck on both UI and features so I understand the hn urge to jump on this. Xero basically cornered the young company market by being a web based and being not entirely fuckin terrible.
Not knowing what they are doing is the basic premise of disrupting a market. It fails most of the times, but when it succeeds, big chances it was made by someone that didn't really understood the problem
Can you list some examples from the past decade?
Thanks for posting, looks pretty polished to me! Lowkey love the design, super modern finance applications do make me irrationally afraid. Perhaps it's trauma from Navient-administered student loans...
I will say this is by far the most passionate README.md I've ever seen, lol;
Do you have any particular reason/motivating experience for this ethos? Why not just use a piece of a paper/the default Excel ledger template/the `ledger` CLI tool if it's so important to do things by hand?P.S. "Truck drivers of the office"...?
There are multiple reasons.
1. Intuit discontinued QB desktop on may 31 this year. 2. Intuit recently raised prices. 3. QB online has terrible navigation. I can make invoice in my system in less clicks. 4. I needed a feature to optionally print supporting documents with the invoice while having the ability to arrange the order of those documents. I then can integrate with mailing service and have PDF ready to mail programmatically. Instead of having to join PDFs together. (this feature doesn't work cause I can't afford IronPDF, it's the only PDF package I would use). 5. I don't like any limits on users or numbers of invoices I can have in my system. 6. Excel is error prone for more than a few records. Drag and drop accidentally one cell to another? 7. Multi-tenancy. I wanted to manage multiple companies without logging out.
>1. Intuit discontinued QB desktop on may 31 this year.
That is false. They have switched to subscription licensing instead of perpetual license. Accountants can still purchase their version of Quickbooks, and yes the price just about doubled in the last few years, to about $1,000 but it's still available.
Brutally minimized to first principles and to the very core. It's always about the journal and that's it. No fluff. Great project.
Congrats on completing a rather involving project. Accounting isn't easy, I know coze I got a degree in it, although haven't pursued a CPA: I make a lot more as software dev and competition is way lower. Like, for every software company a few accountants would do, while it takes hundreds of developers, QA, HR, IT and other stuff to run it.
But I digress. There's no shortage of accounting software, I know coze my wife works for a company selling one :) But to survive and succeed the key is not in the software per se as in support. Continuous support for all the dumbass questions the clients may ask and continuously updating the software to keep up with the incessant small changes in the legislation. Updates without which one cannot even submit a balance sheet to the IRS and are only available upon subscription.
Without those the software is dead in the water.
Except every company needs accountants. Only software companies need developers. There are roughly the same number of accounting jobs in the US as developer jobs. So it may just be due to a lack of software developers that cause the higher pay for developers. Although, outside of FAANG and similar software companies, my guess is that CPAs make more.
As someone who was unfortunate enough to use Quickbooks professionally for several years, I laughed out loud at that meme on the bottom of the readme. Wish you all the luck.
Wow, this is really neat. Congrats on the launch. Are you seeking or accepting contributors? I’ll be installing it today.
I’ve unintentionally worked with and helped implement systemization and automation over a dozen different accounting systems and ERPs. They blur together.
Since I have a tech background, it’s not uncommon for me to say an accounting system or ERP is just line item rows moving though tables leaving their history behind… and how do you need it… and now it exists, haha.
A few questions:
- Journals and accounts are traditionally taught as the manual way to track different financial activities and ensure accurate reporting. Journals capture transactions as they happen, while accounts categorized them for analysis. Now that we have databases and reporting tools, is there a sense of where reporting or crunching things like profitability, job costing, etc could be built up from this?
Account code migration - when implementing a new accounting system, companies tend to dither over getting their GL right, or changing it up at implementation. Being able to maintain that history could help migration of data easier.
As someone who has helped design and lead implementations overall, with accountants handling their part, accounting depts can get caught in trying to do a lot with accounts and journals in lieu of a report.. while databases have allowed ERPs to report in ways (dimensions, etc) that might not be about accounts or journals alone.
Mostly I’m thinking about organizations that wanted to build up calculation of profitability by asset, or resource or service, or product, and how a project like this could help people easily do it from these first principles.
I have a few ideas in the works for accepting contributions that I will iron out in the coming days. I have some breaking changes in the works to make the journal more reliable and testable. The current implementation requires deep understanding of my vision.
AFAIK, North Korea, Russia, and United States, all have the same five accounts types and require double-entry.
This truly is a mission to rebuild an institution. My goal is to educate a new generation of accountants. The kind who can produce any report from raw journal entries and who can add new features to the journal.
Parent-child relationships help with reporting, but I notice the need to include parent-child relationships almost everywhere; locations, items (products/services), chart-of-accounts, users, tasks, etc.
I've not touched reporting because I know it will be easy to do.
If I get the journal, accounts, and transactions right, the rest is easy street.
One thing to mention at this time is that I don't see a need to manually enter journal entries. I'm ready to catch flack for saying this, but maybe... idk. Still in R&D phase.
Lack of manual journals would be a non-starter, I am actually not clear how a business could possibly run their books without manual journals.
An example: you make something that uses 5 inputs. I have inventory and cost of goods sold accounts for each of those inputs, but my invoices out to customers only reference the final product. This is where ERPs add insanely complex inventory management solutions. However, the simple way to deal with it instead is to use a manual journal to reconcile your inventory and cost of goods sold accounts monthly or however often you like.
Interesting example - Complex ERP inventory management and manufacturing experience here:
It seems reasonable to need manual adjustments, but I'm not sure if entries would be needed. Deciding how to make corrections and adjustments seems to be key in any manual journal entries, or not.
If journal entries derive from transactions elsewhere, chaining those together, or something to adjust them them is pretty reasonable.
About split entries like the scenario you've outlined? Cost of Goods Sold, vs manufacturing are all often in different parts of the ERP that may not tie back to journals always. Perhaps there is a pattern to setup that is repeatable. I'm not sure if you have a software background, but source code control of managing the bits of what changed when is important.
Another scenario where manual stuff might not work is if we have a just in time manufacturing process, and don't complete the finished goods until the items are on the truck and signed for by the driver (un damaged) so then you can finalize manufacturing, invoicing, shipping documents, etc. There's ways to reduce having to undo all of those if product is damaged between manufacturing and shipping. Of course this has it's own caveats. Implemented OK in SAP though.
Overall, a real need and goal is: reducing the amount accountants or anyone who works with an accounting data has to dump out data from the accounting system to "manipulate the data" to get a view of what happened/happening/needs to happen.
Unpopular take based on experience: It's been my experience that a good chunk of accounting groups that run around with their hair on fire that the system is somehow not working... calls in someone with database or analysis skills, to discover something wasn't done as needed, or not configured and implemented. In this way, the Technical ERP whisperers out there who are not accountants but handle the "in depth analysis"..
I have all the in the works, including complex assemblies and reporting.
I wish I had the $ to hire help.
If you might consider it, and YC wasn't a fit, I think something like tinyseed.com might be right up your alley.
This is both mission based, as well as a sore need. I don't feel good right now, for example, having to consider which accounting system I'll be using next. Because it should mostly just be an API first, and I guess some screens activated where the API can't just run processes for me.
Given how many accounting systems don’t use relational tables but use a relational db (like sap b1) and do joins manually, it would be a big step forward.
I have seen more than a few accountants dream about learning sql instead of their excel tai-chi.
I taught some to see sql as a sentence that was an instruction to join the columns they wanted.
Since everything is actually related tables.. it would be possible to just hand them something like metabase to start for all reporting since it can traverse and build up queues no problem.
The parent-child relationship I ran into as well as being an issue. It gets increasingly out of control and more complex that I wonder after a certain level of complexity whether sql is the best or sole way to go. I don’t know if this can be avoided at the cost of the user needing to know how to to do complex queries. Maybe there’s a way to simplify it with invoking stored procs somehow.
From this parent-child complexity side of things I explored graph databases for this and it seems to off some potential advantages, particularly for some complex use cases and queries. Keeping it postgres specific, PG can be extended with Hasura and then graphql is be available on the underlying schema. It really is something.
Beyond this, I’m spending more time with a knowledge graph databases outright.
If you haven’t had a chance, I highly suggest checking out TypeDB and a few demo videos. Chances are you will get to see some things you won’t be able to unsee and how it can help the Postgres design.
One of my use cases (non accounting) is sufficiently complex on the parent-child front that I have a basic interface between Postgres and TypeDB working to allow much easier querying and reporting via TypeQL.
If you think Intuit is accounting than you don't really know what accounting is.
Off the top of my head... every major ERP has better functionality, customizability, and usability than this relatively simple take on a financial system. Even Workday... and that's an accounting system grafted on top of a HR platform.
This is basically yet another product created by a programmer that doesn't actually know enough about the field they're disrupting that they don't even realize that their disruption was obsolete a decade ago.
And no, as is this program couldn't be used to run a bodega, let alone an aircraft carrier.
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.
You are right but you are mixing a lot of stuff.
MAJORITY of the world businesses are small shops. Mom and pop businesses or family run shops. They need accounting to track if their customers have paid them, if they have to pay to suppliers and any taxes are due.
Erp systems are wayyyyy too much work for them.
I work with small businesses and they would rather themselves keep half baked records than hire a pro because that saves them cash in the ongoing basis.
Simple accounting helps them. Thats like bringing a shotgun to a knife fight.
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...
And so it has!
Thank you!
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.
An excellent post, thanks.
The question was about a bodega owner ...
Bodega guy can probably get away with Excel (I shudder at the thought but it could work) or a very lightweight and cheap ERP (which doesn't exist)
[flagged]
This comment doesnt deserve the downvotes its getting. If you ever work in an ERP system you will realize the complexity of tracking cost, inventory management (which is not just simple item, location quantity), purchasing, quotes, lead times, approval processes, BOM data structure, assembly, work orders, sales orders internal/external, etc etc. All these may boil down to basic cost account primitives but making a system that is a ledger then dismissing other solutions and saying you could manage the project of constructing an aircraft carrier make you wonder if the author has ever touched an ERP frontend or back. On top of that there are open source ERP and other smaller companies that make proprietary ERP that do not do some of the things intuit may do draw the ire of some.
I agree. Although do you think ERP as a discipline is actually successful in solving these kind of problems? It seems to be a field dogged by underperforming or failed systems.
An extraordinarily arrogant approach to presenting a project.
The TEXT datatype is deprecated in most RDBMSs. A minor and insignificant point but following the 'remove the brown M&Ms' rider principle, it makes me question the integrity of everything else, especially given the insults in the readme and lack of professionalism throughout.
TEXT is absolutely not deprecated in Postgres, which this project is using for its example. It being deprecated by other RDMS seems irrelevant to mention.
It’s autist, I’ll allow it.
Why is the TEXT datatype deprecated ?
Gross
If a user understands accounting + software + databases, the problem and solution is quite simple. Unfortunately that subset is small. Given how much the world runs on software, one can imagine a company where a prerequisite to working there is understanding software and databases.
To the author: What are your thoughts on tiger Beetle? I think it provides most of the primitives that you mention in a highly optimized package (except hierarchical relationships).
Cool project! I think it is worth pointing out contra accounts in the section where you discuss how accounts can increase and decrease. Debiting a contra-asset account would decrease its balance for example.
I'm doing a little detective work here.
1. A posting like this appeared on [Reddit]( https://www.reddit.com/r/programming/comments/1e79xoz/creati...) two months ago. This repo started two months ago. The user [ApexProgrammer](https://github.com/ApexProgrammer) has one repo under their account.
2. These repos' first commits happened around July 12th, 2024, and July 9th, 2024.
3. One reference "Farm Manager," and another reference "Farm to Market."
Questions:
- Are these artifacts from a school project? - Are these AI-driven code repositories bent on world domination? - Are these questions to remain unanswered?
omg, I'm an actual old fart accountant... "quickbooks" is good enough for small businesses (though I 100% appreciate the problems it has) if you need something robust with more controls, you either just use netsuite/etc. or something more specialized for your industry
and FFS, only go the route of custom code as a last resort, you are better off slightly changing your business process to match whatever workflow/etc. is in the OTS ERP instead of having some cheap crappy dev (only crappy since most who do ERP programming are often not well paid) shoehorn your (likely ill conceived) process or report into the existing ERP...
It looks like a great product. I have to be honest though, I didn't read too much in detail - and this was the colour scheme seemed to "scream" at me. There is too much high-contrast colours (deep reds, etc.)
Just my humble opinion. Which I am allowed to have :)
But does it support multi-currency?
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).
All of that makes sense. Using your database's user model is something I've thought about for different types of system, but never done.
I have a random, different question: what was the process by which this effort was approved? I can imagine a lot of companies (and their C[TI]Os) would say "Well, we should buy Oracle Financials and customise it".
How do you get a large enough org to afford this development effort, without getting an org that picks a prebuilt solution that can be customised?
It's because we are very old and we had custom software originally, way back in the 70 and 80's when we were first getting computers. When OpenVMS(the system our custom software was running on) was EOL'd, the existing team was given a lot of leeway to find a replacement. We were not very excited about the options and we had programmer staff already dedicated to the old custom software. Also users wanted "GUI" and "Web". So we implemented a new system in Python and PostgreSQL. PG functions are written in Python too.
I wasn't part of the original team, but I was there for the re-write. I brought in Python and PostgreSQL and I created two-way sync between the old OpenVMS system and PostgreSQL, so we could take our time and didn't need to have a big cutover date. That was a HUGE selling point that got everyone on board.
>The other thing often missing is auditing.
FWIW, QB has pretty comprehensive audit trail and reporting.
>The next big thing often missing is reporting.
Since it's been around so long and has a large user based, QB has plenty of standard and user-contributed reports available, and custom reports are possible. There is also a Statement Writer for more customization although I haven't used it.
> I will add support to choose SQLite when they add native support for geography types.
SQLite won't add that.
The accounting people are annoying because they keep using confusing terms to explain math. Or it is a kind of gatekeeping.
Some big claims in that readme for a project with no tests :)
Lots of C# repo's here demonstrating unit/integration/acceptance testing within dockerised containers if you need some examples https://github.com/PeterKneale?tab=repositories
Big things have small beginnings.
I think Donald Rumsfeld said something about unknown unknowns.
But, tell me what you want tested and add that to my list.
> Big things have small beginnings
What about humble ones ? You come with a strong « I know best than anyone else » yet your project hasn’t even had 1 day of experience in the « real world ».
> But, tell me what you want tested and add that to my list.
Big numbers, small numbers, positive numbers, negative numbers, positive 0, negative 0, positive infinity, negative infinity, fractional numbers, irrational numbers, latin characters, non latin characters, invalid characters, emojis, dates in the past, dates in the future, dates that don’t exist, the list goes on; really
Lots of very successful software never had those things.
Your accounts ARE the tests!!
looks very promising.
gl!
Hahaha, this is the most aggressive readme ever.
None of you can call yourselves accountants; you're just QwackBooks users. The truck drivers of the office. Your boss thinks of you as a whiny, tail-dragging . That's why he needs just one of you who knows the entire system. Maybe you'll get lucky with an assistant, but most likely they'll cause more problems, because it'll be the boss's daughter and she doesn't give a .
Yes, this initiative has been fueled by hate directed towards Intuit and the overall accounting community for refusing to advance. It's like playing AoE with a noob who's refusing to advance to the next age because there will be more units, technologies, and strategies to manage. Most businesses have one accountant, which means this entire profession is one initiative away from not existing at all. There's no excuse for a modern accountant to not know at least SQL.
The patterns and practices that I demonstrate in the solution are nothing genius, it just took a while to put it all together, and it's very basic. Just one table with credit/debit columns, rows of which have to be organized into a transaction and linked with user-actions, like creating invoice, receiving payment, adjusting inventory, really anything, including foreign transactions.
When the calculator was invented, we didn't get stuck with a bunch of "calculator-operator" professions, so why does accounting get to stay stagnant?
In the UK with have a concept called a micro entity in the tax code. Micro entities have some fairly strict constraints on them (10 employees or less, turnover under £350,000, no foreign currency transactions and so on). Within those constraints the rules are fairly simple and most importantly HMRC provides online forms for filing your books.
I always wondered about starting from those constraints and working back to a basic accounting solution for your typical business person. It would probably cover 90% of the companies in the UK as most of them have really simple requirements.
Luckily I retired before I got around to it.
Keep up the passion!
What are your thoughts on plain text accounting? I know it's not really for businesses applications and really not for accountants but that's how I learnt accounting basics. I find that approach much better as I have total control of the structure. I suspect your application provides a similar level of control as the end company has to implement the details.
I've thought about separating the journal into a command-line application, where the end result might look exactly like plain text accounting, a sorta like ffmpeg for accounting. Plain text is part of my backup strategy.
If plain text are roads, then my approach is rail roads. A strict set of application logic so the operator doesn't get overwhelmed and is capable of managing large number of transactions at higher speeds of entry.
Then, it's just a matter of building more rail roads for any additional functionality. Once built, you'd probably never have to touch that code again.
> It's like playing AoE with a noob who's refusing to advance to the next age
I will steal that, and there's nothing you can do to stop me!
> . . . the most aggressive readme ever.
I love it. It reminds me, in tone, of the Acknowledgements section of the Scsh manual: https://scsh.net/docu/html/man.html
i am upset that both spaces and tabs are used in the sql code blocks the first 3 use tabs and the last 2 use spaces