Database designs for accounting and business applications

I'm guessing you're mixing/missing a lot of things in your design:
First one being that booking Journal Entries (JE) is only mechanics not the aim of the process: the aim being legal déclarations at the end of the fiscal year and to provide ways to management to take décisions regarding the activity,
Second is that reporting is an "instant" process, so keeping values for records… dépends only on the record and not on the period for which your asking the report (just book a late invoice…),
Third is that there no relationship between a "document's" (i.e. customer's invoice) line and the number of lines of JE booked for this line neither the number of VAT lines (with different VAT groups and eventually VAT percentages) which can be booked for the same line.

Could emphasisis on some other points, but these are the main ones.

First one being that booking Journal Entries (JE) is only mechanics not the aim of the process: the aim being legal déclarations at the end of the fiscal year and to provide ways to management to take décisions regarding the activity,

Second is that reporting is an "instant" process, so keeping values for records… dépends only on the record and not on the period for which your asking the report (just book a late invoice…),

Could you clarify that?

Third is that there no relationship between a "document's" (i.e. customer's invoice) line and the number of lines of JE booked for this line neither the number of VAT lines (with different VAT groups and eventually VAT percentages) which can be booked for the same line.

Point 2: in the data-model, you linked the JE line to cash-flow line which is (from my side) a mistake, because if you book a later document, the cash-flow will change.
Second, you're writing only about booking, but I could want to register JE in advance (so to not book them) but wanting to see their effect on my cash-flow: so definitively reporting and not data stored.

Point 3: sorry, going too fast because of my daily job

Your case is a wrong one, sorry; there should be at least three dates: document, due and tax.
Document's date is the one of the document, due is when it should be (invoice) paid and tax when I'm bookeeping it.
If I'm finding this document in a drawer a long time (or could have been sent) later after the document's date, I just cannot bookkeep it for its original tax date, because it may be passed (in all cases, tax date of this document is related to my Partner accounting, not mine : for myself this is Always when I bookkeep it) but I book it when I've found it, which is correct from a G/L point of view and regarding any king of closing periods.
In all cases, this is bad practice: if I'm issuing or receive the document, I should bookkeep immediately, so this case should not happen (I agree, it happens every day )

The view of the cash-flow doesn't depend on this, but on booked documents (JE) and expected documents/JE and/or closing JE and all of these can vary upon time, including in a single day and while booking "forgotten documents" in a drawer
So definitively, cash-flow is a report and not data stored

Writting about period is a different thing: when a period (or sub-period) is closed, for sure its booked data cannot change, so effectively you can expect that the cash-flow won't change; but this is a specific case…

General News Suggestion Question Bug Answer Joke Praise Rant Admin

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.