D365 Petty cash review

D365 Petty cash review

Today I take a chance to review a development of my younger self: the Petty cash addon to the Bank and cash module. In central Europe, this “Petty cash” (de: Portokasse, fr: caisse) often looks like the box shown above. Inside of it there is… well… some cash. I designed, programmed this addon and even localized it for Ukraine back in 2002 mostly on my own in something that can be called a study. It has been there in the D365FO application core all these years, and in version 10.0.39 they finally released it worldwide. 


To activate this add-on, enable Petty cash in the Feature management first. There is also a license key (what used to be called a configuration key) Country/Regional specific feature / Multiple countries/regions / General ledger – extensions for Eastern European countries / Petty cash, it is normally activated by default. Ultimately, you must activate it in Cash and bank management parameters with a slider Enable petty cash.

The setup is well described here: (1) Petty Cash Accounting – Microsoft Dynamics 365 Finance | LinkedIn. In essence, you have to create a symbolic cash account, in a Cash posting profile attach a general ledger account to it (there is usually a 1:1 relationship), then select both in Cash and bank management parameters:

D365 Petty Cash Setup

Then there is a balance check. In Eastern Europe the amount of cash you accumulate may not exceed a certain threshold. In Western Europe I know no such regulations but just common sense; some companies even used to stash money 5 years ago to escape the negative bank interest. In contrary, there is a EU-wide limit for cash transactions of 10 kEUR. This can be set as an Operations limit.

In addition, you must specify at least 2 number sequences for the cash slips (bons): reimbursement and disbursement. Finally, configure a GL Journal name of the Cash type. You are good to go.


Navigate to Cash and bank management > Petty cash > Slip journal, create a new journal header, and under Lines you may start registering cash operations.

Cash Slip Journal

For a sale, choose the cash account in debit and a revenue account in credit. Do not forget the VAT. Once you perform Documents approval / Approve of the line, it draws the next Cash reimbursement slipOrder number”. At this step, it is supposed to print this slip at once, but in Eastern Europe there are legal requirements to its form and content, while in Western Europe there are no such requirements and… no printout. 😊Actually we are talking about a “rudimentary invoice” of less than €400 (de: Kleinbetragsrechnung) with some goods/service description, an anonymous recipient and a VAT included. However, in this case a free text invoice is advised, or you may produce it outright at a retail POS, while field servicemen should use their CE mobile terminals.

Post the journal, and it is going to integrate the cash transactions into the GL.

To pay someone out in cash, the cash account is in credit and the expense account is in debit; again, do not forget the VAT. Use Documents approval / Approve first. Interestingly, the cash balance check (see Inquiries / Cash balance) is performed at the same time, and the balance is built of both posted and unposted slips. Again, it issues a new “Order” number for a Cash disbursement slip, and in an Eastern European country it is going to print it. Here it does not make much sense, since a handyman must issue his own slip / bon to testify that he/she has been paid in full, then we take this receipt and preserve it. One case when we need a printout of our own may be a cash advance to an employee.


Even though this addon remains a monument to my abilities in software design 😉 I am coming to a conclusion that it is pretty useless in Western Europe. The same level of comfort may be achieved with a separate bank account or a simple GL account (see Balance control accounts). In 20 years D365 for Finance has moved upmarket, and with the minimum of 20 licenses it is hard to imagine a company whose main source of liquidity may be cash sales. The module may find some usage in construction industry to pay temporary workers, though.

Dissecting the Warehouse Management app layout

Dissecting the Warehouse Management app layout

The layout of the Dynamics 365 Warehouse Management app is managed by both the App code and the D365 SCM core to ensure a productive workflow. The app receives a state from the Dynamics 365 SCM core encapsulated in a “container,” comprising a list of controls to be presented on the current screen. These hints include the DisplayArea  assignment (the display area where controls that are awaiting input or confirmation are found, see Inspect details of active Warehouse Management mobile app sessions – Supply Chain Management | Dynamics 365 | Microsoft Learn) and the InstructionControl reference for item ID, quantity, location confirmations.

Typically, controls without default values are positioned in the Primary Input Area, awaiting user input through scanning or manual entry. In the above example, the next empty control is LP (license plate) i.e. the licence plate to pick the goods from. These controls which require a user input are presented one after another following the order of controls in the “container” or the explicit Display Priority, if provided by the programmer of the warehouse menu item UI. This is perceived by the user as a series of screens; internally, it remains the same screen.

To determine the DisplayArea, the D365 core employs heuristics. Controls with default values slide down to the Info and Secondary Input Area, except for confirmation fields like Confirm Location, which appear in the Primary Input Area despite seemingly having a default value. The initial value is still empty, but the InstructionControl let the warehouse app present a hint from a different field and display it in italic (here: BULK-010).

Upon assigning values to all controls, the screen is considered complete, triggering the button in the Primary Action Area.

Control placement on the Warehouse Management app screen can be influenced through the WHSMobileAppServiceDecoratorRule class family. For instance, a control with a non-empty default value can still be prompted in the primary input area, as demonstrated in the below code snippet:

[SubscribesTo(classStr(WHSMobileAppServiceDecoratorRuleDefaultDisplayArea), staticDelegateStr(WHSMobileAppServiceDecoratorRuleDefaultDisplayArea, isTextInPrimaryInputAreaDelegate))]
public static void WHSMobileAppServiceDecorator_isTextInPrimaryInputAreaDelegate(boolean _enabled, Map _controlMap, str _data, WHSMenuItemName _menuItemName, EventHandlerResult _result)
   if (_enabled && _controlMap.lookup(#XMLControlName) == #MyControl)

It is important to remove (to be exact, not to rebuild after the last user interaction) such a control from the screen once it receives its input, otherwise it will be prompted repeatedly in an infinite loop.

The second example showcases a custom control with an InstructionControl reference for requesting confirmations while presenting a hint in italic:

final class WHSMobileAppServiceDecoratorRuleInstruction_Extension
   protected WHSMobileAppControlName getInstructionControlName(WHSMobileAppControlName _controlName)
      WHSMobileAppControlName confirmationControl = _controlName;
      WHSMobileAppControlName masterControl;
      masterControl = next getInstructionControlName(confirmationControl);
      if (confirmationControl == #MyControl)
         masterControl = #MyMasterControl;
      return masterControl;

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.


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:


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.