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!

Dynamics GP – 10 tips when running a General Ledger Year End on a large SQL Database


A few weeks ago I assisted with a General Ledger year end for a GP user with a very large number of journals and consequently a very large SQL database.

Usually a year end is a fairly straight forward routine, however as this user has such a large database, along with additional SQL bits and pieces for disaster recovery and bespoke reporting, it required a little more thought to ensure things went as smoothly as possible.

In this post I thought I’d share the steps I took to hopefully assist anyone else facing a similar situation in the future.

Here goes…..

1) Do the basics first.

By basics I mean following Microsoft’s general Year End prerequisites which can be found here.

I find the most important steps are ensuring you have a good backup and also ensuring the general ledger codes have the correct posting type as this can be a pain to correct post year end.

2) Ensure you have enough disk space for the SQL Data and SQL Log files.

This usually isn’t a consideration when running the Year End however given the size of the data its something that needs planning when dealing with GL tables in the 100’s of GBs.

Microsoft’s official guidance on disk space is included in the Year End documentation that I’ve linked to above however I’ve copied the section on disk space below:

During the year-end closing routine, all the records that will be moved are put in a temporary table before they are moved to the GL30000 table. You must have free disk space that is equal to the size of the GL20000 table to perform the routine.

To find the current size of the GL20000 you can use the sp_spaceused system stored procedure i.e.

However I’d also add that when dealing with large data volumes you also need to plan for extraordinary SQL transaction log growth as well.

For example the SQL transaction log grew to 240GB when I did this particular year end. This is because various statements including the INSERT statements into GL30000 are completed in one SQL transaction. Therefore no matter what the SQL recovery model is of your database, the log file is going to grow while the process completes. This is standard behaviour so SQL can roll the whole transaction back should any issue occur.

3) Remove any Database Mirroring or Availability Groups.

In my scenario the user has database mirroring for disaster recovery. I could have left this on however this would result in a lot of transaction log being sent over the wire while the Year End ran potentially doubling the length time it takes. I always see the amount of time something takes, as the size of the window of opportunity for something to go wrong. The quicker I could get the Year End process to go, the less chance I had of something going wrong. On the down side it does mean I had additional configuration to complete post year end, but I was fine with this.

4) Remove any custom indexes

If you have any additional custom indexes on GL20000 and GL30000 its best to remove them. Again its not a problem if you don’t remove them, however it can slow things down and also increase the amount of transaction log that SQL will produce. This is because if you are DELETEing and INSERTing data into tables the indexes also have to be updated. Therefore the less indexes you have the better. This requires additional space and also additional log to record the operations.

**Don’t remove any of the standard indexes though.

5) Stop the SQL Agent.

Maintenance tasks like reindex routines sometimes use the SQL agent to run. As I suspected the Year End will run for a very long time, I stopped the SQL agent to prevent this from happening. Its always best to check that critical operations won’t be affected by this though. If so just disable any SQL jobs that run maintenance on the Dynamics databases.

6) Temporarily revoke permissions for any Reporting Logins.

Ideally I’d like to set the database to single user mode while the Year End ran however as I wanted to monitor the process I didn’t want to restrict this too much. I therefore disable logins that I knew were used for reporting in case anyone sets off a large report in the middle of the year end.

7) Ensure SQL log growth on the database is set sensibly.

As I mentioned above the SQL transaction log is going to grow during this operation regardless of the recovery model. Therefore go to the properties of the SQL database and ensure the growth is set correctly, and its set in MB’s rather than a percent. I set it to grow 10GB increments for this particular year end process.

8) Use SQL monitoring scripts

I like to nosy under the hood when running most things but I especially want a sneak peak on the General Ledger Year End. My tool of choice for this is Adam Machanic’s awesome free monitoring tool sp_whoisative. This is a free script you can use to monitor activity in SQL. Using this I can pretty much see at what point the Year End was up to. i.e. INSERTing the data to GL30000 etc.

**If you didn’t know about this free script, and this is all you take away from this blog I’d be happy :). Its a really cool free tool you can use when troubleshooting all sorts of things in SQL i.e. blocking etc.

I also want to monitor my database and log growth as the process is running. If I monitor this I can predict when the log will run out of space and need to grow. I then check the disk space to ensure the growth will happen smoothly. To do this I use this script

name AS FileName, 
size/128.0 AS CurrentSizeMB, 
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB 
FROM sys.database_files; 

9) Be patient 🙂

One of the most important things is to be patient as this routine can last hours on a large data set. Its also important to never cancel the operation by manually closing GP down even if it says “Not Responding”. If it doubt you can run the sp_whoisactive stored procedure and check what’s happening on the server.

10) Once complete

After a huge sigh of relief I performed an additional backup and then started recreating the indexes, setting up the mirroring and restarting the SQL agent. I also shrank the SQL transaction log back down to a reasonable size.


I hope you find the information in this post useful. Although you may not need to follow all the points I outlined, I think the most important are disk space for the SQL transaction log, monitoring and lots of patience 🙂

Thanks for reading!

Dynamics GP to Dynamics 365 Business Central – A handy list of equivalent Tables and Windows to help a GP user navigate BC


In this post I’ve created a list of Dynamics GP tables and windows along with their Dynamics 365 Business Central counterparts. I’m hoping this will give any GP user venturing into BC a greater insight into how to navigate around Business Central and also which tables store the data. (I’ve included tables because us GP folk like to have a good nosy and understanding of things under the hood:))

At the moment this only includes General Ledger, Sales and Purchase information however I may add to the list in the future.

Please note the GP Window column lists the name of the window in GP. The BC Page column is the name of equivalent page in BC. Its also how you would search for the page in BC using the “Tell me” magnifying glass in the right hand corner of the Business Central screen.

General Ledger

DescriptionGP TableGP WindowBC TableBC Page
General Ledger CodesGL00100 / GL00105Account MaintenanceG/L Account (15)Chart of Accounts
Unposted GL JournalsGL10000 / GL10001Transaction EntryGen. Journal Line (81)*General Journals
Posted / Open GL JournalsGL20000Journal Entry EnquiryGL Entry (17)General Ledger Entries
History GL JournalsGL30000Journal Entry EnquiryGL Entry (17)General Ledger Entries

* Please note General Journals, and any other journal for that matter, can be used to post a whole manner of GL, Sales and Purchasing Transactions in Business Central.

SOP / Sales Ledger

Description GP TableGP WindowBC TableBC Page
Customer MasterRM00101Customer MaintenanceCustomer (18)Customers
* Unposted RM TransactionRM10301Receivables Transaction EntryGen. Journal Line (81)Sales Journals
Unposted RM Cash ReceiptRM10201Cash Receipts EntryGen. Journal Line (81)Cash Receipt Journal
Posted RM TransRM20101Receivables Transactions Enquiry – DocumentCust. Ledger Entry (21)Customer Ledger Entries
History RM TransRM30101Receivables Transactions Enquiry – DocumentCust. Ledger Entry (21)Customer Ledger Entries
Unposted SOP TransSOP10100 / SOP10200Sales Transaction EntrySales Header (36) /
Sales Line (37)
Sales Orders / Sales Invoices etc
Posted SOP TransactionsSOP30200 / SOP3030Sales Order Processing Document EnquirySales Invoice Header (112) / Sales Invoice Line (113)Posted Sales Invoices / Posted Sales Credit Memos

* These type of invoices/credits can also be entered via “Sales Invoices” in BC using GL Codes rather than items.

POP / Purchase Ledger

DescriptionGP TableGP WindowBC TableBC Page
Vendor MasterPM00200Creditor MaintenanceVendor (23)Vendors
*Unposted PM TransactionsPM10000Payables Transaction EntryGen. Journal Line (81)Purchase Journal
Unposted PaymentPM10300Edit Vendor PaymentGen. Journal Line (81)Payment Journal
Unposted Manual PaymentPM10400Payables Manual Payment EntryGen. Journal Line (81)Payment Journal
Posted PM TransactionsPM20000Payables Transaction Enquiry – Document
Vendor Ledger Entry (25)
Vendor Ledger Entries
Paid History PM TransactionPM30200Payables Transaction Enquiry – DocumentVendor Ledger Entry (25)Vendor Ledger Entries
Work Purchase OrdersPOP10100 / POP10110Purchase Order Processing Document EnquiryPurchase Header (38) / Purchase Line (39)Purchase Orders
History Purchase OrdersPOP30300 / POP30310Purchase Order Processing Document EnquiryPurchase Header Archive (5109) / Purchase Line Archive (5110)**Purchase Order Archives

* These can also be entered via “Purchase Invoices” using GL Codes rather than items.

** Archive Orders must be switched on for completed purchase orders to be archived.

Please note there are no equivalent summary windows in Business Central. Totalling and summary values are maintained by Flowfields in Business Central rather than separate tables. See this post for more details.


This is far from a comprehensive list however I’m hoping it contains enough information for someone moving from GP to BC to get started. There are also many more windows in GP and BC that hold similar information, or different ways of displaying the same information. The ones displayed above are just the ones I’ve chosen.

Thanks for reading!