GRNI (Accrued purchases) Report

In the U.K., a report to show Goods Received Not Invoiced (GRNI) seems to be a common requirement. Dynamics AX 2012 has an Accrued purchases report which fits the bill, but unfortunately this report has been enabled only for legal entities operating in the USA and Canada. As a workaround, I have been known to suggest using appropriate filtering on the the inventory transactions table, but this did not stop at least three projects I have worked on requesting that we enable the real Accrued purchases report.

Microsoft have provided a short example of how it is possible to remove the regional restriction on this report, but I recall the date field on the dialogue box also needed modifying to recognise dates in the UK format, so I think that this example could be a bit lacking.

Luckily, all of these problems are resolved by a hotfix that was released at the end of April for Dynamics AX 2012 R3. The hotfix is KB 3160455 and is titled ‘Accrued purchase report can be available for all countries’. I installed it into my demo VM so I could take a look at it.

The country/region restriction on the report is now completely removed, and I also see that it has a new name – ‘Accrued purchases excluding sales tax report’:

The menu item of the Accrued purchases report

The menu item of the Accrued purchases report

Unfortunately, ‘sales tax’ is normally translated to ‘VAT’ in the en-gb language, but if the report works, I think I’ll forgive that. The appearance of the report’s dialogue box has not changed, and offers the option to exclude receipts which have not been recorded in the ledger:

Accrued purchases report dialogue box

The dialogue box of the Accrued purchases report

It seems to be happy with the UK formatted date that I give it. The output itself looks like this:

Accrued purchases report

The Accrued purchases report

And at the bottom of the last page, there is a grand total.

Comparing it to the output from the report in an R3 CU8 system that I have to hand, it seems that one column ‘Value of line of PO’ has been removed, but otherwise the output is the same.

Trade agreement ‘Find next’ on Call center Sales orders

On Sales Price (and Discount) Trade Agreements, AX will look for applicable trade agreement lines in a specific sequence (as described here. Basically, it looks for a “Customer = Table and Item = Table” record first, and “Customer = All, Item = All” last). If ‘Find next’ is ticked on the trade agreement line, AX will keep looking for a trade agreement line with a better price (or discount) for the customer. If ‘Find next’ is not ticked, when AX finds a trade agreement line it stops looking.

If you’ve a price defined for an individual customer and a price for All customers, it is possible to un-tick ‘Find next’ to ensure AX will always use the individual customer price in preference to the All customer price, even if the individual customer price is higher. In this screenshot, trade agreement lines are created for an Item. ‘All’ customers get a nice low price of 10.00 USD. Customer ACBE alone gets a price of 15.00 USD. Notice that ‘Find next’ is not ticked on the trade agreement line.

Trade agreements for 'All' customers and for customer ACBE

Trade agreements for ‘All’ customers and for customer ACBE

Here is a standard Sales order for Customer ACBE for the Item. The price defaults to 15.00:

The price the customer gets on a standard sales order is 15.00

The price the customer gets on a standard sales order is 15.00

I thought I was on pretty strong ground when it came to this behaviour….. and then I enabled Call center functionality and brought Retail Pricing into play. Although AX still refers to the trade agreement sales prices, it seems the behaviour when ‘Find next’ is un-ticked (that I described above) is being ignored: Retail sales orders always find the ‘best’ price that the customer could get – as though ‘Find next’ was ticked on all trade agreement lines. Here, on this Retail sales order, the price defaults to 10.00, even though no changes have been made to the setup of the Trade agreements:

The price the customer gets on a retail sales order is 10.00

The price the customer gets on a retail sales order is 10.00

ACBE is getting the ‘All’ customer price, even though he has his own price which should always apply.

I wanted to investigate using Retail pricing on sales orders, but also had the requirement to honour the ‘Find next’ setting. More in hope than in expectation, I logged the behaviour I’d seen with Microsoft support. I fully expected to be told that this is how the retail pricing engine worked, so when I got back the news that this bug had been fixed I was stunned!

After installing the hotfix, Customer ACBE gets the price 15.00 on the Retail sales order:

The price the customer gets on a retail sales order after the hot fix is installed is 15.00

The price the customer gets on a retail sales order after the hot fix is installed is 15.00

The relevant hotfix (KB 3064046) is a kernel update only. This must mean the retail pricing engine sits outside the AX application. It also means that you’ll have to take this modified behaviour (should you decide to update your kernel), whether you want it or not! After installing KB 3064046, the Kernel version of the becomes 6.3.1000.2594. Therefore, assume that any kernel version equal to or higher than this exhibits the modified behaviour I describe. The hotfix is available now on LCS.

‘Generate RMA’ in the Call Center Customer Service form

If you’re using Dynamics AX 2012 R3, you might have discovered the Call center ‘Customer service’ form. If you operate a call center environment, where agents are taking orders and queries over the ‘phone, it’s well worth a look at how this form brings relevant information and functionality together. This post on the excellent organicax blog briefly shows the functionality.

One useful feature on the Customer service form allows the operator to Generate an RMA directly from an invoiced sales order.


The ‘Generate RMA’ button.

Or, at least you’d think that’s what a button which is only active when you select an invoiced sales order and is labelled ‘Generate RMA’ would do! However, even with CU8 installed, the button actually has no real functionality behind it. It opens the Return order form, but doesn’t create a return for the highlighted order. In fact, it doesn’t create a return order at all; you’d have to start by using the ‘New’ return order button.


No return order is created.

I thought this was a shame, because the Customer service form allows you to do nearly everything from one place – everything except create a customer return. And this is why I am delighted that Microsoft have released a hotfix to address this scenario.

The hotfix is KB3037364, and I’ve installed it into a test system running CU8.


Installing hotfix KB3037364

Now, when I hit the ‘Generate RMA’ button, a new return order for the selected customer gets created. And all of the items, prices and quantities from the original order are copied to this return order.


A Return order is created

There is no functionality to ask which items/quantities should be included on the return, but it’s a great start. In any case, the return order can be edited as necessary.

If we take a look into the AOT, what has the hotfix changed? First, there’s a new method on the Customer service form which dictates if the ‘Generate RMA’ button is active.


Is ‘Generate RMA’ allowed

There is also a new method on the ReturnTable form, which is called by the init method if it determines that the new return order was created by the Customer service form.

And with those small changes, the Customer service form now does everything!

R3 Demand Forecasting generates a blank Forecasting spreadsheet

You may come across an annoying problem if you’re testing Demand Forecasting using the Microsoft Dynamics AX 2012 R3 Solution Demo Package V1.0. The problem occurs when you ‘Generate statistical baseline forecast’, and happens even though you receive the ‘forecast has been created’ message. The first you notice is when you open the spreadsheet, and find the pivot table contains no data.

If you connect to the Demand Forecasting SSAS cube, and process the cube manually, you will get an error that gives you a clue to the cause of the problem. The sqlanalysis user wants more permission to the Dynamics AX database. I fixed it by heading into SQL Server 2014 Management Studio, and assigning user sqlanalysis to the dbo.owner role on the MicrosoftDynamicsAX database:

sqlanalysis user

Give the sqlanalysis user more permission to the Dynamics AX database

This is possibly overkill (but it is only demo data) so as an alternative, on the Dynamics AX Tip Of The Day blog, Murray Fife has written a slightly different solution.

I assume this only applies to the Microsoft Dynamics AX 2012 R3 Solution Demo Package V1.0, and that any real environment would have correct permissions set at install time.

R3 Demand Forecasting – clearing Adjustments

You’ve been playing with the new Demand Forecasting functionality in Microsoft Dynamics AX 2012 R3, and now you’re ready to demonstrate it to your colleagues. Only, you find you’ve a load of manual adjustments and you want to get rid of them so that you can start your demo with clean data. As you’ve found, Adjustments are persistent and even if you set the ‘Generate statistical baseline forecast’ job to ignore them, they remain and re-appear when you next include Adjustments.

The Adjustments are stored in an AX Table called ReqDemPlanForecastChangeEntry. I find that deleting all records in this table, and then generating the forecast again, causes all Adjustments to be lost.

Obviously I can’t recommend doing this on Live data. Please comment below if you know of an easy way to do this, which doesn’t involve the AOT.

Update: Wrong font size on R3 Demo Virtual Machine

I previously wrote about odd font sizes in the Microsoft Dynamics AX 2012 R3 Solution Demo Package V1.0, and promised I’d write here when I had an answer from Microsoft on the subject.

Well I now have that answer, and the short version is that improved support for larger font sizes is being considered for future releases. Whether that means future releases of R3 (via kernel update or CU) or a future version of AX (Rainier?) is not clear.

However, Microsoft directed me to the Dynamics AX 2012 VPAT (Voluntary Product Accessibility) documentation for accessibility issues, where this is apparently documented. And sure enough, after scouring the ‘Microsoft Dynamics AX 2012 R3 VPAT‘, I found this statement:


Statement about text sizes in the Microsoft Dynamics AX 2012 R3 VPAT

‘Customised text sizes up to 200% not supported’. So not only buried on a generic MS accessibility website, but also worded badly. ‘Customised text sizes not supported’ would have been clearer. ‘Only supports Windows text size of Smaller / 100%’ even better.

Looking at the VPAT for previous releases of Microsoft Dynamics AX 2012, I see different wording. This example from the documentation for AX 2012 FP:


Statement about text sizes in the Microsoft Dynamics AX 2012 FP VPAT

So, a font size of 125% was supported, albeit with eight issues listed. The AX 2012 R2 documentation says the same, but with fourteen issues listed. Perhaps as the number of issues increased, the decision was made to remove support for this functionality? Sure is easier than resolving them….


New serial number tracking functionality in Dynamics AX 2012 R3, part 2 of 2.

In my last blog post, we created a Tracking Dimension Group called ‘SellSerial’ to demonstrate the new serial number tracking for service and warranty scenarios in Dynamics AX 2012 R3:

Serial number is 'Active in sales process'

Serial number is ‘Active in sales process’

I created a new item, assigned it this Tracking Dimension Group and brought some into stock. You can see that no serial number is recorded on the On Hand form:

On Hand

The serial number is not recorded against the On Hand

When the item is added to a sales order line it remains impossible to assign a serial number:

Sales Line

The serial number cannot be set on the sales order line

However, during Delivery note (packing slip) posting, there is a new option ‘Register serial numbers’ (on the ‘Lines’ tab -> ‘Update line’):

Register serial numbers

Register serial numbers

By entering a serial number and clicking ‘Add’, it becomes possible to record the serial numbers:

Add serial

Adding a serial number

Once serial numbers have been recorded for the whole quantity on the delivery note line, it becomes impossible to add anymore. The possibility to enter that a serial number was unreadable also exists:

Unreadable serial

Record that a serial number was unreadable

Since ‘Blank issue allowed’ is not ticked on the Tracking Dimension Group, if I fail to record a serial number for the whole quantity, the delivery note posting will fail with an appropriate error :

Missing serial

Not enough serial numbers were recorded

During invoice posting, it is possible to update the recorded serial numbers, or to indicate which ones are included on this invoice if, for example, the full quantity is not being invoiced at this time.

Should the customer return the item, it is possible to record the serial number of the item(s) being returned. This is recorded at the same place; i.e. during the delivery note update. Note that there is no validation to ensure the serial of the returned item matches a serial previously sent to the customer and there is no requirement to use ‘Find sales order’ to match the returned item to the order it was originally sent out on.

By heading to the relevant delivery note or invoice journal, it is possible to view the serial numbers recorded against a line:

Invoice line

The serial numbers recorded against the invoice line

Functionality to ‘trace’ a serial number recorded in this way also exists, although not using the stock dimension trace functionality we have been used to in previous versions of AX. Instead the ‘Item tracing’ form (which was introduced in Dynamics AX 2012 R2, and enhanced in R2 CU6) must be used. The Item tracing form can be found at Stock and Warehouse Management -> Inquiries -> Tracing, and in this example shows that serial ABC123 was sold from site 1 on sales order 000758 and returned to site 2 on sales order 000761:

Item tracing

The item tracing form

Taking a look behind the scenes, we can see that serial numbers which are only active in the sales process are still recorded in InventSerial and can be seen alongside traditional inventory serial numbers:

Serial numbers form

The serial numbers form shows traditional inventory serial numbers alongside those active only in the sales process. Both are stored in InventSerial.

A record is also created in InventDim for each serial number recorded and a new table (InventTrackingRegisterTrans) is responsible for recording the link between InventDim and the Sales order, Delivery note and Invoice:


InventTrackingRegisterTrans records the link to InventDim