Change cheque dates - How much trouble am I in?

bhalpin

The situation is this: A bunch of cheques were posted and they all had the wrong date (wrong fiscal year, in fact.) The challenge is to fix the problem.

I am bout to try something, but am wondering how many of my fingers I'll blow off by doing it.

When viewing the GL account for the bank I can click on a given cheque, then 'Navigate' and see a list of the record types and # of records accociated with the cheque. From each line I can then view the associated records.

What if I was to (in code) use Navigate's ability to find all the records related to a given cheque, and then hammer in the correct date into each record?

I know just enough about NAV to be really worried when something seems this easy.

Comments? Warnings? Dire predictions? War stories? =; [-X [-(

All are welcome!

ssingla

My recommendation will be to reverse and post new transaction. In case you still want to follow your way, then you can see how navigate functionality works or check the entry number/transaction number relationship between the records.

Savatage

I'm leaning toward the "Void" & Reprint the check correctly

Note: If you set the "Posting From" & "Posting To" dates every month in G/L setup - you will never ever get this mistake again.

For example every 1st of the month we move it up. you may not have to be that strict and perhaps set the dates from starting to ending date of the fiscal year. Either way once set - if someone tries to post outside that range a simple message appears telling you you can't post outside your permissed range. Someone says "Wpew!" and correct the dates \:D/

TonyH

Harry is right on here, technically you are navigating around the GAAP compliance of the product by using a license to adjust posted entries. I pretty sure if an auditor found out they would trip.

Void all the cheques and re-post.

ssingla

TonyH wrote:

Harry is right on here, technically you are navigating around the GAAP compliance of the product by using a license to adjust posted entries. I pretty sure if an auditor found out they would trip.

Void all the cheques and re-post.

Surely Harry's suggestion is the only legitimate solution to the problem which maintains the integrity of the database. Off-late I am founding lot of consultants playing with the system and they consider our suggestions as c r a p and I find really difficult to work with them.
The author of the post seems to be aware that he should not modify something manually or through batch job

bhalpin wrote:

Comments? Warnings? Dire predictions? War stories? =; [-X [-(

but still looking for some suggestions on the ways to achieve it.

ssingla

I always suggest/recommend and religiously follow to work the front-end way to achieve whatever I needs to do. I wonder there are many followers my thoughts in our part of the world.

bhalpin

I appreciate all the comments.

The fact is, the actual cheques were issued from their legacy system and dated in Jan '09, but when they were entered in NAV the were mistakenly dated for Dec 31 '08 - the same date as the opening balance-sheet entries for NAV.

So, the truth is the cheques are dated in '09 and they simply want NAV to refelect this and not have their opening balance sheet thrown off by the mis-dated cheques.

I know reversals are they 'correct' way to go, but that is still culture-shock when they (and I) are coming from a system that doesn't impose 'writing in ink' quite as severely as NAV does. The sight of a whole bunch of 'reversals' is still a shock to them. We'll all get used to it though.

B