Anatomy and Time Line of a support case that was successfully resolved to our satisfaction

[josecgomez]

So, a lot of times people come here to gripe about Epicor support and when / how it doesn’t work. I figured I’d throw in some love their way and narrate my case from beginning to end and its outcome along with a timeline.

We use recurring AP Recurring Invoice functionality 2 weeks and we found issues with the GL Distribution of these invoices when they generated. We did our own investigation and figure out what the problem / bug was and we submitted the below case on Jun 20th

Case Details Here (Long)

We use the AP Recurring Invoice functionality quite a bit and we have found 2 data corruption bugs which make it impossible to successfully use the functionality.

I have detailed extensively how to re-create these issues in the video below since it is a complex process to re-create, however we have over 200 reoccurring invoices which are affected by this bug and we would like to get this fixed. We have 2 weeks before the next batch of 200+ invoices needs to be generated.

Video Walk Through of the Problem:

https://www.youtube.com/watch?v=M9pgmg1ynUg This is a link to the problem outlined below being described in detail in a walk through video so that it can be used to replicate the problem

Detailed Steps to Recreate:

Problem 1:

1. Create a recurring AP Invoice for any amount
2. Add 3 lines to the Invoices
3. Add a GL Account to each of the 3 lines on the invoice
4. Delete the Second Line on the Invoice so that you are left with Line1 and Line 3
5. Run the Edit Report and make sure the Invoice Balances
6. Select the Recurring Schedule (1 day may be best so you can easily test)
7. Post the Invoice
8. Once the Invoice has posted successfully go generate the “next” occurrence of the above invoice
9. Run the Edit List Report
10. Invoice will be out of Balance
11. Looking at the TranGLC records for that related invoice you will see that it created 2 transactions
12. One pointing to Line 1 (Key3) and one pointing to Line 3 (Key3)
    
    
13. However the invoice only has Line 1 and Line 2
14. The issue appears to be because the original recurring invoice had a Line1 and a Line3 so the copying procedure that epicor uses for recurring is failing to see this and correct that in the new invoice.

Problem 2

1. Create an AP Recurring Invoice in any amount
2. Add 1 line to the Invoice
3. Add 2 different GL Line entries to the line above
4. That is distribute the GL Debits across 2 or more GL Accounts
   
5. Make sure the invoice is balanced run Edit List
6. Post the Invoice
7. Once the Invoice is successfully posted
8. Run the next iteration of this recurring invoice
9. If you go check Line 1 GL Tab on the new invoice you will notice that it is once again out of balance
10. This time the issue is in the ApInvExp table if you look at the records created there you will notice (2 or more) entries
11. These entries reference Line1 as well as Line2
    
    
12. If you recall our original invoice only had 1 line, the issue here appears to be that again the copy procedure to generate the next recurring invoice automatically increases the line number for each entry in the GL Analysis tab. So if you were to put in 10 GL Accounts on Line 1 ti would generate 10 lines worth of data inside the ApInvExp table which again causes the invoice to not balance.

All of this has been carefully demonstrated in the video above and you should be able to easily replicate in the training DB.

We await a prompt resolution.

6/20
The case was assigned 10 minutes later to an Epicor Support Analyst named Gina Zaldivar
I received an email from Gina right away telling me she was going to follow my instructions and details to verify if she could replicate the issue and she would keep me informed.

6/21
She replied the next morning just shy of 12 hours later that she had successfully replicated the problem (both of them) and that she had escalated to development and assigned a Problem Number for Development

7/1
New AP Invoices generate with the same issue, I email Gina with a reminder about my case, she replied immediately that Development is still working on my case and that she will request an update from them.

7/3
The problem is accepted as an official bug by Development (automated email)

7/4
Gina emails me to inform me of the change and lets me know that there isn’t a timeline for a fix but it has been added to the development back log. She will contact me as soon as there is an update.

7/8
Problem is changed to Release Panned (Automated email)

7/10
Problem is changed to In Progress

7/24
I receive a follow up email from Gina informing me that Development is still working on my case.

7/31
Problem state changed to In Progress (again) Automated Email

8/07
Problem changed to resolution in 10.2.600 (I reported this in 10.2.300) I was a little alarmed by this since that’s 3 MAJOR upgrades from where I am however I let the case progress

8/8
I receive an email from Gina that the issue has been resolved and is being tested

8/14
Status changed to Testing (Automated email)

8/16
Receive an email with an estimated delivery for my version .300 of version 26 eta released October 1st. Tested and cut to production.

8/16
Case is resolved, pending the .26 release.

Over all it took about 2 months for the case to work its way through the different Epicor Support channels, the case was never dropped or forgotten Gina was prompt with updates as she received them and she kept me appraised of progress.

A few lessons learned

1. Troubleshoot as much as possible the issue on your side, make it possible to replicate on the support end. It is really hard (nearly impossible) to fix something that can’t be replicated. I know all users aren’t technical enough to do this, but try your best to provide as much information as possible

2. Understand that you aren’t the only customer with issues and that the issues are solved based on the critical nature of them. This was a data corruption bug that caused no real harm other than annoyance which required us to re-create invoices manually. It is work for us, but at the same time nothing we can’t live without

3. Software Development takes time! there is a lot of testing, regression testing, debugging and more testing that goes into this. So even after your bug is located it will take significant amount of time to fix.

Remember Support folks are human like we are and sometimes you’ll get a grumpy tech or a less than stellar person on the other end. But that is not always the case, a lot of times you get lucky and you get someone like @aidacra or Gina and things can and will work as they should.

We are satisfied with this resolution, it was a little longer than we would have liked but in the end the case was taken seriously, quickly assigned to a qualified person and handed over to development. So support does work, though it requires some patience

3 cheers for support on this one, great job Epicor.

Note I received no payment from Epicor or support about this testimony and those Brownies that they sent me have not affected my account of these facts in any way

[kfierce (Kristine Fierce)]

We are seeing support cases be completed for bugs reported in 10.2.400 too. Sometimes all we get is that the issue is fixed in 10.2.500 and oh one day it also shows on the release notes for .400. I do wish we would have more information if the fix is approved for current version and not just fro the next one. Just my two cents. We have 3 problems that just got fixed in 400.7 and 8 which is awesome.

I suppose anything less than 2 month turn around from reporting the issue, replication, development, qa testing and release is going to be hard unless it is a major functionality break for most companies that does software development. It is easy to get frustrated when you have an issue that is affecting your business and you don’t feel you don’t get response or updates frequently enough.

[ckrusen (Calvin Krusen)]

While I’m sure you could figure out work-arounds for these (a BPM to check for breaks in line nums for #1, and just making multiple lines with one GL each, for #2), did support offer any? Other than “well, don’t do that…”

[josecgomez]

There were no work around since it’s a data corruption bug.
The recommended work around was delete and manually re-create the invoices (which does work) obviously.
Though it’s painful

[Jason_Woods]

Thanks @josecgomez . There are a lot of great support people at Epicor. I find if I give good instructions to replicate an issue, I can get good response and traction (although sometimes I have to escalate past a current support person).
I would agree with @kfierce though, it’s nice when I’m told if it is fixed in the current version.

[AndrewM (Andrew)]

Having worked in support for another large ERP system, I can confirm that timeline is pretty standard and not just for Epicor. You have to remember that every person will have their queue and will be working through each issue in it.
As said, one of the best things to do it make sure you can replicate the issue. Try and work out replication with as few setup steps as possible. The hardest is when you get an issue which is ‘our user received this error’, without any indication of the steps they took to get there, if they have seen it before or if it actually had any impact.
One other piece of advice… be friendly with support. Screaming and shouting about the issue you’re currently facing might get THAT ISSUE resolved faster but will generally mean support are less likely to go the extra mile for future issues. You know, those ones that are in the grey area of a supportable issue. Some in support may be able to offer assistance with a customisation that will get you going.