Epicor has completed an FAQ sheet to help businesses on Epicor ERP 10.1 understand what the new Product Maintenance Methodology means for their business.
This FAQ has three sections:
- New Product Maintenance Methodology,
- Frequency and
Don’t hesitate to get in touch if you have any further queries, we are here to help.
New Product Maintenance Methodology
Question: What is new about our product maintenance methodology in Epicor ERP 10.1 onward?
Answer: With the release of Epicor ERP 10.1, we have updated our product nomenclature, regulated the frequency of releases and the way in which we provide fixes to our customers.
Question: What is the Epicor ERP 10.1 product naming nomenclature?
Answer: The product number has 4 segments. For example, the current product release is 10.1.400.5. Using this example, the segments are explained as follows:
is the Product segment, which is typically incremented as a result of significant architectural enhancements.
is the Version segment, which is typically incremented as a result of significant product application enhancements.
is the Release segment, which is typically incremented as a result of legislative and local application enhancements.
is the Update segment, which is incremented every few weeks and will ONLY contain bug fixes that will have no impact to our customer’s product configurations.
Question: How frequently are Product segments incremented?
Answer: Seldom. Our last Product increment was in 2014 as a result of a technology stack change.
Question: How frequently are Version segments incremented?
Answer: We expect these to be about every 1 to 2 years. Our last Version increment was in December 2015.
Question: How frequently are Release segments incremented?
Answer: We expect these to be about every 6 months or so. Our last Release increment was in December 2015 (at the same time as our last version increment).
Question: In general, how frequently are Update segments incremented?
- In the 1st year following a Version and/or Release level increment, Updates for that Release level will typically be issued every 2 weeks.
- In the 2nd year following a Version and/or Release level increment, Updates for that Release level will typically be issued every 4 weeks.
- In the 3rd year following a Version and/or Release level increment, Updates for that Release level will be issued
- In the 4th and subsequent years following a Version and/or Release level increment, Updates for that Release
level will cease to be issued.
Question: Given the frequency of the Updates, do you expect customers to apply all Updates?
Answer: For On-Premise and Hosted customers, yes, we would recommend that customers apply every Update. Updates are now restricted to providing bug fixes only and are not disruptive to our customer’s product configuration. For Cloud ERP, Single Tenant and Express customers, the Cloud Operations team will apply Updates firstly to pilot and then to production following their Cloud Maintenance Schedule.
Question: How can you ensure that Updates are not disruptive to a Customer’s product configuration?
Answer: As part of our automated build and release process, all software included in an Update is automatically validated to ensure that it complies strictly with a series of rules to ensure that the software fixes will not affect any public interfaces within the product. For example, no impact to any UI Customizations, BPMs, Custom Reports or Integrations and no DB Schema changes.
Question: If I decided not to apply an Update, would I be able to apply the following or subsequent Updates?
Answer: For On-Premise and Hosted customers, yes. Updates are cumulative, which means that all bug fixes from Update 1 will also be included in Update 2 in addition to Update 2’s bug fixes; all bug fixes in Update 2 will also be included in Update 3 in addition to Update 3’s bug fixes and so on. Given the frequency of Updates, the net number of additional fixes added to any given Update will be limited, which will facilitate a swift, focused UAT for our customers. However, this would be negated, should a customer decide not to keep current with applying Updates as the delta would increase each time. For Cloud ERP, Single Tenant and Express customers, the Cloud Operations team will apply Updates firstly to pilot and then to production following their Cloud Maintenance Schedule.
Question: What if I think I have found a potential bug, how can I request a fix under this new maintenance methodology?
Answer: You would contact Epicor Support as normal. If they are able to replicate the bug in the latest released Update, they will report the bug to Epicor Development and depending on the severity of the bug and the impact to your business, Epicor Support may request a fix on your behalf to be included in a future Update. An SCR (Software Change Request) will be created by Epicor Development for tracking purposes and Epicor Support will then inform you of the SCR number, the targeted Update number and its release date.
Question: What information is required by Epicor Support in order for them to request a fix on my behalf via an Update rather than wait for the next Release level?
Answer: You would need to provide the following information:
- The Epicor Support Call number
- Your business process that is being affected by the bug and the operational impact the bug has to that process
- The non-operational impact the bug will have to your business: e.g. cost, additional non-value added hours
- Why you cannot wait for the fix in the next scheduled Release level
Question: What if the targeted Update release date I am given is too far into the future for me?
Answer: You can contact Epicor Support and quote the Epicor Support Call number and the SCR number and request that the target Update be reviewed to see if it can be brought forward to an earlier Update. You will need to provide the reason for your request and the impact to your business.
Question: What if the targeted Update is revised earlier but is still too far into the future for me?
Answer: You can contact Epicor Support and ask that your fix request be escalated, providing the reason for your escalation request.
Question: Will there be exceptions to these Update rules?
Answer: Occasionally, we may need to issue out-of-cycle Compliance Updates which may include functionality for legislation or compliance reasons. However, these will be identified very clearly so that our customers understand the reasons and business impact. The numbering of these Updates will increment by 100, making them easily recognizable. For example, following 10.1.400.12 let us say that we need to issue a Compliance Update, so this would be 10.1.400.100. From that point, normal Updates would then resume and be numbered .101 then .102 and so on.