We had a recent incident when we tried to check a Pack Slip “Shipped” checkbox we were getting a “Correlation Error”.
We tried a number of things trying to figure out why - not realizing that Every time we checked the “Shipped” checkbox our customer was being charged a Credit Card Transaction. So because we tried a number of times we ended up charging the customer $30,000.00 for a $1,000.00 item - VERY embarrassing.
Is there any way or setting we can make that will prevent this in the future?
Open to all suggestions,
Let me guess, you use epx? You can NEVER click shipped again on a credit card order once it fails once. Stop. Do not pass go. You have to remove the credit card from the sales order and recreate the shipment before marking it shipped. We learned this a hard way when a customer showed up in person to demand a refund of 14k for his $100 order.
A BPM that looks for the condition that IF the status changed from Shipped to Unshipped AND that it is a credit card billing type, THEN raise a warning message to the user to not mark the order shipped again unless the credit card is removed, or stop and escalate to someone else, etc.
Mr. @tgwinn - I must confess I don;t know for sure the status ever changes. The Correlation error pops up and the Pack is NOT “Shipped” - I would have to check that out in Pilot. BTW: the correlation error was a BPM that was not EF6 Core and that is fixed now.
I am trying to provide management with some kind of prevention plan.
So when this happened to us, we were never able to find the error. The errors are shared in one log file for all epx customers and support can’t find your particular error.
Ms. @aosemwengie1 I was able to trace the correlation error after downloading the appserver files.
The Credit Card Log is in CRECreditCardProcess.log
The CC process worked without error - that was the problem. as far as CC processing was concerned - everything worked just fine.
I just put in a ticket with Epicor and they are saying that simply clicking on the “Shipped” checkbox creates a CC transaction and they recommend:
Hi Dave,
It cannot. It is affected at the moment you select the checkbox, not when saving. Cannot be changed unless you customize the screen.
Part of the process is to automatically do everything when selecting the “shipped” checkbox. If you don’t want it to charge when you select the checkbox, remove the “credit card” checkbox from the order. Then manually charge it with a deposit and manually create the shipment invoice after.
Nah, that’s normal nowadays. It’s becoming remarkable as an end user to see a charge deferred to shipment. More like, seeing a refund a few days later if it turns out something’s not actually available to ship.
It does make sense and it’s robust. The charge is associated with the order, the order can be invoiced leaving shipment as a liability, and the invoice is charged immediately. Refunds are handled as credit invoices. Impossible to double charge if accounting has basic functionality, and everything has a rock solid audit trail.
Linking the charge to the shipment action is what I find unexpected, outside of (ie) UPS anyway where the shipment is the explicit (no pun intended) deliverable. For the rest of us shipment isn’t our liability to the customer. It’s just a strong “should” as shorthand in the process for most of us.
That isn’t the issue. The issue is that the charge can succeed but TELL epicor it failed. Those two things can NEVER be allowed to disagree. That is a complete failure of design and software engineering.
Go to Company Configuration/materials/shipping and change the shipping service to Web Services. I should add that we are using QS and the REST service has issues. We had all the same symptoms with the CC getting hit multiple times and never able to mark ‘shipped’.
I have been switching back and forth between the services depending upon the shipment.
REST does not work if the billto and soldto are the same.
REST International paperwork does not include all the sales orders.
Web international paperwork does not include discounts.
And one of them does not work with a misc charge in % vs amount.
i know we had this problem on the last QS version too. It was upgraded the other day.
Regarding the international paperwork, I believe the REST-related issues were expected to be resolved in the latest release. I’m not completely certain at this point and am waiting for Shipping to verify.
Unfortunately, the frequent switching between services, combined with a lack of coordination around which service was used for each shipment, has not been managed particularly well. In most cases, the message we receive is simply, “This has to ship today,” and we end up making it work without much opportunity for planning or process consistency.
While I am at, another thing i noticed is that a CC need not be involved with the inability to mark ‘Shipped’, in all our cases there was an integrated carrier involved, Fedex and UPS.
We’re patching this weekend. The tests we ran the international was much more consistently correct. But your analysis sheds some lights on what we need to watch out for.
