Is there a way to remove bad DMT cost adjustment items? It’s killing the WIP Recon Report 
Disclaimer: I’m pretty sure I know and do not like the answer I’m prepared to receive.
I am fairly sure that there is no way to reverse this. it is not a “batched” item. It is a transaction that is executed immediately and adjusts the cost records and puts data into the PartTran table.
Sigh I was pretty sure this was the case Thank you for the confirmation!
@CSmith: Ouch! That’s going to leave a mark! My condolences to you. I would be interested in hearing how you ultimately address that problem.
@timshuwy: What would you recommend as preventative controls for this potential issue? Keeping future fiscal periods closed until they are absolutely needed does not seem to offer any help since the adjustment transactions won’t be posted to GL until the Capture COS/WIP Activity process runs. Using the “Earliest Apply Date” functionality definitely offers no help, since it addresses only past dates/fiscal periods. AFAIK, there is no built-in functionality to prevent this scenario, so is the only solution to use a BPM, a function or custom code? How likely do you think it would be that the submission of a new idea for a “Latest Apply Date” would be accepted for development?
In truth it would be nice to not allow something 20+ yrs into the future on the PartTran table/GL… Not sure how these records will affect things going out that far I will try to revisit in the near future and see what effects they may have caused.
Error on this type of DMT choice would be good IMHO. I could see one at most 3-6 months in the future, but WHY allow something 10 or more years out? Seems crazy to allow this. (Excel copy with the + was the most likely culprit along with an inexperienced user not properly using TEST first )
1 Like
I once created a BPM for a customer to prevent SHIPMENTS and RECEIPTS on a date more than X days in the future or past… They wanted to be able to put something into “tomorrow’s” shipment (which might be Monday, 3 days away), so by putting a BPM in place that threw an error if the date was too far in the future, we prevented a lot of bad keystroke errors.