Epicor recently dismissed a confirmed bug—verified by its own support and development teams five months ago—as a new feature request. To compound the issue, an Epicor admin created a vague, low-quality “idea” in the Ideas portal on my behalf. This action effectively shifts the responsibility for fixing a defect from Epicor to its customer community.
This move sends a clear message: fixing a confirmed issue is a low priority unless it gains enough community votes. This process is fundamentally flawed. A bug is a defect in existing functionality, while an idea is a request for new functionality. By misclassifying a known bug, Epicor’s support process fails to address critical issues and undermines the purpose of both the support and Ideas portals.
Ignoring Real-World Business Impact
The decision to treat this as an “idea” completely ignores the significant business impact of the defect. This is not a minor, cosmetic bug; it causes tangible, quantifiable problems for our business, including:
Wasted Time and Labor: The need for manual corrections to fix transactions wastes valuable time and labor.
Inaccurate Financial Reporting: The issue leads to incorrect financial postings, which violates GAAP (Generally Accepted Accounting Principles).
Increased Audit and Compliance Risk: Incorrect financial data poses an increased risk during audits and could lead to significant penalties if identified as a material weakness in internal controls.
By dismissing a problem with such a serious financial and operational impact, Epicor demonstrates a profound disconnect from the real-world needs of its clients.
A Broken System
The inefficiency of this process was highlighted when an Epicor Ideas admin asked me if I had submitted a support case after development created the idea on my behalf. This demonstrates a complete lack of internal communication and a siloed system where the left hand doesn’t know what the right hand is doing. The lack of review or basic coordination is a disservice to customers who invest time and effort in reporting issues.
This experience suggests a systemic problem with how Epicor handles bug reports and manages its customer feedback channels. We expect a transparent, efficient process for addressing confirmed defects, not a redirection to a public voting system.
Add “Material Availability Check Before Queuing Next” Check Box in Operations in Engineering Workbench
Description:
In Job Management, when an operation is completed, the system automatically queues the next operation or stage, regardless of whether the required materials are available or issued. This can cause jobs to move forward prematurely, leading to disruptions if critical parts are missing.
Proposed Enhancement:
Introduce a Hold for Material checkbox option in Engineering Workbench, Job Entry, and Quote Engineering that allows users to require material availability before the next operation is queued. When enabled, the system would hold progression until all required materials for the next step are confirmed as available or have been issued.
Agree, it has been trending this way for a while. But I find it extremely concerning that an Idea was created under your name without your knowledge. That is not right.
Sorry if this is backhanded optimism, but I hope you are the one that finally gets through to “them” on this.
Maybe that’s the issue - I don’t know who “them” is.
Support? Not exactly; they’re the messenger (though you don’t get an overwhelming sense that they Take Up Your Cause).
Dev? Usually they see the light, I’d say. But like any of us in IT, we go to the loudest screams and/or what execs are excited about currently, and important things just get kicked down the road until sufficiently forgotten.
If there is a dev team that gets assigned bugs with posting/GAAP/data integrity, well they could give Area 51 tips on hiding.
If I don’t get too depressed, I could come up with a list of tickets and ideas I have submitted over the years on these kinds of things. One or two have made it to production (in 9 years).
I mean a list of issues like yours - things that cause accounting to fail basically.
No, it’s not like bank accounts are being embezzled, but there are so many holes in the posting engine, that I can’t tell you how often I wonder why we don’t just manually journal all transactions for the whole month by hand.
But to turn these into Ideas to vote on is utterly stupid - not just the principle of it - but for the simple fact that no one is interested in the bug that you found unless they also have been bit by it. And there is just hardly any overlap between people voting on Ideas and people that care about the posting engine.
If it’s generating bad finances, it must be fixed, regardless of how popular or sexy the problem is.
They do that all the time. They tell me to create an idea. Then I say no I will not create an idea you need to submit this to product development. Then they create the idea anyway and close my support case. Then the idea gets ignored, or occassionally, somebody on the product side will comment on the idea and ask if a support case has been entered. The whole system is designed to jerk us around and is an insult to us as customers who work extremely hard both to communicate issues to epicor and to work around the issues with our users in the absence of legitimate solutions which Epicor should be providing to us.
@Kevin_Barrow I wanted to add some context to my request for a support ticket. Whenever there is a suspected bug, it would be helpful to have the PRB or the case ticket so we can investigate further. In the case, we’ve looked at the PRB and have asked for clarification of why the team feels this is an enhancement. What was written was very detailed and structured, so very much appreciate that level of information!
We (product management) aren’t being difficult when we ask for more data, it’s so we can fight for our users.
If I am reading correctly. How can a problem be created without at least one case in the first place? Which should be linked. Frankly, asking the customer to do supports job is WRONG… Particularly if the ordinal case supplied all the relevant information.
Epicor customers are trying run a business and don’t work for Epicor it’s the REVERSE. Yes there there will always be the customer that takes that the extreme but most of us a fair and reasonable.
Reporting an undocumented feature is not an attack, it’s an opportunity to make improvement.
Clearly there has been another breakdown in process…
Suggestion, perhaps it’s time Epicor introduced a more modern approach of a Technical Account Manager TAM like Amazon does… Don’t get me wrong it costs. Clearly the current model is not working and bringing back the “Build Business (the customers business) not software” approach has fallen off the radar.
If this thread is not a last resort cry for help I don’t know what is… This problem needs to be addressed…
Last “Frideas” (two weeks ago) it seemed like the consensus is that people here love bugs in Kinetic so that they can fix them and have a day job.
I’m still fighting this concept. If you all love re-creating reports for Epicor, well have fun.
But I just cannot shake the idea of patching all the holes in the Posting Engine - if you even find them. I definitely get tired of explaining to accounting why nothing ever fully reconciles or that the transaction hierarchy has an error on nearly every page.
On that note - here’s a pic of the 2025.1 guide. It takes all the way till page 3 to find an error. Still cannot spell CST correctly.
Have I ever reported it? Nope. Ummm… have you read this thread? I’d have to submit it as a product enhancement and wait for enough votes.
This may seem like a silly example, but I include it because it’s easy to explain.
The more complicated ones are the real challenge. We find them and know that they are legit problems, but reporting them goes nowhere. 2 votes, 7 votes, expired. These are not fun or cool and they have zero impact on writing C# code, so no one cares to vote for them. But they do matter to the real people that use the software and the people trying to run their businesses who couldn’t care less about the REST API.
There just needs to be a separate dedicated team for financial bug reporting, specifically. People who get it. If it’s not about Application Studio or BAQs, no one listens today.
The other reason I never report ADJ-CUST is because it’s my bellwether.
I’ve always wanted to see how long it would take for someone else to find it - especially inside of Epicor. It’s not like this document is an obscure one; it’s pretty fundamental to accounting.
I did the same at my job, wondering how long it would take to correct “Light PBracket” (silent P I guess) or a “Servere service” part we use on like 50% of builds.
So far only the first one has been fixed. It’s best if I do not say how long these have been around…
To summarize the issue for the updated Epicor Idea, I had to review the original ticket, which could only be located by searching for the associated PRB. The whole system is a convoluted mess IMO.
I have had a similar response to the issue we are experiencing. After many hours of Teams calls and various testing, the conclusion is they don’t know why it’s happening so it must be working as designed and I should create an enhancement request. I pushed the issue because that answer is not acceptable and I pointed out again that it clearly isn’t doing what it’s supposed to do and they agreed with me. Even still, they essentially shrugged their shoulders and repeated that I should submit an enhancement request. It isn’t an enhancement I wanted, it’s a FIX that is needed! I have no problem submitting an idea, but the fact is it will likely go nowhere if left up to votes. I understand that they can’t fix everyone’s issues at once, but this idea of having to get votes is seriously flawed. If it isn’t working like it’s supposed to, FIX IT.
Going to tone down my response a bit… It’s actually a partnership. Where the customers TRUST Epicor to work with them to help them grow and improve their business… There is a level of TRUST that the product that is being delivered is fit for purpose, and for the most part it is, until it’s not.
