Evopos Help - 2.09.068

Portal - Reports

Portal - Reports

Previous topic Next topic  

Portal - Reports

Previous topic Next topic JavaScript is required for the print function  

Reports can be extremely useful and flexible for managing communications and projects. Issues can be used in a number of ways including:


Customer Service

Information sharing

Project Management

Program control

Any user can report an issue for subjects they have been given access to. Each Issue is based on a Subject (see Subjects below).

New issues are managed by the Managers of the Subject. If issues are contentious or cannot be completed straight away, they can be sent to the Authoriser by setting the status to Proposed. If the Authoriser approves the issue they may allocate to a person to complete.

Issues can also be set to Help and staff are encouraged to comment on these so the best solution can be determined.

We can set estimated time and costs of individual issues. Users can see the full history of Issues they have reported.


There are many benefits to using this system including:

Customer appreciation – Customers can see what you are doing for them. They like to be kept informed and this will help keep them loyal

Staff appreciation – Enables management to see who comes up with the best ideas and who does what

Better team work – Enables everyone to contribute in an efficient way and end up with a better result

Reduce wasted time – It is amazing how much time is wasted, either because information was not shared and issues have to be repeatedly solved, a work is done on something that is never used because of duplication, poor planning or not being approved.


Each Issue is based on a Subject. This can be a Service, a Product or a Project. If the Subject is big it can be broken down into any number of Subject Areas. Subjects can also have Versions or Stages. We can see the costs of a subject (or Area or Version/Stage) in both time and materials by taking the sum of the individual Issues under it.

Progress of an Issue

The issue can progress though a series of Statuses. In some cases an issue will need to be Authorised before any action is allowed. Issues can be marked for discussion (Help).

The progress of an Issue is mostly controlled by it’s status. The various statuses are:

New – When a standard user reports an Issue the status is set as New and it is flagged for the Manager(s) to look at. When an Admin user enters an Issue they may change the status at the same time as the initial entry

Help – When we need Help or Discussion on an Issue before a decision can be made

Hold – When an Issues is held to look at a later time

Proposed – When an Issue is subject to Authorisation. It will be flagged for the Authoriser to look at

Rejected – When an Issue is rejected for any reason

Approved – When the Authoriser has approved an Issue that requires authorisation or when an Admin user has allocated it to someone. It will also be flagged for the Allocated person to look at

Acknowledged – When an issue has been approved it will show as an action on the Allocated person’s Actions. By marking it as Acknowledged or Started the Allocated person is signifying he has seen it and is dealing with it. It will come off their Actions list but will still be on their TODO list. Many users would go straight to started and use the Percent Complete as the measure of work done.

Started – When the Allocated person has started the issue.  As the work progresses the Percent Completed should be updated

Completed – When the issue has been completed

There are also several combined statuses

Action – Issues that are classed as a new action for the current person (eg: have not yet been seen at that particular stage). This includes issues that have not yet been: 1. Approved for the Allocated person, 2. Proposed for the Authorisor, 3.New for the Managers (for that region) and 4.Unread Help issues for any admin users

ToDo – Issues that have been allocated to the current person with a status of Approved, Acknowledged or Started

Current – Issues for any person with a status of New, Help, Proposed, Approved, Acknowledged or Started

Note: The Allocated To can be set at any time, however the Allocation is not activated until the status is set to: Approved, Acknowledged, Started or Complete

Notifications of new issues, new comments and changed status

In addition to this, there is a system of notifying when issues have not yet been read. This is a red colour code or icon next to each new or changed issue when displaying them on the grid.

There are also optional email notifications that can be automatically sent to the appropriate persons. You can turn the email notifications off for each user in the User Details.

The scenarios when the notifications will apply are

When an Issue is reported with a status of New – Notify the Managers of the subject (unless they are the one entering it). Also notify the user reporting it (unless they are the one entering it). Note this is normally only when a customer is reporting a new issue.

When an Issue status is set to Proposed – Notify the Authoriser of the subject (unless they are the one setting it).

When an Issue status is set to Approved – Notify the Allocated To person (unless they are the one setting it).

When an Issue is marked as Help – Notify all staff (eg: Account Managers and Admin users) apart from the person changing the status. (May be hard to figure out when the status has changed)

When a Comment is added – If marked as Help Notify all Account Managers and Admin users apart from the person making the comment. If not Help send to Manager of subject, ReportedBy and AllocatedTo unless the person making the comment

When an Issue is marked as Completed – Notify the reporter of the subject (unless the person is the one changing the status). Maybe later we could have an option to just send one email even if a user had reported 20 issues in that version being published. See Bulk Edit below.

Working with Target Version / Builds / Stages

Target Versions allow you to organise your work better and also enable a group of issues to be changed in one go.

The version code can be broken down into manageable Builds (known as sprints in Agile). For example with 2.04.133, the 2 is the major release, 04 is a minor release and 133 is the Build.

When you are organising new issues try to allocate them to a target Build eg; 2.04.008 or if you are not sure put a question mark eg: 2.04.00?, 2.04?, 2.05? etc.  On a new entry the target can be set to just ? so we can see the issues you need to allocate.

When the issues have been organised with target versions, you can then use the ‘Group’ option to Group Propose them. The Authoriser can then Group Approve them. When the work has been done they can be Group Completed.

Note: It is normally quicker to set the target version on issues and then use: Bulk Edit to bulk change a group of issues to Completed at the time of completion.

It is normally beneficial to get at least a few minor versions approved in advance so it can be validated and budgeted for.

It also a good idea to review the priority, as Priority is a useful way to sort long lists.

Also set the Estimated Hours and try and set the Allocated to who will eventually do it. Also it can help to modify the Details to make it easier to understand and so that the wording suits when it is Completed and in the Changes list.