For financial accounting and statutory reporting purposes companies have to be able to evaluate their inventory according to different valuation methods, such as FIFO, LIFO, etc. in parallel.
Currently it is only possible to assign a single inventory model to an item. There is a standard Russian functionality (dual warehouse) available that allows assigning two inventory models. This Russian functionality does, however, also not help in cases where companies need more than two inventory models, which is often the case in international companies that have to report to local GAAP, local tax rules and - at the group level - IFRS if those accounting standards require different valuation methods.
Please note that this does not require that items in the inventory are revalued. What is needed is a financial feature that allows obtaining alternative inventory values based on different inventory valuation principles.
It would be great if this gap could be closed with the next release/update.
Many thanks and best regards,
It is a very common scenario:
Inventory is physically moved from one site to another (moving from warehouse on the east coast to warehouse on the west coast)
Freight cost is incurred during the move, and this cost needs to increase the inventory value.
There can be other charges such as duty and tariffs if the source and destination in different countries.
Right now there is no reasonable way to add the charges cost to the inventory value of the products moved (as can be done with purchase orders, using charges)
This is a MAJOR pain, and a repeated request.
All retailers track their inventory physically and financially by retail stores. Setting up general ledger in Dynamics 365, we mostly setup account structure with 'retail channel' financial dimension (we can call it profit center, responsibility center etc. if it is setup as custom financial dimension) and that financiail dimenion is assigend to Retail Channels in Retail and Commerce Module. Setting up retail store also requires assigning a warehouse that tracks inventory for that store. All sales transactions that flow from Point of Sale System uses financial dimensions defined on the retail store. Sales, cost of sales, discount etc. are all posted using retail channel financial dimension in GL.
However, when purchase order is created or inventory is adjusted for that retail store usiing inventory journals, financial dimensions are updated manually on these transacitons at line level (purchase order, inventory journals). It is required since inventory is tracked financially at warehouse (store) level. It takes considerable amount of time for the users to manually update financial dimensions on purchase order or inventory journal lines.
Historically, we have done a customization and assigend financial dimension to the warehosue that are defauled over to purchase order lines when the warehouse is selected or inventory journal lines as we select the warehouse.
Just like financial dimensions are setup on Vendors, customers, retail channels and other master data entities in Dynamics 365, it will be great to have same financial dimension framework extended to warehouses. These dimensions would then be defaulted on all inventory transactions that uses warehouses.
According to the existing production posting setup in the cost management or inventory management, several WIP posting entries including offset accounts are enabled:
- Estimated cost of materials consumed, WIP
- Estimated cost of materials consumed
- Estimated manufactured cost
- Estimated manufactured cost, WIP
- Cost of materials consumed, WIP
- Cost of materials consumed
- Manufactured cost
- Manufactured cost, WIP
However, in the standard case these entries will refer to inventory accounts.
What is missing and urgently required for covering financial statement requirements is to include the P&L posting applied at least for semi-finished and finished goods. This is quite a standard requirement not possible to define in the system.
The proposed solution is to provide a 4 column setup table with the possibility to define up to 2 debit account entries and up to 2 credit account entries in order to limit the amount of line entries.
Possibility to distribute costs from Cost center A to Cost center B, C, D using an allocation base build on primary expenses posted on 100+ Cost Elements via cost element Hierarchie node.
Currently this is only possible via a Formular allocation base where every cost element has to be added manually, because hierarchy allocation bases do not work with cost Elements.
cost accounting: allocation to mixed cost object hierarchies consisting of different cost object dimension
Currently costs can only be allocated within one cost object dimension in one run.
In the German "Kostenträgerrechnung" it is common to allocate costs to different cost object dimensions.
It should be possible to allocate costs in one run to different cost object dimensions: From Cost Center A to Cost Center B,C and Cost Unit A and B.
Make it possible to split the consumption posting into the cost Group Components that builds up the cost for the item sold. Many companies using standard cost , need to report how much of the consumption value that is related to material, indirect cost, subcontracting, production OH etc. It´s not enough to use the report Inventory value with standard cost breakdown, they need the split to be posted to different ledger accounts for each transaction.
Today we need to modified the Posting form in order to achive this.
The financial linkage functionality allows linking a single financial dimension with an inventory site. This linkage is a great feature but requires two extensions:
First, the ability to link multiple financial dimensions to a single inventory dimensions and
second, the ability to link financial dimensions to inventory dimensions other than sites. Especially the ability to link financial dimensions to warehouses is an often required feature from a finance & accounting perspective.
For som Companies that sells items With large variances in price (both sales and cost price) the classifications in Operations (actually from at least AX 2009) can come out verry wrong.
If a Company sells sealings that has a cost price for 0,5 euro and also sells bigger items with cost over 100 Euro, operations will not care that the sealing might be more important and has a larger sale than the more costly item. The costly item will be given higher classification than the seal.
Turnover is the customer demand and should always be important for a Company. It indicates also how important that item is for the market.
Dynamics operations should add a New classification for Turnover.