Reversal of incorrect payment falling in incorrect accounting period

Dear Forum Members,

We have a situation where an incorrect payment type was entered. This was not picked up when the till was cleared. As administrator I have reversed the transaction and entered a new transaction with the correct payment type. All seems well superficially, *except* I could not find a means to alter the input date of the new transaction. Unhappily this means the payment now appears in the payments report to fall in the incorrect VAT quarter. This makes my accountant deeply unhappy. I can find no means of adjusting this. Is there some way that I am missing? Failing this, is it possible to update the act.activity_start_time for this record so that in the reports it falls in the correct accounting period?

Kind regards

Chris

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Reversal of incorrect payment falling in incorrect ...

Hi Chris,

You are correct, we do not support back dating payments.  The reason being if you back dated to a date prior to the end period (opening and closing balances) the balances would be incorrect/invalid.  

So firstly can I ask if the amount was correct but the type was not why didn't you just edit the payment as we support changing types (not amounts) of finalised payments. Would that have solved your issue ?

Cheers

Tony

Re: Reversal of incorrect payment falling in incorrect ...

Hi Tony,

The amount was correct but the type was not. It was not picked up until we started doing end of quarter where it was found the EFT and credit card amounts were incorrect. It should have been picked up before clearing and depositing but wasn't. From my understanding once an amount is deposited the payment type can't be changed. I might have this wrong though in which case I have made the problem far harder to fix.

The back dating of payments could be a regular issue for me though so it does raise a wider point. At the end of every quarter any payment made in that quarter must be recorded as occurring in that quarter. As EFT systems run 24h in the UK I generally get a few payments come in just before midnight that have to be recorded the following day as having occurred the day before other wise the bank statements vs reports are not correct and the accountant has a melt down.

If it is as simple as adjusting the act.activity_start to just before midnight the day before then that works for me for such an infrequent problem.

Chris

Re: Reversal of incorrect payment falling in incorrect ...

Hi Chris,

You could make the choice to set the payment date as non- read only in the payment archetype but that may be risky.  It would solve your issue though but could possibly cause other issues if accidents are made updating the default date of the payment.  If you ar ehte only user that may be an acceptable risk ??

Cheers
Tony

 

Re: Reversal of incorrect payment falling in incorrect ...

Hi Tony,

Thanks, that seems like a good idea and far less risky than me making semi-regular update statements in the database...

I've modified the act.customerAccountPayment archetype so that the startTime node is writeable. That seems to have allowed the arbitrary input of a date during a payment.

With regards the payment I have already stuffed up, the gui still won't allow me to edit that citing a reference to a cleared Till. In this one off instance, is the easiest method to alter that payment to issue an update directly in the database?

Cheers

Chris

Re: Reversal of incorrect payment falling in incorrect ...

Hi Chris,

Seems like the only approach available for that payment given the in code restrictions re cleared tills. :-)

Cheers
Tony

Re: Reversal of incorrect payment falling in incorrect ...

Hi Chris,

We have discussing your specific issue and we are trying to understand your reconciliation issue better.  

Can you provide the specific use case that doesn't work for you ?

Are you reconciling your daily payments with a daily payment report or with the Till balance  on clearing ?

Are you after a perfect match between the OpenVPMS daily payments total and what shows up in the bank when the bank does its auto clearing at the end of the day (midnight) ?

Do you process the payment in OpenVPMS  first or on the machine first and then in OpenVPMS or is this concurrent ?

A better understanding of the issue woul dbe great as we don't seem to hear of this as an issue here and from other users ..  :-)

Also the database update of the date is a bit more complex than just updating the act dates.  Any participation associated with the act need to have their activity_start_time and activity_end_time updated as well .. essentially direct database updates are a bit of a no no :-)

Cheers

Tony

Re: Reversal of incorrect payment falling in incorrect ...

Hi Tony,

 

Fundamentally we would like payments that appear in our bank statement to appear in the same VAT quarter that they are made. On a day to day basis it doesn’t matter if a transaction appears in the bank statement and is reported in openVPMS the following day or even the following week but at the margins of this example lies the problem. At end of VAT quarter the transactions that enter our bank account up to midnight that day must have VAT paid on them for that quarter so they have to be reported as having occurred in that quarter.

There is no concept of bank clearance in the UK. Banks subscribe to the faster payments system and unless a transaction fails a fraud filter, it appears instantly in our account when a person makes it no matter the time of day.

Perhaps in a more traditional practice this is less of an issue as most transactions would happen face to face. In our ambulatory practice though, in excess of 90% of transactions are made by EFT.

We are a tiny practice and don’t expect to get any special consideration based what works for us but the ability to enter a payment on the date that it was made rather than the date that it was entered would be immensely helpful. I’m yet to test it but I think making that node in the payment archetype writeable should do the job.

The transaction that I need to correct may just need to be manually accounted for in this vat quarter and next by the accountant. So be it if it is too dangerous to make a manual update to the transactions.

The reason the error occurred in the first place (other than me being careless) is that the idea of clearing a till and depositing it doesn’t really happen for us.

EFT payments are deposited before they ever see the openVPMS system. Credit card payments don’t have a chit as we take them online through a portal system. Cheques and cash are potentially the only items that might be regarded as being in a till and even then cheques are not physically deposited but rather scanned on an app where they clear into our account the following day. This means that hitting deposit on a till clearance that contains more than one type of payment doesn't match physical reality.

The ability to clear individual payments from the till (or even groups of payments by payment type) as they are reconciled against the bank statement and daily credit card statement from the portal supplier would be amazing and work for our style of practice. Similarly being able to selectively deposit items from a till clearance as they find the bank account would match the reality of our transactions.

At the moment, and since the payment cock up of mine, we are trying to make the till clearance/deposit system work for us by clearing the till after recording groups of EFT payments before we take any further cash, cheque or card payments. We then clear that again before taking any further EFT payments. This is all made a bit harder because the on screen display does not include the transaction type in the grid display. I’m guessing you did this to save a join statement but it makes it much slower to reconcile as we have to generate the report rather than just doing it off the grid display.

As stated earlier, ours is such a niche application of openVPMS so we don't expect you to make any significant changes based on our unusual set up.

 

Kind regards

 

Chris

Re: Reversal of incorrect payment falling in incorrect ...

Hi Tony,

Further to my last note, we've had a chance to test the payment date being set prior to today's date. Although in the payment screen the field brings up a date picker and no errors are generated on clicking OK the date is entered with today's date regardless and in all the reports is shown as today's date rather than the one that was entered in the date picker.

Chris

Re: Reversal of incorrect payment falling in incorrect ...

Hi Chris,

Sounds like the application is smarter than I even thought so sorry for the wrong information.  

Back to the drawing board unfortunately ...

Cheers
Tony

Syndicate content