Auto-post inbound delivery notes in a batch

Auto-post inbound delivery notes in a batch

In order to register a manual or an OCR purchase invoice, the accountant should match the quantity against the delivery notes (en-us: packing slip) captured at the warehouse. But what if the inbound area is only equipped with mobile scanners? What if we do not have the carbon copy on hand, or just don’t care about the printed document at all? The shipment may be damaged or incomplete! Indeed, we should only pay for what we’ve physically received:
Register the actual quantity → Post the ‘Product receipt’ with that quantity → Match the invoice against the same → Claim the difference from the supplier, if any.

However, when registering the said delivery note against the purchase order with the Generate / Product receipt button or the respective periodic task, the user must provide the delivery note number as written by the supplier of the goods. This makes an automation with a batch job at the first glance impossible, because it requires human interaction.

Update product receipts

The automatic job Warehouse management / Periodic tasks / Update product receipts is the remedy. For every inbound load within the given constraints, it creates and posts a delivery note aka packing slip with the total registered quantity.
The inbound load does not necessary require any active management. The load may be…

  • Created manually out of the purchase order lines in the Load planning workbench
  • Imported from an ASN, but also
  • Added by the system automatically if the parameter Automatically create at purchase order entry is turned on


If the load is not confirmed, the Update product receipts will confirm it automatically first, then promote to the final status Received. The bogus delivery note number is like LOADID_N, where N is a running number. The quantity is the registered quantity versus the respective load line(s). It does not matter how the registration came about:

  • Mobile scanner PO line/item receiving or PO line/item receiving and put away
  • Mobile scanner License plate receiving or License plate receiving and put away [against an ASN]
  • Mobile scanner Load item receiving or Load item receiving and put away
  • Mobile scanner Mixed license plate receiving or Mixed license plate receiving and put away
  • the new simplified License plate receiving: license-plate-receiving-enhancements
  • the classic inventory Arrival journal
  • and last but not least, the classic Registration at the purchase order line level.

In essence, you just scan the last pallet of the PO and forget. At the end of the working day (or faster, depending on the batch job schedule) the system will process every In process load (i.e. where the receipt of at least one pallet has started) and make as many delivery notes as needed to update the purchase orders.

More on inbound loads

The only limitation is the use of the advanced Warehouse management processes at the warehouse, i.e. the inbound load may only be created at a WHS-enabled warehouse. More on inbound load handing here: https://docs.microsoft.com/en-us/dynamics365/supply-chain/warehousing/inbound-load-handling.

The recent features “Associate purchase order inventory transactions with load” and “Multiple product receipt postings per load” may be beneficial.

Number of records in D365

Number of records in D365

In Dynamics AX2012 there used to be a development tool to quickly count the number of records in all DAX tables: Ctrl-Shift-W, then Tools / Number of records:
Number of records Ax2012

This can be an interesting figure for data migration, measurement of the transaction volume, performance evaluation etc. A similar inquiry in Dynamics 365 for Finance / SCM can be executed in a multitude of ways:

The new grid

At the moment of this publication the grid is still in a preview and slightly defunct, but you can add a grouping into any D365 list and it is going to draw the number of rows inside: right-click a column, say Group by this column and get a counter in the group header:
Count by group in the New grid
The calculation is slow as all records must be loaded from the server into the form data source first. On 10k+ records this method becomes slow to the grade of full impracticability.

Export to Excel

This method works faster than any Data management entity export: press Ctrl-Shift-M to select all records (including invisible / not loaded), then Office button / Export to excel. The success message already gives a clear indication of the total of all records exported: “We finished your export of 6265 rows. The full export took 1.6 minutes.
Export to Excel
This works a way faster, but not the fastest.

Workspace tile

On a screen of your choice, apply a query if needed, then use Options / Add to workspace, then ConfigureShow count on the tile, then check the destination workspace:
Tile counter
This works fast and even provides a drill-down capability, but not techy enough.


Get entity record count

Navigate to Common / Common / Office integration / Excel workbook designer. This little known cockpit let you make magic self-refreshing Excels you can give out to the users. The tailored Excel templates have pre-configured columns and a Microsoft Dynamics Office Add-in conditioned to the current environment. Now look for the entity of your interest and press the sleek button Get entity record count:
Get entity record count
This is a super fast, smart and satisfying method, handicapped by the fact, that not every table in the system is an entity, but it comes the closest to the good old Number of records list.

What Item requirements can’t do

What Item requirements can’t do

This is kind of a recurring question: people have illusions about the Item requirements sales order type in Dynamics 365 for Finance and SCM.

First of all, in connection with a Fixed-fee project in D365 you may only open an Item requirement sales order. In one of the D365 versions they shortly enabled the classic Sales order but then quickly closed the ‘exploit’ (“Sales Orders may not be created for project type Fixed-price“), because a “classic” delivery note (en-us: Picking list) does not produce project transactions; the sales order would forever remain in the status Delivered and would never impact the project revenue. A project Sales order is only available on T&M projects where it can be billed directly.

Project management and accounting/Item tasks/Item requirements

Item requirements form

Pros and contras

A project sales order of the Item requirement type cannot be updated with an ordinary Delivery note but the special “Project – Delivery note” only. Then it produces a cost transaction to drive the project revenue recognition. Once delivered, the line immediately becomes “Invoiced” as if the sales price was zero. The support of Warehouse management had been added some time ago, and the shipment knows exactly which type of the delivery note to trigger upon confirmation of the load. This is what can be considered ‘good’ about the sales order type.

The list of the Item requirement sales order disadvantages is much longer:

  1. One cannot confirm an Item requirement sales order, I seriously can’t comprehend the reason. Order confirmations are not supported, you cannot liaise the delivery to your customer in a structured way.
  2. The user interface differs radically from the normal sales order, which is not well received by users and business owners.
  3. One cannot activate the Direct delivery mode at the IR sales order line level. Instead, you use the classic marking and open a purchase order through the Create purchase order button. Then you have to manually update the purchase order, choosing the customer’s address from the global address book and propagating it to the lines.
  4. Subsequently, a PO delivery note cannot update the sales order unless you affirm the “Consume items for a project…” prompt on posting. This however requires a 1:1 relation between a PO and SO which is not always given if the MRP planning is used: one purchase order may cover both project and non-project demands, and won’t become a Project purchase order. In such a case, the IR sales order delivery note must be posted manually.
  5. Similarly, Intercompany order chains are not supported.
  6. In the Warehouse management module, item requirements should not be consolidated in a load with “classic” sales orders as they may not be on the same delivery note. This is a subtle, nasty trap: in standard D365, a delivery note is posted per load = truck, not per shipment = order. There is an attribute, a flavour of the load whether it’s a ‘project’ load or a ‘normal’ load. In a mix of different sales order types this flavour cannot be right of course (see \Classes\WHSSalesPackingSlipPost): either one shipment or another is going to be posted wrongly or throw an error. Post the 2 delivery notes separately from the sales order screen, neither the load nor the shipment Delivery note button is going to work.
  7. Item requirements do not support multiple funding sources, i.e. multiple billing customers or changes of the customer account in the project contract. And no, the latest feature Allow sales orders for projects with multiple funding sources does not apply to the fixed-price project, try it: “Item requirement may not be created for a project associated to a contract with multiple funding sources“.
    The validation is dumb stupid, the 100% allocation in the funding rules to one or another funding source doesn’t bring any relief. You make this mistake only once; you may still gain access to your IR sales order through the normal sales list page or the Item tasks/Sales orders button, but processing the delivery of this sales order poses a serious challenge (unless you use Warehouse management). And no, you can’t remove the 2nd funding source anymore: Catch-22. You better delete the sales order and start all over.
  8. For the migration of historical orders, there is a special entity “Project item requirements“, and it is weak. It works at the line level and creates one SO header per project, i.e. you have no control over the Sales ID. Most of the sales order header attributes – delivery reason, sales taker, sales responsible etc. – are not available.
  9. Last but not least, non-stockable services are not updated properly by the “Project – Delivery note” and such a line remains in the Delivered status forever, the sales order as a whole will never be “Invoiced”.
    Update 28.07.2021: the issue 9 will go away if you activate the feature Enable creation of item requirement for non-stocked items: “Enabling this and turning on the ‘Create item requirement’ parameter will create an item requirement when creating a PO with non-stocked items.”

What can we do?

Not much:

  • Live with it.
  • Complain about it, but Microsoft has been aware for a long time.
  • Re-enable “classic”project sales orders on Fixed fee projects and programmatically enforce the “Item requirement-style” delivery note on those sales orders. This is not an easy development, but feasible in D365.