Skip to content
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

Open
mbulat opened this issue Sep 25, 2020 · 4 comments
Open

Make entries immutable, and provide an revision/amendment feature #133

mbulat opened this issue Sep 25, 2020 · 4 comments

Comments

@mbulat
Copy link
Owner

mbulat commented Sep 25, 2020

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/

@hainam8x
Copy link

hainam8x commented Oct 7, 2020

I am developer and also accountant, when dealing with accounting systems that are not allowed to be change or delete would be a pain.
In big accounting system like SAP, they do not allow entries to be delete or modified after posted. But systems like SAP used for big company and have resources to hire big accounting team.
In small company, the accounting team are much smaller and many company only have 1 accountant to handle everything. If there are only few people and if accounting systems do not allow accountant to edit/delete entries, that would be a pain and time consuming.
In all accounting software, there are function called "lock the accounting book", accountant cannot change the data before lock date. But for entries not locked, accountant need freedom to control the accounting book themself.
I think this enhancement should be optional, depend on use case

@inopinatus
Copy link

There are other related notions in the temporal domain:

  • It is not merely entries that need become immutable, but time periods, usually due to external compliance & reporting.

  • Some transactions have an effective date that differs from both their reporting date and record timestamps. Example: a merchant account with payments yet to clear (it is commonplace for such accounts to report two balances e.g. "available" vs "pending").

  • Some adjustments call for the ability to rollback a journal in memory, then replay it under external iteration control. Examples: recalculation of compounding interest, or a change in depreciation method.

  • Commercial documents (such as invoices) linked to entries often have a new->draft->provisional->approved lifecycle or similar. Although not part of Plutus, such documents provide meaning and context, are therefore of accounting significance.

And database considerations:

  • Overriding model destruction methods is a thin barrier. I'd go further, suggest table partitioning over time periods with a database-level drop of update/insert/delete permissions after rotation. Another option is signing entries and balances periodically, although this can interfere with the CRDT nature of DE book-keeping.

@mbulat
Copy link
Owner Author

mbulat commented Jan 25, 2021

@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.

@buncis
Copy link

buncis commented Jan 17, 2022

this is would be nice I'm also thinking about combining this gem with https://github.com/collectiveidea/audited too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants