It takes us from 1 hour 30 minutes to over 2 hours to post a sales batch.
We are using average cost for inventory method.
What is normal posting time for 200-400 transactions?
Do you have any advice/ quick fix to speed up posting sales batch?
*This post is locked for comments
I would recommend that you check out the new White Paper on Performance issues. Here is a link to this information:
mbs.microsoft.com/.../MDGP2010_WhitePaper_Performance
Thanks,
Jonathan
Barbara,
You will want to refer to the following articles on CustomerSource for assistance in this process:
How to Change the Valuation Method for an Item in Inventory Control in Microsoft Dynamics GP (no KB number is listed, so hopefully you can search for this title)
Essentially, in order to change an item's valuation, you will need to ensure you have no sales orders, purchase orders, or inventory control transactions containing that item. Then you can use the "Change Valuation Method" utility in GP to change the valuation method for each item.
This, of course, is the "on-paper" way to do it. In reality, it's far more difficult as the challenge lies in whether or not you can feasibly remove each item from all of the sales/purchase/inventory documents on which it might appear. More than likely, you will have to come up with some process whereby you save the transactions to a file, remove the transactions from GP, then re-enter the transactions via an import tool like integration manager, etc.
In the end, we handled this process through a series of SQL scripts that we ran, then ran the utility in GP, then reloaded the transactions with the new valuation method.
Hope this helps,
David
Thank you very much, Francisco! This is very useful!
Open Sql Server Management studio or Query analyzer depending on your version then create a new query, make sure to select the database for the company and type the following
Select count(jrnentry) from PJOURNAL
and then execute it, if you get a number greater than 0 then backup your database first and then execute this
Delete PJOURNAL
execute and try again, if this does not solve the slowness then try to create a DEXSQL.LOG or trace posting with SQL profiler, to determine if there is something else, do you have any third party software that is tied to sales or inventory?
Thank you very much for useful answers!
Francisco: Could you please list specific steps to query PJOURNAL table? I'll do so as soon as we finish posting sales batch.
Andrew: We only have 2-3 lines in each transaction.
David: We are considering switching to FIFO Perpetual. Could you please describe challenges that you had when you switched from Averga Perpetual to FIFO Perpetual in GP?
We once had the same issue (using average costing) but had far higher sales volume than what you've described. It would take hours for batch posting to occur and caused lots of locking and blocking of other processes. It got to be so troublesome that posting was only allowed to be done overnight.
In the end, we determined it to be due to the "Inventory Ripple" effect of using average costing whereby an average cost is maintained per receipt layer. As you post sales invoices, the initial receipt layer is "hit" to update QtySold and average cost for that layer, but then the average costing process also ripples out from that initial receipt layer to potentially hundreds of other receipt layers for the same item to update the average cost for those receipt layers.
In the end, we moved from Average Perpetual to FIFO Perpetual (not without its own set of challenges) and now have vastly improved posting in Sales module.
David
Barbara, you mention that the batch has 200-400 transactions. How many lines does each transaction have? If each transaction has many lines entries, this could explain why the posting is taking a long time to post.
Another thing on this would be to review if you have any customizations added, or table triggers that are affecting your posting ability
barbara, please query the PJOURNAL table, and see if its being cleared
We know that on some installations using SQL express jobs are not created, and on some SQL installations the Agent is not started.
The PJOURNAL table is responsible sometimes for the time it takes posting, you can delete the contents of it and see if this improves your posting experience.
Have a great Day
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,253 Super User 2024 Season 2
Martin Dráb 230,188 Most Valuable Professional
nmaenpaa 101,156