Hint
When you create a report using a status change parameter, consider selecting ‘All data’ and Excel or CSV output. Then you will be able to see each user’s status in the report, in column AY.
Notes on the logic
When you select a Status change option in the Create Report step, and a date range in the prepare Report step, the System interprets this as ‘changed to this status’ during the date range, not as ‘had this status during the date range’. Thus, in a report for ‘Approved’ status for August, users who changed to ‘Approved’ in August will be included, but users who changed to ‘Approved’ status in May, and are still Approved in August, will be excluded.
For reports on ‘From Received or In Progress to Approved’ and ‘From Approved to Expired, and still Expired now’ we asked the developers to implement special logic, to allow the Membership Secretary to run two commonly-required reports.
The following tables illustrate how we think, as at November 2017, the ‘status change’ options are working.
To Received
Example: if you create a report with parameters Current View, To Received, and then Prepare the report with a date range of 1 August to 31 August.
| Transaction | Will be included in the report? |
|---|---|
| Application for membership submitted in August, status today is still ‘Received’ | Yes |
| Application for membership submitted in August, status today is ‘In Progress’ or ‘Approved’ or ‘Rejected’ | Yes |
To In Progress
Note that, due to a logic problem identified by the developers, there is one case where a date range selection will have no effect. If, at the Create Report step, you selected Status = In progress, the System will not process a date range for that report. Instead, it will provide a report that lists In Progress users on the day you prepare the report. We could not think of a scenario where anyone would want a report of users who were In Progress during, say the past month of July, so we considered this limitation acceptable.
Example: if you create a report with parameters Current View, In progress Status, and then Prepare the report for any date range:
| Transaction | Will be included in the report? |
|---|---|
| User changed from Received to In progress, on any date | Yes |
| User changed from Received to In progress to Approved, on any date | No |
In other words, Report on ‘In Progress’ selects the same users as a User Management search on ‘In progress’. So why do we need ‘In Progress’ as an option in Reports Management? Because you can for each user the report selects, display ‘All data’; in User Management you can only see some of the user’s data.
From Received or In Progress to Approved
This report allows the Membership Secretary to prepare a ‘New members’ report for a committee meeting. The new members report is the most likely use that we could think of, for a report using ‘Approved’ status. If we had followed the logic used for the other Status reports, an ‘Approved’ report would have included members who had allowed their membership to lapse and then renewed (i.e. changed from Expired to Approved) in the date range. It would have also included a user who might have been accidentally deleted by the Member Sec, and then, after a Whoops moment, undeleted (i.e. changed back to Approved) a few seconds later. It would also have included a user whose status had been Rejected and was reversed to Approved (very rare, but theoretically possible). So we defined this status option as changed ‘from Received or In progress to Approved’.
Example: if you create a report with parameters Current View, From Received or In Progress to Approved, and then Prepare the report for a date range of 1 August to 31 August.
| Transaction | Will be included in the report? |
|---|---|
| User changed from Received to Approved in August | Yes |
| User changed from In progress to Approved in August | Yes |
| User changed from Received to Approved in August, but was deleted or rejected in September | No in Current View (Yes in Past and All View) |
| User changed from In progress to Approved in August, but was deleted or rejected in September | No in Current View (Yes in Past or All View) |
| User changed from received (or In Progress) to Approved early in August, but deleted or rejected later in August | No |
| User changed to Approved in May; still had Approved status in August | No |
| User changed from Expired to Approved (i.e. they renewed after letting their membership lapse) in August | No |
| Institutional user changed from Received (or In Progress) to Approved in August | Yes |
| User who was Deleted or Rejected, changed back to Approved, in August (rare) | No |
To Rejected
Example: if you create a report with parameters Past View, Rejected Status, and then Prepare the report for a date range of 1 September to 30 September
| Transaction | Will be included in the report? |
|---|---|
| User changed from Approved to Rejected in September | Yes |
| User changed from Rejected to Approved in September | No |
To Deleted
Example: if you create a report with parameters Past View, Deleted Status, and then Prepare the report for a date range of 1 October to 31 October
| Transaction | Will be included in the report? |
|---|---|
| User changed from Approved to Deleted, in October | Yes, in Past or All View (No, in Current View) |
| User changed from Approved to Deleted, and back to Approved, in the date range | Yes, in Current View and All View (No, in Past View) |
| User changed from Deleted to Approved in the date range | No (= no in any view) |
| User changed from Received to Deleted, in the date range | Yes, in Past or All View (No, in Current View) |
From Approved to Expired, and still Expired now
We asked the developers to use special logic for this report, to allow the Membership Secretary to extract a list of people who expired in a certain period and did not renew. At various times, the President or other Committee member has used such lists to send personalised emails to the lapsed members, encouraging them to renew.
Example: if you create a report with parameters Past View, Expired Status, and then Prepare the report for a date range of 1 November to 30 November
| Transaction | Will be included in the report? |
|---|---|
| User changed from Approved to Expired in November, and is still Expired | Yes |
| User changed from Approved to Expired in November, then back to Approved in December or later | No |
| User changed from Approved in Expired early in November, then back to Approved later in November | No |
| User changed from Deleted to Expired in November (i.e. an expired user was un-deleted) | No |