transactions posted with incorrect date

I had that happen to me once, I have no idea how the date got changed. What I did was set the system back to the erroneous date and voided all the transactions made on that date and then ran a Z report, which basically set that day back to zero $ and inventory correct even though there were still transactions for that date. I then set the system back to the right date and ran the transactions through on that date and ran another Z report. All transactions were shown correctly on the right date, money was right, and inventory was correct. I ended up with an extra batch, but that was no big deal to me.

Craig

It can also be done with a query that finds transactions with the wrong date and changes them. I have done it in the past, but am not great with SQL, so I use MS Access to write my queries. Hopefully someone better with SQL will post a query for you.

Marc

Marc,

My only question regarding using a query to change the dates would be how would it effect sales and tax reporting, along with customer transaction records. The Z report for both days would definitely be off. There also would be no paper trail for how and why those days transactions dates were changed. I'm not saying using a query wouldn't be OK, but in this case it might not be the best option. Matt gave the queries so ck in ks can decide which way is appropriate for them. The queries would be quicker, but not by much, unless there where a lot of transactions to void. When dealing with transactions I prefer to make sure I have a paper trail in case of an audit. I use queries in a lot of cases, but this is one instance I wouldn't be comfortable with. Just my 2 cents.

Craig

Craig, you absolutely should be cautious about changing the data directly, but fixing the data to put the records on the right day actually makes everything work better, because the reports and history then matches the z report of the batch they were part of. Keep in mind that the z report doesn't care what date was used during the batch, only what has happened between the opening of the batch (last z report) and now.

I think the only thing that wouldn't match well, would be the date stamped on the paper receipt not matching the correct day. To fix this, you would have to use the previous mentioned solution to change the date, reverse transaction, change back and recreate the transaction again.

Ditto what Matt said - LOL

I actually wanted the dates changed so my sales reports (by date, not batch) would be correct. Also sales tax reports could be off, if the dates fell across months.There may be a few other things I am missing that would be effected by wrong dates. When I looked into it, like Matt says, I did not see any related tables that would cause issues with the changes, except that receipt/journal dates would be different.

Marc

Matt,

That was my point, the paper trail for the transactions wouldn't match the electronic versions. Thus any audit would be more intense as you try to explain all of this. I just don't think this would be one of those times I would take the easy way out with the queries. I still am not convinced there wouldn't be any unforeseen problems with doing this. A batch that was already closed would then have some new transactions in it not included in the original batch.

I understand what you are saying, I guess it all boils down to what data you are comfortable with manipulating after the fact with queries. I messed things up once because I didn't completely understand the balance between all the different table structures and even though I did a backup before, the problems didn't show up until a few days later, making that backup useless. I then had to ask for more help with queries to fix what I had messed up. :-) I really do appreciate that you are willing to share your expertise with all of us though. It's very helpful at times to use queries to manipulate things, and a lot of us need the help writing those queries, so thank you. I hope those that have never used them before really think twice before just forging ahead, because it can be really dangerous.

Craig