Picking list journal: Inventory dimension Location must be specified

Picking list journal: Inventory dimension Location must be specified

One – if not the – notorious error in Dynamics 365 related to production and warehouse management manifests itself at the “Production floor execution” terminal during reporting as finished (RaF). On the screen, the error message “An error occurred while processing the job…” is displayed.

In the activity center, you receive the following detailed error message:

  • Posting – Picking list journal
  • Inventory dimension Location must be specified.

This is due to the failed material withdrawal following the Finish backflushing principle (actual quantity = planned quantity, see The case of a missing flushing principle). The causes are diverse, with the most common being an incomplete warehouse work. This means that the materials haven’t been brought to the machine’s input location, yet someone is trying to report the finished or semi-finished product as complete.

This error pops up very often during the testing phase of the Dynamics 365 implementation. You may say: “Hey, let them finish the picking work first; this may never happen in real life, since the materials are going to be missing for the assembly! The sequence of production steps must be adhered to!”

It is not that simple. I’d say we are talking about a significant design flaw in the Dynamics 365 for SCM system.

Let’s conduct a thought experiment. In an MTS (make-to-stock) scenario, imagine 3 production orders planned for the same product on the same day. All of them get released at once early in the morning, all of them produce warehouse work for the picking of the same raw material. If they are not consolidated into one production wave, it may happen that the warehouse work for the PO3 has been completed much earlier than the warehouse work for the PO1, but the PO1 is started and finished earlier. There is namely no particular order or priority in the warehouse work. The material is going to be at the inbound location of the work centre, the machine operator does not care if it’s for the current or for the next order. Yet reporting the progress at the terminal fails due to the mis-allocation of the material.

Explanation

Presuming the Automatic BOM consumption parameter in Production control > Setup > Manufacturing execution > Production order defaults is set to Flushing principle, and the Post automatically is set to Yes, then the material consumption becomes an integral part of every RaF transaction at the Production floor execution terminal. If the picking list posting fails, the whole transaction is rolled back:

In reality, it is even worse than a clean rollback. On each failed attempt of Progress reporting, a new picking list journal is created. The mere presence of such a picking list prevents any further attempts because the open line(s) in the picking list journal block a portion of the bill of materials through a TransChildRefId identifier – a relationship between the journal line and the BOM line.

With the advanced Warehouse management in Dynamics turned on, the warehouse locations in the master BOM must remain empty. They are allocated during the Release or Release to warehouse phase in Production. If the Resource consumption checkbox is set in every BOM line, then the input location of the work centre is evaluated by the Warehouse management module at the run time as the picking list journal lines are getting created. While doing do, for some reason they are looking for the location in the picking warehouse work. If the particular inbound location is not reserved there in the InventTrans, or the work is not closed yet, the Location dimension in the picking journal is going to be empty:

Troubleshooting

The troubleshooting steps are as follows:

  1. First and foremost, search for any open picking lists for the production order with the button View / Journals / Picking List.
  2. Alternatively, use the list of all open picking journals in the menu Production control > Adjustments > Picking List using the order number. This list should actually be empty, meaning all picking lists should have been posted.
  3. Select the open (not posted) picking list journals and delete them all at once.
  4. Look for any open warehouse work for production, meaning the warehouse work for materials picking: Pick at the main warehouse, Put to the inbound location of the machine. Use the button Warehouse / General / Work details at the production order.
  5. If there is open work, ensure it is processed on the mobile device.
  6. If there is no open warehouse work for the production order, initiate the warehouse picking process again using the button Release to warehouse. A new production wave will be generated, and new warehouse work will be created in the background. If the materials and parts are already at the machine’s location, this warehouse work will automatically be closed, and the materials will be reserved at that location for the production order. The next picking list will have the correct location in all lines, and posting this entry will likely work.
  7. This deals with the racing condition in the above thought experiment, too: the material already found at the location will be rearranged to the current order. However, any open warehouse work for the current order shall be cancelled first. This re-release of released orders may also be automated.
  8. If the report as finished continues to fail at the terminal, the operator may forcefully reduce the quantity using the Adjust material button: click on Adjust material, enter a zero. Repeat this process for all BOM lines. Then confirm the Adjust material screen with OK. Reporting as finished should work now, while the excess material can be eliminated in a manual picking list journal.

If the error happens often, some drastic measures may need to be taken. The point in time for the consumption of materials must namely be changed to At location for most materials and parts. This de-couples the material backflushing from the Report as finished feedback.

Sometimes you pay Reverse Charge in D365

Sometimes you pay Reverse Charge in D365

Under the “reverse charge system” it is the company receiving the service that is liable to pay the VAT, and not the company providing the service. Normally, the net amount of VAT to pay is offset by the same amount of the receivable VAT, and the tax burden remains 0. But not always: sometimes the tax office wins. These are 2 common cases:

    • A service was provided by an EU entrepreneur who had no EU VAT number. The invoice was VAT excluded, but I had to calculate the VAT payable (reporting code 1157 „Steuerschuldübergang bei Bezug gemäß § 19 Abs. 1 zweiter Satz, § 19 Abs. 1c“ in Austria, code 47 „Steuer, im Inland steuerpflichtige sonstige Leistung eines EU Unternehmers § 13b Abs. 1 UStG“ in Germany), while the VAT receivable was nil (otherwise reported as 1166 „Vorsteuer: Steuerschuldübergang gemäß §19, grenzüberschreitende Leistungen“ in Austria or code 67 „Vorsteuer aus Umsätzen nach §13b Abs. 2 Nr. 11“ in Germany).
    • In the case of the self-billing (Gutschriftverfahren) a foreign agency may pay money to an entrepreneur by issuing an invoice on her/his behalf. If the entrepreneur does not have a VAT registration, or it is a small business, the VAT receivable cannot be recognised and the entrepreneur becomes liable for tax. If you register the agency as a customer it is a no-brainer, but the problem is in the non-continuous invoice number issued by the agency.

Solution in Dynamics 365 for Finance

The common business process distils into 3 steps:
– One receives an invoice (or a self-billed credit note) from a supplier (vendor) over €100
– One pays €100 to the supplier (or becomes €100 from the supplier)
– One pays €20 (or €19 in Germany) to the tax office
 
To implement this in Dynamics 365 for Finance, we activate the Use tax in the VAT group (en-us: Sales tax group) as usual (see Minimalistic EU VAT configuration in D365):

On top of that, the special VAT code (here: ServEUnond) for the non-deductible Reverse Charge receives Non deductible % = 100% in the tax code value:
 
The use tax VAT from the supplier invoice calculated in this way “elongates” the original expense, the GL voucher reflects the fact that the service effectively becomes more expensive by 19% (in DE).
This may be considered right or wrong, but a different expense account such as 7xxx “VAT, non-deductible” is not possible in standard Dynamics 365. If needed, this tax expense may be reallocated to a different account manually at the end of the period.

The monthly/quarterly Tax > Declaration > VAT > Settle and post VAT operation does not find any VAT receivable to offset the VAT payable and transfers the liability into the Tax authority’s payable account:
Bingo!

In the case of self-billing, the VAT payable is subtracted from the revenue: the credit note is booked as a revenue via a specially prepared procurement category, for example. The VAT “contracts” the revenue, and in order to do so, the rate of the tax must be negative (!), i.e. -20% (or -19% in Germany). The Negative VAT percentage must be activated first at the tax code record. 

Cross-company data sharing vs. Duplication in Dynamics

Cross-company data sharing vs. Duplication in Dynamics

Cross-company data sharing

 
Cross-company data sharing in Dynamics 365 for Finance and SCM (see System administration > Setup > Configure cross-company data sharing) supposed to be a valid replacement of the virtual companies in Dynamics AX2012 and earlier. I don’t know how about you, but I get the error “Table … is a Main table as specified by the table group and may not be shared unless its Data Sharing Type is Duplicate” every time I wish to share something useful.

It looks for the TableGroup property in the D365 table metadata and practically rejects any table which is not a Group or does not have a simple primary key. What is left for sharing? Some little configuration tables such as the Delivery terms (INCOTERMS), Payment terms ans so on: only these have the TableGroup = Group.  This rules out the most interesting tables in Dynamics such as the InventTable (Product list), CustTable (Customers) or VendTable (Suppliers) (well, this is not entirely true: for the latter there is a dedicated Feature Customer and Vendor master data sharing available for activation). Namely, these have TableGroup = Main.

The TableGroup property of the standard tables is not extendable. The developers left a backdoor: a Main table with the property DataSharingType explicitly set to Single or Duplicate may be eligible too. CustTable is an example. Needless to say, the DataSharingType is not extendable either. There seems to be a yet another backdoor in the form of the SysDataSharingTypeTableConfiguration table where this DataSharingType is supposed to be configured. However, this feature is protected by the flight EnableSysDataSharingTypeTableConfiguration. As with every flight it is very promising and tempting but it remains hard-locked in any production environment.

Dead end? Not quite.

Recurring ‘Copy into legal entity’ data project 

 
In Data management, create a new data project of the Copy into legal entity kind, select the destination company(ies) and the appropriate entity or entities:

It should not grab unfinished work, though. In this example it is obvious to only consider an approved bill of materials. The BOM lines do not have an approved  flag, but if there is no BOMId, no line can be copied either, i.e. it is sufficient to only filter the BOM headers. In general, you should take care of the data consistency. In the particular case of the bills of materials, they should not contain any unknown items or refer to any local inventory dimension such as the site, warehouse or the warehouse location: ensure the default sites in all companies in question have the same code “STD” or “DEF”, and set the Resource consumption checkbox in all lines to make them warehouse-agnostic. The Approver is not a problem, since the employee list is technically shared across all legal entities.

Click Copy into legal entity in batch and set a Recurrence e.g. every weekday. The data project may be run over and over again in a cycle copying the same data, but it is not a problem as it works in the UPSERT mode in Dynamics. However, as the data grows the data project runs slower. We should restrict the set and take only the changes of the day, for example. If you are lucky, there will be a ModifiedDateTime column you can use in the Filter:

(here with a Join and an advanced moving date query).