Dynamics 365 Business Central – Considerations for Document Date and Posting Date when posting Sales Invoices from a Sales Order

Introduction

A common conversation when showing users Sales Orders in Business Central revolves around the importance of updating the Document Date and Posting Date prior to posting the Sales Invoice from the Sales Order. In the early stages when going live with Business Central, it’s also a common mistake not to change these dates, which often leads to reconciliation issues and can potentially require corrections.

In this post I’ll go through why its essential those dates are updated if there is a delay from the time of creating the Sales Order, to Shipping and Invoicing. I’ll also point out some settings that can help prevent posting errors with dates, and other methods for posting Sales Invoices if users keep forgetting to change them causing issues with incorrect entries being posted.

The role of Document Date and Posting Date on a Sales Order

The Document Date and Posting Date are two key dates on a Sales Order. Let’s first look at each of these individually.

Document Date

The Document Date on the Sales Order is used as the Document Date of the Invoice when you post the Sales Invoice. It also determines the Due Date, which is calculated based on the payment terms specified in the Sales Order.

Posting Date

This date is used for the ledger entries that are created when you ship and/or invoice the Sales Order. For example it will be used on the G/L Entries, Customer Ledger Entries and also the Item Ledger Entries and Value Entries.

Now we know how important these dates are, let’s take a look at the common issue users encounter when posting Sales Orders.

The Common Issue – Defaulting Dates

When you create a Sales Order its not only the “Order Date” that defaults to your Work Date but also the “Document Date” and “Posting Date” (you can can change the behaviour of how the Posting Date defaults but more on that later 😊)

This creates a problem if there’s a time delay from the point of raising the Sales Order to the point when you will ship and invoice the Sales Order. When a delay occurs you must manually change the Document Date and Posting Date when you come to ship and invoice the Sales Order, or the ledger entries that are created will have the wrong dates.

Let’s look at this more closely with an example.

Walkthrough Sales Order to Sales Invoice

Here we have a Sales Order that was created on the 15th of August. As you can see the Order Date, Document Date and Posting Date all reflect the 15th of August.

Let’s say we are waiting on more stock of this item, and therefore we aren’t ready to deliver this item on the day of the Sales Order. Then, a few weeks pass, the goods arrive at our location, and we are ready to ship and invoice the Sales Order.

Although my Work Date in Business Central is now the 29th of August (two weeks after the Sales Order was created), the Document Date and Posting Date remain set to the 15th of August when I created the Sales Order. As a result, it’s easy to ship and invoice the Sales Order without remembering to update the dates, as shown in the demonstration below.

As you can see below the Posted Sales Invoice has the incorrect Document and Posting Date of the 15th of August

Therefore, if we were to look at the ledger entries we’d see they were incorrect, as they have posted with the date of 15th of August rather than the 29th of August.

Some Sales Setup options to help

There are built in features to help mitigate these errors. These are located in the “Sales and Receivables Setup” page and are highlighted below

Lets go through each one in turn:

Option 1: Posting Date Check on Posting

With this option selected the user will be warned when posting the Sales Order if your Work Date differs from the Posting Date. For example, I’d receive the message below if I’d have tried to post a Sales Order with a date of the 15th of August while having a work date of the 29th of August

Option 2: Default Posting Date

With this option selected the Posting Date is left blank meaning it must be populated prior to posting. If you try and post without a posting date you are presented with the following error:

Forcing the user to enter the correct date should help reduce errors

Option 3: Link Doc Date to Posting Date

I’ve included this one because it can be used in conjunction with the second option. For example, when this option is selected and you change the Posting Date on the Sales Order, the Document Date automatically changes as well.

This is demonstrated below where the Document Date is automatically updated when I populate the blank Posting Date

This means that by being forced to change the Posting Date, because its blank, I’m automatically changing the Document Date 😊.

Some Invoicing Alternatives

Another option might be to Invoice using the “Sales Invoice” page rather than from the Sales Order.

When using the Sales Invoice page, the invoice is created based on your Work Date, reducing the likelihood of errors with the Document Date and Posting Date. This method also offers additional functionality, such as the ability to consolidate multiple Sales Orders (or more accurately, Shipments) into a single Sales Invoice.

You can also use the “Combine Shipments” feature which gives the option of entering a Posting Date which is defaulted from the Work Date.

Both of these options require you to have posted the Sales Shipment as the “Sales Invoice” using the “Get Shipment Lines” feature to invoice Sales Orders and the Combine Shipments also looks at Shipment Lines from Sales Orders.

Conclusion

This post goes through how important the Document Date and Posting Date are on a Sales Order and how to avoid pitfalls of posting with them set incorrectly.

It outlines a couple of standard features you can use to prevent those errors and also how other features such as invoicing from a Sales Invoice rather than the Sales Order might be more useful in some cases.

Thanks for reading!

Dynamics 365 Business Central – Using a Negative Quantity on a Sales Order to Return Items

I ran into a situation recently where a user had shipped some goods from a Sales Order, which had subsequently been returned prior to the Sales Order being Invoiced. This led me to discover an interesting way to return the goods, and then invoice the Sales Order all at the same time.

After some testing I realised they could add a negative line for the same item, and ship and invoice this all at the same time.

The exact situation and steps I took are described below.

Below is a Sales Order that has a quantity of 10 that have been shipped:

Prior to invoicing this the client has returned 2 therefore I’ve reopened the Sales Order and added an additional line item for -2 for the same item.

I can now Ship and Invoice all the lines which will return 2 into my inventory and also only invoice a total of 8.

If I now check my Item Ledger Entries I can see both entries for this item. There’s a negative 10, as we originally shipped 10, and a positive 2 for the items returned.

I tested this with and without different location settings such as “Require Warehouse Receive” and “Require Warehouse Shipment” and it seems to work fine. I didn’t test it with full WMS switched on and I suspect it may hit problems there.

Thanks for reading!

Dynamics NAV – The Warehouse Request does not exist when posting an Inventory Pick

I recently came across the following error when trying to post an Inventory Pick in Dynamics NAV 2018

On investigation this is being caused because although the Inventory Pick had been created from the Sales Order, the Sales Order had subsequently been shipped and invoiced directly from the Sales Order screen rather than via the Inventory Pick. (this surprised me as I assumed the system would prevent the Sales Order from being shipped and invoiced from the Sales Order if an unposted Inventory Pick existed for it)

For clarity, as I understand things when a location has the “Require Pick” option ticked in the location setup (important to note “Require Shipment” isn’t ticked) the usual process for shipping and invoicing a Sales Order would be:

  1. Create the Sales Order.
  2. Release the Sales Order.
  3. Create the Inventory Pick in a push or pull fashion from the Sales Order.
  4. Post the shipment from the Inventory Pick.
  5. Post the Invoice from the Sales Order.

It seems that somewhere between point 3 and 4 someone had opened the Sales Order and clicked “Post” and selected “Shipment and Invoice” even though the Inventory Pick was still unposted.

On investigation this removes the internal “Warehouse Request” from the warehouse request table and when you try and post the Inventory Pick you are presented with the error “The Warehouse Request does not exist”.

As far I can see the only option here is to delete the Inventory Pick as it can’t be progressed. (I also assume the goods have been shipped)

I’ve tested this same process on a version of Dynamics 365 Business Central and it seems to prevent the Sales Order being shipped and invoiced if an Inventory Pick exists for it. When you do try you get the message below:

This does make more sense to me, I’m just surprised Dynamics NAV doesn’t prevent it.

As with all issues I did learn something new and also had fun looking at the importance of the internal Warehouse Request with all this. This is something I’m hoping to look at it more depth in future.

Thanks for reading!