Introduction
The TIM API is the standard application interface for ECR integration using SIX Payment Services terminals.
TIM API provides a comprehensive feature set to support the requirements of several different markets. This guideline is intended to be used by ECR integrators that need to implement the TIM API functionality in their products.
The following document contains an overview structure, description of the TIM API modes synchronous/asynchronous and describes the corresponding functions, notifiers and data elements that can be used with the TIM API. Furthermore implementation examples are provided. Nevertheless always the corresponding description of a function or data element is authoritative, not the examples.
System Requirements
The TIM API is available for multiple platforms. Due to such diversity the support for the TIM API is limited to certain standards. Those are the minimal system requirements:
- Java 7 JRE
- Android: API Level 16 (Android 4.1, Jelly Bean)
Setup Configuration
The configuration of the Terminal
can be done in two ways:
- In a configuration file “TimApi.cfg”.
- Using / configuring the
TerminalSettings
within the application.
Once a
Terminal
-instance has been created with a
TerminalSettings
-instance, the settings can not be changed anymore.
Changes to the
TerminalSettings
-instance will be ignored.
The network and guides configuration as well as the configuration file are explained in the following
chapters.
For further information refer to
TerminalSettings
.
Network Configuration
Depending on the platform used, the TIM API module can communicate with the Terminal over different communication channels. The default communication is over TCP/IP connection. Default port used is 7784.
On mobile devices also a Bluetooth connection is possible.
For TCP/IP connection there are two possible ways to connect to the terminal:
-
Broadcast-Mode:
- Terminal ID (TID) is known.
- The TIM API starts broadcasting on the default interface and connects to the connection information sent by the matching terminal.
-
Direct Connect:
- IP address of the terminal is known.
- Connection is established directly via IP.
Guides Configuration
There are various
Guides
covering different use case scenarios. The guide retail is the basic guide and is activated as
default. With
setGuides
the guides can be configured. Important: the configuration needs to include all desired guides
(including
the retail guide).
Code-example for creating a terminal including settings with activated guides retail and hospitality:
// Create settings with Terminal-ID of terminal to connect to
com.six.TerminalSettings settings = new com.six.TerminalSettings();
settings.setTerminalId("12345678");
// add wanted guides (with bitwise or)
settings.setGuides(EnumSet.of(Guides.RETAIL, Guides.HOSPITALITY));
// Create terminal
com.six.Terminal terminal = new com.six.Terminal(settings);
//...
// Disconnect from terminal and clean up properly
terminal.dispose();
Configuration File
With the use of the configuration file “TimApi.cfg”
TerminalSettings
can be set from outside of the application. If the user wishes to use multiple instances of the
Terminal
class it can be configured using ini-sections in the config file which are separated with a user
defined
DeviceId. The same DeviceId has to be used in the constructor of the TerminalSettings class if
the specified
configuration is wished to use. If no DeviceId is specified the global ini-section is used.
The precedence of the configuration is as follows:
- TimApi.cfg will be read first by creating a
TerminalSettings
object - The config previously read from the TimApi.cfg file can be overwritten by hand using setter
methods from
the
TerminalSettings
class.
Table with Configuration File Parameters:
Parameter | Description |
---|---|
LogDir | Directory where log files are generated |
LogLevel | Logging level, defines how much information will be logged. For detailed values see Logging / LogLevel |
LogRetainFileCount | Defines how many log files will be kept before deleting (or archiving) to oldest. Logging / Log Rotation Handling |
TerminalId | Terminal ID to be broadcasted in case of ConnectionMode Broadcast |
ConnectionMode | Connection mode used between ECR and EFT. For more information see
ConnectionMode
|
ConnectionIPString | IP address of the EFT terminal in case of ConnectionMode OnFixIP and Websockets. |
ConnectionIPPort | Listening Port of the EFT terminal in case of ConnectionMode OnFixIP and Websockets. |
SerialPort | Serial port to be used for serial connection in case of ConnectionMode Serial. |
SerialBaudrate | Baudrate used in case of ConnectionMode Serial. |
ProtocolType | Protocol type. For detailed values see
ProtocolType .
|
FetchBrands | Automatically retrieves application information during logging in. Default is on (value “On” or “Off”) |
AutoCommit | After executing the Transaction- function the API commits the transaction automatically. Default is on (value “On” or “Off”) |
RequestRepetition | Defines how many times a Commit or Rollback request is sent repeatedly, if the original request has been lost. (Default = 0, means disabled = no repetition) |
EnableKeepAlive | Defines if KeepAlive functionality shall be enabled or not. Default is on (value “On” or “Off”). |
SecuredConnection | Defines if the TCP/IP or Websocket connection shall be secured using TLS. Default is off (value “On” or “Off”). |
Example “TimApi.cfg”: This example describes the TimApi.cfg file with a global ini-section and two different ini-sections for specific DeviceIds:
[global]
ProtocolType = SIXml
TerminalId = 21001234
LogDir = var/log
[MyDeviceId]
ProtocolType = SIXml
TerminalId = 12345678
LogDir = var/otherLog
[MySecondDeviceId]
ProtocolType = SIXml
TerminalId = 87654321
LogDir = var/yetAnotherLog
ConnectionMode = OnFixIp
ConnectionIPString = 192.168.1.13
RequestRepetition = 2
[MyThirdDeviceId]
ProtocolType = SIXml
TerminalId = 18000001
LogDir = var/yetAnotherLog
ConnectionMode = Serial
SerialPort = COM1
SerialBaudrate = 115200
[MyFourthDeviceId]
ProtocolType = SIXml
TerminalId = 18000004
LogDir = var/yetAnotherLog
ConnectionMode = Websockets
ConnectionIPString = 192.168.1.13
ConnectionIPPort = 80
SecuredConnection = On
Operation Overview
Follow these basic steps for using the TIM API:
- Create
TerminalSettings
and initialize connection parameters (see Setup Configuration) - Create
Terminal
instance using the createdTerminalSettings
- Set some properties where required:
- set
PosId
-
create mandatory
list of
EcrInfo
and add withaddEcrData
- create list of
PrintOptions
and set withsetPrintOptions
- add listeners (
addListeners
)
- set
-
Connect
andLogin
. This can be done automatically, when the first terminal operation is called or manually using the login method. - Use terminal operation functions.
A basic flow to perform a transaction is:
Automatisms
The TIM API uses two different types of automatisms:
-
Pre-Automatisms: This means that all actions that need to be done before a function can be called. E.g. a transaction can be called in disconnected state without having called connect, login and activate in advance. These are called automatically by the TIM API before the transaction is performed. The Pre-Automatisms are enabled by default.
-
Post-Automatisms: These automatisms can be enabled or disabled using the members
autoCommit
andfetchBrands
. A Post-Automatism is triggered after an action has been performed. E.g. if a connect has been called andfetchBrands
is activated, anapplicationInformation
request is called automatically after the connect. Or ifautoCommit
is activated acommit
is performed automatically after a transaction has been made.autoCommit
andfetchBrands
are enabled by default.
The following diagrams show the principle of the Pre-Automatisms and Post-Automatisms. Pre-Automatisms are enabled by default and cannot be disabled. If an error occurs the started request from the ECR is returned with an error.
Synchronous flow
Asynchronous flow
Use Cases
Guide Petrol Use Cases
Petrol functionality adds a number of
additional methods,
transaction types
,
containers (AdditionalInfoList
,
Basket
) and
container content (ProcessingDisposition
)
notifiers and
flows
tailored to the needs at petrol stations.
Petrol has the following basic use cases:
Indoor - Online Card
Basket
)
and may be collected form the cardholder (e.g. ID number) and sent on to the online system.
The data is also provided back to the ECR via the Basket
and AdditionalInfoList
containers.
An online system may decline parts of the purchase basket.
The transaction flow differs from the standard scenario in an additional way. To distinguish
between online cards (this scenario) and offline cards
(that scenario ) it is
necessary to first initiate a card detection through an
Init Transaction
.
This is an indoor scenario, i.e. takes place in a attended environment usually a shop that
is part of the petrol station. See this flow
for reference.
Outdoor - Online Card
PreAuthorization
and
FinalizePurchase
.
This is an outdoor scenario, i.e. takes place in an unattended environment usually at the
petrol pump. See this flow
for reference.
Indoor - Offline Card
ProcessingDisposition
returned from Init Transaction
.
After the completion of Init Transaction
the ECR is responsible for all further interaction. For cardholder interaction a number of
dialogs (part of the "Dialog" guide) can be used.
This is an indoor scenario, i.e. takes place in a attended environment usually a shop that
is part of the petrol station. See this flow
for reference.
Outdoor - Offline Card
Guide Unattended Use Cases
Unattended functionality is aimed at the needs of vending machines an similar devices. It adds
additional methods,
transaction types
and
flows.
Unattended has the following basic use cases:
Use Case Partial Commit
commit
-function has an amount parameter.
See this flow for reference.
Use Case Hold Commit
Use Case Amount Adjustment
Use Case Retain Card
Use Case Silent Abort
Guide Austrian Use Cases
The Austria guide adds two new use cases:
- Non guaranteed payment (NGV)
- Delayed payment
Both use cases do not add any new functions.
Only the standard TransactionAsync
and Transaction
functions with
TransactionType Purchase
are
used with additional parameters the can be set in TransactionData
before starting the purchase transaction.
Austrian Use Case: NGV
An NGV payment is used in conjunction with a standard purchase transaction. The difference is that the purchase is handled
as an own risk transaction for the merchant.
Before starting a purchase transaction the NGVMode
can be set
according to NGVMode
to define the NGV behaviour of a transaction.
With the NGVMode
it is possible to either forbid NGV usage for the next transaction,
to allow it with a fallback to a standard purchase transaction or to set NGV usage to mandatory.
- If the NGV usage is explicitly forbidden the purchase transaction must be performed as a standard purchase.
- If the NGV is wished but fallback is allowed it is possible that the current purchase will either be performed as an NGV purchase or automatically as a standard purchase in case it is not possible to make an NGV purchase.
- If NGV usage is set to mandatory the current purchase transaction must be performed as an NGV purchase. If this is not possible the purchase transaction fails without fallback.
To identify if the current transaction has been performed as an NGV purchase or not a new boolean flag NGVUsedFlag
has been introduced in the TransactionResponse
. For statistics the NGV transactions can also be identified
in the Counters
using the same NGVUsedFlag
.
Austrian Use Case: Delayed Payment
The delayed payment can only be used in conjunction with an NGV purchase.
For delayed payments, the clearing of a transaction is delayed by the clearing house for the defined number of days.
The delay is set using the ClearingDelay
member in
TransactionData
.
Terminal methods overview
The basic operation modes of terminal method calls are:
-
Synchronous
Method calls are blocking and return after operation is finished successfully or throw a TimException otherwise. Please not that it is highly discouraged to use synchronous method calls on mobile platforms like Android because the main thread will be blocked by a synchronous call which may not be tolerated by the platform, as they are quite strict regarding blocking calls. This may result in a crash of the mobile App. -
Asynchronous
Method returns immediately after the operation has started or throws aTimException
otherwise. A listener-event-method will be called after operation is finished successfully. All listener-event-methods contain aTimEvent
. In case of failure aTimException
is included. User-implemented listener-handlers can be added to theTerminal
-instance withaddListener
.
Functions called on terminal perform synchronous by default. The asynchronous method has the same name with Async appended to its name.
Code example for adding a terminal listener:
/** Asynchronous listener handling terminal events. */
class MyTerminalListener extends com.six.DefaultTerminalListener {
/* Overwrite all required methods from the DefaultTerminalListener class
* herein which you want to use.
*/
}
// Create a new instance of the implemented MyTerminalListener
// class which then can be added to existing terminal object to handle
// the events that you've implemented.
terminal.addListener(new MyTerminalListener());
Main / guide retail terminal functions
Sync method
Async method Completed event |
Description |
---|---|
activate
activateAsync
activateCompleted
|
Open a user shift. |
applicationInformation
applicationInformationAsync
applicationInformationCompleted
|
Request the list of brands available on the terminal. |
balance
balanceAsync
balanceCompleted
|
Force the EFT Terminal to transmit all transactions to the
host system as well to do the daily closing. |
changeSettings
changeSettingsAsync
changeSettingsCompleted
|
Change configuration parameters of the EFT Terminal. |
commit
commitAsync
commitCompleted
|
Perform Commit-operation after a successful Transaction call. |
connect
connectAsync
connectCompleted
|
Initiates a connection to the EFT Terminal. |
counterRequest
counterRequestAsync
counterRequestCompleted
|
Get counter information`s from the EFT Terminal. |
dccRates
dccRatesAsync
dccRatesCompleted
|
Request DCC rates from the EFT Terminal. |
deactivate
deactivateAsync
deactivateCompleted
|
Close a user shift. |
disconnect
disconnectAsync
disconnected
|
Interrupts the connection to the EFT Terminal. |
hardwareInformation
hardwareInformationAsync
hardwareInformationCompleted
|
Get hardware information from the EFT Terminal. |
login
loginAsync
loginCompleted
|
Activate a communication session between the ECR and
the terminal. |
logout
logoutAsync
logoutCompleted
|
Terminate an active communication session between the ECR and the terminal. |
reboot
rebootAsync
rebootCompleted
|
Force the EFT Terminal to reboot. |
receiptRequest
receiptRequestAsync
receiptRequestCompleted
|
Receive the latest receipt or a list of silent receipts. |
reconciliation
reconciliationAsync
reconciliationCompleted
|
Force the EFT Terminal to transmit all financial transactions
to the host system. |
reconfig
reconfigAsync
reconfigCompleted
|
Force the EFT Terminal to get the configuration from the service center. |
rollback
rollbackAsync
rollbackCompleted
|
Prevent a transaction from being committed to the transaction
log and generates a technical reversal of the authorization. |
softwareUpdate
softwareUpdateAsync
softwareUpdateCompleted
|
Force the EFT Terminal to start a Software Update. |
systemInformation
systemInformationAsync
systemInformationCompleted
|
Request system information from the EFT Terminal. |
transaction
transactionAsync
transactionCompleted
|
Starts an EFT Terminal Transaction. |
Guide Petrol Terminal Functions
Sync method
Async method Completed event |
Description |
---|---|
cancel
|
Cancel an asynchronous function. |
initTransaction
initTransactionAsync
initTransactionCompleted
|
Retrieve card data for the presented card. |
Guide Unattended terminal functions
Sync method
Async method Completed event |
Description |
---|---|
openReader
Async
openReaderCompleted
|
Opens the shutter of the card reader. |
closeReader
closeReaderAsync
closeReaderCompleted
|
Closes the shutter of the card reader. |
ejectCard
ejectCardAsync
ejectCardCompleted
|
Ejects the card from the card reader. |
openMaintenanceWindow
openMaintenanceWindowAsync
openMaintenanceWindowCompleted
|
Opens a maintenance window where the terminal can perform all maintenance processes it was not able to perform before.> |
closeMaintenanceWindow
closeMaintenanceWindowAsync
closeMaintenanceWindowCompleted
|
Prohibits the EFT terminal from performing any triggered maintenance tasks. |
holdCommit
|
Increases the commit timeout. |
cancel
|
Cancels a running request. |
commit
commitAsync
commitCompleted
|
Commits a transaction after succesful authorization. A lower amount may be commited than the authorized amount. |
amtAdjustment
|
Send an amount adjustment notification to the terminal during an open transaction. The amount is used as the new amount for the transaction. |
Guide dialog terminal functions
Sync method
Async method Completed event |
Description |
---|---|
openDialogMode
openDialogModeAsync
openDialogModeCompleted
|
Open dialog mode on the terminal. |
closeDialogMode
closeDialogModeAsync
closeDialogModeCompleted
|
Close dialog mode on the terminal. |
showDialog
showDialogAsync
showDialogCompleted
|
Show dialog on the terminal. |
showSignatureCapture
showSignatureCaptureAsync
showSignatureCaptureCompleted
|
Show signature capture on the terminal. |
Additional terminal listener-events
Listener-event | Description |
---|---|
requestCompleted
|
Operation started by an asynchronous function has finished.
Applications can use both operation specific completion callback in combination with this generic completion callback. |
terminalStatusChanged
|
The terminal status has changed. The new status can be
retrieved from the TerminalStatus property. |
Flows
Guide Petrol Additional Flows
Petrol Flow: Indoor - Online Card
Petrol Flow: Outdoor - Online Card
Petrol Flow: Indoor - Offline Card
Petrol Flow: Outdoor - Offline Card
Guide Unattended Additional Flows
Flow: Partial Commit
Flow: Hold commit
Flow: Amount adjustment
Flow: PreAuthorization
Flow: Retain card
Flow: Silent abort
Guide Austrian Additional Flows
Austrian Flow: NGV Purchase without delay
The following flow describes an NGV purchase without any specific clearing delay set. The NGVMode
"AllowedWithFallback"
is used which indicates it the card used is not capable of NGV payments the terminal is allowed to make a fallback to a standard purchase. This flow shows a
successfully performed NGV payment which can be seen by checking the value NGVUsedFlag
, which is set to "true".
Austrian Flow: NGV Purchase with delay
In the flow below, additionally to the NGVMode
"AllowedWithFallback" also the
ClearingDelay
is set to define a specific clearing delay in days.
This means that the NGV payment clearing will be delayed by the amount of days specified. This flow shows a successful NGV payment including
a clearing delay.
Austrian Flow: NGV Purchase fallback with Non-NGV card
The following flow describes an NGV payment with NGVMode
"AllowedWithFallback" which
results in a fallback to a standard purchase due to the fact that the card used is not capable of NGV payments.
The NGVUsedFlag
is used to determine if the NGV payment was performed as such or if a fallback
was used. In this case the NGVUsedFlag
value is set to "false" which indicates that the requested
NGV payment was not successful and the fallback to a standard purchase has been done.
Austrian Flow: NGV Purchase mandatory with error
The following flow describes a mandatory NGV purchase transaction which could not be performed by the terminal.
As the used NGVMode
is "Mandatory" but the card used is not capable of NGV payments, the
transaction results in an error which means a resultCode
!= '0' and an error payload as transaction response.
Logging
LogLevel
By default the TIM API has a Logger that defines how much logging is generated inside the TIM API. To this Logger different handlers can be added, e.g. ConsoleHandler for logging into the debug console or FileHandler to log into a file. By default a FileHandler is added to the TIM API logger.
The following logging levels are valid:
- ALL
- FINEST
- FINER
- FINE
- CONFIG
- INFO
- WARNING
- SEVERE
- OFF
The logging level can be adjusted programatically as follows after a terminal object has been created:
// Set the TIM API internal logging level
Logger.getLogger(terminal.getLoggerName()).setLevel(Level.ALL);
// Set the logging level of the different handlers that have been added to the logger
Handler[] handlers = Logger.getLogger(terminal.getLoggerName()).getHandlers();
for (Handler handler : handlers){
handler.setLevel(Level.FINEST);
}
// To add a special handler to the TIM API logger
Logger.getLogger(terminal.getLoggerName()).addHandler(myHandler);
Log Rotation Handling
The TIM API allows to configure a log file rotation handling, which means
that it can be defined how many log files should be kept before deleting or archiving them.
Furthermore it can be defined how many log files are allowed in one archive and how many archives should be kept before deleting the oldest.
To define this behaviour the following parameter can be used, which are located in TerminalSettings
if they shall be set programatically.
If not they can be also set in theTimApi.cfg file.
-
LogRetainFileCount: Defines how many log files will be kept before deleting (or archiving) the oldest.
setLogRetainFileCount
-
LogFileCountPerArchive: Defines how many log files will be put in an archive before creating a new archive.
setLogFileCountPerArchive
-
LogRetainArchiveCount: Defines how many archives will be kept before deleting the oldest. 0 = no archiving
logRetainArchiveCount
Code Examples
This chapter contains example implementations for TIM API.
A simple implementation using synchronous calls looks like this:
package simpletransaction;
import com.six.timapi.Terminal;
import com.six.timapi.TerminalSettings;
import com.six.timapi.TimException;
import com.six.timapi.constants.TransactionType;
import com.six.timapi.Amount;
import com.six.timapi.Receipt;
import com.six.timapi.constants.Currency;
import com.six.timapi.TransactionResponse;
import java.util.logging.Handler;
import java.util.logging.Level;
import java.util.logging.Logger;
public class SimpleTransaction {
public static void main(String[] args) {
// Create initial terminal settings
TerminalSettings settings = new TerminalSettings();
// Define terminal ID for default connection mode BROADCAST
settings.setTerminalId("12345678");
// Define log directory
settings.setLogDir("C:\\Temp");
// Create new terminal
Terminal terminal = new Terminal(settings);
// The logging level can be adjusted as follows, after the terminal object has been created.
// The standard Java logging levels are valid
Logger.getLogger(terminal.getLoggerName()).setLevel(Level.ALL);
// By default, the logger has a FileHandler for logging into a file. The logging level that shall be
// used for the file logging can be adjusted as follows.
for (Handler handler : Logger.getLogger(terminal.getLoggerName()).getHandlers())
{
handler.setLevel(Level.FINEST);
}
try{
// Start transaction. Automatically connects to and activates the terminal
TransactionResponse trxResponse = terminal.transaction(TransactionType.PURCHASE, new Amount( 14.00,
Currency.CHF));
// If successful
System.out.println("Transaction successful");
// Both cardholder and merchant receipt are returned
for(Receipt receipt : trxResponse.getPrintData().getReceipts()) {
System.out.println(receipt.getRecipient() + receipt.getValue());
}
}
catch (TimException te) {
System.out.println("Transaction failed, exception: " + te.toString() );
}
catch (Exception se) {
System.out.println("Systemexception: " + se.getMessage());
}
}
}
The same example as above but using asynchonous calls can look as follows:
import com.six.timapi.Terminal;
import com.six.timapi.TerminalSettings;
import com.six.timapi.Amount;
import com.six.timapi.constants.TransactionType;
import com.six.timapi.constants.Currency;
import javax.swing.*;
class ECRSample {
public static void main(String [] args) {
// Create terminal settings as described in the example above!
TerminalSettings trmSettings = new TerminalSettings();
// Create terminal instance using the communication settings. These settings can
// not be changed anymore at a later time.
Terminal terminal = new Terminal(trmSettings);
// Set properties affecting the next login and transaction process. Changing POS-ID
// has no effect until the next logout-login. Changing User-ID affects the next
// transaction initiated
terminal.setPosId("POS1234");
terminal.setUserId(12345678);
// Add the notifiers you wish to handle.
// It can be done by adding a subclass of six.timap.TerminalNotifier as follows:
// Add activateCompleted, transactionCompleted, commitCompleted, deactivateCompleted
// and balanceCompleted notifier if required.
terminal.addListener(new TerminalListener() {
@Override
public void activateCompleted(TimEvent e, ActivateResponse data) {
// my code to be called if a activate request completed.
}
@Override
public void transactionCompleted(TimEvent e, TransactionResponse data) {
// my code to be called if a transaction request completed.
// After the transaction request is completed correctly, a commit can be performed.
// Only required if AutoCommit is not enabled.
SwingUtilities.invokeLater(new Runnable() {
public void run() {
terminal.commitAsync();
}
});
}
@Override
public void commitCompleted(TimEvent e) {
// my code to be called if a commit request completed.
// A deactivateAsync() can be called here. This is not required if the option
// AutoDeactivate is enabled, it will then be performed automatically.
SwingUtilities.invokeLater(new Runnable() {
public void run() {
terminal.deactivateAsync()
}
});
// If AutoDeactivate is enabled, a balanceAsync() can be called directly and a
// deactivation will be performed automatically.
SwingUtilities.invokeLater(new Runnable() {
public void run() {
terminal.balanceAsync()
}
});
}
@Override
public void deactivateCompleted(TimEvent e, DeactivateResponse data) {
// my code to be called if a deactivate request completed.
}
@Override
public void balanceCompleted(TimEvent e, BalanceResponse data) {
// my code to be called if a balance request completed.
}
});
// Start a transaction process
// If the terminal is not yet logged in or activated this two actions are performed
// automatically before performing the transaction.
terminal.transactionAsync(TransactionType.PURCHASE, new Amount(12.50, Currency.CHF));
// If the option AutoCommit is enabled the commitAsync() method is called automatically
// after the transaction has finished.
// If not enabled, the commitAsync() method shall be called after receiving the
// transactionCompleted event.
// If the commit request is completed correctly the deactivate can be started
// (see commitCompleted method). If the AutoDeactivate option is enabled a deactivateAsync()
// is not required to be called. Another request that need a Deactivated state will then
// perform a deactivateAsync() automatically. Otherwise the deactivateAsync() method can
// be called after a successful commitCompleted event.
// So if AutoDeactivate is enabled, a balanceAsync() can be called directly.
// This can be done e.g. in the commitCompleted event (see commitCompleted event).
}
}
Attention: Events are send from inside a thread different than the main thread. If you need to access code in the event handling thread use something like java.awt.EventQueue.invokeLater or javax.swing.SwingUtilities.invokeLater
Function-State-Matrix
Legend:
- B1-Retail
- B2-Petrol
- B3-Unattended
- B4-Advanced Retail
- B5-Banking
- B6-Dialog
- B8-Gastro
- B9-Hospitality
- B10-Value Added Services (VAS)
- B11-Austrian Use Cases
Function | State | Book(s) | ||||
---|---|---|---|---|---|---|
Disconnected | Connected | |||||
LoggedOut | LoggedIn | |||||
Closed | Opened | Dialog | ||||
Activate | - | - | o | o | - | B1 |
ActivateServiceMenu | - | - | o | - | - | B3 |
AdjustReservation | - | - | - | o | - | B9 |
AmtAdjustment | - | - | - | o | - | B3 |
ApplicationInformation | - | - | o | - | - | B1 |
AuthorizeCredit | - | - | - | o | - | B5 |
AuthorizeDeposit | - | - | - | o | - | B5 |
Balance | - | - | o | - | - | B1 |
BalanceInquiry | - | - | - | o | - | B4, B5 |
Cancel | - | o | o | o | o | B1 |
CancelReservation | - | - | - | o | - | B9 |
CashAdvance | - | - | - | o | - | B4 |
ChangeSettings | - | - | o | - | - | B1 |
CloseDialogMode | - | - | - | - | o | B6 |
CloseMaintenanceWindow | - | - | o | - | - | B3 |
CloseReader | - | - | - | o | - | B3 |
CollectPoints | - | - | - | o | - | B10 |
Combined | - | - | - | o | - | B5 |
Commit | - | - | - | o | - | B1 |
CounterRequest | - | - | o | o | - | B1 |
Credit | - | - | - | o | - | B1 |
DccRates | - | - | o | - | - | B1 |
Deactivate | - | - | o | o | - | B1 |
EjectCard | - | - | - | o | - | B3 |
FeatureRequest | - | o | o | - | - | B1 |
FinalizePurchase | - | - | - | o | - | B2 |
FinishCeckout | - | - | - | o | - | B10 |
Giro | - | - | - | o | - | B5 |
HardwareInformation | - | - | o | - | - | B1 |
HoldCommit | - | - | - | o | - | B3 |
InitTransaction | - | - | - | o | - | B2 |
KeepAlive | - | - | o | o | o | B1 |
LicenseChanged | - | - | o | - | - | B1 |
LoadVoucher | - | - | - | o | - | B10 |
Login | - | o | o | - | - | B1 |
Logout | - | o | o | - | - | B1 |
LoyaltyData | - | - | - | o | - | B10 |
OpenDialogMode | - | - | - | o | - | B6 |
OpenMaintenanceWindow | - | - | o | - | - | B3 |
OpenReader | - | - | - | o | - | B3 |
PreAuthorization | - | - | - | o | - | B2 |
ProvideLoyaltyBasket | - | - | - | o | - | B10 |
Purchase | - | - | - | o | - | B1 |
PurchaseForcedAcceptance | - | - | - | o | - | B4 |
PurchaseMailOrdered | - | - | - | o | - | B4 |
PurchasePhoneAuthorized | - | - | - | o | - | B4 |
PurchasePhoneOrdered | - | - | - | o | - | B4 |
PurchaseReservation | - | - | - | o | - | B9 |
PurchaseReservationPhoneAuthorized | - | - | - | o | - | B9 |
PurchaseWithCashback | - | - | - | o | - | B4 |
Reboot | - | - | o | - | - | B1 |
ReceiptRequest | - | - | o | o | - | B1 |
Reconciliation | - | - | o | o | - | B1 |
Reconfig | - | - | o | - | - | B1 |
Reservation | - | - | - | o | - | B9 |
Reversal | - | - | - | o | - | B1 |
Rollback | - | - | - | o | - | B1 |
SendCardCommand | - | - | - | - | o | B6 |
ShowDialog | - | - | - | - | o | B6 |
ShowSignatureCapture | - | - | - | - | o | B6 |
SoftwareUpdate | - | - | o | - | - | B1 |
StartCheckout | - | - | - | o | - | B10 |
SystemInformation | - | - | o | - | - | B1 |
TerminalStatus | - | o | o | o | o | B1 |
VasInfo | - | - | - | o | - | B10 |