Attempting to replicate or reverse engineer Dynamics GP windows and features can be a risky undertaking.

A few years back, I worked with a customer who was moving five years’ worth of data into Dynamics GP, which required a detailed migration of every single transaction. As anyone who’s done this knows, it’s a big job. Extracting and organizing data from the old system is tough, and importing it all into GP is no picnic either. To make matters worse, you always find data errors that further complicate the import.

This particular project involved importing their AP payments, which meant also importing the payment applications to show which invoices each payment covered. While Dynamics GP lets you import manual AP payments, importing AP payment applications isn’t possible using standard tools like Integration Manager or eConnect. This is where things got interesting.

They asked me to import a massive number of AP payment applications, and I naively thought, “How hard could it be?” Famous last words.

I did manage to create a custom AP payment application import, but it took twice as long as I expected. Thankfully, the customer was understanding and paid me for the extra time. The import worked, and they were able to get all their historical payment applications into GP.

That project taught me that even seemingly simple Dynamics GP processes can be much more complicated than they appear.

Fast forward to 2013. Another customer needed to apply single AR payments across hundreds or thousands of invoices, filtering by Batch ID and PO Number. This wasn’t possible in the standard AR apply window, which has no filtering. They had customers with thousands of open invoices, and a single payment might apply to a thousand of them.

We explored third-party solutions and even had a Dexterity developer look at customizing the window to add filtering, but nothing worked. I was left trying to find a way to mass apply payments with their specific filtering needs.

Against my better judgment, I agreed to build a custom .NET window using Visual Studio Tools. And boy, am I regretting it. The Dynamics GP Apply Sales Document window, while seemingly simple on the surface, is extremely complex under the hood. It requires a deep understanding of data management, state management, and UI development—skills I don’t often use. Numerous details made the process much harder than I anticipated.

After months of work and several redesigns, I have a solution that meets their needs, functions correctly, and handles all the behind-the-scenes tasks of the Dynamics GP Apply Sales Document window. The upside is that the new window is robust and flexible, exactly what the customer needed. The data displays instantly, filters immediately as the user types, and applying payments to thousands of invoices is a one-click process. But getting there was much harder than expected.

I’ll deliver this project, but it’s been a real learning experience. Going forward, I’ll avoid requests to recreate Dynamics GP functionality, windows, or processes. Things are always more complicated than they appear on the surface.

With enough time, money, and development resources, anything is possible. But my experience has taught me that it’s easy to underestimate custom projects like this. They’re risky, and you need to go in with your eyes wide open.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him onGoogle+andTwitter

http://www.precipioservices.com

Licensed under CC BY-NC-SA 4.0