To consider an operation definitive it is necessary to evaluate the status of the transaction using the resyncType parameter, this indicates if it is possible to consider the movement with the associated ID as archiveable.

The parameter will always be present and can have the following values:

• CREATED_TEMPORARY: the transaction ID can still change, so we suggest not to archive it.
• CREATED: a transaction has been created. --> the transaction can be archived with the associated ID.
• INSERTED: a transaction has been added later. --> the transaction can be archived with the associated ID.
• MODIFIED: a transaction description modified at a later time (STEP 2) --> the transaction can be archived with the associated Id.
• DELETED: a transaction deleted at a later time. --> the transaction can be archived with the associated Id.

In addition, we have the resyncDate parameter that indicates the last time the transaction was updated due to a new synchronisation (resync).

This means that this parameter will only be valued for the statuses INSERTED, MODIFIED and DELETED, while it will be null for the statuses CREATED_TEMPORARY and CREATED. Obviously, in the case of INSERTED it will have the same value as createdDate.

The main purpose of the parameters is to be used via GET API queries for movements, showing only transactions that have been added, modified and deleted at a later date.

This makes it possible for the TPP to update its archive/DB accordingly.