I’ve seen this error message crop up a few times. It occurs when you try to receive a Purchase Order in Receiving Transactions Entry and you are presented with the message below even though “Purchase Order Approvals” hasn’t been activated in the “Purchase Order Enhancement” module

As mentioned in several articles online it can be caused because a budget hasn’t been assigned in the “Commitment Setup” window for the year of the Purchase Order you are trying to receive against. Therefore if you go into “Commitment Setup” and assign a budget to the relevant year the issue is resolved. However, on some occasions I’ve found missing records in the commitment table causing the issue. (perhaps because several Purchase Orders have been raised whilst the Commitment Setup was missing a budget for that year)

At first I tried running “Checklinks” on the Purchase Order Enhancements tables via “Microsoft Dynamics GP > Maintenance > Purchase Order Enhancements” however when this failed I’ve fixed the issue by manually inserting data into the commitment tables based on data in the Purchase Order line table.

Just in case anyone else encounters the same issue I thought I’d share the script I’ve used.

INSERT INTO cpo10110 
            (ponumber, 
             ord, 
             actindx, 
             reqdate, 
             vendorid, 
             approvl, 
             committed_amount, 
             polnesta, 
             qtycance, 
             unitcost, 
             postedsubtotal) 
SELECT pop.ponumber, 
       pop.ord, 
       pop.invindx, 
       pop.reqdate, 
       pop.vendorid, 
       '1', 
       pop.extdcost, 
       pop.polnesta, 
       pop.qtycance, 
       pop.unitcost, 
       0.00 
FROM   pop10110 pop 
       LEFT JOIN cpo10110 poe 
              ON pop.ponumber = poe.ponumber 
                 AND pop.ord = poe.ord 
WHERE  pop.polnesta IN ( 1, 2 ) 
       AND poe.ponumber IS NULL   

As you can see this SELECTs data from the Purchase Order Line table (POP10110) and inserts into the Commitment tables (CPO10110) where its missing from the Commitment table (CPO10110).

As with any script that updates data please ensure you have a good backup of your data prior to running this. I’d also recommend testing this in a TEST company as well before implementing in the LIVE or production company.

Its also a good idea to just run the SELECT portion of the script in the first instance and see if it highlights the PO you are trying to receive against. If it does you can always investigate further, for example ensuring lines aren’t cancelled or checking if there definitely is a budget setup for the year of the purchase order. You also need to ensure the line item has a valid account number.

You can also adapt the script and change the WHERE clause so it just includes the POs you know to have the problem.

I hope this comes in handy for someone else in the future.

Thanks for reading

Background

As I’ve mentioned previously I mainly come from a Dynamics GP background. Recently I’ve been posting transactions in Dynamics NAV \ Dynamics 365 Business Central and trying to follow things through to the General Ledger entries as I try and piece together how the system works.

Why two G\L Registers?

When you post a transaction in Dynamics NAV\Business Central General Ledger Entries are automatically created. You can view these by looking at the G\L Register.

When posting a Purchase Invoice for an Inventory Item and viewing the G\L Register one thing stood out. Instead of one set of G\L Registers for the transaction there were two? Furthermore, one set of G\L registers had a Source Code of PURCHASES (G\L Register No 898) and the other set of G\L registers had a Source Code of INVTPCOST (G\L Register No 897)

Coming from a Dynamics GP background this seemed quite strange? I can see WHAT the system is doing, its splitting out the inventory postings, but I couldn’t understand WHY it was doing this? In Dynamics GP all the General Ledger distributions for this one transaction would have been posted and given one G\L Register No (or Journal Number in Dynamics GP) and one Source Code. (or Source Document in Dynamics GP)

So why two sets of General Ledger postings? Why not just post one set of General Ledger posting which included all the General Ledger distributions for this one transaction?

To test things further I posted a Sales Invoice for an inventory item and the same thing happened? Two sets of General Ledger posting and two different Source Codes:

One Conclusion

After playing around a little more it finally dawned on me why it could be splitting this one transaction out into two G\L registers, with two Source Codes, rather than making one posting like Dynamics GP.

There’s a setting in Inventory Setup called Automatic Cost Posting that you can switch ON or OFF. Throughout my testing this had always been ON.

However when I tested posting a Purchase Invoice with this switched OFF I found you don’t get any inventory related postings.

With the option switched OFF its only when you subsequently run the Post Inventory Cost to G/L batch job that the inventory postings are made.

So, in the case of my Purchase Invoice earlier, if Automatic Cost Posting had been switched OFF, only one G\L register with a Source Code of PURCHASES would have been posted.

Therefore, my assumption is that one of the reasons Dynamics NAV \ Business Central creates separate G\L Registers and Source Codes for transactions with Inventory is because the system might not immediately post the Inventory postings when you post the initial transaction. Depending on the Automatic Cost Posting setting it could post the Inventory part of the transaction hours, days or weeks later. (basically when the Post Inventory Costs to GL batch job is ran)

I still need to do lots more reading and studying on Inventory costing and Inventory accounting in Dynamics NAV\Business Central so in time I may see other reasons but for now this seems like one reasonable explanation.

If someone knows of other reasons, I’d love to hear them 😊.

Thanks for reading.