NEW V3.12 SecuTix already provides a batch to renew memberships valid for a whole season. This batch has now been extended to handle memberships valid for a fixed duration after purchase, no matter the duration of validity and season length.
Solution
Date management
- The already existing Membership renewal function of the Batch of subscription batch allows you to renew memberships valid for a fixed duration that will expire until a given date (or that have expired recently). This expiry date can be defined with an absolute date (expiry date = 31.01.2022) or by means of a duration (expiry date = date of batch run + 10 days). All memberships that expire before or on the expiry date will be taken into account.
- If a processed membership has already expired, the new membership will be valid from the current date (date of batch run). Example: the batch runs on the 15.01.2022 and identifies a membership that has expired on the 05.01.2022. The renewed membership will be valid from the 15.01.2022.
- If a processed membership hasn't expired yet, the renewed membership will be valid from the day following the end validity date. Example: the batch runs on the 15.01.2022 and identifies a membership that will expire on the 20.01.2022. The renewed membership will be valid from the 21.01.2022.
Season management
When a membership is renewed,the new membership may be in the same season, the next season, or even a later season as shown on the figure below:
The batch function allows to handle all these cases, but you have to set the mapping table of the batch accordingly. See getting started section for more details.
Getting started
You first have to create a batch of type batch of subscriptions.
Setting up the mapping table
You need to fill the mapping table related to the created batch in order to:
- Define which membership will be renewed. The batch will only renew memberships stored in its mapping table
- Define which membership needs to be used to renew an existing membership. Each membership is defined by a product and a season. Note that the new membership may be identical to the old one if the renewal is performed within the same season, but you still have to mention it in the mapping table. More precisely, you have to consider:
- The season of the membership to be renewed (in yellow in figure above) that depends on the start validity date of this membership
- The season of the membership used for the renewal which depends on the start validity date of the new membership
Considering the cases illustrated on figure above, suppose that the current date is 01.06.2021 and you want to renew several memberships with different validity duration. For sake of simplicity, the explanations below will consider that each season matches exactly one calendar year.
- For case 1, you will map the membership (belonging to season 3) with itself, as illustrated below
- For cases 2 and 3, you will map a membership belonging to current season 3 with a previous membership belonging to season 2. The fact that the new membership may only expire in season 4 isn't relevant.
- For case 4, you will map a membership belonging to current season 3 with a previous membership belonging to season 1
Run the Membership renewal function
An expiry date has been added to the existing schedule parameters:
All other parameters behave the same way as before. In particular, you can either:
- Renew a specific membership by selecting the target season and the origin membership
- Renew all memberships concerning a given target season and mentioned in the mapping table
Restrictions and points to take care of
Potential need of multiple batches
A given mapping table allows to map a target season to a single origin season. As a result, if you need to map the same target season to several origin seasons because of memberships with different validity duration, you will have to create several batches, each for one origin season. For instance, if you have to handle the 4 cases illustrated in the figure above, you would need:
- One batch to cover case 1 mapping target season 3 with origin season 3
- One batch to cover cases 2 and 3 mapping target season 3 with origin season 2
- One batch to cover case 4 mapping target season 3 with origin season 1
The prices are set-up exactly in the same way as before.
The price grid displays one column for each seat category for which a quota has been defined.
Setting up the price breakdown
The price breakdown uses the price components defined in the season. Please refer to Define flexible price breakdowns for the definition of the price components.
You can enter a price breakdown for each fixed price season ticket price. The definition of the price breakdown is optional.
The set-up process is exactly the same as for the other product families. You can find more detailed information on Define flexible price breakdowns.
Reporting
The sold amounts of the price components defined above (that may need to be shared among the different stakeholders) are provided by the reporting domain "Summary of fees". An example is given below:
Documents
You can display the price components on order related documents as well as on the file summary. You will find more details here.
Data migration
You can immediately start working with this new feature and create price breakdowns for fixed price season tickets. Indeed, all pricing data have been migrated to the new pricing model. The reports will only take into account the defined price breakdowns for the reservations and sales created after the definition of the price breakdown (no retroactive effect).
