Should reversing transaction have the same date as the reversed one
Submitted by Guest on Mon, 05/10/2015 - 22:39
[Posted in the users forum to warn of a potential problem].
When you reverse a payment (in 1.8 and later) the reversing transaction gets the current date.
Hence if you find that payment dated say 28/9 is wrong and reverse it on the 2/10 then the reversing transaction will get the date 2/10.
If you now print the customer's September statement it will complain loudly about a Hidden Transaction mismatch because one of the pair is in the statement period but the other is not.
One cannot say 'if you discover an erroneous payment in the previous month then you cannot reverse it'.
This problem would be solved if the reversing transaction is given the same date/time as the transaction being reversed.
Regards, Tim G
Re: Should reversing transaction have the same date as the ...
I am not sure backdating transactions is a great acounting practice. I do understand the problem, but I think the issue is the way hidden transactions are handled within statement periods.
Basically if you discover a problem in a previous statement period (I would assume you have already issued the statement) hiding it sort of irrelevant at this point. Perhaps the solution is you cant hide reversals outside a statement period.
Re: Should reversing transaction have the same date as the ...
Ben - I agree that reversing a transaction in the long past is a BAD practice. However, in this case the erroneous transaction was dated 30Sept, and the error was discovered and corrected on 2 Oct when the end of month processing for September was being done.
The transaction hiding facility is something we need because of the way we lock finalised transactions. In the Quickbook Pro system I use, I can happily correct any error by editing the transaction and I can enter transactions for past dates. In OpenVPMS one cannot edit a finalised transaction so a hiding mechanism is necessary to hide our mistakes from the customer.
Because one always does Month End processing after the end of the month, it is highly likely that an error in a transaction close to the end of the month will not be discovered until early in the next month resulting in the reversed/reversing pair being split across the month boundary.
Even without a hiding facility, one cannot enter a corrective transaction with a past date so one cannot correct the customer's account for the previous month. It should not be necessary to append a note to the customer's statement saying 'sorry - we know invoice 123 for $456 is an error - please deduct $456 from the amount payable'.
However, there is a problem. Looking at the customer's account we have:
So if the reversing credit had been dated 30/9 although it was entered on 2/10, the Opening/Closing balance pair would be incorrect and thus the next month's statement will be screwed up.
Perhaps the way out is to modify the statement template so that it hides hidden transactions but does not bitch about hidden transaction mismatches, and also adds in an 'Adjustments' line at the end so that what is printed on the statement plus the adjustments add to the total at the bottom that we are asking the customer to pay. This adjustments line will only appear when there are mismatched hidden transactions.
Thus in the above case invoice 3354151 would not appear on the statement, there would be an adjustments line at the bottom for -258.50 and the Balance Due number would be $8,116.50 not the $8,375 shown in the closing balance above.
In the next month's statement, the opening balance would be $8,375 and (assuming no other hidden transactions) there would be an adjustments line at the bottom for +258.50 to offset the hidden credit.
Conclusion: the reversal mechanism should be left as is, but I should adjust the statement templates to work as suggested above. I will discuss this with the practice manager and chief accountant before doing so - but I suspect that we will go this way.
Tim A - yell if you want the standard statement to be modified.
Re: Should reversing transaction have the same date as the ...
I though I should document what we ended up doing.
I added parameters to the report that generates the statements as follows:
The 'Print Hidden Transactions' option allows you to reprint the statement showing the hidden transactions, and the 'Check Unbalanced Hidden Txns' option allows you to turn off the checking.
Recall that our problem was that the hidden pair was split across the end period boundary - ie
So both the September and October statements trip the unbalanced hidden transaction check.
For September, you just turn off the hidden checking and the statement comes out clean (because the code adds up the printed (non-hidden) transactions to get the amount outstanding - which is $8116.50, ie 285.50 less than the closing balance.
For October we have a worse problem - because the Opening Balance on 30/9 is "wrong". The solution here to simply print the statement for both September and October - thus including both of the hidden transactions. We end up with a longer statement - but the opening balance (for 31/8) is correct and the final amount outstanding is correct.
Regards, Tim G
Re: Should reversing transaction have the same date as the ...
Of course this works only if you use a custom statement report that is not the autogenerated one that generates from the Print Statements button in the Reports->Debtors view.
Correct?
Re: Should reversing transaction have the same date as the ...
Correct.
a) I will probably put a generalised version of our 'Extended Statement' in the resource library. However, I do not think that it will be possible for a practice to use it without modification - ie you will need Jasper Studio skills to tailor the various payment instructions etc.
b) You could change the Reporting|Debtors|Report to work the same way - ie with the ability to print a statement from an arbitary date - but you would have to add the extra parameters and change the data selection logic. [The extended statement Explanation text says "The statement is generated from the earlier of the 'Date From' and that of the opening balance transaction found prior to the oldest unpaid invoice, or if there are no unpaid invoices, the last opening balance before the From date."
Regards, Tim G
Re: Should reversing transaction have the same date as the ...
I have now put a generalised (ie needs tailoring to your practice) version in the resource library at http://www.openvpms.org/customisation/extended-statement
Regards, Tim G