Author: Arnold van Wageningen

Please find below a summary of the clean-up features we currently offer in regards to InventSum and InventDim tables which can be found under the menu: Inventory management> Periodic> Clean up.

The Inventory Dimensions cleanup shows the following help text:

“The ‘Clean up unused inventory dimensions’ batch process deletes all existing inventory dimensions that are defined but not used in the current company.

All unused inventory dimensions are deleted permanently. No alert or database log is created during the process.”

An InventDim record is created every time a combination of inventory dimensions (site, warehouse, location, pallet, serial number, batch number) is specified in the system. For example, a purchase order line where a new batch number is specified creates a new record in InventDim with the site, warehouse and batch number the user enters, and allocates a new number from number sequence to the InventDimId. This InventDimId is then set on the purchase order line to show which dimensions were registered. If you now change the batch number, a new InventDim record is created (or existing one with this batch number is found), and the InventDimId from this new record is copied to the purchase order line. The old InventDim record is however not deleted, since it might be used on some other document (sales order, production, inventory, etc.). So this previously created record will remain.

This cleanup tool basically verifies for each InventDim record if it is being used in not only purchase order lines or sales order lines, but also inventory transactions, on-hand inventory records, etc. Everywhere a reference exists to InventDim it is being checked. If it is not used anywhere, it is not needed, and will get deleted. If for whatever reason the same combination of dimensions is used later on, AX simply creates a new InventDim record with a new InventDimId, and uses this instead.

The On-hand entries cleanup shows the following:

“Closed on-hand entries that have not been updated for this number of days will be deleted.”

On-hand entries, or InventSum records, keep track of what is on-hand and what value this on-hand inventory has. It summarises InventTrans records, and basically sums up these records to show what the current totals are for these inventory transactions.

If you have an invoiced purchase order of 10 pieces with a value of 10 USD, and an invoiced sales order for 5 pieces, InventSum would show something like Posted qty 5, Financial value 5 USD. This will set the Closed flag on the InventSum record to False and the QtyClosed flag also to False.

Now, if you sell the last 5 pieces, Posted quantity will reduce to 0, and (depending on inventory valuation) financial value also drops to 0. If all the quantity (posted, deducted, received, etc.) and all value fields (financial value, physical value) are set to 0, AX flags the Closed field to True and the No open quantities field also to True. Many queries in AX look at the Closed field to determine if they should be included. In most queries these records are excluded.

If they are excluded, this clean up tool basically allows you to periodically delete these records to reduce InventSum table size. It cannot delete any other records, since they might have open quantities still or open values.

The On-hand entries aggregation by financial dimensions is introduced with KB 3007375 around December 2014. https://fix.lcs.dynamics.com/Issue/Resolved?kb=3007375&bugId=2816224.

This is basically extending the previously mentioned cleanup tool by also cleaning up records which have field Closed set to True!

The reason why this is needed is basically because in certain scenarios, you might have no more quantities in InventSum for a certain combination of inventory dimensions, but there is still a value. In some cases, these values will disappear, but current design does allow values to remain from time to time.

If you for example use Batch numbers, each batch number (and the combined site, warehouse, etc.) creates a new record in InventSum. When the batch number is sold, you will see quantity fields are set to 0. In most cases, the Financial/Physical value field is also set to 0, but in Standard cost revaluation or other scenarios, the value field may show some amount still. This is valid, and is the way AX handles the costs on Financial inventory level, e.g. site level.

Inventory value is determined in AX by records in InventSum, and in some cases Inventory transactions (InventTrans) when reporting inventory values in the past. In the above scenario, this means that when you run inventory value reports, AX looks (initially) at InventSum and aggregates all records to Site level, and reports the value for the item per site. The data from the individual records on Batch number level are never used. The tool therefore goes through all InventSum records, finds the ones where there is no more quantity (No open quantities field is True). There is no reason to keep these records, so AX finds the record in InventSum for the same item which has the same Site, copies the values from the Batch number level to the Site level, and deletes the record. When you now run inventory value reports, AX still finds the same correct values. This reduced number of InventSum records significantly in some cases, and can have a positive impact on performance of any function which queries this table.

The two last tools only update InventSum. Since InventSum is a summary for InventTrans, you can actually rebuild this table by again summarizing all the transactions, and sum up their quantities and values in the InventSum table. AX can actually do this by running the consistency check for Inventory management:

So if the cleanup does not give expected results, this tool can actually rebuild InventSum records. And setting the From date can prevent previously cleaned up records to be recreated. This does not mean you shouldn’t test this in a test environment first of course!

A few customers have reported intermittent performance issues involving inventory on hand related queries on the InventSum, InventDim and/or WHSInventReserve tables, due to bad query plans regarding the table joins. This not only applies to on hand inquiries necessarily, but anything else dependent on it, e.g. inventory related posting processes, e.g. purchase invoicing. So based on this I am posting some generic solutions you can implement and review which may enable you to provide some relatively quick wins.

This assumes you already implemented all of the best practice recommendations for AX performance. You can find a good summary of articles regarding best practices and what to check here:

http://community.dynamics.com/ax/b/axresources/archive/2014/09/09/performance-resources-for-microsoft-dynamics-ax

My colleague Claes Norell has also written a couple of blog posts focusing on some key settings, including a SQL script to check them:

https://blogs.msdn.microsoft.com/axsupport/2015/09/22/ax-performance-checking-key-sql-server-configuration-and-database-settings/

https://blogs.msdn.microsoft.com/axsupport/2015/09/25/ax-performance-analyzing-key-sql-server-configuration-and-database-settings/

Consider implementing the following hotfixes (the first two being dependent on your inventory model):

KB 2951209 PORT request DAXSE 1014828: Standard Cost Revaluation reopens closed InventSum records.

KB 3007375 Over layer issue on menu Inventory and Warehouse Management caused by DAXSE 3577412 – Performance – Standard Cost Rounding checks are causing significant performance issues.

KB 3063513 Large number of records in WHSINVENTRESERVE that have all Qty fields = 0 – A new clean up job called “Warehouse management on-hand entries cleanup” has been added under the Inventory management module under Periodic > Clean up.  The clean-up job will delete the records in the InventSum and WHSInventReserve table for closed on-hand entries. The impact of running this clean up on a regular basis is significant performance improvements of On-hand related inquiries.*

KB 3112873 This fix optimizes the sp_WHSOnHand stored procedure to use better query plans and make sure it is only called when absolutely necessary.

After implementing the above hotfixes (if relevant), we advise to run the following purging jobs for the InventSum and InventDim tables, especially if the volume records in one or both of those tables is high.

• Inventory And Warehouse Management/Periodic/Clean up/On-hand entries aggregation by financial dimensions (for InventSum)
• Inventory And Warehouse Management/Periodic/Clean up/On-hand entries cleanup (for InventSum)
• Inventory And Warehouse Management/Periodic/Clean up/Inventory dimensions cleanup  (for InventDim)

Please see the following blog post for additional information regarding these jobs:

https://blogs.msdn.microsoft.com/axsupport/2016/05/11/key-clean-up-features-for-inventsum-and-inventdim-tables/

*If you’re using the new warehouse management module, the following blog post is worth reading:

https://blogs.msdn.microsoft.com/dynamicsaxscm/2015/12/28/improve-performance-by-running-the-warehouse-management-on-hand-entries-cleanup-job-for-new-ax-and-for-ax2012-r3-cu10/

Indexing

Previously the following index suggestion has helped other customers (which should be created in the AOT in AX, however the SQL script is given here to illustrate).

Create Index [Index name] On INVENTSUM (ITEMID, CLOSED, DATAAREAID, PARTITION)

Index Maintenance: It is recommended to ensure a plan is in place for regular index maintenance. You may wish to consider the suggestions in the blog post below.

Database Maintenance Strategies for Dynamics AX

http://blogs.msdn.com/b/axinthefield/archive/2012/08/01/database-maintenance-strategies-for-dynamics-ax.aspx

ALTER INDEX (Transact-SQL)

https://msdn.microsoft.com/en-us/library/ms188388.aspx

Possible workarounds to consider for specific scenarios if there are still issues with on hand related queries:

**Disclaimer:

Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. This blog post assumes that you are familiar with the programming language that is being demonstrated and the tools that are used to create and debug procedures.

Plan Guides / Query Hints

Plan guides provide the option to add query hints to the queries from AX without needing to make any changes in the application itself, such as OPTION (RECOMPILE) and OPTIMIZE FOR. However the statement must exactly match the query being executed for the plan guide to be used. For example:

sp_create_plan_guide

@name = N’InventSumPlan’,

@stmt = <enter SQL statement here>

@type = N’SQL’,

@module_or_batch = NULL,

@params = <enter SQL statement parameter,

@hints = N’OPTION (RECOMPILE)';

Of course in stored procedures like sp_WHSOnHand (used by the new warehouse management module), it’s possible to do this by modifying the procedure itself. At least one customer was known to benefit from using (OPTIMIZE FOR (@ItemId = ‘’’’)) as a query hint in this case. A couple of others benefited from replacing the joins between WHSInventReserve/InventDim in the same stored procedure with INNER LOOP JOIN, which directs the query optimizer in SQL to use nested loop joins.

Further details:

Plan Guides

https://msdn.microsoft.com/en-us/library/ms190417.aspx

Query hints

https://msdn.microsoft.com/en-us/library/ms181714.aspx

Nested Loop Joins (in relation to the INNER LOOP JOIN mentioned above)

https://technet.microsoft.com/en-us/library/ms191318(v=sql.105).aspx

Code workarounds

If you are able to identify the call stacks (e.g. using Trace Parser, the SQL statement trace log or the Performance Analyzer (”DynamicsPerf”)) and the above solutions don’t help in specific scenarios, there are some keywords you could consider using in the code (instead of using plan guides), e.g. forceNestedLoop, forceSelectOrder and as a last resort, forceLiterals. Further details:

Select Statement Syntax [AX 2012]

https://msdn.microsoft.com/en-us/library/aa656402.aspx

I am providing below an example with the InventSum::findSum method of how force literals could be used as a code workaround in individual call stacks to generate a specific plan for each set of query parameters, thereby avoiding parameter sniffing and related poor query plan issues.

\Data Dictionary\Tables\InventSum\Methods\findSum

/****Please note above disclaimer****

…

else

{

switch (_sumFields)

{

case InventSumFields::Financial:

selectforceLiteralssum(PostedQty),sum(PostedValue)

// <GEERU>

, sum(PostedValueSecCur_RU)

// </GEERU>

, sum(PdsCWPostedQty)

from inventSum

where inventSum.ItemId      == _itemId   &&

inventSum.Closed      == NoYes::No

#inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);

break;

case InventSumFields::Physical:

selectforceLiteralssum(PostedQty),sum(PostedValue),sum(Received),sum(Deducted),sum(Picked),sum(Registered)

// <GEERU>

, sum(PostedValueSecCur_RU)

// </GEERU>

, sum(PdsCWPostedQty)

, sum(PdsCWReceived)

, sum(PdsCWDeducted)

, sum(PdsCWPicked)

, sum(PdsCWRegistered)

from inventSum

where inventSum.ItemId      == _itemId   &&

inventSum.Closed      == NoYes::No

#inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);

break;

default:

selectforceliterals

#inventSumFields

from inventSum

where inventSum.ItemId      == _itemId   &&

inventSum.Closed      == NoYes::No

#inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);

…

Generally speaking, there are a few ways of implementing force literals, depending on how the query is implemented, including:

1. As a keyword in a select statement, e.g.:

…select forceLiterals sum(PostedQty),sum(PostedValue)

// <GEERU>

, sum(PostedValueSecCur_RU)

// </GEERU>

, sum(PdsCWPostedQty)

from inventSum…

1. After instantiating QueryRun, e.g.:

…

QueryRun queryRun = new QueryRun (query);

QueryRun.Literals(1);

…

1. After instantiating the Query, e.g.:

…

Query query = new Query();

Query.Literals(1);

…

1. In the properties of a static query, e.g.:

Attached you will find a description on how to use notes on header and lines when using eInvoice for Denmark.

How to use notes on header and lines when using eInvoice for Denmark

In AX2012 R3 CU10 two different Total prices (Gross amounts) are calculated in EPOS for the same product with different product dimensions.

E.g. Item price with no tax is 33,61+19% Sales tax = price tax included is 39,9959 if we calculate manually, which is 40,00.

When the product is selected in EPOS the first time- Gross amount calculated 40,00 (tax percentage is 19,01).

The second time, the same product, but with different product dimensions, selected, and now Gross amount calculated 39,99 (tax percentage is 18,98).

On the receipt these two different gross amounts are printed for the same product.

The expectedresult- it should be the same Gross amount calculated for the same product each time.

To get the expected result Sales tax code setup should be the following:

We recommend the Sales tax code to set up with ‘Marginal base’= “Net amount per line”.

With the above setup, you will get an expected result in EPOS- both lines with the same product has the same Gross amount 40,00 and Balance amount for payment 80,00.

From time to time we see questions about the compatibility statements and what they mean. The most common question relates to whether they apply to the kernel or the application.

A common misconception is that you only need to patch the kernel rather than the application. This is not the case.

For example, If the compatibility statement says that you have to be on AX 2012 R2 CU7 in order to use SQL Server 2014, it means that you have to run your applicationat CU7 or higher.

As for the kernel, we generally recommend that you run a recent kernel, so in the AX 2012 R2 CU7 scenario mentioned above, you should be on kernel in the 6.2.3000.nnnn range even if your application is still 6.2.1000.4051.

You can download the latest kernel for your AX version from LCS (link below)

Always download the current version of the AX 2012 System Requirements document (link below) to ensure that you are running your environments in a supported state.

For more details on this topic, see the following:

Overview of Microsoft Dynamics AX build numbers
https://blogs.msdn.microsoft.com/axsupport/2012/03/29/overview-of-microsoft-dynamics-ax-build-numbers/

Microsoft Dynamics AX 2012 System Requirements
https://www.microsoft.com/en-gb/download/details.aspx?id=11094

Dynamics AX In-Market Engineering (Tag: Compatibility)
https://blogs.technet.microsoft.com/dynamicsaxse/tag/compatibility/

Dynamics AX In-Market Engineering (Tag: Compatibility Certifications)
https://blogs.technet.microsoft.com/dynamicsaxse/tag/compatibility-certifications/

FAQ: Microsoft Dynamics AX Kernel Hotfixes
https://blogs.msdn.microsoft.com/axsupport/2014/12/10/faq-microsoft-dynamics-ax-kernel-hotfixes/

LCS – Download latest kernel
https://lcs.dynamics.com/v2/LatestKernel

Some customers could be interested to know if it is possible to resize a Virtual Machine (VM) once it has been deployed from LCS.

Unfortunately, this kind operation is not yet possible from LCS, so the operation must be completed from the Azure Portal.
You can use either Azure Portal for this: Classic or New.

Since any VM deployed from LCS is available from Azure Portal, you can access the Azure Portal and change the size from there.
One thing to note is be sure you are accessing Azure using the same Azure subscription used when the VM was deployed LCS.

Of course you need to respect the rules that are valid for an Azure VM, e.g. you can’t downsize a VM that already uses resources not available in the destination size.

From an LCS point of view there are 2 important items to be aware:

1. You will continue to see the original size.
   At the moment there isn’t an update of the information for the size changed in Azure.
2. Since you still see the original size in LCS, if you need to deploy a new VM instance you’ll deploy again with the original size.
   Thus, if you need a different size you need to make changes again via the Azure Portal.

If you need more information, or you have any questions or doubts, do not hesitate to open an incident and the Microsoft Support Team will be more than happy to answer all your questions.

The Integration Solution for Microsoft Dynamics AX Projects and Microsoft Dynamics CRM, is a solution that relies on the CRM Connector that allow to synchronize projects data between AX and CRM.
For details you can refer to the specific documentation:

• Integration Solution for Microsoft Dynamics AX Projects and Microsoft Dynamics CRM
  
• About synchronizing project information between Microsoft Dynamics AX and Microsoft Dynamics CRM [AX 2012]
  

One important info that is often missed is the supportability of this solution:

• From Dynamics CRM point of view:
  This Project Integration supports only CRM 2013 (It’s required Update Rollup 1)
  This solution is not supported on CRM 2015 or above, neither for version older that CRM 2013.
• From Dynamics AX point of view:
  This Project Integration supports only AX 2012 R2 (It’s required the Cumulative Update 7).
  This solution is not supported on AX 2012 R3.

Thus before to start any kind of deployment that include this Solution, be sure to review the System Req​uirements carefully.

If you need more info or you have any questions or doubts, do not hesitate to open an incident and the Microsoft Support Team will be more than happy to answer all your questions.

When working with AX 2012 projects in LCS (Lifecycle Services), the option for adding Work Items from LCS is missing after completing the setup of Visual Studio Team Services (VSTS) integration. When creating a Dynamics AX (AX7) project and doing the exact same setup, then Work Items can be created from LCS and stored in VSTS.

In an AX 2012 project, if you choose a storage location of VSTS, then the work items need to be created within VSTS, but once created it can be opened from LCS.

If you choose the storage location of LCS, then you can create new work items in LCS, but then there is no VSTS integration.

When you configure VSTS integration in your LCS project, then you need to link it to a specific VSTS project. When you create work items in the linked VSTS project, then the work items will be seen in your LCS project/Work items. You can open the work items from LCS by clicking on the ID link (yellow mark in image below).

Note:

Only work items of type Bug or Task created within the linked VSTS project will be visible in your LCS project/Work items.

The issue occurs when installing the Enterprise Portal on a claims web application, so actually you will also face the same the issue on SharePoint 2010 when using claims. The issue only impacts Safari browser; in IE or Firefox you will not see the issue.

There are two solutions to this issue

• to install Enterprise Portal using “Classic” mode authentication. To do it you need to run PowerShell script to create SharePoint Application: https://technet.microsoft.com/en-us/library/gg276326.aspx and then install Enterprise Portal on such web application. On such an Enterprise Portal you will not be able to enable Forms or ADFS authentication and also Office Web Apps will not work, but I guess that should not be a problem
• if you plan to use Forms https://technet.microsoft.com/en-us/library/hh575253.aspx or ADFS https://technet.microsoft.com/en-us/library/dn621030.aspx authentication you can go ahead and also set it up as in the documentation. Our tests show that as long we have one authentication provider configure the issue is not appearing neither for claims user nor for windows users.

When running the command [AxUpdatePortal -updateall -websiteurl “…” -verbose] on the EP server it sometimes happens that the execution fails with error:
The operation failed to execute. Error: Microsoft Dynamics AX could not locate the Web server…

In the Application event log you find a Warning with Event ID 1309 from source ASP.NET 4.0.30319.0:

3001
The request has been aborted.

5/20/2016 10:06:25 AM
5/20/2016 8:06:25 AM
32d0bf84574147888d67cba77fd69dd2
5
1
0
/LM/W3SVC/1454409847/ROOT/_layouts/EPDeploymentService-1-131082048102200427
Full
/_layouts/EPDeploymentService
C:\Program Files\Microsoft Dynamics AX\60\Setup\EPDeploymentService\
SERVERNAME
6180
w3wp.exe
AXBCProxy account
HttpException
Request timed out.
…

The AxUpdatePortal calls EPDeploymentServie which is running in the same web application as EP and is doing the actual deployment. Depending on the performance of the servers (WEB, AOS, SQL) or network, the EPDeploymentService might time out.

To resolve this, increase the execution time out for EPdeploymentService.
Edit the web.config for EPdeploymentService which you find in C:\Program Files\Microsoft Dynamics AX\60\Setup\EPDeploymentService
At the bottom of the file just after the </runtime> tag, enter the following section:

<system.web>
<httpRuntime executionTimeout=”3600″ />
</system.web>

Save web.config and run IISRESET.

Hello,

If you see the following error message when using the Warehouse Mobile Device Portal: “Sorry, an error occurred while processing your request. Please retry your request or contact your system administrator”, you should first check the application log of the IIS server’s event viewer.

If you are running into a timeout issue, you will see something like:

Exception information:

Exception type: TimeoutException

Exception message: This request operation sent to net.tcp://localhost:8201/DynamicsAx/Services/WHSMobileDevicesServices did not receive a reply within the configured timeout (00:01:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.

This is not a good sign, and you will probably want to understand first why the call to the WHSMobileDevicesServices is taking too long, and tackle the root cause of the problem. But let’s assume you need to change this 1-minute timeout for good reasons.

To do so, you can follow these steps:

1. Open IIS Manager
2. Select web site “Dynamics AX WMDP DEFAULT”
3. Click Actions > Explore
4. Windows Explorer will open, and take you, by default, to: C:\Program Files (x86)\Microsoft Dynamics AX\60\Warehouse Mobile Devices Portal0
5. Edit the web.config file in the following way (elevated permissions are required):

   …

     <system.serviceModel>

       <bindings>

         <netTcpBinding>

           <binding name=”NetTcpBinding_WHSMobileDevicesService” sendTimeout=”00:10:00″ />

         </netTcpBinding>

       </bindings>

   …

The default send timeout value (no value) is 1 minute, in this example we are changing it to 10 minutes.

Don’t forget to restart the “Dynamics AX WMDP DEFAULT” web site.

I hope this is helpful!

Bertrand

We’ve recently released some kernel fixes that improve how Microsoft Dynamics AX 2012 R2 and R3 handle SQL Server AlwaysOn AG failovers.

The R3 version of this fix is visible on LCS here:

LCS | AX 2012 R3 Kernel Fix KB3159596 | Handle SQL Server AlwaysOn AG failovers more transparently and gracefully
https://fix.lcs.dynamics.com/Issue/Resolved?kb=3159596

For AX 2012 R3, you need to be on a kernel that is >=6.3.3000.3972

For AX 2012 R2, you need to be running a kernel that is >=6.2.3000.1684

You can download the latest kernels from LCS here:

https://lcs.dynamics.com/latestKernel/

Alternatively, you can check the kernels that are available on this overview page:

https://blogs.msdn.microsoft.com/axsupport/2012/03/29/overview-of-microsoft-dynamics-ax-build-numbers/

Please see this link for further details on kernel patching:

https://blogs.msdn.microsoft.com/axsupport/2014/12/10/faq-microsoft-dynamics-ax-kernel-hotfixes/

Below is the description how to get feature changes from a Microsoft Dynamics AX hotfix package.

1. Extract the package
2. Go to Models folder
3. Open hotfixinformation.xml
4. Find <HotfixData KB=“<number without KB letters>” (usually it’s a last HotfixData tag
5. See <AffectedObjects> for list of changed objects
6. See <IncludedModels> for list of models. These models can be found in same models folder, e.g. dynamicsax2012r3_cl4565317.axmodel corresponds to <AxModelModelId=“4565317“ />.

How to create project from hotfix changes

Apply hotfix, then just create new project and filter by hotfix model

In AX 2012 R3 CU10, Project Management and Accounting allows the creation of Funding Limits and Funding Rules under the Project Contract. With these Limits and Rules, the system will try to allocate to these rules. However, if a Limit is reached, the rest of the allocations in that rule will be subjected to aspect ratio allocation. This blog will show how this works and why the system may run into allocation issues when posting transactions.

The Scenario: This example will be using the USMF data set under Legal Entity USSI. This example shows where it looks like it should be able to handle the amount asked to allocate, but fails.

1. In USSI Legal Entity, navigate to Project Management and Accounting -> Common -> Projects -> Project Contracts.
2. Click Project -> New -> Project Contract.
3. Enter Test1 for Name.
4. Select US_SI_0002 for Funding Source.

1. Click Ok.
2. In the Project Contracts form, expand the Funding Sources fast tab.
3. Click Add.
4. Select US_SI_0003 for Customer.
5. Click Add.
6. Select US_SI_0062 for Customer.

1. Expand the Funding Limits fast tab.
2. Click Add.
3. Select Active Transport I for Funding Source.
4. Enter 100 for Amount.
5. Click Add.
6. Select Alpine Ski House for Funding Source.
7. Enter 500 for Amount.
8. Click Add.
9. Select Break and Gears for Funding Source.
10. Enter 300 for Amount.

1. Expand Funding Rules fast tab.

1. With Priority 1 line selected, click Allocation.
2. Change Active Transport 1’s Allocation Percent to 60.
3. Click New.
4. Select Alpine Ski House for Funding Source.

1. Click Close.
2. Back in the Project Contracts form under Funding Rules fast tab, click Add.
3. Enter 2 for Priority.

1. Click Allocation.
2. Select Alpine Ski House for Funding Source.
3. Enter 25.00 for Allocation Percent.
4. Uncheck Rounding.
5. Click New.
6. Select Breaks and Gears for Funding Source.
7. Make sure this line has Rounding checkmarked.

1. Click Close.

1. Back in the Project Contracts form, click Project Contract -> New -> Project.
2. Enter Test1 for Project Name.
3. Select TM_NoWIP for Project Group.

1. Click Ok.
2. In the Projects form, click Project -> Maintain -> Project Stage -> In process.

1. Click Ok.

1. Click Manage -> New -> Item Task -> Purchase Order.
2. Select US_SI_000006 for Vendor Account.
3. Expand General fast tab.
4. Select MainOffice for Site.
5. Select MainOffice for Warehouse.

1. Click Ok.
2. In the Purchase Order form under Purchase Order Lines fast tab, select ADVERTISING for Procurement Category.
3. Enter 1.00 for Quantity.
4. Select ea for Unit.
5. Enter 900.00 for Unit Price.

1. Expand Line Details fast tab.
2. Click Setup tab.
3. Delete HOURS from Item Sales Tax Group.
4. Make sure Sales Tax Group is blank.

1. Click Project tab.
2. Delete the Sales Tax Group.
3. Delete the Item Sales Tax Group.

1. Press CTRL+S.

1. Back under Purchase Order Lines fast tab, click Financials -> Distribute Amounts.

The error: “Revenue could not be allocated. Verify that funding rules have been set up to allocate the Revenue,” occurs.

The thought is there is only 900.00 for the line and there are three funding limits that will equal 900.00. Here is the breakdown
of the situation:

The situation has three funding limits that equal up to 900 to allocate, but with two rules that determine how the allocation will occur. Here
is lay out of what it is trying to do. First rule is run:

The system will split the amount according to the first rule giving us 540 to be allocated to Active Transport (Funding Source 1: F1) and 360 to
Alpine Ski House (Funding Source 2: F2).

Next it will try to Allocate:

So, now the problem of allocating the 540 to FL1. The system can only allocate up to 100 due to the limit. FL2 can pull in the full 360, but since
it cannot allocate the full amount to FL1, it will have to create an aspect ratio to keep the amount allocate equal to the limit of FL1:

The aspect ratio is 0.18~ of the amount of what can be allocate to FL1. So, the system will have to keep that ratio with FL2. It takes 0.18~ multiplied
by the amount looking to allocate of 360. This leaves 66.67 to allocate to FL2. After Pass One, these amounts
will be allocated:

This updates the amount left in all Funding Limits and then adjust the amount left to allocate:

Now the system has one more Rule to process, so it will go through Rule 2. It will take the remaining amount against the allocation rule in Rule2:

It will split the amount according to the second rule giving us 183.33 to be allocated to Alpine Ski House (Funding Source 2: F2) and 550 to
Breaks and Gears (Funding Source 3: F3).

Next it will try to Allocate:

So, it runs into the problem of allocating the 550 to FL3. It can only allocate up to 300 due to the limit. FL2 can pull in the full 183.33,
but since it cannot allocate the full amount to FL3, it will have to create an aspect ratio to keep the amount allocate equal to the limit
of FL3:

The aspect ratio is 0.54~ of the amount of what it can allocate to FL3. So, it has to keep that ratio with FL2. So, it will take 0.54~ multiplied
by the amount looking to allocate of 183.33. This leaves 100.00 to allocate to FL2. After Pass Two, it will have these amounts
allocated:

This updates the amount it has left in all Funding Limits and then adjust the amount left to allocate:

Since there are no further rules to run and there is left over revenue to allocate, it will throw the error in the above scenario.

In conclusion, when created Allocation Rules along with Funding Limits, take into consideration that if the amount needed
to allocate in the rule will be more than the amount the Funding Limit can take, it will take an aspect ratio to keep the allocation the
same across all funding sources. Please keep this in consideration when making rules and limits for Project Contracts.

We get a number of questions on the exact steps needed to create and deploy customizations to the Commerce Runtime (CRT).  Here is a step-by-step process to get up and running with a very simple customization.  These steps should work with both 2012 R3 and AX7 versions of the Commerce Runtime

Method 1:  total replacement of the CRT services assembly

• Start Visual Studio and open the Commerce Runtime solution.  By default, this can be found in this location:  C:\Users\Administrator\Documents\Retail SDK CU9\Commerce Run-time\Sdk.CommerceRuntime.sln
• By default, all seven projects in the solution are configured to be signed with a strong name key which isn’t provided:  strongnamekey.snk.  For purposes of this example, we will create unsigned assemblies and configure the CRT to use them.  As part of your development you will want to sign with your organizations key and update the SDK source files with the UpdateAssemblyIdentities.ps1 script.  Details on that process can be found on this page.  For now, right-click on each project and select properties.  On the Signing tab unmark the Sign the assembly checkbox:

• After saving each project, make sure that the solution compiles before making any code changes.  Select Build > Rebuild solution and make sure you get no errors.
• The Sdk.Services project points to the Microsoft-signed version of the Runtime.Services.PricingEngine assembly.  This will cause problems when deploying your customized CRT.  To fix this, remove the reference and point it to the PricingEngine project from the solution instead.
  • Expand the Sdk.Services project and then expand the References menu item.  Right-click on Microsoft.Dynamics.Commerce.Runtime.Services.PricingEngine and select Remove.
  • Right-click on References and select Add Reference.  On the Reference Manager form, expand Solution and then select Projects.  Select the Runtime.Services.PricingEngine project and select OK.  Make sure that you actually mark the project using the checkbox (it’s easy to miss).

• Now make your code changes.  An easy one to test out is to make customize a receipt using the ReceiptService service.  Go to the Sdk.Services > Receipt > ReceiptService.cs file and find the GetReceiptForXZReport method.  Near the end of this method is line of code to copy the text of the receipt into the receipt.Body property.   Add an extra line of text to the receipt after this line:

• Re-build your solution to make sure things didn’t break.
• Now go look for the resulting assemblies.  By default they are saved in the References subfolder of the Commerce Runtime folder.  Sort by date to make them easy to notice. 

• For most customizations, you will be most concerned with the Services.dll and Services.Pricing.dll files.  Copy those (and their corresponding PDBs) to a temporary folder for deployment.
• Copy the files to your CRT folder.  If you are using Retail Server, they will go in the Package\Bin folder.  If you are using the direct database or offline capability for MPOS, they will go in the Retail Modern POS\ClientBroker folder:

• The final step is to tell the CRT to look for your assembly instead of the Microsoft-signed version.  In the same folder you copied your assemblies to, make a backup of the commerceRuntime.config file.  Open the file in a text editor and change the signature information for the Runtime.Services assembly (Version, Culture, PublicKeyToken, and processorArchitecture).  For this example, our assemblies are unsigned so you can remove the entire highlighted text:

• Restart your Retail Server and MPOS and test your changes.  Remember to kill the DLLHost.exe process if using direct database mode.  If everything worked you should immediately see your change the next time you print a receipt:

If things don’t work, check your event viewer for any exceptions.  The most common problem that I’ve seen is that the Microsoft-signed version of the PricingEngine attempts to be loaded.  Dropping and re-creating the reference as noted above usually takes care of the issue.

Method 2:  Deploy a service in its own assembly

Replacing the entire Runtime.Services assembly is a relatively easy option and can be used both in development production environments.  But the real power of the CRT architecture shows up when you completely segregate code changes to just the services you are modifying.  Deploying using this methodology is very similar to how you would deploy a service in Enterprise POS.  This also makes thing much easier from a maintenance view:  if the jump between hotfix releases doesn’t change the code in your services, you don’t have to merge code and redeploy your assembly; you can just install the CRT hotfix and leave your DLL in place until it needs to be changed.

The initial setup steps are a bit more involved but once that leg work has been completed, continuing development is pretty simple.

• Launch a Windows Explorer instance and go to the root of your Commerce Run-time folder.  Right-click on the Services folder and select Copy.  Right-click on white space in the root folder and select Paste.  This will make a folder named Services – Copy.  Rename the folder something like ServicesPartner:

• Go into your new folder and delete all subfolders except for the service you will be customizing.  For this example, we will only keep the Receipt subfolder.  While in the folder, rename the .csproj file as well:

• Open the Sdk.CommerceRuntime.sln solution in Visual Studio.  Using the notes above, change the Signing on the seven projects so the solution will compile.
• In Solution Explorer, right-click on the top node of your solution and select Add > Existing Project.  Navigate to your new folder and select the .csproj file.  Again, select all folders except Receipt and remove them from your project.

• Expand the References node and remove the reference to the PricingEngine assembly since the Receipt service doesn’t use the pricing engine.  This will help avoid any assembly definition issues.
• Right-click in your project and select Properties.  On the Library tab, change the Assembly name and Default namespace to match your organization:

• Select the Signing tab either un-mark the Sign the assembly checkbox or sign it with your organization’s strong name key.
• Make your code changes and rebuild your new project.
• Navigate out to your References folder again and you should see your new assembly:

• Copy the assembly and its PDB into either the bin folder of the Retail Server or the ClientBroker folder of MPOS.
• Open the commerceRuntime.config file and add the following line above the line for the Runtime.Services assembly.  If you followed the steps in Method 1, add the signed assembly information back in first (restore from the backup you made).
• Restart your Retail Server and MPOS and test your changes.   Again, if you’re using direct database or offline for MPOS, kill the DLLhost.exe process so your changes get picked up.

As you can see, the second method really gives you a lot more flexibility on how you develop and deploy customized CRT services and I highly recommend using that approach if possible.

Use the comments below to ask any questions you have on this topic.

There’s a possibility to add two types of environments to LCS project – On-premise and cloud environments. Cloud environments are added by deploying a machine into Azure. On-premise environment is added by System diagnostics installation. It is fairly easy to delete cloud hosted environment from the system. But it is not possible to delete On-premise environment in the current design. The issue has been reported to LCS development team, and fix should be released in August 2016.

In order to delete the On-premise environment in current design, please follow these steps:

1. Open Project
2. Click on On-premise environment

   You see there’s no possibility to delete the environment

    

3. Remove from URL address the highlighted string “V3New” press enter

   Now there’s a possibility to delete the On-premise environment from project

Management Reporter has several maps that integrate subsets of the AX financial data into the data mart database. A portion of the MR Process Service code called the Scheduler runs these integration maps at regular intervals (1 or 5 minutes by default) to ensure the report data is up-to-date. During the integration, a number of SQL statements are run against the AX database and the resulting records are transformed and inserted into the Management Reporter and data mart databases to be available for reporting.

AX 2012 Integration Maps Fiscal Years to Fiscal Year Accounts to Account Exchange Rates to Exchange Rate Transaction Type Qualifiers to Fact Type Qualifier Dimensions to Dimension Companies to Organization General Ledger Transactions to Fact Scenarios to Scenario Dimension Combinations to Dimension Combination Dimension Values to Dimension Value Account Categories to Account Category Organization Hierarchies to Tree Companies to Company

Integration data processing overview:

Prior to MR CU10, all data and its related data was pulled from the AX database and fully processed in the MR services before inserting into the data mart. Processing all the records this way caused a number of performance issues with larger AX data sets. With CU10 and later, MR loads the separate sets of data into staging tables in the data mart and does the processing/validation in SQL stored procedures. The processing (resolving) of the staging data in the data mart is done by the Maintenance Task which runs every minute. It if cannot resolve the staging data on the first attempt, it will continue to try to resolve the data at an increasing (exponential) interval.

The formula for the retry schedule is: 3^(AttemptNumber):

Example:

If staging data was just attempted for its 4^th time, that means at least 129 minutes have passed since the data was integrated originally and the next attempt won’t occur for another 243 minutes. Retry information about the current sets of staging data can be found in the data mart Archive table.

Note: It is possible that MR will not be able to resolve the staging data due to invalid AX data or an integration bug. When this occurs, the unresolved data will be not available in reports until the data is fixed. You may need to rebuild the data mart after it is fixed.

Example of invalid AX data causing an unresolved (“stuck in staging tables”) transaction:

• A new transaction is posted in AX.
  • The dimension combination used on the transaction has never been posted to previously.
• The dimension combination is integrated into the DimensionCombinationStaging table.
• The transaction is integrated into the FactStaging table.
• The Maintenance Task attempts to resolve/validate the records in the DimensionCombinationStaging table.
  • It cannot resolve the dimension combination because one of the dimension values does not exist in the Data mart. It does not exist in the Data mart (DimensionValue table) because it does not exist for the company the transaction is posted to.
• The transaction also cannot resolve because its dimension combination did not resolve.
• Both the dimension combination and transaction will not be available on MR reports.

Please see Troubleshooting Management Reporter Data Mart Staging Records for troubleshooting steps to identify why data mart staging records cannot be resolved.

Management Reporter (CU10+) integration for Dynamics AX 2012 pulls subsets of AX financial data first into staging tables in the data mart database. The Maintenance Task, which is run every minute by the Management Reporter Process Service, attempts to resolve the staging records into the main Data mart tables. If a staging record cannot be resolved (typically due to invalid AX data), it will not be included in generated reports.

The steps below can be used to identify why these records cannot be resolved. Please see Management Reporter AX 2012 Integration Overview for more information about the Management Reporter Dynamics AX 2012 integration.

Steps to Review Staging Data Mart Data (CU14+)

1.  Create the following stored procedure by running the attached script on the data mart database. This will be used to determine which natural FK (foreign key) is not resolving for each staged fact:

ShowUnresolvableFacts

2. Execute the stored procedure by running this command:

exec ShowUnresolvableFacts
You should see a list that looks like the following:

Any unresolvable row will hold NULL in at least one of the four FK Id columns (DimensionCombinationId, PeriodId, ScenarioId, or OrganizationId) where its corresponding Key column (DimensionsKey, FactDate, ScenarioKey, OrganizationKey) is not null.

• If the PeriodId column is null, look in the source system for a period for the company indicated by the OrganizationKey column for the fact’s FactDate.
• If the ScenarioId column is null, look at the transaction in the source system having the key specified in the SourceKey column.  Determine whether the transaction contains bad data for its scenario or whether the scenario integration has missed data needed by one of the transaction providers.  In the result image above, the budget facts’ scenario key is bad data due to the BUDGETMODELDATAAREAID column in the BUDGETTRANSACTIONHEADER table containing an empty string.
• If the OrganizationId column is null, there is likely one or more companies missing from the DDM.

In most cases, we expect the cause of unresolved facts will be the DimensionsKey.  This would surface as the DimensionCombinationId column containing null.  In this case, you’ll need to determine whether the combinations referred to by the facts are in the DimensionCombinationStaging tables.  If they are, then you should be able to run the attached stored procedure to determine what is causing the combination to not resolve.

1. Create the following stored procedure by running the attached script.

exec ShowUnresolvableCombinations

You should see results like the following if there are any combinations in the staging table preventing facts from resolving.

Just like in the Fact query above, one or more pairings of Key/Id columns will contain a non-null value for the Key and a null for the Id column.  In the example above, it appears the Department dimension in the for these records are causing the issue. To verify the data is missing/corrupt in the source system, one would need to copy the Dimension10Key from one of the rows having a null Dimension10Id and look for the dimension value in the appropriate source system table.

Review Dimension value in AX data

Two approaches:

1. Go straight to AX Dimension source view/table and look for the missing dimension value. This is likely the fastest method.

   Example1: Transaction was posted using a dimension that doesn’t exist. It won’t be in source view/table.

   Example2: Transaction was posted using a dimension that doesn’t exist for the company it was posted to. It will be in the source view/table, but not for the expected company.

2. Run the dimension query used during the MR integration to identify why the DimensionValue isn’t being pulled over.

Approach 1: Going straight to AX Dimension source view/table:

Identify the DimensionXKey‘s that didn’t have a corresponding DimensionXId. This means that the dimension combination used on the transaction has a dimension that doesn’t exist in the data mart.

• Note the DimensionX (where X is a number) on the same record as this is the dimension we’ll be looking at in the steps below.
• Note the DimensionXKey that you are interested in as this is the specific dimension code that we’ll be looking for in the steps below.
• Note the OrganizationKey for the record. Example: “5637146826|Ledger” where 5637146826 is the RECID from the LEDGER table. This tells you what company the transaction is posted to.

Pull up the AX source information for that dimension:

You can use one of the statements below, depending on the AX version, to do this:

AX 2012 R1:

select DA.TYPE, DA.NAME, DA.RECID, DA.KEYATTRIBUTE, DA.VALUEATTRIBUTE,

DA.NAMEATTRIBUTE, DA.VIEWNAME, DA.BACKINGENTITYTABLENAME, DA.BACKINGENTITYKEYFIELDNAME, 0 as
Partition

from DIMENSIONATTRIBUTE DA

where DA.TYPE<> 3

order
by DA.NAME

AX 2012 R2/R3:

select DA.TYPE, DA.NAME, DA.RECID, DA.KEYATTRIBUTE, DA.VALUEATTRIBUTE, DA.NAMEATTRIBUTE, DA.VIEWNAME,

DA.BACKINGENTITYTABLENAME, DA.BACKINGENTITYKEYFIELDNAME, DA.PARTITION, DHL.LEVEL_

    from DIMENSIONATTRIBUTE DA

left
join
(select DHL.DIMENSIONATTRIBUTE, DHL.LEVEL_, DHL.PARTITION
from DIMENSIONHIERARCHYLEVEL DHL inner
join DIMENSIONHIERARCHY DH on DH.RECID=DHL.DIMENSIONHIERARCHY and DH.NAME =
‘SystemGeneratedHierarchyAllAttributeStructure’
and DH.PARTITION = DHL.PARTITION) DHL

        on DA.RECID=DHL.DIMENSIONATTRIBUTE and DA.PARTITION = DHL.PARTITION

        where DA.TYPE<> 3

        order
by DHL.LEVEL_, DA.NAME

1. Find the record where NAME equals the dimension you are interested in (the DimensionX from the prior steps).

2. Get the value for the VIEWNAME column for this record and run a select SQL statement against it.

3. Modify your select statement and add a WHERE clause to search for a specific dimension.

4. Make sure the DATAAREAID or LEDGER on the source record matches the same company that the OrganizationKey represents. A common issue is for a transaction to somehow have been posted with dimension values that don’t exist for the company it was posted to, but they exist for a different company.

Approach 2: Run the query used during the MR integration

To get the query used during the MR integration you can do one of the following:

1. Use the Management Reporter 2012 Dynamics AX Integration Query Export Diagnostic to get the integration query for the dimension in question
2. Capture a SQL Profile during the integration map

Option 1: Use the Management Reporter 2012 Dynamics AX Integration Query Export Diagnostic

KB30677534

Note: If the diagnostic fails due to lack of permissions or some other unexpected failure, the text file output will not contain the expected queries.

In the output text file, you will need to copy two queries into a SQL query against the AX database:

1. The ReportingVirtualDataAreaView query directly after this header:

Example snippet of query:

declare @ErrorMessage NVARCHAR(4000);

…

…

    commit
transaction

end

1. The query directly after the header line for the dimension you are interested in.

Example header line for the Fund dimension:

–DimensionName=Fund}{TableKeyColumnName=RecId}{ViewName=DimAttributeLedgerFund_PSN}{Partition=5637144577}

Run the ReportingVirtualDataAreaView query once against the AX database then run the dimension query. These results are the dimension values MR pulls for that specific dimension. If there are missing values then either the dimension value is not valid (as in the previously mentioned example where a transaction is posted using dimensions that don’t exist for the company in question) or one of the tables included in the query joins is missing a required record. If it is the latter scenario, then you will need to remove the joins on the query until the expected dimension record shows up and identify why that join is excluding the dimension record.

Option 2: Capture a SQL Profile during the integration map

To reduce the amount of SQL queries you need to look through you can:

1. Disable the integration (using the Configuration Console)
2. Useful SQL Profiler filters:

Application Filter: .Net SqlClient Data Provider

Database name: AX database name

You can search the resulting trace for the dimension name you are interested in and identify the main query used to pull the values.

In a recent issue, a customer was reporting a problem exporting data using the data management framework. The issue was that during the export they were leaving the “Skip staging” option to “Yes”, which is the default option.

When the export of the entity was run, it reported that it had failed and there seemed to be no apparent reason why. However, the error was reported but it just wasn’t that obvious where to find it. If you have similar issues, then follow these points below:

Click “View execution log”

After selecting the execution log, you will not see any further details at this point. The key is to click “Staging log details”, even though on the export you selected the option “Skip staging” 

You will then see the error messages

This article is published on behalf of Svetlana Kosheleva. The attached document will describe how to configure the Polish Standard Audit file regulatory update in AX 2009 released with KB 3165114

Summary

From 1 July 2016, taxpayers in Poland will be obliged to transmit data in a unified format, the so called Standard Audit File (SAF) at the request from tax authorities.

The listed reports below have been updated:

•Accounting books
•Bank statement
•Inventory
•VAT invoices
•VAT register

A new functionality which enables the extraction of data in accordance with logical structure defined by tax authorities has been prepared in order to build the SAF. The feature was implemented using Application Integration Framework (AIF) services and XSL transformation (XSLT). XSLT allows setting up the selection of Dynamics-relater requisites and mapping them to the e-report elements. In addition, we can set up the relation between VAT codes and e-report elements using Tax reporting codes

SAF_AX2009