Inventory Residual Rounding Dilemma

bpweb123
bpweb123 Member Posts: 19
edited 2015-06-18 in NAV/Navision Classic Client
Need help from experts NAV here. We are using NAV 2009 SP1 Classic Client.

The scenario is like this:
1. Purchase 3 Items A at $10 on 10th Jan 2015
2. Sell 2 Items A on 15th Jan 2015. The Cost Amount (Actual) counted as $6.66.
3. Sell 1 Item A on 25th Feb 2015. The Cost Amount (Actual) counted as $3.33.

I have set Inventory Setup to Automatic Cost Adjust to Always and Enable Automatic Cost Posting. General Ledger Setup Inv. Rounding Precision is set to 0.01. Allowed Posting Date Range for G/L Setup and Users are set to 01/01/2015 to 31/12/2015.

Now the system is smart enough to notice that $0.01 difference in Cost Amount (Actual) and post a rounding difference for the purchase cost in step #1 based on posting date 10th Jan 2015. All looks fine clean here.

The problem comes when I am trying to restrict posting date, closing our posting date range for January. Now the Allowed Posting Date Range for G/L Setup and Users are set to 01/02/2015 to 28/02/2015. In this case, when user is posting the sales on step#3, user will encounter issue with Posting Date is not within range as I understand NAV is trying to post the rounding entry of $0.01 for the purchase. Read from the available post, there is a way to close the Inventory Period for January, and the rounding entry of $0.01 will have posting date 01/02/2015. But this may cause more problem for my company if there is cost adjustment not yet posted to the January entry, getting posted in the wrong month. in which case, I will open the posting date range for user.

Is there any way to setup NAV to post the rounding entry of $0.01 for the Sales instead, meaning to post a rounding entry in step#3 dated 25th Feb 2015? I find it is neater if the system works this way, I may have missed out the proper setting here. Thanks in advance :)

Comments

  • evandeveerdonk
    evandeveerdonk Member Posts: 49
    Hi BPweb123,

    NAV is not an application known well for it's huge amount of setup parameters.
    (That's where we as NAV consultants come in :) )

    The only way to fix this is to re-programm this in the function that does these postings

    Ernst
    http://www.vssolutions NAV-Outlook synchronisation re-invented.
  • easy-navi
    easy-navi Member Posts: 31
    Hello,
    This is an old problem that NAV creates the Rounding Entry in Value Entry table in a very illogical way.
    Because it is connected to InComing ItemLedgerEntry rather than OutGoing ILE.
    Therefore the RoundingEntry has fields: "Posting Date", "Doc No.", "Item Ledger Entry No.", etc. like InComing ILE instead of OutGoing ILE :( (if the Costing Method is FIFO)

    This may cause that and many many other problems in accountancy. Actually i am working on the modification that would fix. If I have it done i'll past the code here.
    http://www.reinwestuj.pl Inwestuj w nieruchomości. Condohotele, aparthotele.
  • easy-navi
    easy-navi Member Posts: 31
    We have on our CU22 that additional code:
    
 ...
  IF ValueEntry."Entry Type" = ValueEntry."Entry Type"::Rounding THEN BEGIN
    ValueEntry."Valued Quantity" := ItemLedgEntry.Quantity;
    ValueEntry."Invoiced Quantity" := 0;
    ValueEntry."Cost per Unit" := 0;
    ValueEntry."Sales Amount (Actual)" := 0;
    ValueEntry."Purchase Amount (Actual)" := 0;
    ValueEntry."Cost per Unit (ACY)" := 0;
    ValueEntry."Item Ledger Entry Quantity" := 0;
    
   //Rounding.BEGIN 
   //That code finds the VE connected with OUTBOUND.ILE (->locVE) and than
   // changes some fields in "ValueEntry" (originally conected with INBOUND), 
   //so after that "ValueEntry" is connected with OUTBOUND.
    
    IF locItem.GET(ValueEntry."Item No.") AND (locItem."Costing Method" = Item."Costing Method"::FIFO) THEN BEGIN
      CLEAR(locVE);
      CLEAR(locItemAppEntry);
      locItemAppEntry.SETCURRENTKEY("Inbound Item Entry No.","Item Ledger Entry No.","Outbound Item Entry No.",
       "Cost Application");
      locItemAppEntry.SETRANGE("Inbound Item Entry No.",ValueEntry."Item Ledger Entry No.");
      locItemAppEntry.FINDLAST;   
      
      locVE.SETCURRENTKEY("Item Ledger Entry No.","Document No.");
      locVE.SETRANGE(locVE."Item Ledger Entry No.", locItemAppEntry."Item Ledger Entry No.");
      locVE.FINDFIRST;        

      ValueEntry."Posting Date" := locVE."Posting Date";
      ValueEntry."Document Date" := locVE."Document Date";
      ValueEntry."Document No." := locVE."Document No.";
      ValueEntry."Item Ledger Entry Type" := locVE."Item Ledger Entry Type";
      ValueEntry."Item Ledger Entry No." := locVE."Item Ledger Entry No.";
      ValueEntry."Gen. Bus. Posting Group" := locVE."Gen. Bus. Posting Group";
      ValueEntry."Valued Quantity" := locVE."Valued Quantity";
      ValueEntry."Source Type" := locVE."Source Type";
      ValueEntry."Source No." := locVE."Source No.";
      ValueEntry."Global Dimension 1 Code" := locVE."Global Dimension 1 Code";
      ValueEntry."Global Dimension 2 Code" := locVE."Global Dimension 2 Code";
      ValueEntry."Prod. Order No." := locVE."Prod. Order No.";
      ValueEntry."Prod. Order Line No." := locVE."Prod. Order Line No.";
      ValueEntry."Journal Batch Name" := locVE."Journal Batch Name";


    END;
    //Rounding.END
    

  END ELSE BEGIN
    IF IsFirstValueEntry(ValueEntry."Item Ledger Entry No.") THEN
      ValueEntry."Item Ledger Entry Quantity" := ValueEntry."Valued Quantity"


    We have still NAV version 4.03. If you have later version please do some tests. Especially check the structure of ItemApplicationEntry table (339), check if locItemAppEntry.FINDLAST; returns the right record.
    http://www.reinwestuj.pl Inwestuj w nieruchomości. Condohotele, aparthotele.

Categories