G\L Entry - Blank account No.

FishermanFisherman Member Posts: 456
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.

Comments

  • BeliasBelias Member Posts: 2,998
    Fisherman wrote:
    accidentally deleted an account
    do you mean that the entire line or only the value of the primary key (making the account no. blank, as you said in the subject)?

    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 :wink:
    -Mirko-
    "Never memorize what you can easily find in a book".....Or Mibuso
    My Blog
  • MalajloMalajlo Member Posts: 294
    If you deleted record in T:15 (how this could happen without warning?) and records in T:17 still have correct account numbers, then new rec in T:15 fixes problem.
    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.
  • BeliasBelias Member Posts: 2,998
    T17 is not the only table where the g/l account no. is stored...there are more other tables, for example the Sales Invoice Line, the dimensions...this is the reason because i suggested the renaming...
    -Mirko-
    "Never memorize what you can easily find in a book".....Or Mibuso
    My Blog
  • FishermanFisherman Member Posts: 456
    Belias -

    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?
  • FishermanFisherman Member Posts: 456
    Malajlo -

    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.
  • FishermanFisherman Member Posts: 456
    All -

    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...
    Okay, I actually deleted the line/account from the Chart of Accounts.

    When I “re-added” the line/account to the Chart of Accounts, the drill down for the net change (postings) showed that there weren’t any there.
  • BeliasBelias Member Posts: 2,998
    ok, understood: take a look at the ondelete trigger of the g/l account table: it calls codeunit 361, which actually blanks all the related records.
    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
    -Mirko-
    "Never memorize what you can easily find in a book".....Or Mibuso
    My Blog
  • FishermanFisherman Member Posts: 456
    Belias -

    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.
  • FishermanFisherman Member Posts: 456
    Well - hit a roadblock that I expected.

    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!
  • Alex_ChowAlex_Chow Member Posts: 5,063
    You'll need to get your partner to do this for you with a developer's license..
  • FishermanFisherman Member Posts: 456
    Talked to them a little while ago.

    They used my update and their license and corrected.
Sign In or Register to comment.