Options

G/L Entry Insert Trigger does not seem to be firing

fiona_twomeyfiona_twomey Member Posts: 20
Hi there,


I am developing in Navision Version 4.0 at the moment. The change I need to make was to ensure all lines posted to the G/L Entry table are stamped with a currency code. I felt the best place to put this change was in the Insert Trigger on the G/L Entry table to minimise the risk of missing any transactions.

My code did not seem to be doing anything so when I debugged and put a breakpoint in the Insert Trigger it never hit this breakpoint. I also put in a message to indicate this trigger had been reached and ran in normal runtime and the message did not appear??

Has anybody come across anything like this before or is there any particular reason why the trigger would not fire?

I am posting Sales Invoices while testing this and 4 records end up in the G/L Entry table after each post so records are being inserted into the table each time.

Fiona

Answers

  • Options
    Luc_VanDyckLuc_VanDyck Member, Moderator, Administrator Posts: 3,633
    edited 2006-07-19
    The INSERT-trigger is not run, because in codeunit 21, function FinishCodeunit, the line
    GLEntry.INSERT;
    
    is used to create a G/L Entry record.

    You better write your code in codeunit 21, to fill in any new fields.

    [Correction: the code is in codeunit 12]
    No support using PM or e-mail - Please use this forum. BC TechDays 2024: 13 & 14 June 2024, Antwerp (Belgium)
  • Options
    krikikriki Member, Moderator Posts: 9,090
    The INSERT-trigger is not run, because in codeunit 21, function FinishCodeunit, the line
    GLEntry.INSERT;
    
    is used to create a G/L Entry record.

    You better write your code in codeunit 21, to fill in any new fields.
    Luc means:Codeunit 12.

    If you want to send the currency code from table 36 to table 17, you need some extra code.
    You have to create the new field in T81 and T17.
    In Codeunit 80, you have to transfer the new field to table 81 just before codeunit 12 is called. In codeunit 12, you have to transfer the new field from T81 to T17.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • Options
    fiona_twomeyfiona_twomey Member Posts: 20
    Hi Luc,

    I have looked at codeunit 21 and in my database this is codeunit "Item Jnl.-Check Line".

    I have searched for the line GLEntry.INSERT and cannot find it. I have also checked for the existence of function FinishCodeUnit and cannot see this here either.

    I am running Version 4.0 with no service packs applied. Are you talking about the same version?


    Thanks,

    Fiona
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    edited 2006-07-19
    Please read Kriki's post

    The Insert is done in codeunit 12.

    Ledger entries are always static tables without business logic (with minor exeptions). Please keep it that way for consistency.
  • Options
    fiona_twomeyfiona_twomey Member Posts: 20
    Hi kriki,


    Thanks for the clarification on the codeunit no. That makes a bit more sense alright.

    The change I need to make, is a bit broader that just ensuring that I transfer currency code from T36 to T17.

    I need to ensure that all lines that end up in G/L Entry table, wherever they originate from, have a currency code stamped against them.

    Do you think if I made the same change to codeunit 90 I would have most things covered?


    Regards,

    Fiona
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    You can also change codeunit 11, and build in a check for your new field. This way you know for sure that, even if you forget to program it, never entries are created without your new field.

    Then, after that, you can find all posting routines your customer uses to populate the field. You might consider all codeunits that are filterd with *Post Line* and some document post routines.
  • Options
    fiona_twomeyfiona_twomey Member Posts: 20
    Hi Mark,

    Thanks for that.

    I have gone down that road in the meantime alright and have ended up with other issues which I will need to investigate. The problems I had were database inconsistency problems and were to do with changes I made to codeunit 12.

    Would I need to change codeunit 12 at all do you think or would changes in codeunit 11 cover this?

    Also, I think it's probably best to mark this topic as solved at this stage and start a new topic.

    Regards,

    Fiona
  • Options
    fiona_twomeyfiona_twomey Member Posts: 20
    Solved in 2nd reply.
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    If you want to add a field to the G/L entries you need to change codeunit 12. But this does not mean extra postings, just an extra field populated.

    Inconsistency problems can be a real pain but there is some supertip posted somewhere on this forum. I think it was Ara3n who posted that.
  • Options
    fiona_twomeyfiona_twomey Member Posts: 20
    Exactly ! That's why I decided to pursue the Insert Trigger option again. However, I do accept though, that if the standard is to keep business logic out of these tables, then we should stick to that.

    I will go in pursuit of that tip by Ara3n to see if I can find it. Thanks for that info.

    Just as a matter of interest Mark. I have only been developing in Navision for about 4.5 months. I had never seen the product before that. I have been given a day to complete this task. I was not given the option of estimating it myself. Would you think that was a realistic estimate in your opinion?
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    If it means just adding an extra field to the G/L entries, a day is more than enough for an experienced developer.

    If you also need to add currency calculations it is getting more complex.

    If this is your first time doing this you need to multiply the estimation with some value for this. What this multiplier is I don;t know and depends on your experience.

    Off-course there is always a difference between how much time it takes and how much a customer is willing to pay for it.

    I guess we are going off-topic here, maybe start a new thread about this.
Sign In or Register to comment.