Administrator on 4/5/2021 8:25:26 PM

Once you are on the latest code we honestly have had no users with problems unless they are a really big company with a lot of data
 
If you print from the inquiry window, choose the checkbook first and that will help with slowness, is this the step they are taking?  I don’t think so based on initial suggestion.
 

This usually works much better for customers I have found and they are happy with it, just a little change of process.

With the work we did one is going through the report options window is using an old dexterity based report/coding
When we re-worked the other areas we converted all that to stored proc based so this could be part of the reason.
I would continue to advise the client to run it through the inquiry window if it works better for them.

Here is the history around it if you want to know:

If this is a larger company, depending on your records in your tables we may see this.
 

1. If you print from the inquiry window, choose the checkbook first and that will help with slowness
   When opening Checkbook Register Inquiry, before selecting a Checkbook ID, select to view Unreconciled transactions only.  This will enable it to go quicker as it will eliminate parsing through the reconciled transactions in history.  Optionally, you can also restrict it to a date range.  Due to the volume of transactions in the history table, we don’t recommend viewing Reconciled transactions using this method 

 
View Checkbook transactions in SmartList > Financial > Bank Transactions.  This runs much faster than the Inquiry window.
 
Inactivate Checkbooks you are no longer using.  Limit Checkbook ID Lookup to Active Checkbooks only.
 
Move reconciled transactions for the highlighted checkbooks to history.  This will reduce open records by 28%.
 
Going forward, run Financial > Routines > Reconciled Transaction Maintenance on your active checkbooks on a regular (at least monthly) basis.
 
 
 
To give you a little history:
In GP 2016 we changed some items around Bank Rec and with those changes, we had some lingering report issues.
See blog on feature changes
https://community.dynamics.com/gp/b/dynamicsgp/archive/2016/11/11/microsoft-dynamics-gp-2016-r2-new-feature-blog-series-schedule


The last issue we fixed in GP 2018 R2, which i think you are on or later you indicated,  when you try to print some of these reprint journals, you go into that options window
There is no option for checkbook so what you find in the dex.sql log if I say print this report for Audit trail code 'ABCDE'

It will loop through EVERY checkbook you have active and inactive, put them all in a temp table, then print that audit trail code, similar to what you stated.

For GP 2018 R2,  we added "checkbook ID" options to several areas.
See this blog
https://community.dynamics.com/gp/b/dynamicsgp/archive/2018/10/26/microsoft-dynamics-gp-2018-r2-option-not-to-show-inactive-checkbooks-in-lookup-windows

We have done work on this already and most customers do not see it only a select few depending on the database size

Now if the issue is more going into the window and pulling up a document and they have upgraded from prior versions; I have found the following issue:
Query the CM20200 which will move to the CM30200
If not many in the CM30200, then we may need to do this.

Here is the blog on what we did and why we added it
https://community.dynamics.com/gp/b/dynamicsgp/archive/2016/12/22/microsoft-dynamics-gp-2016-r2-bank-reconciliation-reconciled-transaction-maintenance

If you are on the latest code, this window is working correctly and it will load blank with "no data" , we may just need to move some “stuff” to history.

If you have nothing in the CM30200 I would in a test company of the live, run the process and then see if you notice anything.
I have also had customers that do not mark off so then everything just sits in the CM20200 that too will cause this to be slow