Logic behind UUID? about django-ledger HOT 4 CLOSED

This is something that I have been thinking about too. Incremented pre-numbered records have been used as an internal control in accounting for a long time. Take for example checks, each with their own number auto-incrementing along a sequence. All forms of documentation and record-keeping were sequentially prenumbered before the move to electronic record keeping. If a check is missing in the sequence, the question arises from the auditor, "what happened to it". Voided or misprinted checks need to be retained by the treasury department for a period of a year to substantiate these gaps. The logic behind this is in a well-designed accounting department, records of a certain class [checks, vouchers, receipts, deposits, credit card charges, journal entries] should not break the sequence regularly. This is an indicator of a poorly operating accounting department and elevates the risk of error. So as an auditor, if I see a lot of gaps or missing elements in a sequence, I know that something is not working as it should be, and I increase my professional skepticism and substantive testing.

Auto-increment answers the question "are there gaps?". It does not answer, who what when where why. I don't think that auto-increment is absolutely needed as long as the system can report these gaps and the reasons/players in some fashion. There is also the consideration that some organizations, individuals, or whoever will not buy into DjangoLedger if auto-increment isn't a part of the system. My wife was in auditing and could speak more to that, I'll ask her.

I envision that if a record is to be deleted, a reason must be submitted by one user and approved by a manager or another person. this would satisfy the needed segregation of duties for proper internal controls. My other idea would be that records of a certain type have a regex-like id. Journal entries would be JE1, JE2, .....JE101. Vendor Vouchers would be VV1......VV101, etc. This would allow the records to be discernable by class and incrimented.

from django-ledger.

A good article on the subject.
UUID or GUID as Primary Keys?

from django-ledger.

Good stuff.

Cheers

from django-ledger.

UUIDs guarantee that each record has a unique identifier regardless of the data store. This condition is particularly important and useful for GAAP compliance, accounting and auditing purposes. There are many benefits of having UUIDs for each record, especially if integrating with other technologies, in particular distributed systems which are important nowadays to develop applications that scale. Also, using plain auto_increment IDs may leak sensible information if using them in the URL.

The article you mention is 11 years old, so I'd like to think that modern databases have gotten a lot better at managing and using UUIDs for primary keys as they have implemented native UUID Data types. I don't think storage is an issue nowadays. A primary UUID key is also indexed for performance. However, I can see why they may not outperform AUTO_INCREMENT.

While I don't like the idea of delegating the task of ID generation to a single database, there may be a benefit for using both, AUTO_INCREMENT and UUIDs on each model. This is something I've been debating and I'm sure that a happy medium can be found.

Also, I believe there's opportunity to design better looking URLs with proper DB indexing, especially for POs, bills and invoices by using their respective numbers or slugs.

This may be a good topic to further discuss.

from django-ledger.