Why can't I discard changes on a Transaction?
I saw a newsgroup posting today asking this common question. You might ask "Master records like Customers and Vendors let me discard changes, so why not transactions?"
There is no discard/undo/cancel changes functionality on most (if not all) transactions within Microsoft Dynamics GP. Why is it so?
Well, there is a simple technical reason for this.... Referential Integrity of the Data.
Master record usually only involve a single table and the data in one table does not have a direct effect on data in other tables. When you make change in the master record, it is not automatically updating other tables. This means that discarding changes is simple as there are no other tables involved. You might note that some fields cannot be changed or that the record cannot be deleted if it has been used. This is to maintain the integrity of the data.
When you make a change on a transaction line, it is immediately saved to the table when you move off that line and any header changes needed are made to the header data in memory. There might be other tables updated as well for other related information such as taxes, distributions and commissions. All of the child tables are updated in the database and it is only the header data that has not yet been written to the table.
When you exit the window or move to another transaction, you must either save the current transaction's header to match what is now on the line (and other tables') records or delete the entire transaction. If you were to "discard" the header changes, it would no longer match what is in the other tables that have already been updated. There is no record of the previous values for the other tables, so there is no possible way to reverse or undo the changes.
In short, we cannot undo as we no longer know what the old data was.
It is possible to write a window with Dexterity that can have an undo facility. The basic concept is to copy all data from the child tables into temporary tables and perform all editing using the temporary table. When the transaction is saved, you can now remove the transaction's records from the actual tables and copy the updated information from the temporary tables back to the actual tables.
So why isn't this "temporary table" method used?. I can think of two reasons:
- Cost: The development effort to rewrite every transaction window in the system would be prohibitive.
- Concurrency: Some data must be updated immediately and not when the user finally decides to save. For example, the allocation of stock items to orders and invoices must be updated immediately, so that the stock cannot be over sold.
Let us know you thoughts, post a comment.
David