Hi chris1129,
this is a "not fun" situation... however, I think you can (maybe with a little "prodding" of the reverse function) resolve this.
Warning! Only do this when you know what you're doing. You should be the only user in the database. I would at least try and verify this on a copy of the production database before. For auditing, a complete documentation of what you're doing is needed. I'd recommend doing this together with the accounting department and a consultant from the NAV partner.
Let's look at what happened:
1. you ran adjust exchange rate multiple times.
2. for every adjustment, you get a G/L register. This contains all entries (and detailed entries) which have been created by the adjustment batch job. Only additional entries have been created, and no existing entries were modified.
All would be as it was before, when these registers can be reverted, and the Adjust Exchange Rate registers updated accordingly. That's what we're doing.
The simpler case is when you've only adjusted ACY, not the customers/vendors/bank accounts. In this case you need to:
- force the reverse function (T179, collect entries to revert) to work for a register without a gen. journal name.
- create a batch which would write a corresponding adjust exchange rate entry.
The posting of the reversal itself works without modifying CU12.
The more complicated case is when you have all possible entries being adjusted at once. In this case, you would additionally need to filter out the entries you want to revert from the register. Unfortunally all the entries have the same transaction no. I would make the Reverse transaction form editable (enough to allow delete) and would remove all entries I don't want reverted - all except the G/L ACY adjustment. Then post the reversal.
Do the above for every adjustment you need to undo. Afterwards, remove the code modifications from the database.
with best regards
Jens
Login
Register
RSS Feed
Rules
FAQ
Search the forum
