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


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.


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!

Dynamics 365 Business Central – A method to Force Approval of New Vendors using a Standard Vendor Approval Workflow


Within Dynamics 365 Business Central you have the ability to create Vendor Approval Workflows which can be triggered on certain conditions. I’ve found that although this is really cool functionality you get right out of the box, it does have a downside.

The issue being if you use the standard Vendor Approval template as the basis of your Workflow, the user has to request that the new Vendor is approved, otherwise the Workflow is skipped. Obviously this gives this functionality massive drawbacks as users can go ahead and create Vendors and never click the “Request Approval” button.

In this blog I’ll explain how I’ve managed to get around this by adding conditions and changing the Vendor Approval Workflow.

** Please note there’s also one caveat in the at the end of the post 🙂

Vendor Approval Workflow from the Template

To demonstrate the problem with the Vendor Approval Workflow created via the Template let’s add a new one.

To do this search for “Workflows” and then on the Workflows page click “New > New Workflow from Template” and select “Vendor Approval Workflow” as per below:

This opens up a new Vendor Approval Workflow based on the template. However as you can see the first event in the approval sequence is “Approval of a vendor is requested”

This means for the Workflow to start the user must click “Request Approval” after creating the new Vendor.

Therefore no matter what conditions we add, and complex approval hierarchy’s we implement, if a user forgets to request approvals the approval workflow will never start.

So the obvious question is how can we get around this restriction? Can we force the system to automatically send approvals when users create new Vendors.

Changing the Vendor Approval to Force Approval

For this to work we have to get a little creative with its setup and conditions.

Firstly, after adding the Vendor Approval you can edit the default events and sequence. So rather than start with “Approval of a vendor is requested” lets change this to “A vendor record is changed”.

You can do this by clicking the ellipse button next to “Approval of a vendor is requested”

Then select “A vendor record is changed”

The workflow will now look like this:

As this stands the Workflow will trigger whenever a Vendor record is changed, however this isn’t exactly what we want. We only want this to trigger for new Vendors, therefore we need to add some conditions.

Now lets click the <Always> condition so we can filter down when the Workflow will be triggered.

This will open the “Edit – Event Conditions” page where we can add the following conditions:

Let’s break down what the conditions are saying:

The first condition is – “Inv. Amounts (LCY):0”. This means the Workflow will only trigger if the Vendor has never had any Invoices posted onto it.

The next condition is – Only trigger when the No. is Changed: This means the Workflow will only trigger when the Vendor No. is changed.

Therefore the Workflow will only trigger if the Vendor has had no activity AND the Vendor No. is changed (which happens when a new one is added).

Hopefully this captures all new Vendors although it will also trigger if someone changes the Vendor No. and the Vendor has never had any invoices posted. (hopefully this will be unusual unless there was a mistake setting up the Vendor)

Let’s test the Workflow

Now to test if this works 🙂

First go to “Vendors” and click “New”

Select a Template and click OK
Now the Vendor page opens and the Workflow automatically triggers and sends an approval request:

Therefore we have successfully forced the Workflow approval to trigger automatically when a new Vendor has been created 🙂


Although I’ve found this to be a great way to configure automatic approvals for new Vendors it does have one disadvantage :(.

Unfortunately you can only have one Workflow which starts with the same event. Therefore if I wanted to create another approval that started with “A vendor record has changed” the system would prevent this as per below

Just something to bear in mind if you wanted to implement this solution 🙂

Thanks for reading!

Dynamics GP Vs Dynamics 365 Business Central – Place Purchase Transactions and Vendors on Hold


This is another blog in a series I’ve been writing comparing functionality in Dynamics GP to Dynamics 365 Business Central.

In this post I’ll compare how purchase holds work in both Dynamics GP and Dynamics 365 Business Central. Both products offer solutions for applying holds at a document and Vendor level, however there are differences which we can explore.

Dynamics GP

In Dynamics GP you apply holds to individual transactions via the “Transactions > Purchasing > Holds” window.

By placing the document on hold you won’t be able to pay this via a manual payment or the automated “Select Cheques” routine (the Dynamics 365 Business Central equivalent being “Suggested Payment” batch job).

Therefore you must remove the Hold via this window in order to pay the document.

You can also produce a list of documents on Hold via a Smartlist prior to creating a payment run to assist with the process.

If you wish to prevent any documents from being paid on a particular Vendor you can tick the “Hold” flag on the Vendor Maintenance window as per below:

Placing the Vendor on Hold will prevent any payments being issued however you will still be able to enter and post transactions other than payments.

Dynamics 365 Business Central

To place a document on hold you go to “Vendor Ledger Entries” and click “Edit List”.

You then enter any 3 characters in the “On Hold” field to indicate the document is on hold. For example below I’ve entered the characters “GW” in the On Hold column.

Although you can use any 3 characters we tend to suggest using users initials as this gives the added benefit of knowing who has placed the document on hold. You can also filter the “Vendor Ledger Entries” either on initials or whether the field is blank or not to identify which documents are on hold (i.e. add a filter for On Hold <>’)

When you add the 3 characters to the On Hold field this excludes the document from being picked up by the “Suggest Payments” batch job in the Payment Journal however you can still pay and apply the document manually. This is different to Dynamics GP which requires the Hold flag to be removed before it can paid.

You can prevent any payment to the Vendor via the “Blocked” field on the Vendor Page.

You can prevent all payments from being made by selecting “Payment” or prevent any transaction from being posted on the Vendor by choosing “All”. This differs to Dynamics GP as even if a Vendor is placed on Hold you are only prevented from posting payments.


Both Dynamics products offer robust solutions for applying document and vendor holds. The main difference seems to be that Dynamics GP gives the user the ability to ensure a single document won’t be paid, even via a manual payment, and Dynamics 365 Business Central gives flexibility to prevent all document types being posted against a blocked Vendor.

Thanks for reading!