...
However, SecuTix doesn't recommend this option since it breaks the fixed seat logic. Indeed, the box office will automatically switch to this logic if no seat is available for all the performances sharing the same physical configuration.
The seat map will select by default:
- The preferred seat of the selected contact(s) if the information is available
- Otherwise, the best seat (i.e. the seat returned by the best seat selection feature)
Preferred seat
After the purchase process, the selected seats are stored as preferred seats. For a given contact, there may be one preferred seat per physical configuration. If a preferred seat already exists for the given contact and physical configuration, it will be overridden by the newly selected seat. Preferred seats may be viewed in the Contact module with the new menu entry Preferred seats. The operator may delete a preferred seat, this action having no impact on the purchased tickets. Preferred seats are only stored during a purchase process. They can't be defined directly from the screen below.
...
Identified seat based on origin season ticket | Identified seat based on preferred seat | Identified seat based on best seat allocation in same seat category | Action | Rationale | |||||
---|---|---|---|---|---|---|---|---|---|
Same physical configuration in target and origin season ticket | Found seat in new physical configuration with same area, row, seat number | Seat is available | Seat has same category | Info is available | Seat is available | Seat has same category | Seat is available | ||
Yes | N/A | Yes | Yes | N/A | N/A | N/A | N/A | Renew season ticket with identified seat | |
Yes | N/A | One (or more) of the conditions isn't met | N/A | N/A | N/A | N/A | Don't renew this season ticket | The end customer expects to reuse the same seat but it isn't available or its category (and, therefore, the price) has changed. The venue must take contact with the end customer. | |
No | Yes | Yes | N/A | N/A | N/A | N/A | N/A | Renew season ticket with identified seat | Since the physical configuration is different, the end customer doesn't expect to keep the same seat category |
No | Yes | No | N/A | Yes | Yes | Yes | N/A | Renew season ticket with identified seat | |
No | Yes | No | N/A | Yes | One (or more) of the conditions isn't met | Yes | Renew season ticket with identified seat | ||
No | Yes | No | N/A | Yes | One (or more) of the conditions isn't met | No | Don't renew this season ticket | ||
No | Yes | No | N/A | No | N/A | N/A | Yes | Renew season ticket with identified seat | |
No | Yes | No | N/A | No | N/A | N/A | No | Don't renew this season ticket | |
No | No | N/A | N/A | Yes | Yes | Yes | N/A | Renew season ticket with identified seat | |
No | No | N/A | N/A | Yes | One (or more) of the conditions isn't met | Yes | Renew season ticket with identified seat | ||
No | No | N/A | N/A | Yes | One (or more) of the conditions isn't met | No | Don't renew this season ticket | ||
No | No | N/A | N/A | No | N/A | N/A | Yes | Renew season ticket with identified seat | |
No | No | N/A | N/A | No | N/A | N/A | No | Don't renew this season ticket |
The batch will proceed in two different steps:
- It will first renew all season tickets that can reuse the same seat (same physical configuration or other configuration containing a seat with the same area, row and seat number).
- In a second step, all renewals requiring a seat change will be performed
The goal is to avoid following scenario:
- A first season ticket uses seat A that has been marked as invalid. The batch allocates seat B
- A second season ticket uses seat B that has been allocated in the mean time for the first season ticket. As a result, seat C is allocated to this season ticket
- A third season ticket uses seat C...
By default, the batch will perform both steps mentioned above. You may change this behavior by adding the custom parameter renewStrategy. This parameter may have 3 values:
- BOTH: performs steps 1 and 2
- NOT_PROCESSED_SSTK: the batch performs only step 1 and stores the season ticket requiring a different seat in a temporary table
- PROCESSED_ERROR_SSTK: the batch performs only step 2 based on the content of this temporary table
However, SecuTix recommends to keep the default behaviour unless you need to handle very specific cases.
This parameter only impacts the renewal of fixed seat season ticket.
Other new parameters
The renewal batch may be run in reservation only mode. More precisely, the Create reservation field proposes following values:
- Always: a reservation is systematically created (no sales order)
- Never: a reservation is never created. In other words, the batch tries systematically to create a sales order and, in case of payment failure or shipment information missing, no order is created at all
- If payment fails: the batch tries to create a sales order and creates a reservation if payment fails or shipment information is missing
Current restrictions
Warning | ||
---|---|---|
| ||
The fixed seat season ticket can only be purchased from the box office |
...
You don't have anything to do to benefit from the fixed seat season ticket ticket. It's directly available.
...