Any users knowledgeable with the Credit Card module? I couldn’t tell you which one we use… but…
Once upon a time, our Credit Card transactions were referencing an invoice that didn’t exist. I don’t know why, but it was right after we went live. It was thought that maybe they were the invoice numbers from our previous system. In any event, we have a bunch of Cash Receipts that won’t post and it seems like it’s because the invoice that we recently created is the same as a very old credit card transaction is referencing. I was able to do a UBAQ and update the CreditTran table to refer to the correct invoice numbers. But my cash receipt still won’t post. Then I thought it might be because we already had the same Check/Ref number entered as well. When the cash receipt was created, it seems to have pulled in the same Check/Ref number from the very old credit card transaction. I tried to delete the Cash Receipt and it won’t because it’s linked to a successful credit card transaction. I also tried to change the Check/Ref but it says I can’t change the invoice. Can someone help me make sense of this? Anyone? Where do those Check/Ref numbers originate? The Invoice maybe? Can I edit them there?
I thought we had this resolved… but no sooner did I mark this as solved as I had reality slap me in the face. The issue is not that we had a bunch of credit card transactions that referenced an invoice that didn’t exist. THe issue might be better described as new credit card transactions are happening but the invoice they are associated to is mistakenly getting updated on a previous credit trans record. It appears we’re getting duplicate PNRef values back from the credit processor and I’m suspecting that the business logic is updating the first PNRef value it finds (probably because they are supposed to be unique). Does anyone here have credit card experience? Can anyone recommend someone?
It started about 8/25/22. It was noticed fairly quickly, but we didn’t know what we were dealing with. We thought the cash receipts were just stuck. And so we spent last month working with Support to get fixes to “unstick” them and correct shipment statuses, and so forth. It wasn’t until late last week that I “took a closer look” and started to notice these irregularities. The problem is persisting daily. It seems random. But all the transactions that are broken all have this short 6 digit numeric PNRef starting with 000… all the ones that succeed and process normally have a 19 character alphanumeric PNRef (looks more official).
Does anyone know how to change the sequence of the PNREF field? It appears to have started counting up from 0 at go-live but on 8/24, it went back to 0 and restarted. Now anytime it reuses a PNREF, the credit card transaction gets stuck. I want to tell it to go back to where it left off!! I don’t see it in the Company Configuration anywhere. Is there a table that stores Epicor sequence numbers I could check? Maybe I could edit it through SQL (gasp I know). I’m desperate.
This happened to me before when support moved the credit card path. Thankfully we had only had about 100 duplicate pnref numbers until it went away. IIRC, the pnRef was stored outside the ERP in a DB file.
EDIT: It looks like it’s a SQLite database called “configuration.db”
That field comes from the gateway (credit card processor) and should be a unique alphanumerical value. This is not actually generated by Epicor, a possible solution would involve asking your credit card company to provide all your daily batches to review that data.
That’s what I was led to believe… but this number is clearly counting up from 0. That must be coming from within our local environment, right? The only transactions that appear to be a unique alphanumeric are the Visa sales type transactions. All others seem to use this 6 digit PNREF.
Copy the configuration.db file from the %programdata%\Epicor\CRE\Payment App directory from the server and look into it using SQLite Browser and see if you can see your current PNRef in any of the tables.
@Doug.C thanks for the suggestion. We were able to find this table but no reference to a PNREF that I could find. We did find a Last Updated date that matches the date in which we “restarted” our count.
UPDATE!
We have finally found the place where this sequence is stored. @Doug.C - you were very close to the exact answer. The file ended up being FDMSstanNum and it was located in PaymentAppData\Logs\Gateway\SRTP\FDMS folder. It’s a file with no extension and when you open it in Notepad, you get a single number. This is the LAST USED PNRef number. So the next transaction will be 1 higher than this number.
Evidently we switched to CRE at some point from another processor and the previous processor used a very long sequence (like 19 characters). Our version of CRE was out of date and there was some tokenization process that needed to happen (and did not) which was possibly allowing the long 19 character PNRefs to continue to populate. But that wasn’t really our issue.
The issue was that the 6 digit PNRefs reset at some point back to 0. According to support, this number can be reset if the log files get deleted… it will recreate itself and start at 0. We’re not exactly sure what event caused us to reset… but it can happen. If it happens, the solution is to look in the CreditTran table and find the highest 6 digit PNRef number and enter it in the file I mentioned above.
