Dynamics GP – Using the “Batch Enquiry” window to assist troubleshooting the “Receiving” or “Busy” batch statuses


Situations can arise where batches show a status of “Receiving” or “Busy” in the various series post windows. This is generally nothing to worry about, it just means a user is active with that batch, however if the batch continues to say “receiving” or “busy” when no one is posting, further investigation may be needed. When this happens users and admins will often dive straight into SQL to investigate further, however this post shows how you can use the little known “Batch Enquiry” window to get a greater insight into what is happening with batches in Dynamics GP, without the need for SQL. You can then take some remedial action to hopefully prevent any long winded SQL fixes.

The Busy and Receiving Batch Statuses

When you are working in a batch in Dynamics GP the batch status changes to record you are active in that batch. For example I’m working in the “GAV JAN INVS” batch so the series post window shows this batch as “Busy”

In the scenario below I’m posting some Sales Invoices, so the General Ledger Batch RMSLS000009 is showing a status of “Receiving”. (as this is receiving transactions from the Sales Invoice batch I’m posting)

As I mentioned above this is all normal behaviour, however instances can arise where no one is in the batch yet the batch status remains as “Busy” or “Receiving”.

Batch Enquiry

When this occurs users and admins can be tempted to delve straight into SQL however you can also use the “Batch Enquiry” window to see which users are active with those batches. The “Batch Enquiry” window is a little known window that gives you a peak into the “Batch Activity” table (the SY00800 table in the DYNAMICS database – a row is inserted into this table when a user is active in a batch).

You can access the window via the option “Enquiry > System > Batch”

Once in this window it gives you an overview of what users have which batches open and a status of what is happening in those batches.

Armed with this information we can check directly with those users to see if they are indeed working in those batches. If they aren’t then the first course of action is to ask them to log out of GP and log back in. Doing this can trigger GP to automatically recover the batch for you, negating the need for any intervention at SQL level.

For example the user “sa” wasn’t active with the batches “SL JAN INVS” or “RMSLS0000009” so after logging the “sa” user back into GP we were prompted with the message below:

This indicates that the system has automatically recovered the batch for you and now you can just go to “Batch Recovery” to continue the posting of the batch. There was no need to go into SQL and start manually removing activity records. In fact doing that in the first instance could have made the fix much more difficult. (i.e. if the batch activity record was removed manually in SQL its likely you wouldn’t have been prompted with the message to recover the batch. Therefore fixing things would have been a manual process)


Hopefully using the batch enquiry can help identify which users need to log out and back into GP which can sometimes force GP to fix any issues with the batch for you without the need for SQL intervention.

It can also help you monitor the system more effectively, giving an insight into which batches users are working on.

Thanks for reading!

Dynamics GP – Steps for adding a new Currency in Dynamics GP


This article outlines the steps needed to create a new currency in Dynamics GP. The article assumes you have the relevant security permissions to access the various windows and also the system password if one is used.

Adding a new currency

First you need to add the currency via “Tools > Setup > System > Currency”

In this case I’m adding the Japanese Yen

After the currency has been added grant your Dynamics GP companies access to the new currency via “Tools > Setup > System > Multicurrency Access”

Once in the “Multicurrency Access Setup” window select the new currency and tick the relevant companies. (this requires all users are out of the system)

Next add the “Exchange Tables” via “Tools > Setup > System > Exchange Tables”

Once in the “Multicurrency Exchange Rate Table Setup” window create the Exchange Table ID and click “Rates” and add the exchange rates.

** You can review any existing exchange tables to confirm the settings used in your system. In my example I’m choosing “Divide” as the calculation method and “Exact Date” as the default rate. You may wish to use different settings on your system.

Next you need to go back to the Multicurrency Access Setup window and grant access to the Exchange Table ID we just created.

Once the currency and exchange table have been created, and access has been granted, we just need to assign the various rate types to the exchange table. We do this via “Tools > Setup > Financial > Rate Types”

In my example I only intend to have one exchange table so I’ve assigned all the rate types to the new exchange table.

** Please note you may only have one rate type in your system. My example is based on adding a new currency for use in the Fabrikam demo company which has three rate types.

Once this is all setup I can test adding a transaction and this all works fine. I’ve added a transaction for 204 Japanese Yen which equates to 2 US Dollars.

If Inventory Items are used in your system you may also need to assign the new currency to either all or some of your Items. This can be done individually via “Cards > Inventory > Item Currency” or en masse via “Tools > Utilities > Inventory > Price List Utilities”


As you can see there are quite a few steps involved in creating a new currency but hopefully if you follow the steps outlined above it will assist you in setting this up.

Thanks for reading!

Dynamics 365 Business Central – Why do you need to specify posting groups on G/L codes?


Since I’ve been working with Dynamics 365 Business Central I’ve loved the concept of posting groups. As a way of a very brief background, posting groups are used by Dynamics 365 Business Central to gather the required G/L codes when you post a transaction. Therefore you add posting groups to entities like Customers, Vendors, Bank Accounts, Item and also more interestingly G/L codes.

Coming from a Dynamics GP background I could understand why posting groups where needed on all entities, with the exception of G/L codes? Surely if I specify a G/L code on a transaction or journal, this is the G/L code I want to post to?

In this post I hope to shed some light on why the system still requires posting groups on G/L Codes.

A Sales Transaction using a G/L Code

As way of an example lets imagine we are adding the Sales Invoice using a G/L code as per below:

This transaction looks fairly straight forward. We are posting a Sales Invoice with a revenue code of 10100 therefore we expect G/L entries of Debit Debtors and Credit this Revenue code. With this in mind why would we need posting groups defined on the G/L code?

Ok, that’s a fair point, so let’s change the transaction ever so slightly and add some line discounts.

So now we have added line discounts we need a posting to the “Sales Discount” G/L code. However how is the system going to select the correct G/L code?

You guessed it, the answer is using Posting Groups.

So, if we look at the G/L card for G/L code 10100 we can find the product posting groups:

As this is SERVICES the system will use this, in combination with the “General Business Posting Group” from the Customer card, to select the relevant discount code using the “General Posting Setup” window, in this case 10300.

Without this information the transaction would fail to post. This is why the system is requiring you to enter posting groups onto G/L codes. They are needed so the system has a method of gathering other G/L codes that might be needed on the transaction.


This is likely obvious to seasoned Dynamics NAV and BC users however its something that took me a little while to fully grasp so I thought it worth sharing.

Hopefully anyone new to Dynamics 365 Business Central found this useful. (you can also read more about posting groups in this post)

Thanks for reading!