If you really want to change go to AR_OpenInvoice and enter in the division number, customer number and invoice number. When you find it edit to change. Next go to AR_InvoiceHistoryHead and enter in the invoice number being sure to pad it to 7 places. When you find it edit to change the invoice date. Note that you will probably have to edit the due date also.

I looked into AR_OpenInvoice, and was told it wasn't found/didn't exist. I assumed it was because it was only looking for non-updated invoices. I understand why they do it, but trying to find a record to edit in DFDM is like looking for treasure through a pinhole. Unless you're looking in the exactly right manner, you can't see what you hoped to find.

You're right that only posted invoices would have to be accessed through DFDM--I'm obviously not thinking clearly today. In my defense, I spent four hours yesterday fighting my computer to have it show me a file that I knew was there. But it makes me wonder why nothing I was looking at would come up.

Just curious whether I'm accessing it correctly, because there seem to be so many paths: When I try to access OpenInvoice.M4T, I go to the server, then Sage-2016/MAS90/MAS_CON/ARCON/AR_OpenInvoice.M4T and get the message that it's not found. The help center is not being very helpful in the process of figuring out what I'm doing wrong.

Just curious whether I'm accessing it correctly, because there seem to be so many paths: When I try to access OpenInvoice.M4T, I go to the server, then Sage-2016/MAS90/MAS_CON/ARCON/AR_OpenInvoice.M4T and get the message that it's not found. The help center is not being very helpful in the process of figuring out what I'm doing wrong.

One has to be "thinking clearly" to use DFD&M and read the Warning message on entry. I suggest you take the support class. Sorry!

Thinking clearly when using DFDM and thinking clearly when asking a question about it aren't the same thing. I was trying to figure out why I was getting a message why the files that I was looking for didn't exist. BigLouie and TomTarget are both knowledgeable and helpful, and I always appreciate their insights.

An invoice can disappear from the Open Invoice table after it is paid.

I wasn't getting a table at all. I got the message that the table itself didn't exist.

Melinda, you have me really nervous mucking around in DFDM based on your comments. I would really suggest talking with your Sage Partner if you really want to continue down this path.

Tom, I haven't been "mucking about"--I was looking around and trying to figure out where things are located, which should do no harm. I have used DFDM before when an invoice was mistakenly marked "paid" due to a cash receipt glitch, with the help and blessing of my reseller, but that was over a year ago. I was trying to remember how I did it and where I found the information, and don't need to invoke my reseller at this point, but will if and when I have to. If you're inferring that I'm recklessly changing data through DFDM, then you're mistaken.

"Can I easily change the date on an updated invoice?"
The answer to this is "no", and I guess the main consideration at this point is "why would you want to"?
If the numbers being in the wrong buckets bother you, a CM with the originally bad date, and DM with the good date would be greatly preferred to DFDM. First, it is easier (as well as being more accurate / complete), and second it creates an audit trail of the correction.

The only reason to change would be if it was an issue for accounting/profit statements. I wasn't even necessarily looking to do it through DFDM, unless it was easily done and didn't make a bigger mess (as stated in my original comment) because I know that it's best used sparingly and with the correct knowledge. I am marking your reply as an answer so I don't continue to get comments from people who think I'm leaving a swath of destruction in DFDM.

Invoice date would affect AR / sales type reports, but GL based reports only consider the posting date. If you use a sales based report for something important (like salesperson commissions), then doing manual calculations would be easier than finding out how that data is stored in the system and correcting it.