Skidata DTA is a ticketing system provided by Skidata company and accessible through APIs. SecuTix can connect to it to cover some specific use cases detailed below.
Skidata DTA is different from Skidata Handshake, the access control system.
A product will be handled by Skidata DTA interface if and only if a mapping exists for that product for that specific interface. |
The use cases below only apply to the products handled by Skidata DTA interface.
When a ticket is bought in SecuTix for a product handled by the Skidata DTA interface,
with shipment mode type RFID (see parameter 5 below),
it is possible for the buyer to load this ticket on a SwissPass or on a Skidata token card to directly pass at the gates with it.
Technical note: this loading is done by creating an order in Skidata DTA system and associating the SwissPass E-id or the Skidata token card id to this order.
When a ticket is bought in SecuTix for a product handled by the Skidata DTA interface,
with shipment mode type different than RFID (see parameter 5 below),
the ticket produced by SecuTix gets a barcode which is an 8 character reservation code, allowing to exchange it onsite for a Skidata keycard.
Technical note: this is done by creating a reservation order in Skidata DTA.
1.) If the check box Cancel Skidata orders in batch is set to false (its default value):
When one of the tickets mentioned above is refunded/cancelled, SecuTix tries to cancel the orders created in Skidata DTA. If the cancellation fails, the refund is still working in SecuTix but error messages are logged indicating that the cancellation failed in Skidata DTA.
2.) If the check box Cancel Skidata orders in batch is set to true
When one of the tickets mentioned above is refunded/cancelled, SecuTix does no call to cancel the orders created in Skidata DTA. The orders are NOT cancelled in Skidata DTA.
The orders can then be synced later using a specific batch called Cancellation in Skidata of tickets cancelled in SecuTix
When a ticket is bought in SecuTix for a product handled by the Skidata DTA interface,
it is possible to execute a report that collects all the orders that have been made in Skidata DTA linked to SecuTix and verify if the status of the orders match in both systems.
If the state between the two systems is differents, an error log will appears. The result of the collected orders will be stored in a file at the end of the execution.
When checkbox is checked:
SecuTix will create reservation orders in Skidata for all non rfid rickets
And will create sale orders in Skidata when people load their tickets on rfid.
(behavior of Skidata DTA interface V2)
When checkbox is not checked:
SecuTix will create sale orders in Skidata when people load their tickets on rfid.
When the reservation checkbox is checked: see above. Below rules are ignored.
When "Create Skidata sales..." checkbox is checked
SecuTix will create sale orders in Skidata for all non rfid rickets
And will create sale orders in Skidata when people load their tickets on rfid, cancelling the previous sake orders, if existing.
When "Create Skidata sales..." checkbox is not checked
SecuTix will create sale orders in Skidata when people load their tickets on rfid.
If checked
After every sale creation, SecuTix will wait for 3 seconds, then call the Skidata DTA API checking the order status. If the state of the order is valid according to DTA, the order is correctly finalized. Else, the order will fail.
Context
Steps to follow to do the migration from DTA to SWEB
Example of readCatalog call :
Now you have configured your new API migration to the new SWEB APIs.
Parameter name | Meaning | Default value |
---|---|---|
setValidityDateFromMovement | Gets the validity date from movement | false (should be true as it is always used like this) |
movementValidity | Not used | |
checkSaleOrderWaitingTime | Waiting time, in seconds, before calling back DTA to check order status | 3 |
checkMissingSkidataConsumerCategoryId | System throws an error if tariff mapping or price mapping are missing, blocking the sales | true |
validSateStatus | List of valid status of skidata orders (used then the check | PENDING,RESERVED,BOOKED,BOOKED_AND_TRANSFERRED,CANCELED,CANCELED_AND_TRANSFERRED,CORRECTED,NO_STATUS,NOT_PAID,PAID |
When cancelling an order, SecuTix does not know if it is a reserved order or a normal order. It tries first to cancel it as a reserved order, then as a normal order. If an order is not a reserved order, the error message above is displayed.
Because SecuTix could not connect to the remote Skidata DTA system. The next steps to analyse the problem here are:
Same answer as for 1.
All executions of functions different from Read Catalog are what SecuTix calls daily executions. Those executions are opened dated midnight at the first interaction of the day with Skidata and are closed at the first interaction of the same kind on a subsequent day.
This question concerns Skidata DTA possibilities. SecuTix has no control over the features of that system.
This error message is returned when SecuTix retries to cancel an order already cancelled in Skidata DTA. The order may have been cancelled on Skidata DTA side or SecuTix is processing to a retry. The latter case is a normal case and should raise no alarm.
If the error message indicates neither SecuTix order Id nor Skidata DTA order id, contact the support so that those information can be added.
If the order was created with NOVA integration, SecuTix has no knowledge of the concerned client. The question must be asked to NOVA teams.
Because Skidata DTA loading and Swisspass loading are different things.
When a ticket is "loaded on Swisspass", the following stuff happens:
This message comes from Skidata DTA system. Please contact Skidata DTA support.
This message comes from Skidata DTA system. Please contact Skidata DTA support.
There is only one supported Skidata DTA interface integration (the v2). There is no "different way". The "old" implementation is not supported anymore due to a demand by SBB which requested a new version.
SecuTix offers no possibility to do that. The orders must be manually cancelled and re-created.
"Old" implementation is not supported anymore. Any change in the implementation of Skidata DTA v2 must be filed as an evolution request and be paid.
This is a global policy implemented in SecuTix.
Warnings are warning and should not trigger immediate action. Errors should trigger user action.
You are reading the documentation of Skidata DTA interface. Skidata Handshake is another product.