My Accounting Controller did a bad thing.
He was working with the chart of accounts and accidentally deleted an account. That account had entries in G/L Entry, which are now showing up with no account number. I'm not sure why NAV allowed him to delete the record in the first place when G/L entries existed, but that's not really my question.
He has since added the account back into the COA. Is there a supported way to reclassify G/L entries to correct this? The other side of these entries apparently are fine and have the correct account numbers on them, so we're unsure whether a top-side adjustment through a journal entry will do more harm than good.
0
Comments
don't you have a recent backup to restore?it will be safer than any method that will be listed in mibuso...by the way...
you said that now the g/l entries show up with a blank account no, but what if you create a blank account no. and renumber it with the correct no.? NAV should take care about the renumbering of the table related fields.
Before doing anything, do some test and balances to check
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
As you mentioned blank account number and correct acc. number, I cant figure out what you actualy have...
Otherwise, set filter in blank in T:17, mark entries, remove filter, select marked only, Find/replace blanks with value.
If this does not work, run a report against blank acc. numbers in T:17.
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
That's actually a very good question. He told me that he deleted it and had to re-add the account, but I need to make sure on that one.
Either way, I have G/L Entries with no account number in them. Is there a system-supported way to correct them?
I've tried updating the table itself, but apparently we don't have permissions to do so.
I guess I'll try to create a report and see which way it goes. I thought I'd reach out first and see if there was a supported way to reclassify G/L entries or not.
Just FYI. This is the reply from my controller. I'm at a loss on how this could have happened in this way... it seems to violate the idea of a relational database. If anything, if NAV had allowed the delete to occur, I would expected a cascading delete... not changing the account number field in the ledger...
I think you can browse this function and find the right functions to call in order to rename your '' account.
It's not an easy work, because it is dangerous, but i think that a developer with the help of a good functional colleague can handle it.
BTW, i've never done it...you probably want some feedback before doing it
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
Interesting. I'll take a look there. Thanks for the heads up.
That's really interesting that the OnDelete() Trigger actually causes a movement of G/L entries into a blank account. I guess this is consistent with a ledger, though.
My license does not allow me to insert, modify, or delete G/L entries.
CodeUnit 361 has explicit permissions to do so, but I cannot copy the code out to a new report/codeunit in order to reverse the modification.
I've looked at the other touch points that occur OnDelete, and we're OK there, but I guess I need to get in touch with my partner and get them to do this with their license.
Thanks anyway!
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
They used my update and their license and corrected.