Common data > BP tables > Direct debit mandates 

Use this function to create and manage SDD direct debit mandates (SEPA Direct Debit).
The mandate features the authorization granted by the debtor to the creditor to allow such creditor to initiate one or several SEPA direct debits.

SEEINFO From the 1st of February 2014 onwards, in countries using the Euro, all banking retail credit transfers and direct debits in Euro will have to meet the SEPA (Single Euro Payment Area) scheme conditions.

    Prerequisites

    SEEREFERTTO Refer to documentation Implementation

    Screen management

    Header

    Fields

    The following fields are present on this tab :

    The company is the creditor defined in the mandate.
    Enter a legal company only.

    Unique identifier of the mandate.

    This field is initialized with the validated main mandate of the company/pay-by BP combination. If there is no validated main mandate, the field is empty but another validated mandate of the combination can be selected.

    SEEINFO  

    • In order to access this field for the current company, the activity codeSDD - SDD management must be active and the parameterSDDMGT - SDD management(chapter TC, group SDD) must be set to "Yes".
    • This field is displayed only for a payment transaction having the SEPA box checked and a revenue sign.
    • Description (field DES)

    Enter a description of the current mandate.

    Close

     

    Tab Mandates

    Fields

    The following fields are present on this tab :

    Creditor signatory

    • Address code (field CPYADD)

    This is the default address code of the company.

    • Address description (field CPYADDDES)

     

    • SEPA creditor identifier (field SCINUM)

    This creditor identifier is retrieved automatically from the "Companies" record ( GESCPY) when the company code is entered. It cannot be modified.
    If there is no identifier, a blocking error message is displayed: "The SEPA creditor identifier for the company must be entered." The user must then enter this identifier in the "Companies record ( GESCPY).

    SEEINFO There is only one creditor identifier per company.

    Debtor signatory

    It is the pay-by BP (or debtor) defined in the mandate.

    Enter or select the customer code (GESBPC).

    SEEINFO The user can only select a BP that is defined as a customer.

    • Address code (field BPCADD)

    This is the address code of the default customer.

    • Address description (field BPCADDDES)

     

    • IBAN code (field IBACOD)

    Enter or select the debtor IBAN code among the IBAN codes associated with the address code.

    • BIC code (field BICCOD)

    The BIC code is automatically entered according to the IBAN. It is impossible to modify it.

    From the 01/02/2016 on, for the SEPA transactions, the BIC code is not mandatory on mandates.

    The date entered in the parameterOPTBICSTR - Optional BIC start date(TC chapter, SDD group) determines whether you can leave the field BIC code empty in the mandate, based on the mandate creation date.

    If the parameter value allows to leave this field empty, you can validate the mandate (from the button Validation, or from the function of Mandate validation (VALMDT).

    Identification

    • Main mandate (field MAIMDTFLG)

    Select this box to specify that the current mandate is the main mandate for the company/pay-by BP combination.
    This reference is used to initialize the mandate reference used:

    • upon creation of an invoice for this company/pay-by BP combination and with a SDD-type payment mode;
    • upon invoice payment.

    The status of this mandate must be "Approved".


    SEEINFO For each company/pay-by BP combination, there can only be one main mandate.

    Accessibility

     

    • Status (field STA)

    The selected values can not be accessed. The system assigns the corresponding status according to the events impacting the mandate. 

    • The start value is the "Initial" value, upon mandate creation. The mandate is not validated yet.
    • The "Approved" value is displayed when the user has saved all the elements that are compulsory to validate the current mandate, and has clicked on the Validation button. A validation confirmation is requested from the user. Modifications are possible only in the context of amendments.
    • The "Adjourned" value is displayed when the mandate is put on hold because of a problem on a direct debit. Changes are possible only in the context of amendments.
    • The "Revoked" value is displayed when the creditor or the debtor ends permanently the direct debit authorization. The mandate can no longer be modified and it is stored in the database. A revocation confirmation is requested from the user.
    • The "Expired" value is displayed when the last (or single) direct debit has been performed. The mandate can no longer be modified. If the expired mandate was a main mandate, the user must select another mandate as the main mandate. The expired mandate is automatically unselected as main mandate.

    Characteristics

    • Signature date (field SIGDAT)

    The signature date of the mandate is entered manually by the user.

    • Signature place (field SIGCTY)

    The signature place of the mandate is entered manually by the user.

    • Type (field TYP)

    Three values are possible:

    • CORE: the creditor or the debtor are companies or individuals.
    • COR1: derived from the CORE type. This type allows for a shorter submission time of the direct debits than the CORE type. It is primarily used in Germany and Austria.
    • B2B: the creditor or the debtor are companies only.
    • Payment type (field PAYTYP)

    Choose the Recurring type in case of multiple direct debits.
    Choose the One-off type in case of single direct debits.
    In this case, the "Final" check box becomes inactive and the "No. of direct debits" field can no longer be accessed.

    • Final (field FNLFLG)

    This box can only be accessed in the event of recurring mandates.

    It makes the management of the final sequence (FNAL) possible. When the last direct debit is reached, the system assigns the final sequence to this last direct debit. In this case, the mandate is expired and it is no longer possible to issue new direct debits for this mandate.

    • No. of direct debits (field PAYNBR)

    This field can only be entered if the "Final" checkbox is selected.
    This number can not be less than the number of lines of issued direct debits listed in the "Direct debits" tab.

    • Mandate end date (field ENDDAT)

    This field cannot be entered. The system automatically calculates the date of end of mandate based on the type of mandate and the sequence of the last direct debit.

    • If the mandate is revoked, the end date is the revocation date.
    • If the mandate has expired, the end date is the due date for the last direct debit (FNAL or OOFF).
    • If the mandate is revoked, the end date is the last direct debit date + 36 months.
    • Without first sequence (field WIOFIRSEQ)

    Select this checkbox to manage validated mandates originating from another accounting system.
    In this case, the sequence of the next direct debit has the recurring type (RCUR), not the initial type (FRST).
    This checkbox is enabled only for the recurring payment type and it is not selected by default in mandate creation mode.

    • Migration (field MIGFLG)

    This box can only be accessed in the event of CORE recurring mandates.

    Select this box to migrate direct debit authorizations granted before the SEPA scheme. This only applies to authorizations issued before 1 February 2014.

    When it is selected, this box determines the activation of the "Migration national identifier" field.

    • Migration national identifier (field NTLMIGIDT)

    Enter the national identifier contained on existing mandates (signed before 1 February 2014).
    This field is activated only if the Migration box is selected.

    Others

    • Final debtor (field FNLDBT)

     

    • Underlying contract (field UDLCON)

     

    • Name of signatory (field SITNAM)

    Person who signed the mandate as debtor.

    • Function of signatory (field SITFNC)

     

    Close

     

    Tab Direct debits

    Presentation

    Use this tab to inquire the list of the direct debits issued for the current mandate. Enter, for instance, the direct debit date, the amount, and the currency.

     

    Fields

    The following fields are present on this tab :

    Grid

    • Direct debit date (field PAYDAT)

    This is the direct debit due date.

    • Amount (field AMT)

    It is the amount of the direct debit charged on the debtor's account.

    This is the currency of the direct debit (in Euros only).

    • Slip no. (field FRMNUM)

    Number of the slip containing the issued direct debit.

    • Payment no. (field PAYNUM)

    Number of the issued direct debit.

    • Sequence (field CODSEQTYP)

    The sequence is an instruction to be transmitted to the bank (via the banking file).
    It is assigned to the payment based on the type of mandate and the order of creation of the direct debits.
    For a one-off type (single) mandate, the sequence is OOFF. For a recurring type mandate, the sequence is FRST, RCUR and FNAL.

    • Description (field LIBSEQTYP)

     

    • Dispute reason (field DPT)

    This is the rejection reason.

    Block number 2

    • Total direct debits (field TOTSDDPAY)

    This is the total amount of the issued direct debit.

    The currency must be the Euro.

     

    Action icon

    Payment
    Remittances

     

    Close

     

    Reports

    By default, the following reports are associated with this function :

     MANDATE : Mandates

     LISMANDATE : List of mandates

    This can be changed using a different setup.

    Specific Buttons

    The Validationbutton is enabled only if the following mandatory fields are populated:

    • Address code of the company,
    • Address code of the customer,
    • IBAN code,
    • BIC code, except when the value of parameter OPTBICSTR - Optional BIC code start date (TC chapter, SDD group) specifies that the BIC code is optional on the mandate,
    • Signature date,
    • Signature place.

    The validation action enables the Adjournment and Revocation buttons.
    SEEINFO A confirmation message is displayed after validation.

    Use the Adjournment button to put the mandate on hold.

    The mandate can no longer be used for invoices, open items and payments. Modifications are possible only in the context of amendments. If the adjourned mandate is a main mandate, the Main mandate box is automatically cleared.

    Click on the button Validation to reactivate the mandate.
    SEEINFO The mandate needs to be validated for the Adjournment button to be activated.

    Use the Revocation button to terminate permanently the authorization previously given to the creditor to issue direct debits orders.

    A mandate can be revoked even if the last direct debit has not been issued. 
    If the revoked mandate is a main mandate, the Main mandate box is automatically cleared. It can no longer be modified and it is stored in the database.

    The revocation action is irreversible, a confirmation is requested from the user: "The revocation of mandate $1$ is irreversible. Are you sure you want to continue?".

    SEEINFO The mandate needs to be validated for the Revocation button to be activated.

    Error messages

    In addition to the generic error messages, the following messages can appear during the entry :

    The SEPA creditor identifier for the company must be entered.

    This blocking error message is displayed when there is no SEPA creditor identifier. The user must enter this identifier in the Companies record).

    Does this IBAN change correspond to a bank change?

    This message is displayed when the mandate is validated and the creation date of the mandate is equal or greater than the optional BIC start date, and if:

    • you modify the IBAN on the mandate,
    • you modify the BIC code on the customer record (Bank ID tab) and then modify the mandate.

    This message is particularly important in case the BIC code is not entered on the mandate: the system cannot automatically differentiate an IBAN change from an IBAN change linked to a bank change.

    SEEINFO The date entered in the parameter OPTBICSTR - Optional BIC start date(TC chapter, SDD group) determines if you can leave the BIC code field empty on the mandate, depending on the creation date of the mandate.

    According to your answer ('Yes' or 'No'), the system performs consistency checks and updates in the amendments table.

    On import, the answer depends on the value of the field NDAIMPFLG- SMNDA or IBAN in the MDT import template.

    SEEINFO The SMNDA rule applies when the IBAN or bank are changed.The IBAN rule applies when changing the IBAN ('IBAN only').

    When modifying the IBAN in a mandate, the following error messages can be displayed following consistency checks:

    BIC inconsistent with bank change.

    This blocking message is displayed in the following cases:

    • You have modified the IBAN on the mandate but did not modify the BIC code (this is the 'IBAN only' rule).
    • You answered 'Yes' to the question "Does this IBAN change correspond to a bank change?" , though no bank change was performed.

    Example with IBAN change on the mandate:

    Customer IBAN and BIC.
    IBAN1 and BIC1 code
    IBAN2 and BIC1 code

    Completed flows:
    1) Mandate validated with IBAN1 and BIC1.
    2) IBAN1 changed to IBAN2 and 'Yes' answered to the question.

    Result:
    Blocking message: BIC inconsistent with a bank change.

    BIC code changed: choosing the "IBAN-only" rule is not consistent.

    This blocking message is displayed in the following case:

    • You have modified the IBAN and the BIC code.
    • You answered 'No' to the question "Does this IBAN change correspond to a bank change?" , though a bank change was indeed performed.

    Example with IBAN change on the mandate:

    Customer IBAN and BIC.
    IBAN1 and BIC1 code
    IBAN3 and BIC3 code

    Completed flows:
    1) Mandate validated with IBAN1 and BIC1.
    2) IBAN1 changed to IBAN3 and 'No' answered to the question.

    Result:
    Blocking message: BIC code modified: choosing the rule 'IBAN only' is consistent.

    Example with BIC change on the customer record:

    IBAN and BIC of the customer on the mandate:
    IBAN1 and BIC1 code

    Completed flows:
    1) Mandate validated with IBAN1 and BIC1.
    2) BIC1 changed on the RIB record of the customer for BIC2.
    3) Update of the mandate and 'No' answered to the question.

    Result:
    Blocking message: BIC code modified: choosing the rule 'IBAN only' is consistent.

    There already is an IBAN amendment from IBAN $1$ to IBAN $2$.

    The amendments table stores the modifications applied to the IBAN or BIC code.

    This blocking message is displayed in the following case:

    • You have modified the IBAN but did not modify the BIC code (this is the 'IBAN only' rule).
    • You have then reverted the IBAN back ('IBAN only') to its former value.
    • You answered 'Yes' to the question "Does this IBAN change correspond to a bank change?" , though no bank change was performed.

    Example with IBAN change on the mandate:

    Customer IBAN and BIC.
    IBAN1 and BIC1 code
    IBAN4 and blank BIC code

    Completed flows:
    1) Mandate validated with IBAN1 and BIC1.
    2) IBAN1 changed to IBAN4 and 'No' answered to the question.
    3) A 'IBAN only' recording is created in the amendments table.
    4) IBAN4 changed to IBAN1 and 'Yes' answered to the question.

    Result:
    Blocking message: A IBAN amendment already exists from IBAN1 to IBAN4.

    There already is an SMNDA amendment from IBAN $1$ to IBAN $2$.

    The amendments table stores the modifications applied to the IBAN or BIC code.

    This blocking message is displayed in the following case:

    • You have modified the IBAN and BIC code (this is the 'SMNDA' rule).
    • You have then reverted the IBAN back to its former value.
    • You answered 'No' to the question "Does this IBAN change correspond to a bank change?" , though a bank change was indeed performed.

    Example with IBAN change on the mandate:

    Customer IBAN and BIC.
    IBAN1 and BIC1 code
    IBAN4 and blank BIC code

    Completed flows:
    1) Mandate validated with IBAN1 and BIC1.
    2) IBAN1 changed to IBAN4 and 'Yes' answered to the question.
    3) A 'SMNDA' recording is created in the amendments table.
    4) IBAN4 changed to IBAN1 and 'No' answered to the question.

    Result:
    Blocking message: A SMNDA amendment already exists from IBAN1 to IBAN4.




    Tables used

    SEEREFERTTO Refer to documentation Implementation