Challenge 2: execute an arbitrary X++ class in Dynamics AX "7" aka "Dynamics 365 for Operations"

class DocuFileMigrateDBtoAzure
{
    public static void main(Args _args)
    {
        DocuValue           docuValue;
        DocuRef             docuRef;
        DocuType            docType;
        System.IO.Stream    fileStream;
        Microsoft.Dynamics.AX.Framework.FileManagement.DocumentLocation         location;
        Microsoft.Dynamics.AX.Framework.FileManagement.IDocumentStorageProvider storageProvider;
        DataArea            dataArea;
        ;
        while select dataArea
        {
            changecompany(dataArea.id)
            {
                docType = null;
                docType.skipTTSCheck(true);
                while select forupdate docType
                    where docType.TypeGroup == DocuTypeGroup::File
                {
                    if (docType.FilePlace == DocuFilePlace::Database)
                    {
                        docType.FilePlace = DocuFilePlace::Archive;
                        docType.update();
                    }
                    storageProvider = Docu::GetStorageProvider(docType, false, curUserId());
                    if (storageProvider == null)
                        continue;
                    while select forupdate docuValue
                        where docuValue.StorageProviderId == 0
                           && docuValue.Type == DocuValueType::Others
                    join docuRef
                        where docuRef.ValueRecId      == docuValue.RecId
                           && docuRef.ActualCompanyId == docType.DataAreaId
                           && docuRef.TypeId          == docType.TypeId
                    {
                        fileStream = Binary::constructFromContainer(docuValue.File).getMemoryStream();
                        if (fileStream.Length == 0)
                            continue;
                        docuValue.FileId = newGuid();
                        location = storageProvider.SaveFile(
                                docuValue.FileId,
                                storageProvider.GenerateUniqueName(docuValue.OriginalFileName),
                                System.Web.MimeMapping::GetMimeMapping(docuValue.OriginalFileName),
                                fileStream);
                        fileStream.Close();
                        if (location == null)
                            continue;
                        if (location.NavigationUri)
                        {
                            docuValue.Path = location.get_NavigationUri().ToString();
                        }
                        if (location.AccessUri)
                        {
                            docuValue.AccessInformation = location.get_AccessUri().ToString();
                        }
                        docuValue.StorageProviderId = storageProvider.ProviderId;
                        docuValue.update();
                    }
                }
            }
        }
    }
}

// Align the users and the workers by the e-mail address first, and the name second
public static void generateDirPersonUser()
{
    DirPersonUser               dirPersonUser, dirPersonUser2;
    UserInfo                    userInfo;
    SysUserInfo                 sysUserInfo;
    HcmWorker                   hcmWorker;
    LogisticsElectronicAddress  electronicAddress;
    DirPerson                   dirPerson;
    Name                        rearrangedName;
    DirNameSequence             dirNameSequence;
    DirPersonName               dirPersonName;
    while select userInfo
        join sysUserInfo
            where sysUserInfo.Id == userInfo.id
        notexists join dirPersonUser2
            where dirPersonUser2.User == userInfo.id
    {
        dirPerson.clear();
        if (sysUserInfo.Email) // 1st attempt
        {
            select firstonly hcmWorker
                join dirPerson
                    where dirPerson.RecId == hcmWorker.Person
                join electronicAddress
                    where electronicAddress.Locator == sysUserInfo.Email
                       && electronicAddress.RecId == dirPerson.(DirPartyTable::electronicAddressType2primaryFieldId(LogisticsElectronicAddressMethodType::Email);
        }
        if (! dirPerson && strAlpha(userInfo.name))
        {
            dirPersonName.clear(); 
            [dirPersonName.FirstName,
             dirPersonName.MiddleName,
             dirPersonName.LastName] = str2con(strReplace(userInfo.name, '.,', ' '), ' ');
            while select dirNameSequence // 2nd, 3rd etc. attempt
            {    
                rearrangedName = dirPerson.name(dirPersonName,  DirNameSequence.DisplayAs);         
                select firstonly hcmWorker
                    join dirPerson
                        where dirPerson.RecId == hcmWorker.Person
                           && dirPerson.Name  == rearrangedName;
                if (dirPerson)
                    break;
            }
        }
        if (dirPerson && hcmWorker::getMaxEmploymentEndDate(hcmWorker.RecId) > DateTimeUtil::utcNow())
        {
            dirPersonUser.clear();
            dirPersonUser.initValue();
            dirPersonUser.PersonParty = dirPerson.RecId;
            dirPersonUser.User = userInfo.id;
            dirPersonUser.ValidFrom = hcmWorker::getMinEmploymentStartDate(hcmWorker.RecId);
            dirPersonUser.ValidTo = hcmWorker::getMaxEmploymentEndDate(hcmWorker.RecId);
            if (dirPersonUser.validateWrite())
            {
                dirPersonUser.insert();
            }
        }
    }
}

In fact, we can: in the German-speaking countries (the so-called DACH area, Deutschland- Austria- Confoederatio Helvetica) there is a long established school of the formal cost accounting. It introduces the cost center (CC) accounting where the actual monthly costs of ‘service’ cost centers (accounting, marketing) are iteratively allocated to the ‘manufacturing’ cost centers (machine shops or single machines). By dividing this cost by the number of hours the machine has been running the past month you get the revised cost rate for the next month. In the cost purpose (CP) accounting direct material costs are recorded against cost purposes (e.g. finished products, groups of products, customers or market segments), where indirect costs booked on cost centers are periodically allocated to cost purposes by a certain basis, which gives the full cost per product on month average.

This scheme was first implemented in Axapta 3.0 for Columbus IT Austria  by a Byelorussian near-shore company CS&IE and then acquired by Microsoft. Later Microsoft recognized those “Cost center accounting” and “Cost purpose accounting” modules were a bit crude, and replaced them with the “Cost accounting” solution initially developed by the Swiss partner Circon Circle Consulting. The latter module has been in existence since Dynamics AX 4.0 through Dynamics AX 2012 R3. In the forthcoming version “AX7” this module may re-appear in a later release.
In this blog I am going to show how to leverage the standard capabilities of this "Cost accounting" module.

Setting the scene

In chemical manufacturing or metalworking, it is not always possible to record even the direct material costs against the finished product order, let alone the indirect ones. The product “individualization” begins in the late production stages where for example an addition of a perfume to the basis makes a distinct hair shampoo SKU, or where the steel is alloyed with vanadium and molybdenum to reach the steel grade ordered by the customer. The “semi-finished materials” i.e. intermediate products are manufactured continuously, and immediately transported further in pipes or railway cars.

 
The smallest “cost purpose” for such an intermediate product may be a daily order or a team shift batch. The batches should preferably have the constant chemical composition, and they are barely distinguishable. The factory does not record which intermediate product (molten iron) batches are consumed by which individual order (steel grade). Only the quantity of the intermediate product is tracked, i.e. metric tons of the iron used, or liters or cubic meters of a gas or a fluid inflow, etc.
To make the things worse, by-products are collected and re-processed and fed to the earlier stages in the production. For example, the accumulating scale – the oxidized crust left from forging - may be collected and fed back to the blast furnace, building a loop in the cost flow.

Sample case

On a highly simplified example below I am going to show how to use the Cost accounting module in the first 2 stages of the steelmaking process (sintering and smelting) to absorb the cost of the raw materials in sintering (coke, limestone flux, iron ore) into the cost of the smelting product pig iron. For the simplification I do not take the fuel consumption in the sinter plant, or the highly energetic blast furnace gas into consideration.
The wages are allocated to the respective SP (sinter plant) and BF (blast furnace) cost centers. The intermediary product – the sinter - is produced continuously in daily batch orders, measured in metric tons and reported against the cost purpose “Sint”. The molten iron and the slag fraction are tapped and poured into torpedo cars at the blast furnace roughly every 6-8 hours, weighted in tons and reported against the cost purpose “Iron”. The by-product has the cost purpose “Slag”. Every tapping is represented by an individual batch production order in Dynamics AX.
The below table summarizes a very schematic material balance in ferrous sintering and smelting. The quantities have been reduced from the month to one day of production:

Scenario in Dynamics AX

In the standard demo company USPI, create 6 released products measured in tons as shown below, note the production type necessary to activate the Process manufacturing capabilities:

 
Set the standard cost price as shown in the table above.
Create the new financial dimension CostPurpose, enter 3 values “Iron”, “Sint” and “Slag”, and add this dimension to the P&L accounting structure. Allow for blanks. Add 2 new cost centers: “BF”, “SP”.
Assign the dimension “Iron” to the product “Iron”, “Sint” to “Sinter” and “Slag” to “Slag”. Make sure that in the item groups the production issue offset and receipt offset posting types are bound to the new profit and loss accounts 500111 “Change in inventory - Raw materials” and 500101 “Change in inventory – Products”. The reason is that the Cost accounting module cannot acquire balance sheet GL transactions.
Procure sufficient stock (e.g. 10000 tons each) of the raw materials Coke, IronOre and Limestone. You may use the shortcut Manage inventory > On-hand inventory > Quantity adjustment.
For the products Sinter and Iron create 2 formulas (Engineer > Formula > Lines) using the above table with the reference input quantities. Beware the Formula size (1.4 tons for the sinter, 1 t for the pig iron).

For the pig iron add the by-product “Slag” (0,3 t per 1 t of iron) with the button Co-products. Set the Burden=None: the slug is not an additional cost but a product that can be sold profitably. Approve and activate the formulas.

The ERP orders in the first stages of steel production are not individually planned but entered after-the-fact with the recorded output quantity. In the production control module (Production control / All production orders) create a batch order for 8400 metric tons of Sinter. The Iron batch orders are likely to be entered on every blast furnace tapping, let’s say for 1500 t, 2500 t, and 2000 t:

The formula lines with raw materials are automatically provided with the product cost purposes “Sint” and “Iron”, respectively. In this scenario we do not absorb any planned labor into the production cost; inactivate any anticipated overheard in the costing sheet.
Produce 8400 t of Sinter with the Process > Report as finished button. Use picking list back-flashing to automatically consume the appropriate quantity of the raw materials.
Now produce 1500 + 2500 + 2000 t of Iron along with 450 + 750 + 600 t of the Slag by-product, use back-flushing to quickly record the consumption of Sinter and Coke.

Sell 1000 t of Slag at 15 USD per ton with a sales order to some customer.

Now simulate the monthly salary allocation with a general ledger journal: post 5333 and 10000 USD to the account 600250 "Manufacturing Salaries" and the respective cost center:

We have now collected data sufficient to start applying the Cost accounting module.

Cost accounting setup

Go to Cost accounting / Setup / Dimensions and make the CostCenter and CostPurpose dimensions available to the module. In Cost accounting parameters, choose Cost category identical with account number. Perform the periodic job Account reconciliation; this will synchronize all P&L accounts in the company with the cost accounting primary Cost categories:

You will later add the non-numeric “local cost categories” manually. On the General tab, Transaction control activate the dimensions CostCenter and CostPurpose for the cost categories 401100, 500101, 500111 and 600250. You are now ready to inject the GL transactions into the Cost accounting module: Periodic / Transactions / Process ledger transactions. The result can be verified in Inquires / Cost transactions:

There will be some costs without a cost center or cost purpose, because the data does not exist at the GL source. You may use Cost accounting / Setup / Dimension posting control to selectively filter out the blank CostCenter on 401100, 500101, 500111 and the blank CostPurpose on 600250.
We may now start viewing and aggregating the direct raw material costs in the module. The necessary setup is the Line structure (Cost accounting / Setup / Grouping / Line structures). Ideally, this line structure should resemble the P&L statement. Start with a basic structure with the cost category lines 1_RM, 2_WG, 4_CP, 5_SL and the totals 3_TC and 6_TS, the remaining nodes you may add later:

The effect of this aggregation can be observed in Inquires / Dimensions, Cost balances. Mark the Total cost and Quantity in Display setup and choose your Line structure. The result is an aggregation of the primary [material] costs posted against a financial dimension, here for the CostPurpose = Sinter:

The indirect costs – the wages – are not yet displayed. They wages are absorbed into the product cost by means of a CC-CP allocation:

CC “SP” --> CP "Sint"
CC “BF” --> CP "Iron"

This kind of an allocation is usually performed in Dynamics AX Cost accounting by a variable basis with the so-called service transactions. They are taken from the production route hour data and allow for the CC-CP allocation of the machine cost (CC) over the product cost (CP) if the same machine have been used to make different products. In our case the “SP” staff only works for the “Sint” production, whereas “BF” people only make “Iron”. I.e. the allocation can be constantly 100%.

The Dynamics AX Cost accounting module knows distributions and allocations in a Calculation version. The “distributions” can re-arrange costs from one CC to another or from one CP to another while preserving the Cost category at the inception. The "allocations" move costs from one dimension (CC) to another (CP), but they require separate Secondary cost categories. Now you have to create CC-CP and CC-CPwg secondary categories as shown on one of the screenshots above. Create one calculation version (Setup / Calculation / Calculation version) for the Actual cost, and add first 2 allocations (you will add the remaining ones later):

Choose the “debit” cost category Allocation account = CC-CP, and the “credit” Offset account = CC-CPwg. Mark Calculate fixed costs and the Offset transaction dimension = Cost purpose. The Calculation value type=Total costs. On the tab page Dimension, you can choose the CP dimension value to distribute the CC cost over: “Sint” and “Iron”, respectively. Enter the Reference quantity = 100. The leftmost symbol in the grid must become green if everything has been set up properly.

Now perform the Periodic / Period calculation. The Inquires / Calculation transactions should start appearing, 4 of them, and in the dimension balance for the “Sint” the wages of 5333 should be displayed.
In the next iteration the resulting full cost of the sinter is spread over the iron batches: CP Sint --> CP Iron. The raw material cost in Sinter may be processed with a distribution; here I may spread a whole Line structure node (1_RM) for CP=Sint over the Line structure node=1_RM of CP=Iron while preserving the original cost category 500111 inside:

Unfortunately, this trick is not going to work with the indirect wages allocated to the Sinter, because internally the “distributions” are executed before the “allocations”, i.e. there will be no allocated wages to distribute.

1. Remove the CP=Iron (the red one in the table) from the formula line “Sinter” in the iron production batches before the back-flushing. The intermediate product cost is now “orphaned” and doesn’t show up under “Iron”. This would require a customization to automate.
2. Book the intermediate product Issue to a separate GL account i.e. cost category and exclude it from the line structure. This is not always possible because the classification of the product as “intermediate” or “final” may be vague: the intermediate products may also be sold to a customer.
3. Building on the fact that in a continuous production the intermediate products cannot accumulate, we may subtract the reported-as-finished “revenue” (line 4_CP) of Sinter from the direct costs of the Iron (line 1_RM): the whole 'change in inventory' of sinter will be spread over CP=Iron with an “allocation”.

Check the cost balance inquiry:

Now you know that the full cost of your daily pig iron batches was 667833 USD, where the raw material contribution over the whole material chain was 652500 USD and the salary was 15333 USD.

Conclusion

• AMEX - American Express – gives a plain text KR 1025 file, currently being replaced by the GL 1025 format
• Master Card uses the Common Data Format 3.0 (CDF3), an XML file.
• VISA provides the Visa Commercial Format 4.0 (VCF4), a plain tab-separated text file

• The AIF framework is built upon the WCF and .NET libraries, but
• NET does not support XSLT 2.0 specification with its unparsed-text() and tokenize() functions and this is not expected to change in the near future, and
• XSLT 1.0 transformations cannot take a plain text file, the input to an XSLT 1.0 transformation must be a well-formed XML. An attempt to convert a text file ends up in a “Line 1, column 1” error message, i.e. an XML header is expected by the XSLT processor.
• Ergo, we are doomed.

• Pre-process the text file and put it into a CDATA node of a well-formed XML document
• Perform the transformation in an external .NET library.

The latter approach is well illustrated in the blog importing-credit-card-statements-into-dynamics-ax-2012-using-aif-and-transformation-library. However, this implementation is far from being an industry grade solution. Firstly, this implementation if not official and it uses hardcoded text constants. Without the DLL source code, itit  impossible to maintain. Secondly, for every change the DLL must be recompiled and re-deployed, and the AOS service must be restarted. While you are developing your interface you might need to restart the AOS service 100-200 times; you must be really masochistic to bring it upon you.

In contrary, a XSLT transformation may be replaced on-the-fly without even restarting the Inbound port service (to do that, use Tools / Application Integration Framework / Manage transforms, button Load). The XSLT language is a complex but powerful functional language, and it is a well-recognized industry standard. An XSLT transformation can be nicely debugged in Visual Studio. It can be adjusted by the system administrator, and it can accommodate to future changes.
Inspired by the AX2012 R3 “Advanced Bank Reconciliation”, which is able to import BAI2 and MT940 plain text files through an AIF inbound port, I developed a VISA VCF4 interface to 99% with XLST transformations only.

The remaining 1% is a generic, very simple .NET DLL that takes any text file and wraps it into a CDATA section. In the Bank Reconciliation this is done not in a transformation pipeline but in the X++ code, see \Classes\BankStatementFileImport\getImportFileContainer.

The transformation pipeline consists of 3 transformations:

The target format must conform to the AIF batch message schema: aside of the typical AX <Envelope> with the <MessageParts> the whole message has to be additionally embedded into a <Batch> node.
Processing of such a message can take place in an AX batch job. Beware: an attempt to call the function synchronously Travel and expense / Periodic / Credit cards / Credit card import from file from the AX client may lead to a processing error “Cannot logon to AX…”, because different credentials may be expected by the service. Either way, the above function is very useful in testing the transformation itself and the XML schema: you first call it interactively to check if the message reaches AX (System administration / Services and Application Integration Framework / Queue manager), then launch it in the batch mode to test the final stages when the message is being de-serialized and written to the TrvPBSMaindata table.

Visa Commercial Format 4.0 interface implementation

A VCF file consists of one or more transaction sets, one set per company (i.e. legal entity in AX). A transaction set consists of one or more blocks of transaction records, it is delimited by a header transaction “6” at the beginning and a trailer transaction “7” at the end.

One transaction set may have up to 13 blocks of transactions. A transaction block is a group of transactions that belong to the same record type. Like transaction sets, each block requires a header record “8” at the beginning and a trailer record “9” at the end.

Hence, the 6-7 and 8-9 lines always come in pairs, and this structure is very similar to an XML file with opening and closing tags:

6 Company Header Transaction Set

8 Header Block Transactions – Type “01”

Transaction 1
Transaction 2
Transaction n 

9 Trailer Block Transactions – Type “01”
…

8 Header Block Transactions – Type “05”

Transaction 1
Transaction 2
Transaction n

9 Trailer Block Transactions – Type “05”
…

7 Company Trailer Transaction Set

The following record types are to be provided daily, e.g. transactions
- Car Rental Summary Type “02” (if available)
- Card Transaction Type “05” (if available)
- Line Item Detail Type “07” (if available)
- Line Item Summary Type “08”
- Lodging Summary Type “09”
- Period Type “11”
- Passenger Itinerary Type “14” (if available)
- Leg-Specific Information Type “15” (if available)

For the purpose of expense entry automation the Type 05 records are of most interest.

Potentially we may also import “02”s, “14”s and “15”s into an TrvEnhancedData record by sending a nested element such as
<TrvEnhancedData class="entity" type ="tns:AxdEntity_TrvEnhancedData_TrvEnhancedItineraryData">, but the TrvEnhancedItineraryData inherits from TrvEnhancedData, while AX programmers forgot to provide any of the \Classes\TrvTrvPBSMaindata_TrvEnhancedData_XXX container classes. Standard Dynamics AX simply cannot uptake the TrvEnhancedData descendant tables.

The first stage of conversion is provided by a puristic C# assembly AX2012_TransformAnyTextToXML.DLL. It writes the text into an XML file with a large CDATA section.

 using System.Text;
 using System.IO;
 using System.Xml;
 using Microsoft.Dynamics.IntegrationFramework.Transform;
 
 namespace AX2012_TransformAnyTextToXML
 {
 public class TransformAnyTextToXML : ITransform
 {
 public void Transform(System.IO.Stream input, System.IO.Stream output, string config)
 {
 StreamReader sreader = new StreamReader(input);
 XmlTextWriter xwriter = new XmlTextWriter(output, Encoding.UTF8);
 
 xwriter.Formatting = Formatting.None;
 xwriter.WriteStartDocument();
 xwriter.WriteStartElement("root");
 xwriter.WriteCData(sreader.ReadToEnd());
 sreader.Close();
 xwriter.WriteEndElement();
 xwriter.Close();
 }
 }
 }

Build and deploy it as described here: https://technet.microsoft.com/en-us/library/gg863930.aspx.

The second stage is an XSLT transformation VCF4TXT_to_XML.xslt that recursively breaks down the long text string into records by the “LF” character, and into fields by the “TAB” character. The result is a pre-digested XML file with enumerated fields. Headers and footers are records of their own, but I elevated their fields up to the <TransactionSet>, <TransactionBlock> level to facilitate cross-record lookups and XPath axis addressing.

The third stage is an XSLT transformation VCF4XML_to_AX.xslt that applies business logic and converts the resulting XML file to the Dynamics AX AIF message format. It makes one <Envelope> per <TransactionSet> i.e. company.

The mapping from a long 10 digits “Company Identification” code to the 4 char AX legal entity code is hard-coded into the XSLT transformation. In an environment with just one company or there only one company issues VISA cards you may omit his section: the <Company> is not a mandatory element.

Another added „sugar“ is a <MessageId> tag for idempotency. AX may not import the same file twice. This is enforced at later stages through the uniqness of the TrvPBSMaindata.CCTransUniqueID field, but also by the <MessageId> in the XML header. On an attempt to import a second file with the same <MessageId> AX is going to show an error message „Duplicate message. Message has already been processed.“

Logically the <MessageId> corresponds to the VCF download Sequence Number which is unique in every credit card statement file. However, AX expects a GUID in the <MessageId> element. In our case this GUID must be deterministic. For example, it must reproduceably return the same GUID {feb9aab5-8853-9501-0381-3a7d6075d3d1} for the same Sequence Number „02746“ in the VCF4 file. This logic is implemented in an inline C# script stringToGuid() through a SHA1 hash, courtesy of a great guy called Ben Gripka (see stackoverflow.com/questions/2642141/how-to-create-deterministic-guids).

The conversion tables from the ISO numeric codes for countries and currencies into the ISO symbolic codes are embedded directly into the VCF4XML_to_AX.xslt.

The mapping between merchant SIC codes <CatCode> such as 5411 “Retail-Grocery Stores” and expense categories is configurable in Dynamics AX (Travel and expense / Setup / Credit cards / Credit card category codes). The credit card type “VISA” is hardcoded in the XSLT.

Here is a sample of the resulting XML file, ready to be consumed by the AX service:

Conslusion

A VISA credit card interface with virtually no customizations in Dynamics AX is feasible. The reference XSLT transformations are attached.

The situation with the support for the remaining credit card providers is still unsatisfactory. Please vote for my product suggestion on MSConnect.

VCF4XML_to_AX_v2.zip

Indeed, the feature was not only tracking inventory cost in 2 currencies (the local accounting one and in the reporting i.e. secondary currency) but also calculating it in accordance with 2 different cost calculation models and posting the financial impact into the general ledger in an isolated GL layer to make it visible on IFRS vs. local account statements. Every inventory transaction was given an additional set of fields CostAmountSecCur* to store the value in the secondary currency. The feature was blamed for bugs, but after a while it made it into the Dynamics AX core application. A decade later the bugs are gone and the feature is still there in Dynamics AX 2012 R3 for Russia and other Eastern European countries, it has been kept on a par with the latest developments at the AX logistics core.

What have been the reasons to keep it in the application?

• Initially it provided a stable inventory value in the ‘hard’ currency USD, in a country where retail prices in rubles RUB were updated daily and sometimes grounded in a pseudo-currency tied to the dollar. The COGS in RUB was reflecting the past purchase price whereas the revenues were driven by the inflated sales price, resulting in a disproportionally huge profit in RUB. Only the COGS in USD was comparable with the revenues in USD and provided a more solid basis for a business decisions in an economy ravaged by hyperinflation. With the Russian economy “in tatters” my dual warehouse feature may gain back some popularity :)

• Not that long time ago I was asked by a CEO: “We buy in euros, we sell in euros, why on Earth would we track our stock and assets in the Polish zloty?!” Indeed, IAS 21 says “an entity is required to determine a functional currency … based on the primary economic environment in which it operates”, but auditors are generally less tolerant and expect the balance to the produced in the national currency.

• Costing models in accounting and in the cost accounting sometimes differ. For example, on the balance sheet the average price may be applied to the product stock, whereas in the cost accounting the product may be recorded at a standard price. Here we may utilize the “dual warehouse” with the reporting currency same as the local one but with 2 different cost valuation models.

The emphasis is put here on the last requirement as it seems to be pretty common across the globe.

Example 1

I am using the standard Dynamics AX 2012 R3 demo database, the RUMF company. “RUB” is both the local currency and the reporting currency there. The license configuration key Country regional specific features / Multiple countries regions / Russia / Dual warehousing must be active. Contrary to AX2009, local compliance features in Dynamics AX 2012 cannot be re-used in a “foreign” legal entity by just turning the configuration key: the primary company address must be in Russia. I leave it to the reader to hack AX and to ‘jailbreak’ this feature. Do not expect it to be very easy.

Let me first highlight the business case the feature was initially intended to support. Imagine a product valued at a monthly average price. It is delivered in 2 batches at the same effective price in USD but a different equivalent in RUB:

The contribution margin in the ‘hard’ currency USD is 33.33%, while the contribution margin in RUB is just 14.17%. Which is the “right” one depends on the cost structure of the company. Technically, the one cannot be deducted from the other without knowing the full transaction history. In Dynamics AX a separate inventory closing run is required. This is exactly what the “Dual warehouse” feature does: it allows for 2 parallel closing runs, 2 settlement data pools and a secondary GL ledger.

Example 2

Now let us explore my major case with one currency but 2 models:

To test it, set up a new item model group. Pay attention the secondary inventory model group and the Post secondary financial parameters. The latter activates the “dual” GL posting layer.

Create a new product with the tracking groups None-None. Assign a default site and a warehouse. Use the button Manage costs / Item price on the released product ribbon to assign a standard price to the item. Do not enter the price of 10.00 on the first tab page of the “Pending price” grid but on the second, in the field Secondary cost! Leave the primary standard cost to be zero. Activate the price. In the item group of the product, set an account for the “Rounding variance”.

Open a purchase order to the “Vortex corporation” and post 2 PO invoices with different prices as outlined above. Open a sales order and post an AR invoice with 50 kg.

Now check the inventory transactions and look at the awaited, but still stunning result, or as we say at Microsoft – awesome. Just awesome:

Note the column Cost amount (cur.) meticulously tracking our standard cost as opposed to the average cost in the ordinary Cost amount column. Now open the GL voucher for the second PO invoice:

Examine how the system recorded the cost variance in a separate posting layer.

You may also perform the Inventory management / Periodic / Closing and adjustment vs. Closing and adjustment in currency. Here nether of the procedures is going to make any cost adjustments, since within the primary cost model the momentary cost price happens to be the same as the total average, while the secondary model should not produce any settlements at all for our product valuated at a standard cost.

Conclusion

The examples above have been deliberately kept simple; in reality different currencies and models lead to collisions where an inventory transaction may be settled in one model but remain ‘open’ in the other; where manual adjustments and write-offs are only applied to one of the models; where the ‘physical’ price affects the calculation. I still hope this short introduction has given you an idea what this feature can do if applied creatively.

Stopped (error): X++ Exception: Work item could
not be created. Insufficient rights for user %1.

at SysWorkflowWorkItem-create

SysWorkflowWorkItem-createWorkItems

SysWorkflow-save

SysWorkflowQueue-resume

Moreover, the issue still occurs even after assigning the user to the System Administrator role?

The cause for this is most likely that you have disabled one or more configuration keys in the License configuration in Microsoft Dynamics AX.

As an example, the Vendor invoice approval workflow stops with the above error.

Let’s in the AOT navigate to Workflows -> VendInvoiceApproval -> Outcomes -> Approval

And have a look at the Properties for this node.

ActionMenuItem = VendInvoiceApprovalApprove

Let’s verify the Configuration key for this menu item by still in the AOT to navigate to Menu items -> Action -> VendInvoiceApprovalApprove and have a look at the Properties for this node.

The Configuration key is LedgerBasic. This configuration key is most likely not disabled in the License configuration for Microsoft Dynamics AX.

So let’s check the Web menu item.

WebActionMenuItem = EPVendInvoiceApprovalApprove

Let’s verify the Configuration key for this menu item by still in the AOT to navigate to Web -> Web Menu items -> Actions -> EPVendInvoiceApprovalApprove and have a look at the Properties for this node.

The Configuration key is VSS. This is the configuration key for the Vendor portal and must be enabled for the Vendor invoice approval workflow to be successful. Enabling this Configuration key in the License configuration in Microsoft Dynamics AX solves the above problem. In Microsoft Dynamics AX navigate to System administration -> Setup -> Licensing -> License configuration. Navigate to Procurement I and make sure that Vendor portal is checked.

The conclusion is that the Vendor Invoice Approval workflow will not work in Microsoft Dynamics AX without the Vendor portal being enabled, even if the Vendor portal is not to be used.

• “Free” breakfast at the hotel = 20% reduction = -€4.80
• Free lunch at work = 40% reduction = -€9.60
• Dinner sponsored by the boss = 40% reduction = -€9.60

Domestic business travel – case 1 “One-day training”

• solve it organizationally, establish “human-driven” approval rules
• make a small customization to enable the total trip duration, the start and the end date as parameters in the expense policy definition.

Domestic business travel – case 2 “3 days of training with hotel”

Domestic business travel – case 3 “Fine dining”

This time the hotel served breakfast to Otto. The breakfast must presented on the invoice separately, since any meal at the restaurant is taxed at the full rate of 19%, whereas the accommodation is subsidized through the reduced VAT of 7%. One can hardly get a decent breakfast in Germany for 4.80 EUR, and in Switzerland breakfast would cost not 48 EUR * 20% = 9.60 EUR but probably around 20 CHF ~= 19 EUR. In practical terms, to get off with as little damage as possible, Otto has to strip the hotel bill of the breakfast and record no reduction for breakfast. There is still no need for the itemization of the hotel bill. The fine dining with the customer is tolerated by the BMF, but it should be at a reasonable cost. The statutory definition of “reasonable” in 2015 is no more than €60 per person. This so-called “entertainment” may not reduce the corporate tax base, but the VAT may be recovered. Until recently the BMF used to only return 70% of the VAT, but after an intervention of the European Union the VAT amount may now be recovered in full. We require a new expense category of the type “Meal” with the full VAT rate assigned. To enforce the “reasonable price” rule, an expense validation policy may be set up: Amount < Number of guests * €60 The policy screen in AX does not allow for complex formulas with multiplication, but we hope that Otto is not going to throw a wedding party for a hundred of guests, and we are able to set up an exhaustive list for any party with a number of guests between 2 and 10-20:

The first condition additionally enforces an obligatory entry of the invited guests. The system will show an error unless the button Guests… is clicked in the “eMeals” line:

Try and see what happens if bier costs 20 euros more. Here is the total impact of the Otto’s activities, as expected:

Domestic business travel – case 4 "Travelling abroad"

As we have learned already, daily allowances are country-specific. The reduced domestic rate for Germany is 50%, but the reduced foreign rates are close to 66% (but not exactly):

The reduced rates are rounded by the government to whole euros. To match the reduced foreign rate, I use a tailored percentage. It should approximate the daily rate with a deviation less than €0.01: 41/62 = 0,66129… => 62.00 * 66.13% = 41.0006 ~= 41.00 32/48 = 0,66666… => 62.00 * 66.66% = 31.9968 ~= 32.00 The respective setup of per diems and tiers per location is shown on the following screenshot:

Note that the rates are updated by the BMF every year and have to be regularly re-imported with validity dates. This is also true for the calculated percentage for first/last day. The meals reduction in AX now takes the rates for the location “Switzerland-Geneva” into account:

The foreign VAT on the hotel bill is not recoverable, the selection of the right country code ensures no VAT is going to be deducted. The amount paid in Swiss francs is converted to euro at the intrinsic System exchange rate type the AX (see System administration / Setup / System parameters) on the given day. Again, breakfasts have to be subtracted from the total bill amount:

Newly in 2015, a special challenge is posed by roundtrips across foreign cities with different rates as explained here on a case of the USA: www.spesen-ratgeber.de/verpflegungsmehraufwand-ausland-2014-neue-ausloese-tabelle/ The legs have to be entered in AX in separate expense report lines, because the only place to specify the location driving the rate is the line, there are no per diem sub-lines in AX. This makes erroneously the first day of the leg an “arrival” and the last – a “departure” day. This is not entirely correct, because the days “in the middle” are eligible to the full 24h-rate of the destination reached by 24:00 o’clock on the respective date. Indeed, “2/3 Los Angeles rate” + “2/3 Miami rate” is not the same as “1 Miami rate”. This may be helped by dummy locations without any reduction for the first and last day.

On per diems configuration in Dynamics 365 for Finance and Operations, read Configuring Austrian and Norwegian per diems in Dynamics 365.

• “Calculations” and a slight possibility to work with real numerical values
• A feature to automatically re-use configurations instead of generating a new one every time

Yet with regards to the integration with the rest of the Dynamics AX system both tools sometimes share similar weaknesses:

1. The configurator cannot take main product attributes as parameters to build one complex re-usable model with forks for similar products with some slightly varying properties.
2. The used product configurator attributes are not stored in a human readable format on the generated configuration record. Needless to say, an AX configuration does not possess its own attributes at all, nor are the attributes searchable in the AX rich client.
3. Lookups from AX master tables (usually products, units, product groups) seem to only be leveraged in Retail attributes, while in the product configurator every value should be re-entered as a “free text” in a dedicated attribute type.
4. Process manufacturing formulas are not supported even if they are technically exactly the same as discrete BOMs.
5. New configuration IDs are taken from a number sequence (000147, 000148, 000149…) and together with the resulting configurations names bear no meaning to the user. Furthermore, a constraint-based product may not have a pre-configured set of initial configurations with distinct codes. One may only use configuration templates for that.

While the ivory towers are high, thanks to customizable interfaces in AX we can help ourselves. Below is a solution to the last issue, a feature that allows the user to enter a voluntary free-text ID for the new product configuration record. The feature is looking for an attribute with the solver name ConfigID among the options chosen by the user:

and takes it instead of drawing a new number from the number sequence. One screen of X++ code is attached to this blog. The issue with the dummy configuration name may also be solved following this pattern. A natural approach would be a name composed of the same unique attributes as in the "re-usable configuration cache".
Now, who is going to tackle the points 1-4?

SharedProject_PC_FreeText_ConfigID.zip

Here the common part ends. The users may follow very different kit handling processes:

• The kits may be pre-assembled and assume some work at the picking workplace
• Or the kit just requires a joint shipment
• On the invoice the kit may be represented by a single line or it may expose its components
• The sales price for the kit may be less than the sum of the component’s prices, or it may be the same

For example, an epoxy resin may be sold in a combination with a hardener; the ratio between the resin and hardener is pre-defined. This assumes a Bill of Materials for the Epoxy kit:

In this example, the “Epoxy set” costs less than the total sales price of the components (150) it entails.

A related problem may arise in the high-tech industry when selling software-hardware bundles. Shown to the customer as one line on the sales confirmation and the invoice, the revenue from this bundle broken down by the revenue stream:

The guarantee may be managed as a non-stockable item or even as a stockable one, should it be provided by a 3^rd party.

Depending on the requirements above the preferrable solution in Dynamics AX 2012 R3 may differ:

Let us explore the options in more detail, with its benefits and shortcomings.

(1) Sales BOM explosion

Imagine one “Epoxy SET Bisphenol A” would cost exactly €150 and will be shown to the customer as 2 separate lines. We just know that the epoxy resin is useless without the hardener and we are happy to offer the hardener as an option. Create a simple bill of materials of 2 lines for the set EXY-6001, approve and activate it:

In this example, one set requires 500 ml of the resin and 500 ml of the hardener.

Now create a sales order, enter a new line with the set and apply the Sales order line / Explode BOM lines function:

Choose Select all, OK. The sales order quantity for the original goes to zero, the line is effectively replaced by its 2 components, each with an individual price set in the released product master:

Note the need for the user to press the button. What if the operator does not know there is a BOM behind the set? Use distinctive product names or implement a customization to apply the BOM explosion automatically.

Make sure there is enough stock for EXY-7001 and EXY-7002, produce a delivery note and an invoice for the order. As expected, the invoice shows 2 lines with a total amount of €150. There is no reference to the original set.

(2) Supplementary items

Imagine the buyer of an EXY-7002 “Epoxy hardener” lot is offered a promotional “Mixing bowl”, 1 piece at a discounted price.

Navigate to the EXY-7002 released product record records, use Sell / Supplementary sales items on the ribbon to enter the information as shown below:

Note the sales price for the EXY-7010 “Mixing bowl” is again taken from its own product settings, unless the option Free of charge is chosen. I.e. the level of control of the sales price is very low.

Return to your sales orders, create a new one 50 liters of the hardener EXY-7002. Note that nothing happens when you save the sales line for the main product. Again, the operator MUST know there is a potential supplementary item and press the Sales order line / Supplementary items button:

The Once only option chosen above allows for just one supplementary item line instead of 50 (per liter).

Note: similarly to the BOM explosion and standard multi-line discounts, the supplementary item calculation requires an thoughtful action (clicking the button, approving with OK) from the user. You may think of programming an automatic notification of a supplementary item applicable.

The resulting invoice printout is from the functional perspective equivalent to the previous solution (1) with 2 lines and individual prices:

(3) Sales BOM explosion (customized)

Having the limitations of the solution (1) and (2) in mind, I may recommend developing a customized BOM explosion routine which replaces the components’ sales prices with the (lesser) set sales price. The calculated sales prices follow the ratio of components’ sales amounts. The invoice printout is customized to replace the 2 set component lines with the kit sales line.

You may find the source code of the customization attached to this blog entry. It is kept very minimalistic and non-intrusive, more like a proof of concept. The core of the customization is a change in SalesLine.expandBOM method as well as a hook in the  SalesInvoiceDP.insertIntoSalesInvoiceTmp invoice printout data provider:

Here is what happens when you apply the modified BOM explosion routine to your sales order line:

The sales prices of the components now accommodate the set sales price.

The invoice printout obscures the components as if it was just the set alone, while the kit components are still picked, shipped and posted to the General Ledger at the back office:

(4) Retail mix-and-match discount

Note the difference in the sales price allocation between the solutions (1-2) and (3): the presence of the second line (hardener) have an influence on the first sales line (resin). A similar effect may be achieved with the retail mix-and-match discounts: “take a pillow to your blanket and have a 10% discount on both”.

This may also be applicable to wholesale or manufacturing: we anticipate the demand for the hardener to correlate with the resin and procure / produce both in a constant ratio. The customer is motivated to buy both products together. Should he only buy the resin, the hardener accumulates in our stock and we suffer.

In the previous versions of AX the retail pricing engine was only used on hardware points of sales (POS) and not in the rich client sales order. In AX 2012, the both worlds are united in the Call center extension to the sales orders. The configuration is not quite easy, though. First of all, we need a new “Call center” retail channel to be established in Retail/Common/Retail channels/Call centers:

The Channel user must be associated with the new call center to take advantage of the retail sales orders. In fact, this user – the call center operator -  is given a very limited, workflow-driven access to the sales order form.

Additionally, a Price group of the retail type must assigned to the call center. You may also find it useful to associate your products with a retail category in the retail hierarchy, and the call center should normally be grounded in your Retail assortment hierarchy:

Our mix-and-match agreement must be activated if the 2 products – 50 liters of resin and the 50 liters of hardener – meet each other in the same sales order. This requires a Mix and match group setup of 2 lines there the Number of products needed = 50+50 = 100. Yes, this calculation is kind of weird. My understanding is that in the retail business the stuff is normally sold in small numbers (1+1=2).

In the Retail/Common/Pricing and discount/Mix and match discounts form you must be able to configure the following:

Here the two components together are granted a discount of 10% for both. The link to the call center is established though the Price group (see the button above). Set the status of the discount to Enabled. The discount becomes effective immediately.

Having all the necessary setup in place, proceed to the sales order and enter a new one. With the right AX user every new sales order is associated with the call center and marked as a Retail sale in the order Header view. This activates the retail price and discount engine in the lines.

Enter the first sales line for the 50 liters of EXY-7001. Nothing happens at first, but when you are about to leave the second one (50 l of EXY-7002) a notification appears:

The result is as follows: the 10% discount is applied to the both the resin and the hardener:

Beware: this interactive discount calculation runs amok when you enter a sales quantity more than the Number of products needed = 100.

Moreover, this discount agreement is applied to ANY customer: the call center and retail modules are made to implement a uniform sales process to a large group of mass customers.

As a call center operator, you must Complete the order, providing payment info before shipping and billing. The invoice printout is as follows, individual lines with combination prices; a percentage discount is always converted into an amount by the retail price engine:

(5) Retail product kits

A solution alternative to the BOM explosion is offered by the new retail kit functionality in AX2012 R3. Retail kits are better understood as tangible ones, put into one box: “Canon EOS 100 + 40mm lens kit, boxed”. The retail kits are therefore stored at the warehouse and assembled explicitly. The assembling procedure is managed with a kit assembly order. It silently posts a BOM inventory journal, an approach well known to an experienced Dynamics AX consultant.

The kit requires a configurable product master to be set up (Retail/Common/Kits/Product kits). By clicking Configure you are able to enter the components. Every set of components results in a new Configuration of the kit product:

A retail-enabled “call center sales order" checks for kits on-hand and may raise a kit assembly order automatically when you “Complete” the sales order. Posting the assembly order consumes the components and increases the stock of the kit item. This kit may now be shipped and billed with a trivial invoice layout:

Note: the retail product kit functionality does not use BOMs. The retail ‘flavor’ enforces strict rules for the sales order entry, its modification and fulfillment. The retail kit is normally a stockable one, its shipping requires an explicit confirmation of the assembly order by the warehouse operator.

PrivateProject_SalesBOM_Explode_Kit.zip