1

I need to show 5 decimal places in the price field in sales line, purch line and item master (sales tab). I created new EDTs with 5 decimal places to replace the salesLine.SalesPrice and InventTableModule.Price field. But as soon as the sales line is created. The value in SalesPrice field is rounded off to 2 decimals. For eg value in Item master is 10.12345 but on sales line it is displayed as 10.12000. The last 3 digits are gone.

I have heard multiple approaches till now from various posts/blogs.

  1. To change the NoOfDecimals property to 5 on RealBase EDT effectively changing the Amount field across the application. I do not want to do this.

  2. Changing the rounding rule at GL>Setup>Currency>Rounding rules. The fields are not editable.

  3. I changed the EDT to 5 decimals for PriceDiscTable.Amount field. But no help. I guess the SalesPrice in my case is not flowing from Trade Agreements.

Anything i am overlooking/missing?

Thanks

Harry
  • 145
  • 1
  • 4
  • 13
  • 1
    Could you sell in different units? For instance if you currently plan to sell in KG, sell in grams. Would this remove the need for the modification and the problems aariste points out? – David Lawson Dec 20 '12 at 09:41
  • Well the thing is its not me who sells, my client does :) But a good point, i will discuss this with my business consultant. – Harry Dec 20 '12 at 10:05

2 Answers2

1

Take a look at PriceDisc.price() method. Even if you change the decimals in the EDT or create a new EDT method Dynamics will round the price by code regardless of if you're getting the price from trade agreements or the InventTableModule price field.

The PriceDisc.price() method will later call the Currency.priceTypeRound(...) method where it will be rounded to 2 decimals:

private Price priceTyperound(Price          _price,
                         PriceRoundOff  _unit)
{
Price   price;
real    decimals;
;

switch (this.RoundOffTypePrice)
{
    case RoundOffType::Ordinary:
        if (_unit)
            price = round(_price, _unit);
        else
            price = round(_price,0.01);
        break;
        (...)

The rounding type will depend on the values of the last tab (Round-off) in the Exchange Rates form. So you'll have to modify some more things if you want the decimals to work properly.

I hope this was helpful.

Adrià Ariste
  • 118
  • 2
  • 7
  • Thanks for your reply. One strange thing is when i create a sales line, it initializes the values (qty, salesprice) without hitting the debugger. But when i move the cursor to another row, debugger starts. So i am still not sure where the values are coming from. My breakpoint is at CurrencyExchangeHelper::roundWithRuleType method. And the parameter _amount in this method has a value of 0 in my case and code returns 0 value. So i dont know how this logic works! – Harry Dec 20 '12 at 09:54
  • 1
    Try setting the breakpoint in the ItemId modified method of the DS. – Adrià Ariste Dec 20 '12 at 10:13
  • AX keeps surprising me. If i manually try to force the value in salesPrice field using initFromInventTable method of SalesLineType class, that also doesnt work. I can get a handle on inventTableModule and stratightaway transfer the value from Price field to SalesPrice field. Atleast thats what i thought. Another thing is since this method runs in IL, i had to compile to IL, still no help. – Harry Dec 20 '12 at 10:47
  • I think it's because the price is rounded in the Currency.priceTyperound method which is called later. – Adrià Ariste Dec 20 '12 at 13:10
0

aariste i think you are refering to AX version 2009 since Currency.priceTypeRound method is deprecated in 2012. But i did find similar methods in Currency table and in a new class called CurrencyExchangeHelper added in 2012. Sadly, the whole pricing mechanism is too complex and i decided not to meddle with it. Another difference in 2012 is that few methods run in IL so normal debugger cant catch them until you change a setting in Tools called "Execute business operations in IL". I am now forcefully pushing the salesPrice and recalculating the lineAmount overriding the Trade agreements pricing logic. I am totally in favor of increasing the Price Unit as David Lawson suggested instead of code changes. Thank you both for looking into the problem and advising.

Harry
  • 145
  • 1
  • 4
  • 13