- What steps have been taken so far? Often times, I find that attempts to correct the issue (sometimes even multiple posted corrections) have contributed to the current issue.
- What is the current state of the issue? What remains to be corrected (e.g., the GL is incorrect but the RM aging is correct)? Getting to this bottom line can often be helpful in solidifying the real issue.
But we want to avoid these issues in the first place, right? So getting back to the dancing. Here are the common correction points that I emphasize to students and users, to point out the importance of correcting transactions where they originated.
Sales Order Processing
- To correct a posted invoice (Transactions>>Sales>>Sales Transaction Entry).
- Enter and post a return (Transactions>>Sales>>Sales Transaction Entry).
- Updates inventory (if applicable), sales history by item, receivables management, and general ledger.
- Do not void using Receivables Management (Transactions>>Sales>>Posted Transactions), as this will only update the general ledger and receivables management.
Purchase Order Processing
- To correct a posted receipt or invoice (Transactions>>Purchasing>>Receivings Trx Entry, Enter/Match Invoices).
- Enter and post a return (Transactions>>Purchasing>>Returns Trx Entry).
- Updates inventory (if applicable), purchasing history by item, payables management, and general ledger.
- Do not void using Payables Management (Transactions>>Purchasing>>Void Open), as this will only update the general ledger and payables management.
Project Accounting (Employee Expenses, Miscellaneous Logs, Timesheets, and Equipment Logs)
- To correct a non-purchasing transaction (purchasing transactions are corrected in POP per the example above), return to the original entry window (Transactions>>Project>>Timesheet Entry, Employee Expense Entry, etc).
- Enter a Referenced type transaction and use negative quantities to decrease the original posting. You can use the PA Trx Adjustment tool to assist with this process (Transactions>>Project>>PA Trx Adjustment). Using either method will result in an update to project accounting, payables management (if applicable), payroll (if applicable), and the general ledger.
- Do not correct the transactions in payroll, or by voiding the transaction in payables, as these methods will not update the project accounting module.
Well, that's it for tonight. I promise that my next post will get in to the finer points of correcting project accounting billings and inventory transactions, which have more variations than the examples I have provided above.
But, in the meantime, please share any tips and tricks you have gathered over the years to assist users in understanding how to dance with the one who brung 'em :)
Christina,
ReplyDeleteGreat post. This also gets my 'Best Title Award'! Hee.
-Victoria
Thanks, Victoria! I definitely am a Missouri gal :)
ReplyDeleteWhat are your ideas on correcting an Enter/Match Invoices transaction that was matched to the incorrect shipment (receipt)? I keep going in a circle on this one. :(
ReplyDeleteThanks
Hi Stef--
ReplyDeleteI don't have a good solution there. I think the only way to do it through the application would be to do a return with credit, re-record the shipments and then the invoice-- which stinks. I would try posting on the Dynamics community forum, https://community.dynamics.com/product/gp/f/32.aspx, to see if you get any better responses :)
Take care,
Christina
Hi
ReplyDeletehow could you void a Sales Return?
would that be making another sales invoice? but a fake one?
Thanks a lot
Hi F-
ReplyDeleteYes, that would be appropriate if you needed to remove the item from inventory that was returned.
Take care,
Christina
What about the promise to write up correcting inventory transactions and other modules. If you wrote them up please post links. If not your broke your promise... :)
ReplyDeleteHa! So long ago! But I will definitely take it under consideration :)
ReplyDelete