Several years ago I had a customer who was migrating 5 years worth of data to Dynamics GP. They needed to do a detailed data migration, so every transaction needed to be imported into GP. Those who have done such a migration know what a hassle it can be. It is often very difficult to extract and organize all of the data from the prior ERP system, and then importing it all into GP can be a major undertaking. And to top it off, you invariably discover some errors in the source data that makes it even more difficult to import into GP.
As part of that project, the customer needed to import their AP payments. And if they import their AP payments, they need to import the payment applications to reflect which invoices were paid by each payment. Those of you who have used Integration Manager and eConnect know that although you can import AP Manual Payments, there is no way to import AP payment applications. Let the fun ensue.
I was asked to import thousands and thousands of AP payment applications. I thought sure, how hard could it be? Heh, famous last words.
I was able to pull it off and produce a custom AP payment application import, but it probably took two times longer than I expected. Fortunately the customer was gracious and actually paid me for all of my work. The import worked well and helped them import their massive pile of historical payment applications.
That project taught me that even seemingly simple Dynamics GP processes can be deceptively complicated.
Fast forward to 2013. One of my customers needed a way to apply a single AR payment to hundreds or thousands of invoices based on Batch ID and PO Number. The standard AR apply window has no filtering options, so it would be impossible for them to try and use it. One of their customers could have 5,000 open invoices, and a single payment might need to be applied to 1,000 of those invoices.
We looked into third party options and even had a Dexterity developer try and customize the window to add custom invoice filters. But nothing panned out. So I was stuck having to find a way to enable the customer to mass apply payments to piles of invoices with their specific filtering requirements.
Somewhat foolishly, I agreed to create a custom .NET window using Visual Studio Tools. Boy, am I paying the price. While the Dynamics GP Apply Sales Document window seems like a relatively simple window, when you dig into the details of what it is doing and how it is doing it, it is quite complex, and requires data management, state management, and UI development skills that I just don't normally need. And there are a lot of details that make the process much more complex than I would have imagined.
After months of tedious work and a few redesigns, I finally have a solution that I think is robust enough and flexible enough to meet the customer's requirements while also working properly and managing all of the housekeeping that goes on behind the scenes with the Dynamics GP Apply Sales Document window. On the plus side, I think the window is very powerful and flexible--it is exactly what the customer needs. The data is displayed instantly, can be filtered instantly as the user types, and applying a payment to thousands of invoices requires just one click. But developing the window has been much more difficult than I had anticipated.
While I think I'll be able to pull this one off, it has definitely left some scars, and I'm telling myself that in the future I need to try and decline any requests that involve reproducing Dynamics GP functionality or windows, or reverse engineering Dynamics GP processes. Things are often much more complex than they might appear when using the Dynamics GP UI.
Certainly with enough time and money and development resources anything is possible, but based my experience, it is far too easy to underestimate such custom projects--they are risky endeavors.