We recently installed a minor patch update from 10.2.300.20 to 10.2.300.37 to fix a few minor issues we had been seeing in our version. I had been reluctant to update without testing all of our business processes but I read through the release notes between the two minor versions and found no mention of anything major that we should be concerned about. Besides, we tested the issues that were broken and now they were fixed (yay!).
About a week after the update, an accountant mentioned that we were no longer charging tax correctly on service calls. I knew to look at the BPM I had created to calculate tax on ARInvoice.FSCalls (OOB Epicor handles service call billing as one lump sum which is a tax no-no). After some investigation, it appeared that the method with the BPM attached (ARInvoice.GetFSCalls) was no longer getting called through the interface. Epicor decided to use a different method (ARInvoice.GetFSCallsJobs) so they could return a popup list of service jobs being closed during the call.
Ok. That seems pretty significant to create a new method on a business object and start calling that one instead of the old one. I must have missed something in the release notes. However, upon reviewing the release notes, there was no mention of why this was changed nor when it was changed. I thought, wow this is a big deal, so I contacted my CAM who then told me simply to contact support. A bit frustrated, I opened a support ticket and eventually got this response:
This was introduced due to ERPS-117790. The signature of GetFSCall did not change even if the system doesn’t call GetFSCall. It is still available as it was throughout 10.2.300 with the same signature.
The ARInvoice.GetFSCalls method still exists and this method is doing the call to the new GetFSCallsJob method.
The Problem is the UI was changed to call the new method, so the BPM is not triggered because the old method is no longer called by the UI."
I see. People make mistakes and maybe they forgot to put this in release notes. I search EpicWeb for this KB but can find it nowhere. So I asked why this was not referenced at all in release notes. How do I know to test this functionality? Isn’t that what release notes are supposed to tell me? Got this response:
We want you to know that we take your concerns seriously our development team will consider to add this type of changing notes going forward. The signature of GetFSCall did not change even if the system doesn’t call GetFSCall. It is still available as it was throughout 10.2.300 with the same signature.
The signature of the GetGFSCall method didn’t change , so it would not have been mentioned in the release notes
Thanks for considering mentioning something that may break a fix put in place to fix your already broken product functionality Epicor!
I was referring to the Change List - PDF section which is an accumulation of all the updated modules and the resolution types between minor revisions from the base version. I focus on the “All Changes” and “Software Interface Changes” between the version I have installed and the version I plan to install.
I added my +3 votes to Ideas. We got seriously burned when upgrading from 10.2.300.x to 10.2.300.y when they added an undocumented requirement that the counter sales prefix can only be 1 character.
Trust us, they say… Dot releases are minor changes that don’t affect the framework they say… Just install the patches and don’t worry about doing a full month-long testing series with each department they say. Ha ha! I won’t do that again… I wish we could patch earlier and more often, but it needs to be tested, especially if the release notes aren’t documented well.
Honestly, even IF changes are documented perfectly, will the users read them and test those items properly? And still, should we only test our modifications or also the functionality we expect to see in the product?
I think I would prefer Epicor’s help in created automated testing - as one might do in, oh, I don’t know, maybe…
@Mark_Wonsil I strongly agree with this as well (https://epicor-manufacturing.ideas.aha.io/ideas/ERP-I-139), that will be awesome when that day comes. In the mean time, the fact they are missing system behavior changing release documentation to me either indicates a lack of discipline or a lack of customer awareness. As far as customers reading the notes, that is on us and Epicor should expect nothing less of us. They can throw it back at us or ignore us if we don’t do our due diligence!
Voted!!!
Also @Mark_Wonsil in regards to automated testing, there it the Epicor ATE tool which allows you to script out tests. I need to spend more time with it, but it seems very powerful.
ATE is a good Integration tester for sure but it only tests the .Net client if I recall. As we get to an all web client, there will be other options.
I know I’m reaching here but I’d love to have some unit testing capability in addition to integration testing. Some of this can be done with Postman or PowerShell. But it would be REALLY cool to Be able to do some XUnit on our BPMs, Functions, and Configurators. I also suggested to Jose and Josh that Trace Replay would be a cool feature to add but they got day jobs…
I cast the maximum of 3 votes for Tanner’s idea. I also created a new idea (https://epicor-manufacturing.ideas.aha.io/ideas/ERP-I-721) related to his idea and Tanner reciprocated with his votes. Please consider the additional idea, and then if you like it, please also support it with your votes!
Just wanted to say “thank you” to everyone who voted for idea #721, which Epicor has now implemented according to the following message that I received from Epicor today:
“we have updated our Release Notes production process to include ServiceNow IDs (PRB numbers) in the Change List. You will be able to find them in Update Release Notes starting with version 10.2.700.12, 10.2.600.23, 10.2.500.33, 10.2.400.38, and, of course, in version 11.1.100 when it’s released. Hope PRB numbers will help you work with Epicor ERP updates more efficiently.”
