Dynamics 365 Business Central – Message “There is nothing to post because the journal does not contain a quantity or amount” when posting a Recurring General Journal

Introduction

When attempting to post a recurring general journal you receive the message “There is nothing to post because the journal does not contain a quantity or amount” even though you have specified the General Ledger codes and the amounts and everything appears fine.

This is a common query that crops up, and also something I see from time to time in the forums, so I thought I’d write it up for reference and to hopefully help anyone else who receives this message.

The Recurring General Journal

Below is a recurring general journal. I’ve populated all the required fields however when I try and post it I get the message below:

The Solution

The reason I’m getting this message is because of the unique way in which a recurring general journal works. In a Recurring General Journal the “Posting Date” is compared to the “Work Date” and if the posting date is greater than the work date you receive this message.

I’ll therefore compare the Posting Date on my journal to my Work Date, and as you can see the Posting Date is in advance of my Work Date:

Therefore, in my case, the solution is to change the user date to a date of 01/01/23 (or a date in advance of 01/01/23) and try again:

After doing this my journal will now post 🙂

Conclusion

As far as I’m aware, this is the only journal that behaves this way. For example, I can post a General Journal and the system won’t check the Work Date against the Posting Date.

I suspect the primary reason for this behaviour is to prevent a user mistakenly posting a recurring general journal numerous times, as by default the lines remain on a recurring general journal after you have posted it, and the posting date automatically advances based on the “Recurring Frequency”. (i.e. if the recurring frequently in 1M the Posting Date changes by one month).

Therefore you could post the journal once and then post it again by accident. Having the system perform this simple check prevents this.

Thanks for reading!

Dynamics GP Vs Dynamics 365 Business Central – Where is the General Ledger Journal Entry Number in Business Central?

Introduction

When you post a transaction in a subsidiary module in Dynamics GP, a journal is created in the General Ledger to record the transaction in the chart of accounts. The journal has its own unique journal number that groups all the distributions related to that transaction together and is stored in the GL table on all the lines.

Being a long time Dynamics GP user, when I started using Business Central, on posting a transaction I looked for the equivalent journal number in the G/L Entries, but couldn’t find it? Yes, there are G/L entries created, but I couldn’t find what I classed as a unique journal number that binds these together just like the Dynamics GP journal number.

In this post I’ll walk through what I regard as the closest equivalent to the Dynamics GP journal number in Business Central.

Dynamics GP – Journal Number

When you post a transaction in a subsidiary module in Dynamics GP, like a Sales Invoice for example, this is recorded in the General Ledger as a Journal Entry.

For example when I post the Sales Invoice below its recorded in the General Ledger using a unique Journal Entry number. The same journal number is stored on all the lines of the journal.

And here’s the Journal Entry recording the transaction in the General Ledger. The journal entry number is stored on all the distribution lines.

Therefore when posting one transaction in Dynamics GP, you get one Journal Entry with a unique number grouping all the distributions relating to that transaction in the General Ledger.

** Please note things like the originating document number and customer number are also transferred and stored in the GL table in Dynamics GP just like Business Central.

Dynamics 365 Business Central – G/L Entries

Going back to the example of a Sales Invoice, when you post a Sales Invoice in Business Central a series of Entries are created including G/L Entries.

Therefore if I were to post the Sales Invoice below

I’d get the following G/L Entries.

As you can see each line has a unique “Entry No.”. There is no obvious unique number from a GL point of view that groups all these lines together. (You can group them together using the “Document Number” but this is the Sales Invoice document number. There is no GL specific unique reference that groups these together in the G/L Entries table.)

Up steps the G/L Register

Although not obvious at first, whenever you post any transaction in Business Central, along with all the various entries that are created, a G/L Register is also created.

The G/L Register has its own unique number and encompasses all the entries that have been created by posting the transaction. It does this by holding the “From Entry No.” and the “To Entry No.”

Below is the G/L Register that was created by posting the Sales Invoice above

As you can see this has a unique GL reference. This is the “No.” column.

Therefore this is what I regard as Business Centrals equivalent to Dynamic GPs journal number.

Conclusion

Once I’d grasped this concept of entries and registers, I felt I had a greater understanding of the posting flow in Business Central.

Thanks for reading!

** Please note there is also a “Transaction No.” field stored on the G/L Entries which appears unique however I’ve found you can post one document number which can generate more than one “Transaction No.”. I blogged about this here

Dynamics 365 Business Central – Why didn’t the Reverse Transaction function in the General Ledger Entries page reverse all my General Journal?

Introduction

A client reported that when reversing a large journal via the “Reverse” option in the “General Ledger Entries” page only part of their original General Journal was reversed?

This stumped me and forced me to dig deeper into how the journal was posted. On investigation it seems the journal lines on the journal had been grouped, and each group has been given a different “Transaction No.” in the G/L Entry table. Then, when the reversal option had been selected, only those lines with the same “Transaction No” had reversed.

Its the first time I’ve come across this behaviour in one distinct journal, so in this post I’ll demonstrate how this happened and the correct way this should have been reversed. (i.e. I’d expect this for different document numbers but not the same document number)

The Journal

The clients journal contained many lines however I can recreate the scenario with a much simpler journal.

Below is a journal with five lines. All the lines have the same Posting Date and Document number and the journal balances to nil. This is essentially one journal which we want to post as one unit.

I’ll now post the journal and go and view this in the General Ledger Entries page. I filter on the document number and I can see the full journal. This is great and just what I expect 🙂

The Reversal

I now realise I’ve made a mistake and want to reverse the whole journal. Therefore, while still in the General Ledger Entries page, I select the top line and choose “Process > Reverse Transaction” from the menu however it only gives me the option to reverse a portion of the journal? (the first three lines of the original journal)

So what has happened here? Why is the system not offering to Reverse all the entries on this Document Number?

The Transaction No. column

As shown on the screen shot above it seems the “Reverse Transaction” option pulls back the G/L Entries based on a “Transaction No.”?

I’ve never seen this column before, and when I try and add this via personalisation to the “General Ledger Entries” page, its not an available column?

I’ll therefore dig deeper and look at this document number directly in the the G/L Entry table, and there I can see the journal has been grouped and each group has been given a separate “Transaction No.”

So now the question is why has a journal with the same Posting Date and Document Number been broken up and given two separate “Transaction No.”?

The answer lies in how I posted the journal. If I look back at my original journal I’d inadvertently balanced the journal in two sections.

It seems even though the journal lines have the same posting date, and more importantly the same document number, the system gave these a different “Transaction No” based on how its balanced part way through.

Finally, it seems the “Reverse Transaction” function pulls back the entries based on this “Transaction No.” which causes a complication if I wanted to reverse the whole Document Number.

Quickly Reverse all Entries

So how do I reverse all the lines?

In my example its quick and easy as the journal is small. I could stay in the “General Ledger Entries” page and select one of the first three lines, and click “Reverse Transaction” and then select the fourth line and use the same “Reverse Transaction” option. However what happens if the journal contained many lines that had been grouped into lots of different “Transaction No.”?

In this scenario you can reverse via the G/L Registers page.

As the G/L Register contains all the G/L entries in my journal I just click click “Reverse > Reverse Register” as per below

This gives me all the G/L Entries in my journal that I can then reverse.


Conclusion

It was great investigating and finding out more about how Business Central works in the background. In some ways you could argue this behaviour is advantageous, as you have the opportunity to only reverse part of one huge journal.

My biggest takeaway from this is when reversing an entry via the “Reverse Transaction” in the “General Ledger Entries” page ensure all the expected lines are being reversed.

Also, if you do want to reverse all the journal lines consider using the “Reverse Register” function on the “G/L Register” page rather than “Reverse Transaction”.

Thanks for reading!