A/P-A/R accounting >  Payments >  Payment proposal  

Display all Hide all

Use this function to generate automatic payment proposals for posting invoice payments from the Purchasing, Sales, or A/P-A/R accounting modules.

Open items (invoices and credit memos) that cannot be managed by this function:

Open items that are not yet recorded on a statement.

Open items with an unknown payment approval status ("payment approval" field different from "payment approval").

See Payment entry (GESPAY) to generate payments manually.

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management

The automatic payment proposal is carried out on a selection of open items of invoices/credit memos. Payments are generated thanks to the data available on the original invoice, but also using information available in the automatic proposal screen. These screens can be displayed in two different ways:

  • in a control grid, that lists the payments coming from the campaign ('Control' mode activated in the second tab), or
  • in the payment entry function ('Control' mode deactivated).

For the same sequence of invoice open items to be settled, there can be one or more payments created on the basis of the selection and the chosen options.
For example: by default, a single payment is created for a set of invoice open items with different due dates for the same BP. If the option 'one payment/due date' has been selected, as many payments are created as there are due dates.

The open item is thus a 'fixed' concept, that represents the amount to be paid for a specific invoice. On the other hand, the concept of payment varies since it is defined for a selection of options.

SEEINFO   From the results table, right-click the invoice to specify whether the discount has been generated.

Header

Presentation

It is important to indicate the action to be performed:

  • a withdrawal ('Expense'),
  • a receipt ('Revenue').

It is mandatory to enter the company on which the payment campaign is carried out.

Two blocks of criteria ('Due date' and 'Settlement discount') help refine the selection of the open items to be paid. Each of them corresponds to an open item selection mode.

  • Due date block: a date range makes it possible to select the open items according to their due dates.
  • Settlement discount block: only applies to the open items entered with an early discount/late charge code. In this case, the selection criteria are:
    • a discount date range,
    • a due date range, whose activation is determined by the general parameter DEPDUDDAT - Due dates in discount section (chapter TRS, group TDC).
    • a number of allowance days,
    • a check box 'Always discount'.

These two selection blocks must be considered as being independent from one another and linked by condition 'OR'.

For example:

Data:

  • The DATDEP - AR Discount reference date (chapter TRS, group TDC) has the 'Due date' value.
  • The early discount/late charge code is set up as follows:

     

    No. of days

    rate

    1 

     -10/

    -10.00/

    2 

     0/

    0.00/

     

     

     


    A 10% discount is applied if the payment is made more than ten days before the due date.
  • Open items contained in the database:

     

    Discount 

    'Virtual' discount date 

    Due date until

     Open item A

     Yes

     August 20

     August 30

     Open item B

     Yes

     August 05

     August 15

     Open item C

     No

      -

     August 28

     Open item D

     Yes

     August 03

     August 13

Criteria and results:

  • Example no. 1: 'Due date' block only.
     
    Criteria entry: due date from August 20 to August 31.
     
    Selection of open items A and C.
     
  • Example no. 2: The DEPDUDDAT - Due dates in discount section parameter has the 'Activated' value. 'Settlement discount' block only.
     
    Criteria entry: 
    - discount date from August 06 to August 20,
    - due date from August 10 to August 30,
    - no allowance days, nor always discount option.
     
    Selection of open item A:
    With a number of allowance days = 2, open items A and B would be selected.
    If the accounting date of the payment is August 23, a payment will indeed be generated for these two open items, but without the benefit of an early discount since the payment is too late with respect to the 'virtual' discount date.
    If in addition the always discount option were selected, the selection would still concern open items A and B, but whatever the payment accounting date, the two selected open items would benefit from the calculation of an early discount.
     
  • Example n°3: The DEPDUDDAT - Due dates in discount section parameter has the "Activated" value.
    Use of both selection modes at a time, with the same criteria as above.
     
    Selection of open items A and C.
    With a number of allowance days = 2, open items A, B and C would be selected.
    If in addition the always discount option were selected, the selection would still concern open items A, B and C. But whatever the payment accounting date, open items A and B (entered with a discount code) would benefit from the calculation of an early discount.

Close

 

Fields

The following fields are present on this tab :

Block number 1

  • Payment sign (field SNS)

Only open items associated with a type of payment with this sense will be generated.

Block number 2

Only the open items for this company will be taken into account for the payment generation.
By default the user's company.

Date selection mode

  • Date selection mode (field DATSELMODE)

 

Due date

  • From due date (field DATMIN)

Open items from: (1). to (2).
If a date range is entered, only the open items whose due dates are contained within this range will be taken into account for the payment generation.

Early discount until: (3).
If a date is entered, all the open items without early discount code and the open items with an early discount code lower than the entered date will be taken into account for the payment generation.

In a nutshell, if all the dates are entered, the following open items will be taken into account:

  • the open items without early discount code meeting the dates (2) and (3)) and
  • the open items with an early discount code included between the minimum date (1) and the maximum date ((2) or (3)).
  • To due date (field DATMAX)

 

Settlement discount

  • From discount date (field DATDISMIN)

 
  • To discount date (field DATDISMAX)

 
  • From due date (field DATDISDUDM)

 
  • To due date (field DATDISDUDM)

 
  • Allowance days (field ADDALLDAY)

 
  • Always discount (field ALWDISFLG)

 

Close

 

Tab Criteria

Fields

The following fields are present on this tab :

Block number 1

  • All transactions (field ALLTPY)

Select this check box to include all payment transactions. If not, the Transaction field is required.

When you select this check box, the Bank ID country, IBAN prefix, and Bank ID number columns display in the Details grid on the Payment proposal selection window. In this case, Bank ID number is required and the line is highlighted red if a mandatory field missing.

Enter a single transaction for automatic payment proposals. This field is available when the All transactions check box is not selected.

If Bank ID is managed for the specific transaction, the Bank ID country, IBAN prefix, and Bank ID number columns display in the Details grid on the Payment proposal selection window. In this case, Bank ID number is required and the line is highlighted red if a mandatory field is missing.

If Bank ID is not managed for the transaction, these three columns do not display in the Details grid.

Depending on the sense chosen (Expense or Revenue), the payment transaction proposals vary (see the documentation on the setup of the Payment transactions). If no transaction is selected, each payment is created on the first payment transaction encountered which refers to the payment mode.

A filter can be applied to the payment mode: only the invoices or open items showing the selected payment mode will be taken into account (as a reminder, the payment mode is defined via the payment condition).

Example 1:   

Data:
For 3 payment due dates (customer invoice open items):

  • One of them, 30 days end of month (CHQ30JFM payment condition): 100 EUR
  • The other, Check with immediate credit (CHQCPT payment condition): 100 EUR
  • The last one Cash with immediate credit (VIRCPT payment condition): 100 EUR

The first two payment conditions are linked to the CHQ payment mode (Check). The last one is linked to the VIR payment mode (VIR for Transfer).

The CCHQ (Received checks) and CCHQR (Checks to cash) payment transactions use the CHQ payment mode.

Only the CVIR (Received transfers) payment transaction  use the VIR payment mode.

Result:
On automatic payment proposal, if the 'Payment transactions' and 'Payment mode' fields are not entered, the following payments are created:

  • A payment of 200 EUR on the CCHQ payment transaction (1st transaction found with payment by check).
  • A payment of 100 EUR on the CVIR payment transaction.

Various payments are generated for the invoice open items on statement (see the explanations on the specific processings).

Example 2:   

Data:
Same data as for Example 1. But the payment mode is specified: CHQ

Result:
A payment of 200 EUR is generated on the CCHQ payment transaction.

Example 3:   

Data:
Same data as for Example 1, but the CCHQR transaction is selected. Are only accepted open items by checks.

Result:
A payment of 200 EUR is generated on the CCHQR payment transaction.

Conclusion of the examples 1 and 2: the payment mode acts as a filter, either because it is a selection criterion (Example 2) or because, when it is associated with a transaction, it only authorizes open items involved by said payment mode (Example 3).

SEEWARNINGAll validated invoice open items using the payment mode(s) linked to the payment transaction, and meeting the other selection conditions, are submitted for payment WITHIN THE SAME TRANSACTION.Exceptions must be managed either in the control grid (if the "Control" option is activated) or, if the case arises, directly upon payment entry.

Example 4: For 10 invoice open items having the check as the payment mode (CHQ), all are settled, but only two are placed in intermediate posting These two payments must be entered under the CCHQR transaction. It is then possible to launch the automatic payment proposal for the other open items, by specifying the CCHQ transaction. Another method (using the "Control" mode) consists in generating all the payments on the CCHQ transaction, then refining the obtained result by deselecting the two payments to be recorded under draft management. It will then be possible to restart a campaign for the CCHQR transaction.

 
  • All payment methods (field ALLPAM)

All payment modes or a particular payment mode.

Enter a single transaction for automatic payment proposals. This field is available when the All transactions check box is not selected.

If Bank ID is managed for the specific transaction, the Bank ID country, IBAN prefix, and Bank ID number columns display in the Details grid on the Payment proposal selection window. In this case, Bank ID number is required and the line is highlighted red if a mandatory field is missing.

If Bank ID is not managed for the transaction, these three columns do not display in the Details grid.

Depending on the sense chosen (Expense or Revenue), the payment transaction proposals vary (see the documentation on the setup of the Payment transactions). If no transaction is selected, each payment is created on the first payment transaction encountered which refers to the payment mode.

A filter can be applied to the payment mode: only the invoices or open items showing the selected payment mode will be taken into account (as a reminder, the payment mode is defined via the payment condition).

Example 1:   

Data:
For 3 payment due dates (customer invoice open items):

  • One of them, 30 days end of month (CHQ30JFM payment condition): 100 EUR
  • The other, Check with immediate credit (CHQCPT payment condition): 100 EUR
  • The last one Cash with immediate credit (VIRCPT payment condition): 100 EUR

The first two payment conditions are linked to the CHQ payment mode (Check). The last one is linked to the VIR payment mode (VIR for Transfer).

The CCHQ (Received checks) and CCHQR (Checks to cash) payment transactions use the CHQ payment mode.

Only the CVIR (Received transfers) payment transaction  use the VIR payment mode.

Result:
On automatic payment proposal, if the 'Payment transactions' and 'Payment mode' fields are not entered, the following payments are created:

  • A payment of 200 EUR on the CCHQ payment transaction (1st transaction found with payment by check).
  • A payment of 100 EUR on the CVIR payment transaction.

Various payments are generated for the invoice open items on statement (see the explanations on the specific processings).

Example 2:   

Data:
Same data as for Example 1. But the payment mode is specified: CHQ

Result:
A payment of 200 EUR is generated on the CCHQ payment transaction.

Example 3:   

Data:
Same data as for Example 1, but the CCHQR transaction is selected. Are only accepted open items by checks.

Result:
A payment of 200 EUR is generated on the CCHQR payment transaction.

Conclusion of the examples 1 and 2: the payment mode acts as a filter, either because it is a selection criterion (Example 2) or because, when it is associated with a transaction, it only authorizes open items involved by said payment mode (Example 3).

SEEWARNINGAll validated invoice open items using the payment mode(s) linked to the payment transaction, and meeting the other selection conditions, are submitted for payment WITHIN THE SAME TRANSACTION.Exceptions must be managed either in the control grid (if the "Control" option is activated) or, if the case arises, directly upon payment entry.

Example 4: For 10 invoice open items having the check as the payment mode (CHQ), all are settled, but only two are placed in intermediate posting These two payments must be entered under the CCHQR transaction. It is then possible to launch the automatic payment proposal for the other open items, by specifying the CCHQ transaction. Another method (using the "Control" mode) consists in generating all the payments on the CCHQ transaction, then refining the obtained result by deselecting the two payments to be recorded under draft management. It will then be possible to restart a campaign for the CCHQR transaction.

 
  • All sites (field ALLFCY)

Select this check box to include all sites for the selected company.

Only the open items for this site will be taken into account for the payment generation.
By default the user's site.
This site must belong to the company that may have been entered previously.
  • All BP types (field ALLTYPBPR)

All BP types or a specific BP.
  • BP type (field TYPBPR)

Only the open items with this BP type will be taken into account for the payment generation.
  • All BPs (field ALLBPR)

All BPs or a particular BP.
In any case, the payment remains single-BP.

The entered BP type must match the BP type that may have been entered previously.
Only the open items for this BP will be taken into account for the payment generation.

 
  • All users (field ALLUSR)

 

 

Control accounts

If entered, only the open items whose collective account belongs to this group will be taken into account for the payment generation.
  • Control (field SAC)

Only the open items for this collective account will be taken into account for the payment generation.
If a BP type or a specific BP has been entered, it must be compatible with the collective account.
  • Account (field SACACC)

 

Currencies

If entered, only the open items whose currency belongs to this group will be taken into account for the payment generation.
In any case, the payment remains single-currency .

If entered, only the open items for this currency will be taken into account for the payment generation.

Open items

  • Prepayments (field INSFLG)

If yes, the pre-payment open items will also be taken into account for the payment generation.
  • All document types (field ALLTYP)

Clear this check box to filter the selection based on the open item entry type or based on a range of journal entry numbers.

 
  • From entry (field PCEDEB)

 
  • To entry (field PCEFIN)

 

Close

 

Tab Generations

Presentation

Open items on statement

When the invoice open items are entered on a statement, two separate cases occur:

  • If there is no statement posting (the value of the parameter SOICPT - Statement posting (chapter TRS, group SOI) is set to no), the payment is submitted for the open items on the basis of the characteristics of the statement (payment mode, site, etc.).
  • In the event of statement posting (the value of the SOICPT - Statement posting parameter is set to yes), the payment is submitted for the open item associated with the journal that closed the statement.

In both cases, a payment specific to the statement is created.

Close

 

Fields

The following fields are present on this tab :

Amounts

  • Maximum item (field DUDMNTMAX)

If entered, only the open items whose amount is lower than this amount will be taken into account for the payment generation.

 
  • Minimum payment (field PAYMNTMIN)

If this field is entered, only the payments in reporting currency with an amount greater than this amount are created. Caution, the payment amount depends on the selected payment options (for example: does the payment include all the open items on a single payment transaction? Does it have a range? Is it a payment by site, by open item, etc. ?)

 
  • Total maximum (field MNTMAX)

The proposal will be limited to this amount, expressed in reporting currency.

 

Bank

This field displays the bank to which the payments are assigned. The mentioned bank must necessarily be associated with the company for which the automatic payment proposal is activated.

The entry transaction of Payments determines if the information is mandatory or optional.
  • Banking pool (field POO)

Bank allocation to which payments will be allocated. If neither a bank nor a bank allocation have been entered, and the bank is mandatory for a type of payment previously entered, entry of a bank of a bank allocation is requested.

  • Application mode (field ALLMOD)

In the event of a maximum proposal amount, if the payments are allocated to a bank allocation, this specifies which priority should be given to the open items to be integrated to a payment. In the other cases, the priority is given to large amounts.

Payment grouping

  • One item/payment (field PAYDUD)

If yes, a payment will be generated by open item meeting the criteria.
  • Due date (field PAYDUDDAT)

If yes, the open items with the same due dates will be grouped together in a single payment.
  • Control account (field PAYSAC)

If yes:

  • the customer pre-payment open items will be grouped together within a single payment.
  • the supplier pre-payment open items will be grouped together within a single payment.
  • the open items of journals with the same collective account will be grouped together within a single payment.
  • Site (field PAYFCY)

If yes, the open items with the same site will be grouped together in a single payment.

Miscellaneous

  • Sort order (field ORDRE)

A log file is displayed at the end of the payment proposal. It draws up the list of the payments that are created or to be created in case of simulation.
In this list, payments can be displayed: 

  • by BP code,
  • by BP title,
  • by payment transaction code
  • by payment due date.
  • Simulation (field SIM)

If yes, a text file is generated and it displays the list of the submitted payments.
If no, payments are generated.
  • Control (field CTLFLG)

If this option is checked, launching the automatic proposal will open a screen underlining the open items submitted for payment. Before the payments submitted by the program are generated, the user can modify the proposal. They can choose not to pay some open items, to modify the amount submitted for payment or the early discount amount of some other open items. The user can also decide not to generate anything. This type of generation is only possible if the "Simulation" field is not checked.

  • Default selection (field SELDEF)

This field is available when the Control check box is selected.

When you select the Default selection check box, the Select column on the Payment proposal selection screen defaults to Yes for all suggested payments.

If this box is not selected, the default value for this column is No.

In either case, you can still select Yes or No for each proposed payment.

Payments

Site of the generated payments. It must be compatible with the company, bank or bank allocation.
  • Control (field SACPAY)

Collective account of the generated payments. It must be compatible with the BP that may have been selected previously.
  • Account (field SACPAYACC)

 

Optional field that is used to generated the payments in a specific currency.
  • Accounting date (field ACCDAT)

For the transactions with management by due date and whose first posting is the bank posting, payments are generated at the due dates. In the other cases, payments are generated at the date entered here.

  • Remittance reference (field REF)

Note reference.

The information indicated in this field is used for generating bank files in the SEPA format. It corresponds to the field 'Purpose code' in the .xml file.
This data will be found again in all payments generated via the automatic suggestion tool as long as they are created via an open payment entry transaction with the SEPA format.

Close

 

Payment proposal selection

Presentation

This screen displays the list of open items that can be proposed for payment based on the criteria from the previous screens.

From this window, you have the following options from the Action panel:

Create:

Currency totals: Click this button to view payment totals by currently.

Report: Generate the PAYPROPLIST - Automatic proposal report from information in the Details grid.

Details grid

This grid displays information for each open item for which payments are proposed. The Bank ID country, IBAN prefix, and Bank ID number columns display under these conditions:

The All transactions check box is selected on the Criteria tab.

Bank ID is managed for a selected transaction. In this case, the Bank ID is required. If it is missing, the line is highlighted in red.

Close

 

Fields

The following fields are present on this tab :

Block number 1

 
  • Remittance reference (field REF)

 
  • Maximum item (field DUDMNTMAX)

 

 
  • Minimum payment (field PAYMNTMIN)

 

 
  • Total maximum (field MNTMAX)

 

 

Block number 2

  • Accounting date (field ACCDAT)

 
  • Control (field SACPAY)

 
  • field SACPAYACC

 

 

 
  • Banking pool (field POO)

 

Grid Details

  • Select (field SELEC)

This field is used to remove specific due dates suggested in payment by the program.

Only due dates with this zone set to 'YES' will be posted on the generated payments.

 
  • Company name (field BPRNAM)

 
  • Due date (field DUDDAT)

 
  • Discount date (field DISDAT)

 

 
  • Invoice (field NUM)

 
  • Original document (field ORINUM)

 

 
  • Amount (field AMTCUR)

This field is initialized with the amount suggested in the due date payment. It is expressed in due date currency.

The user can modify the amount of the due date payment.

  • Discount/Late charge (field AMTDEP)

This field is initialized with the discount amount of the open item calculated by the automatic proposition program, as a function of the discount code associated with the invoice.

Once a discount code is associated with an open item, the discount amount can be modified.

  • Withholdings (field RITAMT)

 
  • Balance (field SOLDE)

 
  • field AMTLOC

 

 
  • Ctrl. (field SAC)

 
  • Account (field SACACC)

 
  • Address (field BPAPAY)

 

 

 

 
  • Payment method (field PAYMETH)

 

This field displays the country for the Bank ID.

This field displays when the All transactions check box is selected on the Criteria tab or when Bank I D (BID) is managed for a selected transaction.

If BID is managed and a mandatory field is missing, the line is highlighted in red.
  • IBAN prefix (field IBAN)

This field displays the IBAN prefix.

This field displays when the All transactions check box is selected on the Criteria tab or when Bank ID (BID) is managed for a selected transaction.

If BID is managed and a mandatory field is missing, the line is highlighted in red.
  • Bank acct. number (field BIDNUM)

This field displays when the All transactions check box is selected on the Criteria tab or when Bank ID (BID) is managed a selected transaction.

The Bank ID displayed defaults from one of the BP’s pay-by addresses and there can be a different BID for each pay-by address.

If you change the Bank ID, it changes for all lines for the same payment and that are set to Yes in the Select column for the line. The related Bank ID country and IBAN prefix fields update to match the new Bank ID.

If BID is managed and the Bank ID number field is empty, the line is highlighted in red if a mandatory field is missing.

Block number 4

  • No. of payments (field NBRPAY)

 
  • General total (field TOTAMTCPY)

 

 

Close

 

Reports

The PAYPROPLIST - Automatic proposal report is generated from the control grid that displays the list of the open items which could be proposed for payment. Hence, it is only available when the processing control for the automatic proposal has been requested. For the same reason, this report cannot be edited through the standard function of report generation.
lt can be generated by clicking the Edit menu in the Action panel or clicking List from Print pull-down menu. The standard print screen displays for the entry of the report settings.
By default, open items marked in the table to be paid (Yes in the Selection column) are printed in the report. However, the report setting Print excluded payments can modify this.

Batch task

This function can be run in batch mode. The standard task PAYPROPAL is provided for that purpose.

Conditions for the automatic creation of a capitalizable expenditure

When a discount line related to the early payment of a purchase or a supplier invoice is generated, a negative capitalizable expense is automatically created provided the following terms are met:

  • The company is submitted to the German or Austrian legislation.
  • The DEPMGTMOD - Discount management mode parameter (Module TC, group INV) has the value: Distribution by VAT (invoice level).
  • Payment attribute: The setup of the discount line accounting code is compliant with:
    - The Expense creation box is checked.
    - The Early discount/Late charge box is checked.
    - The generated entry matches this pattern: Account <=> BP.
  • Accounting codes: The accounting allocations of Tax type codes (determined from the tax code on the payment line) are defined for line 13 Adjustment to deduct. These are used for the accounting allocations of the negative expense.
  • Account setup:
    - the Fixed asset tracking must be activated in order to authorize the use of the account on assets and expenditures that are managed in the Fixed assetsmodule,
    - the Expense creation must be authorized,
    - the Accounting nature must be entered.

SEEINFO When the payment entry transaction sets several steps for the paying process, the expense generation related to the discount takes place during the first step of the payment posting.
The reference of the generated expense is mentioned in the corresponding log after the payment saving.
At the expense level, the payment reference is displayed in the field: Invoice and the Invoice type gets the value: Early discounts/Late charges.

Should the payment related to a discount be cancelled:

  • The discount expense is automatically cancelled if it has not been capitalized yet.
  • A positive expense is automatically created if the discount expense has already been capitalized.

Menu Bar

Limitations

Management of tax discounts

When the company manages tax discounts for the invoicing elements (the DEPMGTMOD - Discount management mode parameter (TC chapter, INV group) is set to Rebate on VAT), then the early discount/late charge amounts in payment entry or proposal includes taxes. The calculation does not take into account the VAT already deducted from the early discount/late charge when invoicing.

Unmatching/Rematching

After cancelling a payment, the open items for a payment and associated open items:

  • Could no longer be matched
  • Could be partially matched (in lowercase) although the group is balanced

This is because the accounting cancellation of a payment does not always take into account the matching information if:

  • The open items of the canceled payment are matched with other entries that are not present in the canceled payment
  • These entries contain a credit memo that is allocated and matched to an invoice in the group even though it was closed (parameter LETAUTCNO- Auto match inv ->credit note, (CPT chapter, MTC group) is set to Yes).
Case of an inactive BP client or supplier

Creating payments for an inactive BP is prohibited in Manual entry of payments.
To avoid completely blocking the recording of a payment received from, or directed to, a recently inactive BP, the payment of the open items for this BP remains possible in the automatic Payment proposals function.

Open item selection by payment currency picking

While creating a payment by selecting an open item date, the  Currency field is loaded with the currency of the first selected open item date. The currency cannot be modified.

If you require a payment currency different from the open item currency, enter the payment currency before selecting a due date.

Cases not managed in standard

Sage X3 does not manage the following cases in standard mode: payment in currency A  and prepayment in currency B, with a BP in the payment header different from the BP of the order.

Open items in the selection panel

In the selection panel, the  Open items and Grouped open items  lists only suggest open items with an entry type where the  Management of open items check box is selected.

Specific case :

For a payment in creation progress with the payment site not yet entered (payment legislation not known). In this case, the legislation of the entry type to be considered is determined as follows:

  • If the entry transaction includes a legislation, this legislation is considered. The open items displayed apply to the entry types of this legislation where the  Manage open items check box is selected.
  • If the entry transaction does not include a legislation, the system searches for the LEGFIL - Legislation (selection filter) parameter (SUP chapter, INT group).

    - If the LEGFIL parameter includes a value, the legislation of this parameter is taken into account.
    - If the LEGFIL parameter is blank, the system searches for the default folder legislation and the first legislation found is considered as a last resort.

Exceptions when the entry type is linked to no legislation:

1) When the site is not specified on the payment, the open item is displayed in the grouped open item list, even when the open item has been posted for a company with a legislation different from the one of the entry transaction.

2) If the payment entry transaction is not linked to any legislation, the open item is displayed, regardless of the default folder legislation or value of the LEGFIL parameter.


Manual matching

If you allocate open items by manual matching, the payment remains allocated and the payment is still displayed on the print-out.


Prepayment open items linked to a sales order

When creating a prepayment open item linked to a sales order where the Exempted tax field is set to Yes, the following apply:

  • There no VAT calculation in the sales document, although a tax rate is set in the tax code grid in the Tax rates function (GESTVT).
  • When such a prepayment is paid and posted, the VAT is calculated according to the tax rate in the tax code grid.

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation