I'm working on an eConnect integration that imports Payables Manual Payments. The integration itself is working fine, but after adding support for the Credit Card payment method, I noticed an oddity.
If I manually enter a Payables Manual Payment for a Credit Card Payment Method, it looks like this.
Notice the Amount fields in the lower right corner. The payment amount is for $111.11, and that amount is displayed in both the Unapplied and Total fields on the left.
However, this is what an eConnect imported Credit Card payment looks like.
While testing, I noticed that the Total field is zero for the imported Credit Card payment.
If I query the PM10400 records for both of the Credit Card payment transactions, I see that the CHEKAMNT field is zero for the eConnect imported payment, and has a value for the payment entered manually in GP.
The eConnect taPMManualCheck node only has one amount field, which is DOCAMNT, so I don't think I'm missing an amount field value in my submission to eConnect.
After reviewing the SQL for the taPMManualCheck stored procedure, I think I found the bug. To verify my suspicion, I imported a new payment with Payment Method of Cash. Sure enough, the imported Cash payment has the same issue: the Total field is zero.
And the record in PM10400 has the same issue--the CHEKAMNT field is zero.
Looking at the Insert statement that is being called by the taPMManualCheck stored procedure, you can see that it is inserting the value using a parameter called @CHEKAMNT.
The fact that the field is called CHEKAMNT and the parameter is called @CHEKAMNT should be a clue as to the genesis of the problem.
It would seem that the Payables Manual Payment Entry was originally designed to only record payables "checks", and was subsequently modified to support Credit Card, Cash, and more recently EFT.
eConnect was updated to support Credit Card and Cash (it does not support EFT), but when updating the taPMManualCheck procedure for those two new payment methods, this "Total" amount / CHEKAMNT bug was introduced.
For some reason, two new parameters were added to the stored procedure to differentiate the Cash Amount and Credit Card Amount values.
But although these parameters are set based on the payment type, only the @CHEKAMNT value is used for the insert to PM10400. So it looks like the developer forgot to make sure that the appropriate amount parameter was used for the actual Insert.
So how do we work around this issue?
One easy approach is to use the taPMManualCheckPost procedure to fix the problem. This script in the Post proc appears to work well based on a quick test.
However, if you have ever used the eConnect Pre or Post procedures, you likely know that the big downside is that they typically get wiped out when a GP service pack is installed or GP is upgraded. Nearly everyone (including myself) forgets that they have the custom Pre / Post scripts, and it takes a few weeks after an update or upgrade before they realize they have bad data in GP due to the missing Pre / Post proc. So for that reason, I am not a huge fan of the Pre and Post scripts, despite their convenience.
So for my application, instead of using the Post script, I'm going to add the SQL update to my .NET code, so that my application performs the update of the CHEKAMNT field after the Manual Payment is successfully imported. That way the customer doesn't need to install a custom stored procedure and remember to update it after any GP upgrades.
And with that long winded explanation of another eConnect bug, may all of your future integrations bring happiness and joy to your Dynamics GP users.
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