Solution
When the ticket status is sent back to S-360, in particular in the case of transfer, S-360 will automatically create a contact, if necessary, and assign that ticket to that contact, thus keeping the cultural contact of each ticket in sync with the current mobile ticket owner.
The contact will only be created, if a contact with the same email address does not already exist in S-360. If no contact is found, then the system will create a contact with an internet account, copying the following information from TIXNGO to S-360:
Title
First Name
Last Name
Email
- Mobile phone
Date of birthday
Nationality
Passport/ID
Country of residence
Communication language
Accept communication from institution by email
Accept transmission of electronic coordinates from third party
If a contact already exists with that email address, then the system will use that contact. However, it may happen than more than one contact were created with that email address. In that case, the system will use the contact with an internet account. If there are two such contacts (individual, relay), the system will use the individual contact.
Getting started
The only configuration required to activate the sync is to add the following custom parameter to the interface running the "retrieve ticket status from TIXNGO" function (aka feedback interface).
- enableTicketDistributionToCulturalContact=true
| Warning |
|---|
The following custom parameter must be set in all interfaces running the "injection". This will ensure that tickets being injected will skip the step to find the current mobile owner and instead will be systematically injected to the cultural contact.
|
Impact on operations
While many operation will benefit from the activation of the sync, notably any trouble-shooting operation, the main operation impacted by this change is the reprint and inject.
OLD behavior, without the sync active
Without the sync active, a reprint of a injected ticket on S-360 side could result in a form of uncertainty when injecting that new ticket because the ticket may need to be injected either to the latest mobile owner (as known by TIXNGO) or to the current cultural contact (as was done upon initial injection).
The way this was solved was by allowing to configure different behavior for different invalidation reasons. When the operator reprinted a ticket, by selecting a specific invalidation reason, he/she could implicitly choose between sending the new ticket to the latest owner or "reset" the injection back to the current cultural contact.
STEPS
- Reprint
- Select specific invalidation reason
- Based on invalidation reason ticket is injected to latest owner or current cultural contact
NEW behavior, with the sync active
With the sync active, decision for the operator will be much simpler and the outcome much more controlled, because the new ticket will systematically be injected to the current cultural contact.
Indeed, since the latest mobile owner will systematically match the current cultural contact, there is no need to rely on the implicit "invalidation reason" trick. When reprinting a ticket the operator will have the possibility to explicitly define the contact which should get the ticket. The operator will either keep the current cultural contact or assign it to a new one, e.g., to the main contact of the file, if it needs to be "reset" back to the original owner.
STEPS
- Reprint
- (Optional) Select a different cultural contact, if the new ticket should go to a different contact than the current owner
- Injection to cultural contact