Management of Transactions in Error

Management of Transactions in Error

SDD lifecycle management

Figure 33 - Sdd Lifecyle – First states

Management of transactions in Error

Transactions in error appear only on the dedicated screens. They do not appear on the screens of regular transactions such as SDD or in the list of associated SDD to a mandate. The transactions in error can be of several kinds: SDD, SCT, or Reversals. As they are transactions in error, they require action from a user before being taken into account in SEPA Payment Suite processes.

The actions associated to transactions in error are consultation, confirmation of the reject, correction, link to a mandate and recycling to try to process the transaction as a regular one.

List of cases producing a transaction in error

To create a transaction in error, the creation request must have some mandatory data:

  • The National Creditor Identifier or the SCI
  • The endToEndId (if SPS cannot generate it automatically).

A payment request transmitted by file or file upload, is in error when it fails to pass the control of acquisition, that is to say, in the following cases:

  • The required data are missing from the transaction request:

    • The mandatory information according to the format of the request

  • The organization cannot be retrieved

  • The amount does not respect the limit fixed by the EPC

  • The SCI present in the request is not consistent with the request sender (sender of the file or application calling the web service),

  • The creditor’s account of the transaction, if present, is not declared for the Payment or is not allowed on the corresponding entity.

  • The mandate (found with the couple SCI / UMR or SCI/ UIR) does not exist in the database and cannot be created

  • The mandate status is “Revoked”, “Cancelled” or “Finalized”

  • Transaction reference is not valid ([A-Za-z0-9/\\-\\?:()\\.,\\+\\s]+)

  • Transaction reference already exists in the database,

  • The sequence type of application is provided in the transaction request and is inconsistent with the expected sequence type, for example in one of the following cases:

    • The transaction request has a ONE OFF type and refers to a recurrent mandate
    • The transaction request has a type FIRST / RECURRENT / FINAL, and refers to a One off,
    • If “RCUR only management” is activated and the transaction request has the type FIRST/FINAL

  • Transaction request has a RECURRENT / LAST sequence type, and no transaction is present for this mandate

  • The Due date is after mandate cancellation date

  • The Mandate is ONE OFF type and have already on SDDs

  • Counterparty account (debtor or creditor in case of an SCT) is incorrect / missing

  • For SDD ; must match the mandate debtor account (unless the manage mandate database based on transaction requests option is checked)

Transaction in error - Lifecycle

Figure 34 - Lifecycle of a transaction in error

Description of the states:

  • In error: A transaction is in anomaly when during the integration process of a transaction, one of the acquisition control failed. When the transaction is under this status, the user can correct the transaction, confirm the reject or recycle it. If recycling fails, the transaction is still in status “In error”.

  • Recycled: A transaction in error is recycled when recycling the transaction has been successful that is to say that a regular transaction could be created following this recycling

  • Rejected: A transaction in error is rejected when a user has confirmed the rejection of the transaction.

Correction

A user can correct a transaction in error, the information to change are:

  • End To End Identifier
  • Sequence type (only if the transaction is a SDD): choice between Automatic(SEPA Payment Suite will then automatically define the correct sequence type based on mandate lifecycle) or Last. Possible values of the Sequence type may vary depending on the activation of “Rcur only management” field of the organization. Once the field “Rcur only management” is activated for the organization then sequence type field cannot have First and Final as possible option.
  • Amount (can be changed by the authorized users only, else amount is displayed in masked form and non-editable).
  • The SCI (from a list of SCI allowed for the user logged in)
  • The creditor account (from a list of creditor has authorized for the user logged in)
  • The due date
  • The mandate to which the transaction must be linked.

According to the reason of the reject, only some information can be changed. All changes made ​​ will be saved in the audit trail and displayed in the lifecycle of the transaction in error. Those changes will also appear in the “regular” transaction lifecycle afterwards.

Recycling

A transaction in error can be recycled:

  • Automatically after the user confirms its modification
  • Manually by a user, without any modification to the transaction request (for example after manual entry of a missing mandate)

During the recycling acquisition, integration controls are run once again (see
list of cases producing an application anomaly). If recycling is a success, a regular transaction is created (SDD for instance). The type of creation and the creation file, if existing, of the transaction are those from the transaction in error. A direct link between the SDD and the transaction in error is made. Changes done manually by the user on the transaction in error are also displayed to the regular transaction lifecycle. The transaction in error becomes “Recycled” and cannot be modified or recycled again.

WEB GUI

Search screen for Transactions in Error

The screen will list all transactions in error recorded on the platform and the reject reason associated with each. Search criteria to refine the results list. The transactions in error can be of several kinds : SDD, SCT,…

The user has the following actions: check the details of a transaction in error, confirm the reject (either single or many), recycling (either single or many), and correction of the transaction (in a unit only). Each action corresponds to a role SPS, the user has access to such actions only if the corresponding roles are included in their profile.

Figure 35 – Screen for search transaction in error

List of search criteria:

  • Creditor filter
  • End To end Id
  • Creation date and hour
  • Due Date
  • UMR
  • UIR
  • Status
  • Amount (It is displayed in masked form if the user is not authorized to view the amount)
  • Creation file
  • Reject reason
  • Type: SDD, SCT, Reversal

Columns in the result list:

  • Check box
  • Creation date and hour
  • End To End Identifier
  • Type
  • Reject reason
  • Status
  • Due Date
  • Amount
  • Access to detail
  • Access to the correction : only if the transaction is “In error”
  • Confirm the reject : only if the transaction is “In error”
  • Recycle: only if the transaction is “In error”

Button associated to the list of results:

Reject : Confirm rejection of selected transactions using the check box. Only the transaction “In error” can be rejected

Recycle : allow to recycle selected transactions using the check box. Only the transaction “In error” can be recycled

A message indicating the result of process is displayed to the user.

Detail screen of the transaction in error

Figure 36 - Page de consult transaction in Error

The screen of the transaction in error detail displays several fields. Fields that were not present in the transaction request are displayed on the screen as empty. Mandate data displayed are coming from the associated mandate, if one could be found. The amount field is displayed in masked form if the user is not authorized to view the amount. The life cycle of the transaction in error is displayed.

In addition to the back button on the search screen, the action buttons are displayed if the user has the corresponding rights:

  • Edit the transaction
  • Confirm the reject
  • Link to a mandate
  • Recycle transaction

Edition screen for transaction in error

It is possible to correct a transaction in error only If the status of the SDD Reject is not “FIXED” and the reject is not confirmed.

Figure 37 – Screen to correct a transaction in error

On the screen to edit the transaction in error, the information displayed is:

  • Information of the mandate if the transaction is attached to an existing mandate in the system
  • The information in the transaction in error, as present in the detail screen
  • The information which can be corrected by the user:
    • End To End Id
    • Sequence type
    • Amount ( if the user is not authorized, it is displayed in masked form and non-editable)
    • Due Date
    • SCI
    • Business Code
    • Creditor Accounts

Codification rules: grey background for fields that can not be modified, red writing (value or field name) for fields that need modification. The possible values of Sequence type field vary based on the activation of the field “Rcur only management” for the organization. Once field “Rcur only management” is activated , the drop down of the Sequence type will not have “First” and “Final” as possible values.

Once the user corrects the transaction, he clicks on “Update”. The transaction is then updated. Then the user checks the consistency of its data: he can correct again the transaction or he clicks on “Recycle on demand.” Clicking on “Recycle on demand”, the acquisition controls are made on the modified transaction in error.

If one of them fails, a message is displayed on the screen telling the user the reason for rejection, corrections are still needed. The user is on the correction screen.

If the corrections are valid, its status becomes “Recycled”.

A transaction (SDD, SCT, Reversal) is created and it comes in standard processes. The corrections made and the user responsible for the action is stored in the audit trail.

From the screen of transaction (SDD, SCT,…) detail, the lifecycle of the transaction in error is displayed.