Payments all get the same accounting date as the reconciling bank statement regardless of transaction date
Description
Environment
relates to
Activity
Carlos Ruiz December 28, 2023 at 4:07 PM
Carlos Ruiz July 30, 2020 at 7:19 AM
Agree, in case this is reopened to implement because of customer needs, then it must be done with a SysConfig that by default is disabled, and the SysConfig comment must explain the risk when having multiple schemas/calendars
Deepak Pansheriya July 30, 2020 at 7:16 AM
Triaged By
Closing as per Steven's comments not good idea to implement this and there is alternate way to achieve this.
Steven-Adaxa May 31, 2016 at 1:13 AM
Hi Carlos
Did you send to me for comment?
I would not be in favour of what Daniel suggests. The Bank Statement
should be a normal *mpiere document and those documents have the same
accounting date.... except for the Bank Statement as it was originally...
and which was why it caused problems.
I can see the logic of what Daniel is saying but it is just a trade-off
between which problems you prefer not to have.
The problem I prefer not to have is for a bank statement line to pick up
the payment date as the accounting date for the bank statement line because
that date may well be in a closed period that you have already reported on
.... then the user changes the bank statement line date and if a foreign
currency is involved then the BS line gets posted at a different exchange
rate introducing a permanent error in the accounts.
So unless Daniel's offering solves those two problems then you are just
trading off one set of problems against another and any suggestion that
IFRS standards says having one set of problems is worse that having the
other set seems is just personal; opinion .. my view is that having the
wrong rate and transactions in a closed/reported period is the worst
outcome and I would live with the handling issues. (the transaction date is
being posted o the Transaction Date column in Fact Account?)
btw ... the currency rate problem could have been fixed by picking up the
rate in the original Payment posting but we were looking for a quick fix
and using the payment date and still using the currency rate lookup routine
solved our immediate problem of getting the correct rate and posting all as
the document date solved the other.
regards
steven
On 31 May 2016 at 04:09, Carlos Antonio Ruiz Gomez (JIRA) <
Daniel Tamm October 3, 2015 at 11:56 AMEdited
Thanks for the feedback Steven I decided to fix the original problem in since this problem is a cause of that previous bug fix.
Since I generally have the accountant's perspective on iDempiere I'd like the system to make as much sense as possible to an accountant, so I'd like to avoid special solutions to something that is basic to an accountant
I'm putting this in peer-review again in the hope that my patch on together with this patch https://bitbucket.org/dantam/idempiere.se-historic/commits/211933d3f9dc676b527c00084d726b7bed8ce005 is accepted by the community.
Regards
Daniel
The bank statement is used to account for when payments actually land on the (bank) account. When reconciling bank statements (ie comparing the real world bank account with the actual accounting) the date is crucial. Wrong dates in the accounting can make finding errors in the accounting VERY DIFFICULT, especially if there are a lot of transactions.
In an attempt to prevent a bug occuring (IDEMPIERE-480) when running FactAcctReset the original functionality of the bank statement was changed to the current functionality which is as follows:
When making a bank statement, all statement lines get the same accounting date as the bank statement. This forces the user to either
1. reconcile every day (even if there's just one transaction per day)
or
2. live with the fact that payments are all accounted on the bank account on one single date (even if the payments actually affected the bank account on other dates).
Option 1 is still GAAP. Option 2 is non-GAAP and if there are many transactions per reconciliation, option 2 is an accountant's nightmare when finding errors in the accounting.
GAAP = Generally Accepted Accounting Principles
http://en.wikipedia.org/wiki/GAAP
Considering that iDempiere is an accounting system that should follow and preferrably enforce GAAP (or at least make it difficult to not conform to GAAP) my view of the priority should be as follows:
FactAcctReset is a non-GAAP process. It actually violates GAAP since it changes the accounting and removes every trace of the previous accounting. There's no way where you can have the system present a "diff" between how the accounting looked before running FactAcctReset and how it looked after running FactAcctReset. This is a clear GAAP violation.
To account transactions on a different date (reconciliation date) than when they actually happened in reality is non-GAAP.
If FactAcctReset works/has bugs or not is from a GAAP-perspective not relevant since it shouldn't even be there.
If transactions are accounted on the same day as the transaction happened is very relevant from a GAAP-perspective.
My suggestion would be
Revert the effects of fix IDEMPIERE-480. The fix didn't fix the actual problem with the FactAcctReset process as I see it.
Make the user select a period as well as accounting date when creating a bank statement, much in the same way as when creating a GL Journal entry.
Before complete, check that all dates on the statement lines are within the selected period.
By having the user have to select a period (automatically suggested when the accounting date is entered), the user will understand that all lines has to be within the period. The system will also check the dates that they are within the period. The period selection prevents statements that span multiple periods.
I think this is such an important accounting issue that is should be solved before iDempiere's first production release.