Posting Recommendations in Dynamics GP
26/09/19 11:49 Filed in: Dynamics GP | Best Practices
The transaction posting process in Dynamics GP is one of the most processor-intensive tasks in the system. Most users, however, do not give it a second thought when clicking the "Post" button. This is a tribute to how well designed modern ERP systems are, but I think it is always good to take a look at some best practices for posting in Dynamics GP.
When posting batches in Dynamics GP the best thing to do is to leave the system alone to do its thing. There are several ways to post in Dynamics GP. These include posting one transaction, posting one batch, posting multiple batches in a series, and posting multiple batches in multiple series. Obviously, the batch posting process is more intensive if there are multiple batches involved and also the type of transaction also has great impact on the posting process.
For example, the sales transaction posting process is one of the most intensive as far as processing power requirements. When you post sales transactions, about a couple dozen tables may be affected in the database, including tables in the sales, accounting, inventory and bank series. In addition to this, the more lines a sales document has, the more work the system has to do to post said transaction.
It is important, then, to consider the following recommendations when posting transactions:
If you follow all or some of the above recommendations you will be minimizing the risk of posting problems, especially on environments with large volume of transactions. If you want us to evaluate your posting processes and suggest improvements, contact us.
The ICON Team
When posting batches in Dynamics GP the best thing to do is to leave the system alone to do its thing. There are several ways to post in Dynamics GP. These include posting one transaction, posting one batch, posting multiple batches in a series, and posting multiple batches in multiple series. Obviously, the batch posting process is more intensive if there are multiple batches involved and also the type of transaction also has great impact on the posting process.
For example, the sales transaction posting process is one of the most intensive as far as processing power requirements. When you post sales transactions, about a couple dozen tables may be affected in the database, including tables in the sales, accounting, inventory and bank series. In addition to this, the more lines a sales document has, the more work the system has to do to post said transaction.
It is important, then, to consider the following recommendations when posting transactions:
- Ideally, close other applications and let Dynamics GP be the only open/running application in your PC. Applications take memory and processor time away from other applications even when running in the background.
- Within GP, close all open windows.In particular, any report window or smart list have the potential to lock your posting process. A posting process is usually followed by a report and if you already have a report displayed on your dynamics GP environment, the current posting process sits “waiting” its turn to display its reports while you have another report open (maybe even minimized). This can give the impression to the user that the posting process is stuck, when in reality it is just waiting for you to close the open report so the posting report can pop up.
- DO NOT switch to other applications when posting. This seemingly unimportant task takes the operating system focus away from GP and onto the other application you are switching to, potentially robbing GP of precious processing priority and power.
- Depending on circumstances, even with all of the above, the posting process may put GP in an apparent “Not Responding” state. This is likely not the case, and you should simply wait for the process to run its course.
- Network issues could cause problems with posting. During posting, the network activity between the PC and the server is greatly increased, and any issues with networking will delay or stop the process.
- Consider having the post process done on the server by an automated process. Posting from the server makes sense for many reasons:
- The server has typically more processing power than any individual PC
- The server hosts the database so no networking issues there if both the posting service and the database are in the same hardware.
- Usually no other programs are running on the server that could cause issues when posting.
If you follow all or some of the above recommendations you will be minimizing the risk of posting problems, especially on environments with large volume of transactions. If you want us to evaluate your posting processes and suggest improvements, contact us.
The ICON Team