RSM Dynamics ERP Pros

How to use Smart Rounding in Microsoft

Dynamics AX for customize pricing rules
By Mac McHenry On April 2, 2015 Add Comment In About ERP Software,

This blog contains all the information needed to create custom rounding rules when establishing
pricing for a companys items for sale. In Microsoft Dynamics AX 2012, this is called Smart
Rounding. The beauty of the smart rounding function is that it allows you to define how, when
and where to round your price. For example, some companies might want to round down. In
some cases $29.95 is a more desirable number to round to when the price is actually $30.00. In
others, you might want to round that $30.00 up to $50.00.

The beauty of Smart Rounding is that the choice is yours.

How to set up Smart Rounding

Navigate to Sales and Marketing > Setup > Price/Discount > Smart Rounding.
 Create your Rounding version
Give it a descriptive name
Click the Green Plus sign to start creating your Smart Rounding rules

Enter the From value for a starting value you might want to consider zero, as in the
example above
 Enter the To value in my example we are trying to round up to the nearest hundreds, so I
set my To value at $99.99.
Syntax this sets the rounding value. Use the # sign to let the system know what the
rounded number format looks like. My rounded up result will always be by hundreds.
Lower Limit I put this value to blank. For my rule, even a penny would round up.
Upper Limit I put this value at 999. The upper limit defines the highest value for rounding
up.
After you establish your rule, you can check it by entering a value in the raw price
Entering the raw price gives you the rounded value.

Ive enter a second series to my rounding rules so that you could get a clearer understanding of
how the rules work.

I could keep adding additional lines to get me to my end value.

Last and certainly far from least, this function can be specified for many currencies. In my
example, I set it for USD, but you can establish these values for the currency or currencies you
desire.

Because multi-currency can provide you with unusual pricing, the Smart Rounding functionality
can make these unusual pricing structures smooth out to something more compatible with your
customers expectations no matter what currency they trade in.

Applying Smart Rounding

Now we have a smart rounding rule, we need to apply it. Navigate to Sales and Marketing >
Journals > Price/Discount Agreement Journals.

Using the down arrow, select the Sales journal

Select the Journal Line menu

On the adjustment menu, select the Apply Smart Rounding. To complete the assignment, post.
Hopefully this illustrate how powerful a feature Smart Rounding can be in your sales process. If
you have examples of how youve used this function, please let us know in comments. If you
have an existing Dynamics AX solution and want to optimize for your business, RSM is an
experienced ERP implementer and proven Microsoft partner serving the Dynamics community for
more than 30 years. Contact our professional at erp@rsmus.com or 855.437.7202.
By: Mac McHenry Illinois Microsoft Dynamics AX partner
BOM calculations with standard costs
The purchased item information that is used in a standard cost BOM calculation
includes the following:

Cost A purchased items costs are maintained as site-specific cost records in a

costing version for standard costs. Each cost record has an effective date, and
the BOM calculation date determines which cost record will be used. For
example, a BOM calculation with a future calculation date might use a cost
record with a pending status and a future effective date.
Cost group The cost group that is assigned to a purchased item provides the
basis for cost segmentation in the calculated costs of a manufactured item.
Warning conditions that are embedded in the items BOM calculation group
enable the BOM calculation to identify potential problems. This can be when the
purchased item has a zero cost, a zero quantity in a BOM, or an out-of-date cost
record. The applicable warning conditions can be overridden when initiating a
BOM calculation.

The manufactured item information that is used in a standard cost BOM calculation
includes the following:

Standard order quantity for inventory The items standard order quantity for
inventory, acts as the default accounting lot size for amortizing constant costs in
a BOM calculation. The accounting lot size will also reflect the order quantity
multiple if it is specified.
Warning conditions that are embedded in the items BOM calculation group
enable the BOM calculation to identify potential problems. One example could
be that the manufactured item does not have a BOM or route. The applicable
warning conditions can be overridden when initiating a BOM calculation.

The bill of material information that is used in a standard cost BOM calculation
includes the following:

BOM version The BOM version that is assigned to the manufactured item has
effective from and to dates, and a status for approved and active. The bill
version can be company-wide or site-specific, and it can optionally reflect
quantity breakpoints.
BOM line item quantity A component typically has a variable quantity
required, but it can be a constant. The component quantity is typically
expressed for producing one parent item, but it may be expressed per 100 or
 per 1000 to handle decimal precision issues. The component quantity can also
be calculated based on measurements.
BOM line item scrap A component can have a variable or constant quantity
for planned scrap.
BOM line item valid dates A component can have valid from and to dates.
BOM line item type of production The costing lot size for amortizing constant
costs will reflect the BOM calculation quantity and a make-to-order explosion
mode, because the BOM calculation assumes that the manufactured component
will be produced to the exact quantity instead of its standard order quantity.
Sub-BOM for a manufactured component A manufactured component can
optionally have a specified BOM version, which would be used instead of the
items current active BOM version in a BOM calculation.
Sub-route for a manufactured component A manufactured component can
optionally have a specified route version, which would be used instead of the
items current active route version in a BOM calculation.
Operation number and the impact of operation scrap percentages The
operation number links a component to a specific operation, and operations can
have a scrap percentage. The linkage enables BOM calculations to account for
scrap percentages and cumulative scrap percentages across multiple operations
on the components required quantity.
Ignore BOM line item in cost calculations A component can be ignored for
BOM calculation purposes.

The operations resource information that is used in a standard cost BOM calculation
includes:

Hourly costs The hourly costs that are associated with an operations resource
are expressed as cost categories that are assigned to set up time and run time.
These cost categories should be identified for resource groups and operations
resources. The hourly costs that are associated with a cost category can be site-
specific or company-wide.
Per unit costs Some manufacturing environments assign operations resource
costs per unit of output, which would be expressed as a different cost category
for quantity. For example, the quantity-related costs can reflect piece rates for
labor, or a paint manufacturer may assign operations resource costs per gallon
of output.
Overriding operations resource information on routing operations The
resource information about cost categories will be inherited by operations,
where it can be overridden. BOM calculations will use the cost category
information that is specified on the routing operations.
Cost group for a cost category The cost group that is assigned to a cost
category provides cost segmentation in the calculated costs of a manufactured
item. For example, different cost groups might be used to segment the
 calculated costs that are associated with machines and labor or with setup and
run time.

The route information that is used in a standard cost BOM calculation includes:

Route version The route version that is assigned to the manufactured item has
effective from and to dates, and a status for approved and active. The route
version must be site-specific, and it can optionally reflect quantity breakpoints.
Routing operation time The time can be specified for runtime and setup time.
The hourly time is typically expressed for producing one parent item, but it may
be expressed per 100 or per 1000 to handle decimal precision issues.
Routing operation time for secondary resources A secondary resource has the
same operation number as the primary resource, and the same routing
operation time. For example, an operation might require a machine as the
primary resource and labor and tools as secondary resources.
Routing operation scrap percentage BOM calculations will account for scrap
percentages and cumulative scrap percentages across multiple operations. This
applies to the required time for routing operations and the required quantity for
components that are linked to operation numbers.
Cost categories for a routing operation Operations resource information
about cost categories will be inherited by operations, where it can be
overridden. BOM calculations will use the cost category information that is
specified on the routing operations.

The manufacturing overhead information that is used in a standard cost BOM

calculation includes:

Surcharge A surcharge calculation formula reflects a percentage of value, such

as 100 percent, that is tied to a specific cost group, such as labor.
Rate A rate calculation formula reflects an amount per unit, such as USD 10.00
per hour, that is tied to a specific cost group, such as labor.
Time-based versus material-based overhead The manufacturing overhead can
be tied to routing operations or material components.

The costing version information that is used in a standard cost BOM calculation
includes:

Costing type The costing version must contain standard costs. Several
restrictions apply to BOM calculations that use standard costs. For example,
these restrictions specify that miscellaneous charges must be included in unit
costs and that the BOM calculation explosion mode must be single level.
Mandated fallback principle The costing version can mandate the use of a
fallback principle, such as using a specified costing version or the active cost
records. The mandated fallback principle typically applies to a costing version
 that represents the incremental updates in a two-version approach for cost
updates.
Blocking flag for pending costs A blocking flag can prevent BOM calculations
of the pending cost for manufactured items.
Specified from-date The specified from-date will act as the default calculation
date for all BOM calculations that involve the costing version.
Specified site A specified site will limit BOM calculations to the single site.
Content of the costing version must include costs The content must include
costs. It can optionally include sales prices in order to calculate suggested sales
prices for manufactured items.

Several sources of information can be specified when initiating a BOM calculation.

This includes the site, the calculation date, and the costing version.
QUICK GUIDE: DYNAMICS AX 2012 DATA LAYER &
DECIMAL PRECISION
We all know that Dynamics AX 2012 uses Microsoft SQL Server as its
database backend, but how does AX handle decimal-based data types in
the data layer? In this blog, we will be going into detail on how AX handles
Real based Extended Data Types, how that data is saved in SQL, as well
as some potential pitfalls of bypassing best practices when it comes to
integrating with and importing data into AX.

Lets take the AmountCurDebit EDT as an example. you can see in the
Type hierarchy browser that AmountCurDebit inherits its number of
decimals ultimately from the Money system data type. The Money System
Data Type rounds to two decimal places, therefore, the AmountCurDebit
EDT rounds to two decimal places as well (Figure 1).
 Figure 1 AmountCurDebit EDT on the LedgerJournalTrans table
When opening the LedgerJournalTrans table in the AOT, you can see that
the amounts are two decimal places (Figure 2). But, what does this data
look like in SQL?

Figure 2 AmountCurDebit EDT rounds to two decimal places

Here we have selected the same records from within AX and directly from
the SQL database. You can see that although the data is displayed with two
decimal places in AX, the actual data is saved to a precision of 16 decimal
places in SQL. Why is this? (Figure 3)
 Figure 3 AmountCurDebit data in AX vs SQL
The reason that the data in SQL is showing 16 decimals is that the
AmountCurDebit AX EDT is translated to a SQL data type of Decimal with a
scale of 32 and precision of 16. This means that a number with a length 32
on the left and 16 on the right can be saved here (Figure 4).
 Figure 4 AmountCurDebit EDT definition in SQL
At this point, you may be asking, Why should I care? Good question! We
have seen instances during data migrations or data integrations that bypass
the AX Application Layer (AOS) that has resulted in values with greater
decimal precision than the EDT of the table field. This can cause
headaches and sneaky data corruptions that may not surface until there is a
big problem. Just what happens in AX when this occurs? Lets take a look.

In Figure 5, there is example job that is updating ten records in the

LedgerJournalTrans table with decimal values with a precision greater than
2.
 Figure 5 Example of updating LedgerJournalTrans.AmountCurDebit with too high decimal precision
As the script runs, it selects records from the LedgerJournalTrans table and
updates the AmountCurDebit field.

AX does not respect the EDTs decimal precision because it sees the
AmountCurDebit value of the LedgerJournalTrans table as a Real type
(Figure 6).
 Figure 6 AX Debugger shows AmountCurDebit with decimal precision of three
Now that we have some records that do not respect the EDTs two decimal
rule, how will AX respond when these records are accessed?

You can see in figure 7 that AX rounds the values for us following the usual
rounding rules you might expect. When the third decimal place is greater
than 5, AX rounds up, otherwise the number is not changed.

It is plain to see how discrepancies like these can cause real havoc in your
system. Accounting will not be happy if their general ledger postings do not
match up!
 Figure 7 Corrupt data in LedgerJournalTrans in SQL vs AX
So, how do you avoid this type of data corruption? Extended Data Type
decimal precision is enforced at the UI level. You can see this in the
example table weve created in figure 7. The table only has one field with
the EDT of AmountCurDebit.

If you attempt to enter a value with a decimal precision greater than two, the
AX UI will round the value for us when you leave the field (Figure 8).
 Figure 8 Example of UI rounding a value in AmountCurDebit EDT field
If you have a requirement to insert/update records from X++, you must
make sure to respect the decimal precision of the EDTs we are interacting
with. One solution we like to use for EDTs that are saving monetary values
is to leverage the CurrencyExchangeHelper class. This class is able to
round values based on the currency rounding settings of a given currency.
Lets take a quick example of this in action (Figure 9).

Figure 9 Example of CurrencyExchangeHelper class rounding currency values

Here is our script from earlier with a modification to use the
CurrencyExchangeHelper class. If we run this code, we can see that
CurrencyExchangeHelper class will return a rounded value for us (Figure
10). You see here that the value is rounded as expected.

Figure 10 Debugger showing CurrencyExchangeHelper class rounding a value

If you choose to use this method to round values, please make sure the
currency rounding settings are correct in your AX environment. You can find
them in the Currencies form (General ledger Setup Currency
Currencies). Figure 11.

Figure 11 Currencies form in AX 2012 R3

In this blog we covered the following items:

o An EDT with a Real base type is saved on the data layer with a
precision of 16 decimal places.
o The NoOfDecimals property of a Real EDT is not respected in X++ table
buffers and we need to account for this when working with them.
o Corrupt records that do not respect AX EDTs can cause unexpected
results in AX.
o The AX UI is what rounds values for us in respect to the EDT
NoOfDecimals property.
o We can use the CurrencyExchangeHelper class to round monetary
values for us in X++ code.
Have you experienced complications with Real EDTs and data corruption in
your AX 2012 systems? We love to hear about how others have solved
 similar problems. Leave a comments below with your problems and/or
solutions, and an AXM expert will get back to you shortly!

2 COMMENTS
Henry Krinkle
November 6, 2016 8:01 AmReply

This is a very informative post and has helped me with a very tricky data
warehousing problem. My question is how did you discover the Money
datatype has 2 decimal places? When I look at the type hierarchy browser,
no details are displayed for the money data type.

Thanks

Henry

o Aaron Emde
November 9, 2016 5:11 PmReply

Hi Henry,

Apologies for not getting back sooner Busy week here at AXMentor!

Im glad that the blog post helped you solve a problem. Data
warehousing with AX data can be a pain when it comes to rounding and
unexpected results due to the examples outlined in the blog post. Ive
come across some tough issues when building data warehouses and the
resulting SSAS cubes.

In AX, Extended Data types will inherit the NoOfDecimals property of

their parent. You can of course overwrite them, but if you leave the
property at Auto, it will simply inherit.

But what about the Money EDT? Since this is a System Data Type, you
cannot view it in the type hierarchy browser and see any really
meaningful properties (see screenshot below). You have to view
Microsofts documentation on that EDT. Heres the link for Microsofts
documentation on the Money EDT Money System Data Type [AX 2012]
at this link. Due to the lack of documentation here, you kind of have to
guess as far as the NoOfDecimals property. Although, the default here is
two decimal places.
Heres a screen shot to show you what I mean.
I hope this helps to on your journey.
If myself or AXMentor can assist you with your data
warehousing/reporting needs, please do not hesitate to reach out. Myself
and my team live/breathe reporting and we always like to tackle the next
challenge out there. I see youre in the UK from your email and we work
with some really great customers out your way as well as here in the US.
DECIMALS, PRICES, UOM, CURRENCY, ROUNDING
This post is probably one of a series that I wanted to use to explain some fundamentals of AX that might turn into a
whitepaper for some guidance on implementation choices, configuration and customization you might undertake to solve a
customer business problem.

Lets start from the beginning. AX being an ERP has a job to deal with accounting and operational issues. The accounting
being tracking the money going through the business and operationally the quantity of product or service going through the
business.

If we have a business that sells products at retail/distribution then dealing with numbers is pretty simple. I sell 5 each items at
USD$1.98 = USD$9.90 total sale. So we have a few measurements here. Quantity in this example is a whole number. Item
units of measure in this example each. Currency the measurement of the price is in USD in this example.

Lets look at these. Quantity is always relative to the unit of measure (UoM). If I have 5 of something I have to say what
measurement that is in. So each, box, pack etc are typical distribution/retail UoM and generally they are generally related to a
quantity being a whole unit.

What if we work with precious metals, liquids like chemicals, beverages, protein industries like meat processing. Lets work
with metals in this example. A price for base metals are traded through a market place like the London Metal Exchange
(LME) this is a fluctuating price based on supply and demand of the metal.

Looking at LME today, 14th of August 2014, the price of aluminium is USD$2004.50 per tonne for a cash buyer. So if I
purchased 5 tonne it would be 5 tonne * USD$2004.50 = USD$10,022.50

Tonne being a metric unit which is equivalent to 1000 kilograms (http://en.wikipedia.org/wiki/Tonne)

If I want a small aluminium part I dont go and buy a tonne of metal. I want to work with someone that will sell me a smaller
amount and process it for me. The processor has to deal with the base metal cost, processing fixed costs, variables costs,
margin that need to be calculated to work out a final cost of a piece to the end customer. But Ill come back to these what I
want to highlight first is unit conversion and rounding.

If we have purchased 5 tonnes then we have 5000 Kg of metal. So 1Kg base metal price would be USD$2004.50 / 1000 =
USD$2.0045. Now we have 4 decimal places for the price and important point we need to work. If I sell my 5000 Kg *
USD$2.0045 = $10,022.50 which is the same as what I purchased it in.

If I round this price to two decimal places this would be USD$2.00. If I sell my 5000 Kg * USD$2.00 = USD$10,000.00.
Which is USD$10,000.00 USD$10,022.50 = USD$22.50 less than what I outlaid.

If I work in Europe we likely work in metric, if we work in the US then we are likely work in pounds
(lb) http://en.wikipedia.org/wiki/Pound_(mass). One US pound (lb) is 0.45359237 Kg. Or expressed the other way
2.20462262 lbs = 1kg. Ive only shown to 8 decimal places again the decimal places are important for the discussion.
Lets put that back in price perspective for what I purchased. 1000 Kg = 2,204.62262184 lb. So USD$2004.50 /
2,204.62262184 = USD$0.90922591 per lb. I purchased 5000 kg / 0.453592370 = 11023.11311 lbs. * USD$0.90922591 =
USD$10,022.50 which is what it cost me to purchase the base metal. If we had rounded to 2 decimal places then we have
11023.11 lb and the price is USD$0.91 = USD$10,031.03. Which is USD$8.53 more than it cost so in this case the rounding
worked in my favor.

So while this is basic math this needs to be translated into how you setup the ERP application across all the different module
areas to suit the business. What Ive tried to do here is paint some complexity as well with units from different geographies
because this is important to consider when setting up the business application if you are running in one database there are
some parameters that are shared independent of the legal entity and some that are legal entity specific.

In future posts lets explore this setup in AX. Lachlan