I seem to frequently work on unusual and obscure tasks and issues in Dynamics GP, and I discovered another one recently.
I have a large Dynamics GP customer that issues thousands of AP payments every month. The payments are issued to dozens of countries using every payment mechanism imaginable. Checks, ACH, wires, debit cards, PayPal--you name it. The payments are issued from both Dynamics GP and through at least one third party international payment processing service.
The company issues so many payments in so many forms that they have a very interesting and challenging problem. The problem stems from the fact that they regularly encounter situations where the payment is not successfully delivered to the vendor. Maybe the check was returned as undeliverable. Perhaps the ACH info wasn't correct. Maybe the PayPal email address was wrong. Given the number of different payment methods they use, sometimes they discover this in a few days, while sometimes it takes a few months to be notified that a payment was not successfully delivered. Given their high payment volume, the challenge this creates is having to void hundreds of payments a month in Dynamics GP so that they can re-issue the payment.
The void process is so time consuming for them that they asked me to develop a solution that could automatically void payments in GP. I developed that solution, which is a very long story on its own, but in the process of testing, I discovered an unusual scenario that made it difficult to automatically void a payment.
The issue is that it is possible to issue the same check or payment number from multiple checkbooks in Dynamics GP. This isn't something I had considered before. So if I pay a vendor with Check 100 from Checkbook 1, and then later happen to pay that same vendor with Check 100 from Checkbook 2, the vendor now has two payments with the same check number. Given the number of GP checkbooks, the number of payment methods used, and the fact that a third party payment processor is involved, I couldn't rule out this possibility.
Here's an example of what that scenario looks like in the Void Historical Payables Transactions window.
Even if you filter the vendor and the document number, the window displays multiple payments. In the screen shot, I used the extreme example of payments with the same date and amount. In this case, the only way to tell the difference between the two payments is by the internal GP Payment Number value.
A user who is manually performing a void would have to select a row in the scrolling window and click on the Document Number link to drill in to the payment and see which Checkbook was used to issue the payment. But because the Checkbook ID is not shown on the window, an automated solution just looking at the data in the scrolling window cannot tell which payment should be voided. So I'm probably going to have to enhance the automated solution to verify the date and amount shown in the grid record, and also lookup the payment number to determine which checkbook issued the payment.
One could reasonably say that it is unlikely that a vendor would be issued two payments from two checkbooks with the same payment number. I would have previously agreed, but the fact that this issue happened to come up in my limited testing on my development server would seem to indicate that it could be more likely than you might think. And if you've worked with ERP systems long enough, you know that if an obscure problematic situation can arise, it usually will.
I thought that this was a good example of how flexible functionality in Dynamics GP and unexpected or complex scenarios can produce a situation that requires custom solutions to handle unusual situations, even if unlikely.
Steve Endow is a Microsoft MVP
for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.
He is the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
No comments:
Post a Comment