Dynamics NAV\Business Central – Review of Location settings – Require Receive \ Require Put-away \ Put-away worksheet

Background

Recently I’ve been testing the various setting on the location and how this affects the processes and steps involved in the receiving and putting away of inventory.

The settings I’ve been paying particular attention to are “Require Receive“, “Require Put-away” and “Put-away Worksheet“.

The different options and combinations you have selected affects how you process the receiving and putting away of the inventory, and which documents are used.

I’ll detail each of these below and each one assumes you have the “Bin code required” option selected as well.

Important note:- while learning and researching this subject I found this excellent post by Olof Simren which goes into great detail on this subject. http://www.olofsimren.com/processing-of-receipts/. This is a truly awesome post that I would highly recommend reading. The post is really well written and easy to understand, and at first it put me off writing this blog, as it covers things so well that I didn’t want it to appear like I was just repeating this information. However I decided to go ahead as the primary purpose of my blog is to assist in my learning and understanding of Dynamics NAV and Business Central, and writing things up really helps me. Of course if others find it useful as well then that is always a massive bonus 🙂

Location Setup

Firstly, the options I’m referring to can be selected on the “Location” page as per below:

Require Receive

If you just have the “Require Receive” option switched on then you are stating that a Warehouse Receipt document should be posted to receive the inventory.

You can create a Warehouse Receipt document in either a push or pull fashion. i.e. you can go to “Warehouse Receipt” and recall the Purchase Order into the Warehouse Receipt or alternatively you can create the Warehouse Receipt from the Purchase Order using the option below:

After posting the Warehouse Receipt the goods are recorded in the Inventory and both item ledger and warehouse entries are created.

Therefore when just using the “Require Receive” on its own the process of recording inventory is as follows:

  1. Create and release Purchase Order.
  2. Create and post Warehouse Receipt.

An advantage of using this method is the ability to pull, and therefore receipt, more than one Purchase Order at once.

One limitation of using this method is you can’t easily record the inventory in more than one bin for the same line while receiving. (i.e. if you wanted to put the inventory into more than one bin for the same line item you’d have to be creative and re-open the Purchase Order and split the line and then use the Warehouse Receipt to receive)

** Please note during my testing I’ve found that although the option “Require Receive” is ticked ON you can still post the receipt from the Purchase Order by clicking “Post > Receive”

Require Put-away

If you just have the “Require Put-away” option switched on you are stating that you must first put-away the goods via a Inventory put-away document. You can create an Inventory Put-away in either a push or pull fashion. i.e. you can go to Inventory Put-away and recall the Purchase Order onto the Inventory Put-away or alternatively you can create the Inventory Put-away from the Purchase Order using the option below:

After posting the Inventory Put-away the goods are posted into inventory and both item ledger and warehouse entries are created.

Therefore when just using the “Require Put-away” on its own the process of recording inventory is as follows:

  1. Create and release Purchase Order
  2. Create and post Inventory Put-away

One benefit of using the Inventory Put-away is you can “split line” to record the inventory in more than one bin.

One limitation with Inventory Put-aways is you can only process one purchase order at a time. As you see below the Purchase Order number is stored on the header of the Inventory Put-away thus restricting the lines to one Purchase Order:

** Please note that as with the “Require Receive” option I’ve found that although the option “Require Put-away” is ticked ON you can still post the receipt from the Purchase Order by clicking “Post > Receive” thus bypassing this option. However this is mentioned as expected behaviour in this Microsoft document https://docs.microsoft.com/en-gb/dynamics365/business-central/warehouse-pick-items i.e. the snippet below is taken from that document

Require Receive and Require Put-away

When you have both the “Require Receive” and “Require Put-away” options ticked in combination you must now complete a two step process before the inventory is available. The first step is to create and post a Warehouse Receipt, which records the inventory in a receiving bin, and posts Item Ledger and Warehouse Entries. On posting the Warehouse Receipt a Warehouse Put-away is automatically created which enables you to register the movement of the inventory from the receiving bin to another bin, which then makes the inventory available. (this part posts additional Warehouse Entries)

Therefore when just using the “Require Receive” and “Require Put-away” together the process of recording inventory is as follows:

  1. Create and release the Purchase Order.
  2. Create and post a Warehouse Receipt. (automatically creates Warehouse Put-away)
  3. Register the inventory using the Warehouse Put-away

An important thing to note here is we are now using the “Warehouse Put-away” rather than the “Inventory Put-away” which means we can process more than one Purchase Order at once. (i.e. if the warehouse receipt we posted had more than one Purchase Order a “Warehouse Put-away” would be created for all Purchase Orders)

** Please note as with the previous configuration I found i could still post the receiving of the inventory from the Purchase Order as long as the bin code was populated on the purchase order line.

Require Receive \ Require Put-away \ Use Put-away Worksheet

With all three options ticked in combination you first create and post the “Warehouse Receipt” however posting the “Warehouse Receipt” doesn’t automatically create the “Warehouse Put-away“. You use the “Put away worksheet” to recall the “Warehouse Receipt” and then create a “Warehouse Put-away“.

Therefore when using the “Require Receive“, “Require Put-away” and “Use Put-away Worksheet” in combination the process of recording inventory is as follows:

  1. Create and release the Purchase Order.
  2. Create and post the Warehouse Receipt.
  3. Use Put-away Worksheet to create a Warehouse Put-away.
  4. Register the inventory using the Warehouse Put-away.

** Please note I also found even with all three of the options switched on I could still post the receiving of inventory from the Purchase Order as long as the bin code was populated on the purchase order line.

Conclusion

Interestingly in every scenario I could bypass the processes by simply posting the receipt directly from the Purchase Order. I found the only way the system forces you to follow the warehouse processes is when “Directed Put-away and pick” is switched ON on the location. I’d be interested to know if i’m missing something here or if this is expected behaviour as i do find this a little surprising.

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!

Dynamics 365 Business Central – Error drilling back to the Purchase Order from a Sales Order drop shipment

I recently ran into an issue drilling back on a Purchase Order from a Sales Order with drop shipment lines. The exact error was “Purchase Order No. must have a value in Sales Line…….It cannot be zero or empty” as shown in the screen shot below:

Purchase Order No. must have a value in Sales Line

On investigation this only affected the lines on the Sales Order that had been shipped and invoiced. If I drilled back on an outstanding line on the Sales Order the Purchase Order is displayed without issue. After troubleshooting this it seems when you receive and invoice the line item on a drop shipment the system removes the link back to the Purchase Order and consequently you receive an error trying to drill down.

I’ve detailed how you can recreate the issue below, with a neat trick that can be used to view the data in the Sales Order tables via your browser.

To recreate the error first add a Sales Order with more than one drop shipment line as per below:

Sales Lines marked as Drop Shipment

Next create the Purchase Order and pull through the Sales Order using the function below

Function to Get Sales Order lines

Finally go back to the Sales Order and ship and invoice the first line

The first line has been shipped and invoiced

Now highlight the first line and try and drill back to the Purchase Order using the option below

On doing this you are prompted with the error

Purchase Order No. must have a value in Sales Line

Using the information detailed in this Microsoft article we can view the actual data even though this is the SaaS version of Business Central and I have no access to a development environment https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-view-table-data

Therefore following this document I added &table=37 to the end of my URL to view the full contents of the Sales Line table

On viewing the data in the table I can see the Purchase Order Number has been removed from the shipped and invoiced line

Purchase Order No. and Purch Order Line No. removed once shipped and invoiced

This is preventing me from drilling back on the Purchase Order. If you check the Purchase Line table (table 39) you can see the Sales Order number has also been removed, so you wouldn’t be able to drill down on the Sales Order from the Purchase Order either.

I also worked through the issue on my local Dynamics NAV install and observed the same behaviour, therefore I’m sure this is by design, however I’m unsure of the reasons. It seems the link to the Purchase Order is permanently removed once the sales line has been shipped and invoiced.

I also checked table 113, which is the Sales Invoice Line table, but this also doesn’t seem to keep the link back to the purchase order.

I’d be interested to know if I’m missing something here. Perhaps there is a way to get back to the Purchase Order from the sales document once its been posted. If there is I’d be very grateful if you could let me know.

Thanks for reading

Dynamics 365 Business Central – A quick walk through a Payables Payment Run using Payment Journals

Introduction

Over the last few days I’ve been working through a vendor payment run in Dynamics 365 Business Central and thought it useful to document my journey.

In this step by step post I’ll be generating payments using the “Suggest Vendor Payments” feature and then also going through the process of removing an invoice from a payment as you would in real life.

Setup

To keep things simple before I started I created two vendors, V00080 and V00090, and posted a couple of documents on each vendor. I’ll use these as the basis for my walk through.

On the vendor I set the “Payment Method” as “Cheque” as per below (I’ll likely look at another post for EFT\BACS in the future)

Setup of one of the Vendors I created for my walk through

The documents I posted onto the vendors created the following vendor ledger entries which I’ll be working with:

As you can see I have two invoices on vendor V00080 with a total of £180.00 and two invoices and one credit note on V00090 giving a total of £240.00.

Payment Journal

In order to pay these documents I’ll be using the “Payment Journal” which can be found by clicking the search option and typing “Payment Journal”

Once in the “Payment Journal” page the first thing to select is the batch. As you can see I’ve selected one called PAYMENTRUN


If we drill down on the batch you can see it determines the balancing account and also the number series to use. I’ve select “Bank Account” as the balancing account so the system will create “Bank Account Ledger Entries” that I can later reconcile via the bank reconciliation.

Once we have decided on the batch we can turn to creating the payments.

Suggested Vendor Payments

The process that completes the initial swoop looking for transactions to pay based on a set of criteria is “Suggest Vendor Payments”

On clicking “Suggest Vendor Payments” you are presented with the following options

I’ll focus on the ones I’ll be using as part of my payment run for vendors V00080 and V00090

Last Payment Date:- This is the due date cut off. I’m going to set this to 31/07/19 as I don’t want to pay any invoices after this date.

Find Payment Discounts:- I’m going to switch this on because if there are any payment discounts, I want the payments that are created to reflect them.

Summarise per Vendor:- I’m going to switch this on because I only want to create one payment journal entry per vendor rather than one entry per invoice I’m paying.

Posting Date:- I’m going to set this to 14/08/19 as this is the date I’ll be paying the invoices.

Balance Account Type:- I’m going to set this to “Bank Account” as I want the system to create bank account ledger entries so I can reconcile the payment via bank reconciliation.

Bal Account No:- I’m selecting “CHECKING” as this is the bank I’ll be paying from.

Payment Type:- I’m selecting “Computer Cheque” as on this occasion I’ll be printing cheques.

Vendor No:- I’ll be entering a range of V00080..V00090 as I only want to pay those two vendors

Therefore my options are:

When i click OK I get the following payments generated for me.

Now the system has generated the payments we can go ahead and tweak them for what we actually want to pay.

Editing the Payments

As you can see the system has generated a Payment for Vendor V00080 of £60.00 and a Payment for Vendor V00090 of £240.00

To view the invoices that have been applied on the payment you click “Process > Apply Entries”

If I select this option on the payment of £60.00 on Vendor V00080 you can see the invoices applied:

As you can see above the system has applied INV00002 but hasn’t applied INV0001. This is because INV0001 has a due date of 01/08/19 which falls outside of the due date cut off I entered into the “Last Payment Date” field in the “Suggest Vendor Payments” window. I’m happy with this so I’ll click ok and move to the next payment.

If I highlight the payment for Vendor V00090 and click “Process > Applied Entries” I get the following screen:

The first thing to note is the system has included the credit memo on the payment run. This is great and exactly what I’d expected.

Next I’m going to remove INV90001 from the payment run as I’m not ready to pay this Invoice just yet. To do this I’ll highlight the line and click “Process > Set Applies-to-ID”. Doing this blanks out the “APPLIES-TO-ID” field and also sets the “AMOUNT TO APPLY” and “APPLN. AMOUNT TO APPLY” to £0.00 on the invoice as per below

This all seems fine however when you click OK it would appear the payment amount hasn’t been updated on the Payment Journal to reflect the change I made?

It would seem I have to manually update this or the system would still post a payment for £240.00 onto the account. i.e. the posted payment would remain open and there would be an amount remaining of £30.00 on it.

I therefore edit the payment amount on the header to £210.00 to reflect the new payment amount:

Printing the Cheques

To print the cheques you just need to select “Cheque > Print Cheques”

On clicking this option you are presented with the following options:

I’m going to leave all the defaults and click “Print” and select my printer.

After doing this the flag “Cheques Printed” is checked.

Posting the Payments

Once you have printed the cheques and are ready to post you can just click “Post\Print> Post” as per below

This will create the Vendor Ledger Entries and also Bank Account Ledger Entries as our “Balancing Account Type” is set to “Bank Account”.

If I now view the “Vendor Ledger Entries” I can see the payments have been posted and applied to the invoices.

Conclusion

I hope you have found this write up on the payment run useful. I’m sure I’ve left out some options that can be used and being new to the Dynamics 365 Business Central \ NAV world I’d be very interested to hear of other peoples experiences.

Thanks or reading.

Dynamics NAV \ Business Central – “The Posting Date is not within your range of allowed posting dates” when posting a Purchase Invoice

Introduction

You receive the message “The Posting Date is not within your range of allowed posting dates” when trying to post a Purchase Invoice in Business Central.

According to the user setup the “Posting Date” of the document I’m posting is within the allowed posting range so why won’t the system allow me to post it?

Background – Value Entries

To provide a little more detail I’m trying to post a Purchase Invoice that I’ve matched to a Posted Purchase Receipt and I’ve increased the Unit Cost on the Purchase Invoice as the price has changed since the goods were received. I’ve also sold the items on a Sales Invoice before I’ve tried posting the Purchase Invoice.

Therefore, if we look at the value entries of this item prior to attempting to post the Purchase Invoice they are as follows

We have a value entry for the Posted Purchase Receipt showing a date of 12/05/2017 and a “Cost Amount (Expected)” of £10.00 (this the amount I used when posting the Purchase Receipt)

We also have a value entry for the Sales Invoice showing a Posting date of 25/05/2017 and a “Cost Amount (Expected)” of £10.00.

Details of the Purchase Invoice

The Purchase Invoice I’m posting is dated 01/06/2017 and I’ve amended the Unit Cost from the original £10.00 that pulled through from the Posted Purchase Receipt to £12.00


Now when I try and post this transaction, I receive the message

Therefore, just to confirm the Posting Date of the Purchase Invoice is within my allowed posting dates below is a screen shot of the User Setup window showing my Allow Posting Dates

The dates are also within the General Ledger allowed posting dates as shown below

Therefore, at first glance its not apparent why the system isn’t allowing me to post this document? The Purchase Invoice posting date is 01/06/17 and this is within my range of allowed posting dates?

The Issue – Automatic Cost Adjustment and Adjust Cost Item Entries

When posting the Purchase Invoice, the system has detected that the cost has changed from the Posted Purchase Receipt, and as this has been sold on a Sales Invoice, the cost of goods sold need adjusting.

The system therefore tries to post an adjustment using the Posting Date of the entry its adjusting (in this case the Sale Entry on the 25/05/17), which is in May, and as this falls outside of my posting range I receive the error “The Posting Date is not within your range of allowed Posting Dates”.

** Please note there is a complex method for selecting the Posting Date if the Posting Date of the entry being adjusted also fell outside of the “Allowed Posting Dates” of the General Ledger and also if “Inventory Periods” are being used. More information on this can be found in this Microsoft document https://docs.microsoft.com/en-us/previous-versions/dynamicsnav-2016/dn948192(v=nav.90)

** Its also worth noting I’m getting this message when posting the Purchase Invoice because the option “Automatic Cost Adjustment” is set to “Always” in Inventory Setup. This means the system checks for cost adjustments when you post the transaction. If this wasn’t set to “Always”, then depending on its setting its possible the document would post however when the “Adjust Cost Item Entries” batch job was subsequently run the error would occur.

See below for my Inventory Setup

Solution

There are two possible solutions to my issue here. The first is to change my “Allowed Posting Dates” in the “User Setup” to 25/05/2017 through to 30/06/2017. This will then include the posting date of the entry that will be adjusted.

Alternatively, I could change the “Allowed Posting Dates” in the General Ledger Setup to 01/06/2017 through to 30/06/2017. Then, as per the article I linked to, the system would use the date of 01/06/2017 for the adjustment entries, (i.e. the first open date in the General Ledger Setup) which does fall in my allowed periods to post to.

Therefore I’ll change my “Allowed Posting Dates” in the User Setup as per below

And now when I post the Purchase Invoice this is succecssful

If I now view the Value Entries you can see the adjustment entry created with a Posting Date of 25/05/17.

Conclusion

Although this is a simple example it shows why you may encounter this error when it seems the postings date configuration on the User Setup should allow a document to post.

Thanks for reading

Dynamics NAV \ Business Central – Expected Costing with Purchasing Transactions

Background

Within Dynamics NAV \ Business Central you can switch Expected Cost Posting to G/L both ON and OFF via the option below in Inventory Setup.

In this post I’ve been playing with this feature to see how things work and how the various postings differ to Dynamics GP. I also take a look at how the Value Entries in Inventory play a pivotal role in this. I end by taking a closer look at the SQL tables involved and how things fit together.

Expected Costs in Dynamics GP

When you receive goods via a Shipment transaction in Dynamics GP a Purchase Accrual is automatically created to a General Ledger accrual account to record the expected cost in the General Ledger. This account is generally taken from the Creditor Card as per below:

Dynamics GP – Creditor Account Maintenance

The opposite debit entry is taken from the Inventory Item card as per below:

Dynamics GP – Item Account Maintenance

Let’s add a Purchase Order Shipment transaction in Dynamics GP and see this in action:

Dynamics GP – Receiving Transaction Entry

As you can see from the screen shot above, I’m receiving one Inventory item, and this has created an accrual distribution crediting the 000-2111-00 accrued purchases account I specified on the creditor card. The balancing debit side is to the Inventory code that we specified on the Inventory Item card.

Now let’s see what happens when we invoice the Shipment:

Dynamics GP – Purchase Invoice Entry

Just as expected the accrual is reversed via a Debit entry to the 000-2111-00 accrued purchases account and the accounts payable is credited. Therefore, the balance in the accrual account is now nil.

There’s no way to disable this behaviour in Dynamics GP. When you post a “Shipment” for some Inventory Items General Ledger entries are always created. (however you can prevent the entries posting through to the General Ledger via the Posting Setup)

Expected Costs in Dynamics NAV \ Business Central

Before we look at Expected Costing in Dynamics NAV \ Business Central we first have to take a step back and look at the various inventory entries that are created when you post inventory transactions.

When you post an inventory transaction in Dynamics NAV \ Business Central the system creates a minimum of two inventory entries: an Item Ledger Entry and a Value Entry. The Item Ledger Entry records the change in quantity and the Value Entry records the change in inventory values. For the purposes of this post we just need to know that when posting Purchase receipts Value Entries are created for Expected Costs, and when you post Purchase Invoices, Value Entries are created for Actual Costs, and Expected Costs are reversed.

Expected Cost Posting to G/L – Switched ON

Unlike Dynamics GP you can switch ON and OFF accrual postings in Dynamics NAV \ Business Central via the Expected Cost Posting to G/L option in Inventory Setup. When you switch Expected Cost Posting to G/L ON interim accounts are used to post the accrual and inventory entries for Purchase receipt transactions.

The equivalent Dynamics GP accrued purchases account is called Invt. Accrual Acc. (Interim) and is specified in the General Posting Setup window and is selected based on the Posting Groups used on the Item and Creditor. (see my previous post for more details on the posting groups). I’ve highlighted this below

Dynamics NAV \ Business Central – General Posting Setup

The Inventory code for the debit side of the transaction is taken from the Inventory Posting Group and again is based on the combination of posting groups used. I’ve highlighted this below

Dynamics NAV \ Business Central – Inventory Posting Setup

The key difference here is Dynamics GP doesn’t use an interim Inventory account whereas Dynamics NAV \ Business Central does.

In my Cronus demo data, the option Expected Cost Posting to G/L is currently switched ON so let’s see how this works when I create a Purchase Order for an Inventory item and receive it.

Here’s my Purchase Order and after clicking Post I’m going to choose receive so I receive the items into the Inventory:

When I view the item I can see this has created the following Value Entry (Number 454) which shows the Cost Amount (Expected) and Expected Cost Posted to G/L both populated.

If I highlight the Value Entry and click Navigate > General Ledger I can see the G/L Entries associated with the Value Entry

As expected, we can see the 5510 Accrual account is being credited and the debit entry is posting to the 2111 “Interim” Inventory code.

Now let’s invoice the purchase order and take a look at the G/L entries. First I click Post and select Invoice on the Purchase Order. (Incidentally if I were to select Receive and Invoice the system recognises I’ve already received the items. It doesn’t receive them again)

This has created the a new Value Entry (Number 455) . There’s a few things to note here. Firstly the Cost Amount (Expected) and the Expected Cost to G/L have been reversed. Secondly the Cost Amount (Actual) and Cost Posted to G/L have been populated.

Again if I highlight the Value Entry and choose Navigate > General Ledger we can the G/L Entries associated with this Value Entry.

As you can see the original entries created via the Purchase Receipt have been reversed by posting a debit to the 5510 Inventory accrual account and a credit to the 2111 Interim Inventory account. The system has then posted new entries to the 2210 Resale items inventory account (debit) and the direct cost applied account (credit). (for more info on the direct cost applied account see my previous post).

So that’s it. Although there are a few extra distributions to Dynamics GP everything makes sense. Its also apparent that the Value Entries have a direct relation to the G/L entries that are created.

Expected Costing to G/L – Switched OFF

Now let’s see what happens when we post a Purchase Receipt with the Expected Cost Posting to G/L switched OFF. First I switch the option OFF and then create and post the Purchase Receipt

This has created the following Value Entries (Number 456)

The key thing to note here is that although the Cost Amount (Expected) is populated the Expected Cost Posted to G/L isn’t. This means no G/L Entries have been created. To prove this click Navigate > General Ledger to view any G/L Entries

Let’s now invoice the Purchase Order and see what happens:

This has created the following Value Entry

This Value Entry records the Cost Amount (Expected) being reversed and the Cost Amount (Actual) and Cost Posted to G/L are also populated. Therefore we get the following G/L Entries

As expected no expected cost postings have been created or reversed for this transaction.

Bonus – G/L Item Ledger Relation and Post Value to G/L SQL tables

An unexpected bonus of writing this post was the chance to geek out on some of the Dynamics NAV tables. Unlike Dynamics GP, I don’t have much of a grasp of the SQL tables in Dynamics NAV however while going through the various scenario’s I was curious about how a couple of things worked which encouraged me to dig a little deeper.

The first thing was how I was able to drill down on the G/L Entries from the Value Entries screen? This meant there must be a direct or indirect relationship between the tables.

After some digging I found the link was via the G_L – Item Ledger Relation table. Therefore writing the SQL query below enabled me to join the G/L Entries and Value Entries table to see all the details for Value Entry Number 455

The next thing I was curious about was what would happen if the Expected Cost Posting to G/L was switched from OFF to ON when there were lots of Purchase Receipts that hadn’t yet been invoiced?

I found the answer to this question lay in the two prompts you receive when you switch Expected Cost Posting to G/L from OFF to ON (or ON to OFF). Below are the two messages you get when toggling the setting

Dynamics NAV \ Business Central – Inventory Setup

As per the first message it seems when you switch the option Expected Cost Posting to G/L ON the system determines if the Actual Costs for the Purchase Receipt have been posted and if not a record is written for that Value Entry to the Post Value Entry to G_L SQL table. This has a link back to the Value Entry so the system knows to create the Expected Cost interim postings for this Value Entry.

To show this in action, I switched the Expected Cost Posting to G/L option OFF and queried the SQL table:

SQL Query on Post Value Entry to GL Table

As per the image above the SQL table is currently blank.

I then created a Purchase Order and received it as per below:

Dynamics NAV \ Business Central – Purchase Order

After posting this I queried the Post Value Entry to G/L SQL table again to see if any new rows had been added and the table was still blank

SQL Query on Post Value Entry to GL Table

I then checked the Value Entry for my receipt and as per the screen shot below the Cost Amount (Expected) is populated but the Expected Cost Posted to G/L is blank. As this is only the Purchase Receipt the Cost Posted to G/L is also zero.

Dynamics NAV \ Business Central – Value Entries

I then went back to Inventory Setup and switched Expected Cost Posting to G/L back ON and clicked YES to the prompt and now when I check the Post Value Entry to G/L table its populated as per below

SQL Query on Post Value Entry to GL Table

After toggling the Expected Cost Posting to G/L option to ON the system has determined that this Value Entry has no G/L Entries for the Expected Costs and has inserted a record into the Post Value Entry to G_L table with a direct link back to the Value Entry that was created when I posted my receipt.

Now if I run the Post Inventory Cost to G/L batch job as instructed in the second message G/L entries are created for the purchase receipt, the SQL table is cleared, and the Value Entry is updated. See below:

The report output of the “Post Inventory Cost to G/L” shows entries have been created:

Dynamics NAV \ Business Central – Post Inventory Cost to G/L

Below are the expected cost General Ledger entries created to the interim accounts. (in my previous example these were created immediately because I had Post Expected Costs to G/L switched ON)

Dynamics NAV \ Business Central – General Ledger Entries

And finally the Expected Cost Posted to G/L field on the Value Entry has been updated to show the General Ledger entries have been created and posted.

Dynamics NAV \ Business Central – Value Entries

If I now check the Post Value Entry to G_L table in SQL I can see its been cleared.

Incidentally if I were to switch OFF Expected Cost Posting to G/L before running the Post Inventory Cost to G/L batch job the SQL row is removed from the Post Value Entry to G_L table.

Conclusion

In conclusion I find the way Dynamics GP deals with expected costs to be a much more conventional and simple approach however there’s no doubting that Dynamics NAV \ Business Central gives more flexibility.

Although I don’t know much about the inner workings of Dynamics NAV \ Business Central it also seems to me that G/L Entries are created based on the Value Entries.

In another post I hope to look at how Expected Costs work with Sales Shipments and Sales Invoices.

Thanks for reading.

Dynamics NAV \ Business Central – Thoughts on the Direct Costs Applied and Purchases Accounts

Background

One thing I’ve noticed when posting Purchase Invoices with Inventory items in Dynamics NAV \ Business Central are the additional distributions to the Direct Cost Applied and Purchases accounts?

I’ve never been quite sure what the Direct Cost Applied account is, and when I’ve looked into it, I can’t find much information out there either. While researching for a previous post (here) a theory struck me for why the system might be posting to this account. Therefore, in this post I’ll detail my thoughts as to why Dynamics NAV \ Business Central posts to the Direct Costs Applied and Purchases accounts when posting Purchase Invoices using Inventory Transactions.

Purchase Invoicing in Dynamics GP

Firstly, I’ll go back to my roots – let’s see what distributions Dynamics GP creates when posting a Purchase Invoice with an Inventory Item. In this example we are receiving the Item and posting the invoice at the same time. Dynamics GP calls this a Shipment \ Invoice.

Dynamics GP – Shipment\Invoice Distributions

As you can see the distributions created are as follows:

Debit: Inventory

Credit: Accounts Payables

Debit: VAT

This would also create one General Ledger Journal in Dynamics GP (G/L Register is the NAV\BC equivalent) with one Source Document (Source Code is the NAV\BC equivalent).

I’m not an accountant but this makes sense to me. We bought something for £6 so we have a Credit postings to Accounts Payables. We have increased our Inventory so we have a £5 Debit to Inventory, and finally a Debit to VAT.

As this is not an expense invoice there are no P&L implications at this point. We will have Cost of Goods Sold postings when we sell the item.

Purchase Invoicing in Dynamics NAV \ Business Central

When I post a Purchase Invoice for an Inventory Item in Dynamics NAV \ Business Central the distributions created are below. (*Please note I have Automatic Cost Posting switched ON in Inventory Setup)

General Ledger Entries – Purchase Invoice – Automatic Post to GL switched OFF

There’s a couple of things to note here. Firstly, there are two more distributions when compared to Dynamics GP. We have distributions to the Direct Cost Applied account (7191) and the Purchases account (7110). Secondly, some GL Entries have a Source Code of PURCHASES and others have a Source Code of INVTPCOST.

Why the extra distributions?

If we dig deeper and go to the G/L Registers for this Purchase Invoice we can see the system has created two separate G/L Registers.

This G/L Register for the PURCHASES portion of the transaction:

G/L Register for PURCHASES

And this G/L Register for the INVPTCOST portion of the transaction

G/L Register for INVPTCOST

The system has created two G/L registers because in Dynamics NAV \ Business Central you can defer the INVPTCOST portion of the GL postings via the “Automatic Cost Posting” option in the Inventory Setup.

Because of this each of these separate G/L Registers needs a balancing entry in order for the debits and credits to balance and the posting to work. In the case of the PURCHASES G/L Register of the transaction the 7110 Purch, Retail account is used and for the INVPTCOST G/L Register the 7191 Direct Cost Applied account is used.

One Possible Conclusion

Based on these findings one theory I have for the postings to the Purchases and Direct Costs Applied accounts when dealing with Inventory Items is to accommodate the Automatic Cost Posting option in the Inventory Setup. (the ability to defer the posting of the Inventory portion of the transaction). It could also be because for other aspects of the costing engine that I haven’t delved into yet.

If this option didn’t exist, and Inventory postings were always posted in real time, I can’t see why there would be a need to post to these additional accounts.

This is just an observation. I have no clear evidence to back this up. I’m just a Dynamics NAV \ Business Central newbie wondering why this works differently to Dynamics GP.

Above all I’m here to learn so if there are other reasons for the additional distributions I’d love to hear them.

Thanks for reading