Consumption Journal

Avdhesh_YadavAvdhesh_Yadav Member Posts: 5
Dear All,

have anyone faced the problem of very slow posting by the consumption Journal?
We are using Nav 6.0 SP1 Classic Client and SQL Server 2008.

Posting is so slow that for the consumption of 220 lines, it takes around 2-3 hours.

>Finished Quantity on the Released Production Order is 500 for a serialized item.
>All the Item on the consumption journal are non serialized.

We are using Manual Flushing method on all the item.

We already checked the configuration of the SQL Server, that is OK.

Please suggest any relevant reply.

Thanks...

Comments

  • bbrownbbrown Member Posts: 3,268
    How is the performance of other posting activity? System performance in general?

    There can be several contributing factors to an issue lke this. Of which hardware is only one. I typically find that these issues are the combination of multiple issues.

    For our reference, can you provide your hardware details? Also how large is the database?
    There are no bugs - only undocumented features.
  • Avdhesh_YadavAvdhesh_Yadav Member Posts: 5
    All the Processes like Item Journal Posting, Item Reclass Journal Posting and others,and documents posting is very good.

    and also some production order consumption is fast too.

    We analyze that, problem is for those production orders for which output quantity have been sold and
    consumption is pending.
  • bbrownbbrown Member Posts: 3,268
    Do you have "Automatic Cost Adjustment" turned on?
    There are no bugs - only undocumented features.
  • Avdhesh_YadavAvdhesh_Yadav Member Posts: 5
    Hi Brown,

    >Automatic Cost Adjustment is set to never.
    >Automatic Cost Posting is unchecked.

    We run the adjust cost batch at night.
  • ebitasebitas Member Posts: 71
    Hi Avdhesh Yadav;

    I'm having the same problem.. Have you found a solution? if yyes will you please share it with me..

    Thanks
  • jspoppjspopp Member Posts: 54
    Hi, we were experiencing this issue as well right after we upgraded to NAV 6.0. We escalated it to our NAV partner and then onto Microsoft. I believe the issue is code in table 339 (Item Applicatiion Entry). The curernt code causes excessive looping and the fix was to limit this process. Goog luck with this!
  • ebitasebitas Member Posts: 71
    Thanks you so much for replying. I do appreciated. I'll look into that table and see what I can do.. One more thing, is it possible to email table 339 with the fix so I can compare the code? this will help alot ..

    Again, Thank you so much for your help..
  • jspoppjspopp Member Posts: 54
    Hi, I don't have access to that code. Check and see if there is hotfix on this issue. We experienced it about 2 months ago so there may have been something published on this issue
  • ebitasebitas Member Posts: 71
    Thank You. I'll check if there is a hotfix. Mean while it will be great if you are able to export the object and email it I'll be able to open it up and view the code.

    Thanks a lot for your help.
  • vijay_gvijay_g Member Posts: 884
    Might be the code for optimize is using FINDFIRST with REPEAT..UNTIL. :-k
  • Himanshu_NigamHimanshu_Nigam Member Posts: 23
    turn off the "Automatic Cost Adjustment" then chk..
    and uses batch report for applying "Cost Adjustment"
  • bbrownbbrown Member Posts: 3,268
    turn off the "Automatic Cost Adjustment" then chk..
    and uses batch report for applying "Cost Adjustment"


    I asked that question earlier. They're already doing that.
    Hi Brown,

    >Automatic Cost Adjustment is set to never.
    >Automatic Cost Posting is unchecked.

    We run the adjust cost batch at night.
    There are no bugs - only undocumented features.
  • ebitasebitas Member Posts: 71
    Thanks for everyones input on this issue.
    Thie issue has been resolved and here is the solution if anyone needs it in the future:

    OBJECT Table 339 Item Application Entry ...
    CODE
    ...
    PROCEDURE CheckCyclicProdCyclicalLoop@1100(CheckEntryNo@1006 : Integer;ItemLedgEntry@1304 : Record 32) : Boolean;
    ...
    BEGIN
    + IF NOT IsItemEverOutput(ItemLedgEntry."Item No.") THEN
    + EXIT(FALSE);
    +
    ...
    ItemLedgEntry.SETRANGE("Prod. Order No.",ItemLedgEntry."Prod. Order No.");
    ItemLedgEntry.SETRANGE("Prod. Order Line No.",ItemLedgEntry."Prod. Order Line No.");
    ItemLedgEntry.SETRANGE("Entry Type",ItemLedgEntry."Entry Type"::Output);
    IF ItemLedgEntry.FIND('-') THEN
    REPEAT
    + IF EntryIsVisited(ItemLedgEntry."Entry No.") THEN
    + EXIT(FALSE);
    +
    ...
    LOCAL PROCEDURE CheckCyclicFwdToAppliedEntries@8(CheckEntryNo@1000 : Integer;VAR ItemApplnEntry@1005 : Record 339;FromEntryNo@1002 : Integer;IsPositiveToNegativeFlow@1009 : Boolean) : Boolean;
    ...
    VAR
    ToEntryNo@1008 : Integer;
    BEGIN
    - IF EntryIsVisited(FromEntryNo,ItemApplnEntry) THEN
    + IF EntryIsVisited(FromEntryNo) THEN
    ...
    - LOCAL PROCEDURE EntryIsVisited@10(EntryNo@1000 : Integer;VAR ItemApplnEntry@1001 : Record 339) : Boolean;
    + LOCAL PROCEDURE EntryIsVisited@10(EntryNo@1000 : Integer) : Boolean;
    ...
    + PROCEDURE IsItemEverOutput@16(ItemNo@1000 : Code[20]) : Boolean;
    + VAR
    + ItemLedgEntry@1001 : Record 32;
    + BEGIN
    + ItemLedgEntry.SETCURRENTKEY("Item No.","Entry Type");
    + ItemLedgEntry.SETRANGE("Item No.",ItemNo);
    + ItemLedgEntry.SETRANGE("Entry Type",ItemLedgEntry."Entry Type"::Output);
    + EXIT(NOT ItemLedgEntry.ISEMPTY);
    + END;
Sign In or Register to comment.