Sage 100

Interesting answer from Erik Kaas on the thought process on which bug fixes are made and how quickly. What's most interesting is the statement that bug fixes only go back ONE version. In essence this means customers should be on the current or immediate prior release if they want full protection and ability to receive fixes from Sage. I don't think I've seen this type of situation has come up before -- where a customer was on a supported version but not N-1 and therefore unable to receive a fix. However for any customers who view the ability to get timely bug fixes as critical - we may be better off recommending an N-1 upgrade plan. Food for thought. Via LinkedIn: Thanks everyone for raising these questions. I'd like to share some insights into our process for determining what issues are fixed, in which release and how we deliver these fixes to customers. Issues come in many flavors, sizes and shapes, so we follow a process to guide our decisions. All new reported issues are researched, duplicated, triaged and prioritized by Sage support and R&D. We look at the issue's severity (what is the business impact on the customer) and the number of customers affected to determine a priority rating. The priority rating then determines when a fix will be released, using the following guidelines: Priority 1 issues are released as a hot fix for the current release version, and the prior released version (N-1). These are posted on the Sage Partner/Customer Portal for download. . As of this posting, that would include Sage 100 ERP 2013 Product Update 1 (5.00.1.0) and Sage 100 ERP Version 4.50.5.0. Priority 1 issues are issues that make the system crash, stop the application from working, or affect critical parts of the application without an available workaround. Priority 2 issues are targeted to the next scheduled Product Update for the current release version, and the prior major released version (N-1) are corrected. As of this posting, the correction would appear in Sage 100 ERP 2013 Product Update 2 and Sage 100 ERP Version 4.50 Product Update 6 (4.50.6.0). Priority 2 issues typically affect a critical part of the application but there is an (maybe awkward) workaround available, or are issues that affect non-essential parts of the application. Priority 3 issues are targeted to the next major release. As of this posting, the correction would appear in Sage 100 ERP 2014 (5.10.0.0). Priority 3 issues typically have a simple workaround available for a critical function, or have an awkward workaround for something less critical. Priority 3 issues often also are usability and UI issues that may be a nuisance but do not prevent a user from getting their tasks done. In the end, the final determination of when a fix will be released, is a judgment call made by a group representing customer support, R&D and product management, with input from the business partner and/or customer to understand the business impact. This prioritization is designed to offer the best service level to the majority of our customers at all times. It has proven to be very effective as we noticed a great increase in Sage 100 ERP customer satisfaction (NPS) over the past year. However, we understand that it may also result in customers sometimes having to wait longer than they would like to receive a fix. One important thing to also understand is that there are exceptions. Sometimes fixes are not suitable to be released as a hot fix or even in a product update. Sometimes the fix involves making a change to Sage 100 that could have a deep or severe impact, and would therefore require a full regression test using automated testing, manual testing and multiuser testing. This is something that we only do with major releases. The particular issue that you experienced was such an exception. It was deemed a Priority 2 issue, but was one we deemed unsuitable for a Product Update due to its risk, as it involved a change to the Interpreter. But this goes both ways sometimes we are able to include some Priority 3 fixes in a Product Update rather than waiting for a major release for example. Hopefully this explanation allows you to better understand our processes, so that you can better explain to customers how, when and why fixes are made available by Sage. PS we will post more details on this process in the Sage Partner/Customer Portal

Link: http://goo.gl/ObVi7

Similar Sage speak to my post several months back. Again, his lips are moving, so be careful. Bottom line, Sage has minimized the R & D, engineering and support to the MAS product line. Don't expect fixes to go back a version NOR expect any quick fixes on the CURRENT release.

There are so many factors which come into play when encountering potential program issues, I understand and agree with the N-1 policy. The reasons given to us for not upgrading are a third party program that has not been upgraded, substantial customizations or lack of funds. As we move forward to standard service level agreements that cover upgrades, that last one hopefully goes away. The first two need to be addressed in a strategic systems plan. Do our clients have those? Do they plan?

I think this policy has been around a while. I recall back in the 3.x days that a client had an issue with Work Order costing that was solved in the 3.71 release. At the time 3.71 was current, 3.70 was N-1 but the fix was only available in 3.71 due to the changes needed in both BoM and WO. I just had an incident with a MD where the functionality of a utility in their program was corrected in a product update for their program along with Sage PU (4.50.4). I had to update to Sage PU4 to get the fix and load the MD's PU4 updates. So I guess they're in a similar situation too.

Agreed - think it's time we tell customers the day is here to stay current (absent significant issues with upgrading an add-on, etc).