Featured Post

Dynamics GP 2016 R2 is Now Available .. and #MSDynGP will Always be Avilable

The Microsoft Dynamics GP team announced today that Microsoft Dynamics GP 2016 R2 has released . Dynamics GP 2016 R2 continues the grea...

Monday, July 29, 2013

Unit Cost and Currency Decimals Setup

Regardless of the fact that Dynamics GP decimals; either quantity or currency, is fixed during the setup, A business might encounter several cases in which a variance might result from this issue.

The fact is that Dynamics GP deals with decimals as accurate as possible, in order to prevent any variances.

I would like to discuss this issue through a case study in order to thoroughly show how accurate Dynamics GP could be in dealing with currency decimals.

1- Item Card Unit of Measurement:

    Case = 6 Pieces

Unit of Measurement Setup


2- Item Card Maintenance:

Item Card

3- Receiving Transaction Entry:

Unit Cost = 50
UOM = Case

Receiving Transaction Entry


4- Currency Setup:

Currency decimals Places = 2

Currency Setup


Now, when the receiving is posted. Dynamics GP encounters a a challenge in dealing with the item unit cost, taking into consideration the following issues

1- IV10200 | Purchase Receipt Work

In purchase receipt work, the cost layer is recorded at the "Base" unit of measurement, considering the currency decimals limitation (which is 2 )


Unit Cost for Base Quantity 50/6 = 8.3333333333   ??

Calculation Methodology:
In order to ensure that the cost is recorded accurately with zero variance, Dynamics GP calculates cost as follows (Smart list below is the Inventory Purchase Receipt):




Dynamics GP splits the transaction quantity into two layers, the first layer quantity is (Total Quantity - 1) , and the other layers quantity is (1). In order to calculate the cost;

-  Total Extended Cost (50) / Total Quantity (6) = 8.3333333333  
-   First Layer Cost: Round(8.3333333333,2) = 8.33
-   Second Layer Cost: Total Cost (50) - [ Rounded First Layer Cost (8.33) * First Layer Quantity (5)] = 8.35


Best Regards,
Mahmoud M. AlSaadi


  1. It's worth mentioning that there is a support article on this issue KB Article ID 2741489;

  2. We are using an avereage perpetual costing..
    the problem with us is that.. system take the cost of the remaining 1 pc rather than the average cost of the X-1 Qty !!
    we tired finding a solution to make system recalculate the average cost depending on X-1 qty instead of the 1 pc :-(
    we still using adjust cost utility after each purchasing trx !!!!
    do you have please any suggustion to solve this problem?
    Ex: it takes the cost for the item 101XLG as 8.35000 rather than 8.33000 !!
    can you help?!

    1. Hello,
      Thanks for your question, I will be reviewing it shortly and get back to you with a detailed answer. It might need a blog post to get things cleared out.

      Best Regards,

  3. I hope to hear from you as soon as possible..

    appreciate your help.

    1. I have illustrated my findings on a blog post, check it out on

  4. I have difference between GL warehouse account and Inventory status report I think it's because of rounding and multi currency shall I make all to zero decimal place

    1. Hello Mohamed
      Have you been able to run the "reconcile to GL" utility in order to check which journal entries cause such variance ? I would hesitate to suspect that the decimal rounding would cause a difference only in one case, which is having a different currency decimals in the supply chain level than the General Ledger module.

      Your feedback is highly appreciated,

    2. This comment has been removed by the author.

    3. This comment has been removed by the author.

  5. In Currency Setup Window 2 Dicmals
    In Item Currency window 2 Dicmals

    Reconcile to GL Show that no Diffrent

    Stock Status report show Diffrent Number than GL account warehouse with small Diffrent which I think from rounding.

    In Smart List 5 Dicimals in cost And After Check Links 2 Dicimals