What is the release policy of the RetailVista POS software by NedFox?

This document describes how NedFox handles modifications in RetailVista POS, future updates, bug fixes, etc. RetailVista ERP is not covered by this documentation, a separate release document QA 364 is available for that. Pilot projects are also not covered by this release policy.

RetailVista POS is managed through version control in eSocrates, where customers are divided into customer groups. The management and configuration of these groups is done by NedFox.

In order to streamline the development process, NedFox enters all modification requests as tasks in eSocrates. The status of all tasks can be tracked by both customers and resellers in eSocrates (for customers through the support website).

Once a year, in October, a meeting is held with resellers and retail organizations to discuss the roadmap for the following year. Based on the outcome of these discussions, a high-level roadmap document is compiled and a number of specific tasks are scheduled in detail in a roadmap sprint. The content of this roadmap sprint is visible in eSocrates. Please note: No rights can be derived from the roadmap! If tasks are truly crucial, the costs for implementation will be charged to the customer and only then can it be guaranteed that a task will be included in the next release.

The rollout of updates for RetailVista POS differs from the RetailVista ERP environment, as the POS software is installed locally. For this reason, it is much easier to roll out a version in phases. Therefore, there is no fixed release frequency for updates of RetailVista POS, they can occur more or less frequently.

In order to achieve these releases, we work with sprints of 4 weeks each, in which we schedule parts from the roadmap sprint of that year. The sprints are further supplemented with tasks that have emerged from the support desk of NedFox, which also handles the reseller tickets.

From time to time, POS updates are made, which are visible in the version control of RetailVista. At the request of a reseller, a specific POS version can be released, for example, only to the reseller itself. This gives resellers the opportunity to become aware of the changes made and, if desired, to perform testing and acceptance work.

Sometimes, the amount of work in a sprint is less than expected, and then the scope of the sprint is reduced. It may happen that some tasks that were planned in the sprint are not completed. As a rule, these tasks are automatically moved to the next sprint. Especially in the last sprint before a final release, it may happen that certain tasks will not make it to the release and will be part of the subsequent release. It also happens sometimes that the impact of a task is found to be too extensive and the task is removed from a sprint.

Ultimately, it is up to the reseller to give the green light per customer group to roll out the update. Without approval, a customer group will not be updated. The approval per version and customer group will eventually become part of eSocrates.