Archive for November, 2010
We have seen a surprising increase in business from companies that are operating under the protection of the U.S. bankruptcy code. This seems like a paradox, but bankruptcy trustees and redirected management are looking for a solid alternative to massive business systems that still require substantial support fees and maintenance. What we’re hearing from our new clients is the following:
- Subscription pricing allows for a minimal upfront investment in business systems
- Hosted business systems requires no additional systems management personnel
- Subscription pricing and hosting requires no long term commitment
- A solid mid-range ERP system can be a good replacement for a huge tier-1 system
- Flexibility, flexibility, flexibility
- QuickBooks, no way, no how, never
If a big change in your business is causing you to take a fresh look at how you invest in, and use business systems, you should take a good look at a mid-range ERP system offered in a hosted environment with subscription pricing.
Not all support calls are easy. In fact, there are certain people that call for help (I can usually recognize their voice) and I immediately know I’m going to be digging for a resolution for 2 or 3 days. That’s mostly because of the persons experience with Dynamics GP. The resolution is not going to be a check links, reconcile, batch stuck, ID-10-T, type issue. If they are calling for help it’s usually an issue with Dynamics GP. (You know who you are)
Often these issues relate to a newer version of Dynamics which is the case with EFT for Receivables in Dynamics GP 2010. After an upgrade to the newest version of Dynamics GP the system kept crashing when trying to process EFT’s for RM. Dynamics would lock up and give the standard “Not Responding” error message. The user would exit out of GP and come back in. That would create a stuck batch and the IT guy would have to go through unstucking the batch (that’s the technical term for it) and run check links to get the transactions open again. But the process would never complete. This happened on all workstations and even on the super duper blazing fast new server they just put in.
After having the live company copied over to a test company we tried the process again. It crashed on demand so we were quite confident it was a data issue as the same process worked like a charm in other companies.
So after a while of beating my head against a wall looking for a resolution I swallowed my pride and contacted MBS for support. ***Side note. MBS support is really, really, really, challenging since they implemented a new support system. I yelled at them at the last partner summit in October quite a bit and I thought things were improving but for some reason things just keep being difficult.*****
To make a long support call(s) short, for each EFT transaction it runs through the CM20300 table 25 records at a time looking for matches. The table in this company just so happens to be over 100,000 rows. The process was happening, it just took a really long time to complete. The other companies we tested on only had around 17,000 rows.
For 25 EFT transactions it took about an hour to complete. In Dynamics GP 10.0 it took a matter of seconds.
I wish I could give a decent resolution to this issue right now. So far the work around options are:
- Live with it. Dedicate one workstation to process EFT’s. Or run the process just before closing and leave the workstation on overnight.
- Remove history so the process is faster. We deleted all but 9,000 rows in the CM20300 table and the process still took 5 minutes to run 54 EFT transactions
- Complain. This is my preference. I like beating up on MBS. Its one of my simple pleasures in life
This issue took several calls and updates to come to this point. I should have known what I was getting into as soon as I heard “DOUGIE, how’s it going”.