-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make entries immutable, and provide an revision/amendment feature #133
Comments
I am developer and also accountant, when dealing with accounting systems that are not allowed to be change or delete would be a pain. |
There are other related notions in the temporal domain:
And database considerations:
|
@hainam8x I think if you’re only ever planning on being a small 1 person company, you might consider that Plutus isn’t the best tool. Probably something like quickbooks might be a better fit. The idea behind Plutus is to prepare a company to grow, and transition from the startup phase to growth and investment. In that case, the extra pain of implementing certain accepted accounting practices means when outside auditors etc need access to books, things have been done properly. Think of it as a little pain in the beginning to save a lot of pain going forward. Obviously anything in this system can be overriden, either manually through the database or by forking Plutus for your own needs. But I’m fairly committed to keeping Plutus in line with GAAP. |
this is would be nice I'm also thinking about combining this gem with https://github.com/collectiveidea/audited too |
Proper double entry bookkeeping prevents entries that are posted to the books from being changed or deleted. Outside auditors typically want to see the history of all accounting events, even errors, to ensure that accounting is being done properly (no shenanigans). So ultimately Entries need to provide a way to be amended.
In plutus Entries are "posted" automatically. That means that there's no "trial" set of events where an accountant would normally go and post the proper debits and credits in the account books. So that means that once an entry is written to the DB, we have to assume someone, somewhere might be running a report, and that means those entries can't just disappear in the future.
So this issue is going to track the addition of a revision system. As a basic example, it should be able to VOID an entry. The entry would somehow need to be marked "voided", and then another entry reversing the credits and debits needs to be made. An obvious API would be
entry.void
which would automatically take care of everything.Part of this is also ensuring that no one else can cover up accounting irregularities by destroying/deleting records, so those methods will need to be overridden.
I'll be looking at the JD Edwards Accounting Guide for some direction, eg...
https://docs.oracle.com/cd/E26228_01/doc.93/e21540/revise_void_post_jrnl.htm#WEAGA233
Some more background on why immutable makes sense:
https://blog.divvyhomes.com/2019/05/14/building-your-own-ledger-system-pointers-and-pitfalls/
https://developer.squareup.com/blog/books-an-immutable-double-entry-accounting-database-service/
The text was updated successfully, but these errors were encountered: