patrickmouwen: Financial dimensions on web orders vs non-Retail orders

[Blog bot]

Источник: http://patrickmouwen.com/functional/...retail-orders/
==============


Say we have non-Retail B2B sales and B2C weborders in 1 company. We sell the same items through these channels. We expect the financial dimension values for the same financial dimensions to appear on our order lines but… they differ between these scenarios… HUH?And at invoicing we get stuck (posting is cancelled) as in the B2C scenario we miss a mandatory financial dimension value CostCenter… ARGGGGG!


Cause

For the cause of this issue we have to dig into the way the financial dimensions are inherited in each scenario. Here’s what happens in both scenarios:

In both scenarios the sales order header inherits its financial dimension values from a main entity: in the Retail web order scenario that’s the Retail channel, whereas the customer is the main entity in the non-Retail sales scenario (criterion for ‘being’ a non-Retail sales order: RetailSalesTable.RetailOrder == NoYes::No). This difference makes sense as in the Retail scenario you might want to keep track of the sales channel your actual sale originated from.

But there’s one major difference between the scenarios when it comes to sales order header to sales order line inheritance: in the non-Retail case, the financial dimension values on the sales order header and item level are both (AND) inherited to the sales order line. In the Retail web order case it’s a case of OR: if the item contains default dimension values, then these are copied to the sales order level, otherwise the sales order line inherits the sales order header dimension values.

Solution

For non-Retail sales, the inheritance happens as follows:

1. \Classes\SalesLineType\InitFromSalesTable (inherit from SO header to SO line):
   
2. \Classes\SalesLineType\InitFromInventTable (inherit from item to SO line):
   So, the actual magic is in the salesLine.mergeDimension method. Here’s where the AND card is played.

In my customer’s scenario it was important to align the two cases so the Account structures setup in General ledger could be consistent in terms of mandatory financial dimensions. Therefore I decided to apply the merge to the Retail web order area as well – It also makes the situation more consistent in general. For the Retail web orders the financial dimension values are set as part of the Retail > Periodic > Synchronize online orders batch job. The applied business logic resides in the RetailOrderManager::createEachOrderLine method. So in order to align the cases I only needed to call the Merge functionality in this context as well. A change of only 2 lines of code:


One last addition to this: if you look at how financial dimensions are set on customer orders (created from Retail POS through Real Time Service) and sales orders which are created through Retail POS statement posting, then we see another variant (RetailOrderManager::mergeOrderDefaultDimension):
In this context, financial dimensions are set on sales order header level as a hierarchical merge of even 4 dimensions: customer, Retail store, Retail terminal and worker. You’d better be aware of all these variants when setting up AX financially ;-).

Happy DAX’ing!

Patrick


Het bericht Financial dimensions on web orders vs non-Retail orders verscheen eerst op Patrick Mouwen.



Источник: http://patrickmouwen.com/functional/...retail-orders/