Payment Types
The table displays important information per payment type, which is used for validation when creating the payment files. This table is predefined by the system.
The payment types are located in the Role Center under "Setup":
A corresponding view of the available payment types will open.
The menu item "Edit" takes you to the map and the corresponding existing values.
You can change the following fields:
| Option | Description | |
|---|---|---|
| Settled Payment Type code | This field is used for debit/credit clearing. Enter here with which payment type the selected payment type should be cleared. | |
| Inactiv | You can use this check mark to inactivate the payment types that you do not need, in order to keep a better overview. When you call up the payment types in the system, the filter is set to "Inactive = No". If this field is checked, it will not be displayed in the payment types. To display the inactive payment types, you need to remove the filter, which is set automatically. | |
| Purpose Text Header Vendor | In this field you can define how the purpose for the header (this is the first line) should be built for a vendor for this payment type. You can use the following variables: Code Result: %1 Our Contact No. %2 Mandate ID %3 Mandate Datum %4 SEPA Due Days %5 Creditor ID %6 Account Type %7 Account No. %8 Posting Date %9 Payment Date + Used to link line values directly to header without line breaks. | |
| Vendor Purpose Text | In this field you can define how the note to payee for a vendor should be structured for this payment type. Code Result: %1 Document No. %2 Pmt. Amount %3 Pmt. Discount Amt. %4 Pmt. Discount (in percent) %5 Account No. %6 Ext. Document No. %7 Ext. Document No. (if not empty, else Document No.) %8 Document No.(Customer), Ext. Document No. (vendor) %9 Document Date %10 Payment Date %11 Description Invoice %12 Description Payment %13 Currency Code Invoice %14 Currency Code Payment %15 Document Type (first sign) %16 Our Contact No. %17 Mandate ID %18 Mandate Date %19 SEPA Due Days %20 Appln. Remaining Amount %21 Creditor ID @ concatenate values. ^ concatenate values and word-wrap automatically. \ Single use in purpose = line break These codes apply to all uses of this setup. Example: INV %1 of %9 EURO %2 results in "INV 12345 of 18.05.10 EURO 1190,00" as purpose of use. | |
| Customer Purpose Text Header | Defines how the note to payee for the header (this is the first line) should be built for a customer for this payment type. You can view the possible tokens that can be used at this point by clicking the Assist button. | |
| Customer Purpose Text | Defines how the purpose for a customer should be structured for this payment type. You can view the possible tokens that can be used at this point by clicking the Assist button. | |
| Purpose Text Footer | Defines how the purpose for the foot (this is the last line) should be built for this payment type. | |
| Payment Note Purpose Text | Defines how the purpose of payment should be structured for a payment note of this payment type. | |
| Text Application | The text to be used for the clearing entry is entered here. If this field is empty, "Payment from %Voucher number%" will be used. If for the application payment types AUSGL. 1 and AUSGL. 2, the system will suggest the value "Application from %document number%". When entering an individual text, you can also use the tokens of the payment types. | |
| New Head per Entry | Enter the number of entries from which a new payment proposal header is to be created. The field is preset with the value 0 by default. If the entry is empty (value 0), the application takes into account a possible setting in the payment method or in the customer / vendor card (Account Settings Pmt. Export). With this setting you can also avoid, for example, that payment notes are generated and instead several transfers / direct debits are triggered. | |
| Max. Pos. Payment Note | Define from how many entries onwards payment notes should be generated for this payment type. | |
| Limit Payment Amount (LCY) | Ensure that a new payment proposal header is created per vendor/customer if the payment amount would be exceeded by the next open entry. | |
| ISO Pmt. File Header SvcLvl | The service level for the header in the file is set up for ISO payment files. You have the choice between "URGP", "NURG", "SDVA" and "PRPT". This code is then written to the ISO files as "SvcLvl". | |
| ISO Pmt. Default Trans. SvcLvl | Set up the default for the service level per transaction in an ISO payment file. You have the choice between "URGP", "NURG", "SDVA" and "PRPT". This code will then be written to the payment proposal header and finally to the ISO files as "SvcLvl". | |
| Default Instruction Code | If it is possible to use the selected payment type with instruction keys, enter the default value for the instruction key in this field | |
| File Prefix | Specify the prefix for the file for this payment type. | |
| Pmt. File Path | Define the file extension for this payment type. | |
| Azure Blob Storage Connection | The settings to be made here serve to be able to realize a directory import also within the SaaS environment of Microsoft Dynamics 365 Business Central in connection with OPplus. The directory import is part of the payment import module. |
Currently, the following main payment types (=payment options) are implemented:
- SEPA - in the forms of:
- SEPA-Payment - outbound
- SEPA B2B - SEPA Corporate direct debit, direct debits business customers
- SEPA-LS - direct debits private customers direct debit format
- SEPA COR1 - SEPA direct debit Cor1 with one-day advance due date
- SEPA EIL - SEPA Express transfer
- SEPA-INST - SEPA Real time payment
Invalid characters, such as the commercial AND (&), are converted to a space in the SEPA format.
Note
In order to use SEPA direct debits, you must apply in advance for a Creditor ID and set up mandates.
- CHECK / EUR CHECK - If a bank account is entered as the posting account in the Payment Posting Matrix, check entries will also be created when printing checks. Please note that when using this payment type in the respective Business Central bank account, the "last check number" field must not be empty.
- LOCKED - is used to identify the customers and vendors for which payment proposals do not need/should not be created.
- AUSGL. 1 - Clearings are made in client currency, no payment file is created and therefore no bank information is checked. You can use this payment type to clear existing open entries with the payment proposal functionalities.
- AUSGL. 2 - Clearing is done in the entry currency, no payment file is created and therefore no bank information is checked. You can use this payment type to clear existing items using the payment proposal functionalities.
Instruction key per Payment Type
Within the payment types OPplus defines if instruction keys are allowed for the selected payment type. The instruction key controls for certain payment types (e.g. DTAZV) which instructions are forwarded to the involved banks regarding the execution of the payment order. In the payment types, the corresponding field "Default Instruction Key" has been supplemented accordingly. For the following payment types, instruction keys are evaluated in the payment export:
For the payment type DTAZV, for example, the following instruction keys have already been created and are processed in the payment headers during the payment export:
This means that the instruction keys can be created specifically for a payment type and can be stored as default instruction keys per payment type.
If a payment type does not allow the assignment of instruction keys, a corresponding error message will appear.
When creating a payment proposal with a payment type that has been assigned an instruction key, this instruction key is transferred to the payment proposal header, "Instructions" tab.
For example, when using the ISO Payment type, the Instructions tab is not present at all on the payment header.