Purposes / New Head per Entry / Max. Pos. Payment Note
The fields "New Head per Entry" and "Max. Pos. Payment Note" always refer purely to the number of items and there is no direct reference to the note to payee lines. Header and footer lines that may have been set up are not taken into account here and can cause the note to payee to be insufficient.
Since all calculations refer to entry-level and are not linked to each other, both fields - "Max. Pos. Payment Note" and "New Head per Entry" - are evaluated independently of each other. Here, logical attention should be paid to how the setups are made.
|Max. Pos. Payment Note||New Head per Entry||Max. Pos in Cust. / Vend.||Result|
|0||0||20||1 head with 20 entries (payment note by limitation from the system)|
|5||0||20||1 head with 20 entries (payment note by setup) from the 5th entry onwards|
|0||5||20||4 heads with 5 entries each|
|0||1||20||20 heads with 1 entry each|
|10||10||20||2 heads with 10 entries each incl. payment note|
|11||10||20||2 heads with 10 entries each without payment note|
|10||11||20||2 heads: 1 head with 11 entries and payment note 1 head with 9 entries without payment note|
In case you have made a setup for which the existing note-to-payee lines are not sufficient, there is a safety mechanism in the payment export in the form of a warning message that signals that not all entries in the purpose can be displayed.
This problem often occurs using the placeholder "@" within the payment types for concatenation.
Example: A payment proposal for 12 entries is generated for a customer. In the payment type "Max. Pos. Payment Note" = 14 is set up. In addition, the " Customer Purpose Text " is very long because "@%1 %2 %3 %4 %5" has been set up here.
However, this problem can also occur when working with very long (ext.) document numbers and only the placeholders "%1 Document No.", "%2 Payment Amount", "%3 Pmt. Discount Amount" are set up.
During concatenation, all documents are written to the lines one after the other. No care is taken to ensure that the values remain logically linked. If necessary, the document numbers are separated and continued in the next line of the purposes.
In this processing, however, there is the advantage that even more entries can be handled via the purpose before the system would have to create a payment note or a new header.
|line 1||Document 1| Document 2| Document 3|
|line 2||| Document 4| Document 5| Document 6|
|line 3||| Document 7| Document 8| Document 9|
|line 4||| Document 10| Document 11| Document 12|
|line 5||| Document 13| Document 14|…|
|line 1||Document 1| Document 2| Document 3| Document 4|
|line 2||| Document 5| Document 6| Document 7| Document|
|line 3||8| Document 9| Document 10| Document 11|Do|
|line 4||cument 12| Document 13| Document 14|…|
The standard processing for SEPA purposes is as follows:
- In the first place the value "Our Account No.". (if stored on the person account) is entered. After that, the document numbers are filled up one after the other, as the following example shows. This default setting can be overridden at any time.
|Line 1||ABCDEF/00001, 00002, 00003, 00004,|
|Line 2||00005, 00006, 00007, 00008, 00009,|
|Line 3||00010, 00011, 00012, 00013, 00014,|
|Line 4||00015, 00016,|
ABCDEF = our account number
00001 to 00016 the document numbers concatenated
If you do not want such a display, you can change it accordingly with placeholders in the respective payment type, as already described above. As placeholders you have the following options for the reason for purpose lines:
As a placeholder, you have the following options for the purpose headers:
For all payment types that have more than 2 and less than 10 purpose lines, automatic document chaining will be performed unless you have set something else up.
|SEPA, SEPA B2B, SEPA-LS, SEPA EIL||4||35|
The alternative purposes from the customer/vendor bank account card can optionally be combined with the entry-related purposes described above.
If a "+" sign is entered in the first place in the bank account purpose in line 1 or line 2, the purposes will be combined. I.e. first the first two lines from the bank account card are created, if necessary, and then the remaining lines are created in the same way as usual for creating the purpose.
This is illustrated by the various setups:
For example, two "Alt. Reason Rows" are stored on the bank account (in the bank account card):
Result in the purposes after creating a payment proposal in the payment proposal card:
A linked setup with the entry-specific uses would be performed as follows:
There is then a link between the Alt. Reason Row 1 of the bank account card (red) and the defined line-related purposes (green):
If, for example, %1 %11 %6 %9 is entered in the placeholder of the payment type, the text for a single item may not be sufficient per line. 4*35 lines are provided. Now, if more than 35 characters are set for one line (as in this example setup), the purposes will be truncated and not continued in line 2. Thus, it can be said that in this type of setup, a setup line always refers to a purpose line.
However, it is possible to set it up so that the line breaks automatically and the text continues in the next line. For this function, another placeholder is available: "^". You can view this via the AssistEdit:
For example, setting up a payment type could look like this:
For example, the result within a payment proposal would be as follows:
An entry with little text is marked (green area).
A second entry with more text is highlighted (blue area):
The third entry with more text is marked (red area).
If the available space is then no longer sufficient, as is the case here with the fourth entry (purple area), you will be shown a corresponding warning message.