@jgehling don’t pass this offer up 
1 Like
Good Morning,
Sorry for the rant. I realize its easy for me to stand here on my soap box and sometimes it’s too easy to fall into the rabbit hole of complaining, (and what triggered me was leaving the home screen up (no ERP apps open to go get a cup of coffee and coming back to this error:
Thank you everyone for your responses. EMS backs up all of our databases nightly at midnight. We definitely did try re-creating the invoice issue again in our test environment after a refresh and the bug did not re-appear (the invoice for the same customer for the same order was automatically generated successfully). This invoice issue uses the Erp.Internal.AR.CreateInvFromShip.dll as they were not created manually. This has gotten traction and our database is being sent to development (but only after much pressure and reaching out to senior support staff directly)
Hey James,
We have been on Epicor since 10.1.400 and upgraded to 10.2.300 this January, and we have never seen am invoice issue like this before. We did do all necessary testing before going live on this version and everything went extremely well. This issue is just so sporadic and cannot be reproduced on command.
Jeff, I assumed you had tested thoroughly as I said in my OP. My point is that despite everything you have done, your business is losing faith in invoicing - 22 invoices being totally wrong even out of thousands is just not right- get your management to start to put some pressure on Epicor management about this release impacting on your ability to trade.
2 Likes
I feel the same way… Epicor is great at the fact that you can customize much of it in order to fit your needs, but support and specifically Development are hard tow work areas at Epicor.
As you said, most of the times support/development will reject the issue if you can’t replicate it which is awful. There are a lot of processes run in the background so we as users are up to a challenge to find out what exactly is provoking that behaviour.
Escalating doesn’t do a thing to solve issues, and when you ask to some insights of how Epicor operates that process so we(the customer) can test and test until we can get a way to replicate the response is nonexistent. No info about it is relayed to the customer(which is no complete surprise of course)
We are a company that actually have quite of bugs discovered, probably it is also our “fault” in the fact that we are quite a special industry, but come on. I had an issue with the configurator, which rendered the operation useless since the configurator took 55 minutes to close. The solution took several months to actually being adressed by Dev and still they would fix it on 10.2.200 (at the time not even 10.2.100 was available), of course we manage to pushed for solution on 10.1.600 but it took a lot of time and convincing.
Another awful project managment is CSF, they tend to solve only the basics and “hard code” solutions that are no good, even when you try to explain them exactly the issue and how it would be solved for any customer.
I have cases with MRP, MES, WorkQueue, etc. all gone to Development, but the solutions take months normally, from the moment you can persuade support to address it to Dev to the actual solution which pretty much always is bound to be solved on another release or minor version, not even a patch…
Well I pretty much vented, I guess I just needed to get started haha. But bottom line, you are not alone.
1 Like
Just to add to this rant - we all use Excel, we buy it for a couple hundred bucks a license, and nobody ever checks the values in a column to make sure the “Sum” function is actually correctly summing the values.
With ERP software, the assumption is that it won’t work, and that has to be determined and fixed prior to implementation.
Being that ERP software is one hell of a lot more expensive than a spreadsheet, it seems to me that our ERP suppliers have lost vision of their customer’s needs. The assumption that it works properly is only made by the folks creating the code. The marketplace fully understands that it’s highly likely that the product will not work as advertised.
3 Likes
My Users sent SO Acknowledgements and didnt check the Total when Taxes were included on the SO (which Epicor fixed in 10.2) but now when I send Customers an Invoice with the surprise addition of tax on a million dollar custom built fire truck, they are not obligated to pay it – since our SO Acknowledgement was our Legal Agreement. Sucks to lose alot of money. Its easy to say well you should have checked the Report… At what time do I stop doubting the ERP Software? and start questioning my sanity instead of the Computers.
Not all is perfect, definitely room for improvement. Regression testing should be improved on ERP Vendors side… Even an issue on BOM could cause a ripple effect of Vehicle Recalls, in a bundle of 800 materials that 1 strap or screw for example comes in at 0 qty and is missed, causing an airbag to not kick-in 
That can also be caused by human error, absolutely - but theoretically let’s assume Engineers triple checked it all before Checking In the BOM and it just got messed up on Job Entry.
Id like to use it like I use a Calculator, 5x5 = 25 and not 5x5=25(let me verify that just incase 25/5=5)
I wonder if anyone doubts TurboTax or HR Block, like prints out the PDF and goes to a Tax Lawyer and gets a second opinion - or - do you just have faith in it? When I spend 79.99 I usually trust it blindly 
4 Likes
I’ve had/have errors in mine, and when I go to a professional, he gets me out of self employment tax for some limited freelance work that I do. He has to send a letter to the IRS to do it. Turbotax won’t do that for you. So I just have to justify if the taking an afternoon off work and paying $400 is going to be worth it compared to the $80 I spend on turbo tax. Sometimes it is, sometimes it isn’t.
Wish this was something new. I remember implementing a new release of Syteline (another ERP) in 2000 - a much bigger undertaking than what we do today - specifically to fix some major bugs. We found some new bugs which caused significant problems, which, wait for it were fixed in the next release which was being released imminently.
Been in this game a while and around about the mid-90’s previously stable systems introduced GUI/windows compatibility and we started to accept broken, fixed in the next version, software. First 10 years or so th of teh 21st century things stabilized not least as lots of players ran out of cash to enhance their systems and quite a lot of vendor rationalization. Even things like mobile integration were half ass*d bolt ons rather than trying to provide the same experience.
Past ten plus years have just been constant flux/change with everything from mainstream virtualization through SAAS/evergreen IT through IOT to real time analytics to device agnostic ux. Throw in Epicor ditching the RDBMS/4GL they had used previously and perhaps things are being spread to thin.
We all love that Epicor is very much a “core platform” that we can easily customize to do lots of cool stuff. But as businesses, and back to the OP we expect the basic estimate to invoice and all steps in between process to work without really checking (like the excel analogy above). It is the mods/customizations and the more niche, esoteric modules that we expect to have to test/expect issues with.
I know this started as a rant about E10 but I can’t help think that costly monolithic ERP is a bit of an aging paradigm and scalable easy to “stack” best of breed apps may well be the future.
We could run our business on spreadsheets/access db’s but that would be like Fred Flintstone’s car. ERP sold as a Porsche/Ferrari/rolls Royce but can’t help thinking that, to quote Top Gear, it is an Alfa Romeo that it looks great and fun when it works but you better be prepared for all the times that you will be on the side of the road with smoke coming out of the engine.
3 Likes
FIAT - Fix It Again, Tony
1 Like
Run it on Dell servers - Doesn’t Ever Last Long
This is a warped idea that’s been infecting the entire tech industry. It’s led to major issues going unfixed for years in supposedly premier software from top companies. I’d consider identifying and fixing bugs without clear steps to reproduce to be a basic skill requirement for any mid-level developer.
A planes service log:
Pilot: “Engine noise at altitudes greater than 10,000 feet”
Tech: “Cannot reproduce in hanger”
2 Likes
As a developer I got to say it is nearly impossible to find a bug if you can’t replicate the behavior and I’d argue that the Airplane Tech will take that plane for a spin to witness the behavior themselves if they can’t find the problem without being at 10K feet.
Same goes for a car mechanic I don’t know any one that won’t take the car for a spin to find the source of the “clank”
The only way to identify bugs without testing is to have some heavy TDD in place and some software validation.
If you can algorithmically prove out (mathematically) software using Formal Software Verification Systems you can guarantee its bug free however that’s a theoretical / unrealistic solution in the real world.
https://www.quantamagazine.org/formal-verification-creates-hacker-proof-code-20160920/
4 Likes
Speaking from long experience as a developer, that’s simply untrue. If you know your software, you instinctively know which parts could cause the error described, and you go and look at those parts and usually find the problem. Sometimes you don’t even need to look; you instantly know what the problem is when you hear the bug report. This is true even in highly complex systems, provided the architecture is clean.
If I were an Epicor developer, I’d want every single bug report to come across my desk no matter what. A large percentage of issues probably are (or originally would have been) five minute fixes for someone familiar with that module. But they go unresolved for years because the right person didn’t see them or didn’t have the authority to apply the fix. As time passes, developers lose familiarity with their own code or move on to other projects or companies, and the cost of fixing minor issues increases. If bugs aren’t fixed quickly, it doesn’t take long for the cost of fixing the backlog to exceed the cost of rewriting the whole project from scratch. The backlog grows faster than the company can keep up with it. Even the overhead of identifying duplicate reports becomes overwhelming. And that’s when you start hemorrhaging customers and developers… coughAndroidcough
1 Like
Unfortunately with Agile development (Scrum), it’s doubtful any developer owns any functionality. Multiple teams could be developing in the same modules, so the most efficient way the support development team can troubleshoot the issue is by knowing how/when it breaks.
One of the core tenets of Agile is collective ownership:
Collective code ownership, as the name suggests, is the explicit convention that every team member is not only allowed, but in fact has a positive duty, to make changes to any code file as necessary: either to complete a development task, to repair a defect, or even to improve the code’s overall structure.
When companies don’t operate this way, you can smell it from the outside.
This may be true of a tiny app maintained by a single developer (or a couple). But any application of consequence built by a company with a team of dozens or hundreds of developers over a period of 30+ years as Epicor has been it is impossible for anyone (even the product owners) to know all intricacies and specific details or behaviors of an application which is why it is necessary to be able reproduce the bug to identify it particularly if its a conditional bug that only happens when two different stars are aligned during the lunar cycle on Tuesdays.
Last time I inquired Epicor (core) before kinetic etc has 172 million lines of code.
1 Like
What you describe requires employee IP to prevail. At scale it’s simply not practical to operate that way. Across hundreds of developers, thousands of customers, multiple countries (enter language barrier) and several decades, it would be a disorganized mess with direction of the developers changing with the wind. A small software company (I.E Insite/Quickship for a long time) can totally get away with this, but anyone large it’s just not possible.
This thread is a perfect example. Jose and I know the ICE framework at the nitty gritty level, where the sausage is made, and I couldn’t even tell you where to start with this. I would never report this to development and expect them to do anything with it.
1 Like
at scale nothing will be 5 min. Unit testing and regression testing and user testing all has to be done even for a simple change. Example maybe someone used a hard coded string somewhere (some crappy code it is what it is) and a dev is like hey this string is causing the issue, and changes it. Now it breaks a hardcoded string condition somewhere.
Probably an extreme example, but you get my point. When you’re dealing with GBs worth of code and 1000s of classes with crazy dependency structures Butterfly Effect takes hold.
1 Like