Payment Attributes

Code identifying the payment attribute, entered as 1 to 5 alphanumeric characters and, specific to each payment line.

Non-compulsory field containing the legislation code (miscellaneous table 909).

The entered value is used upon creation and validation of the folder and upon addition of data during legislation copy.

The data concerning the requested legislations and the common data (legislation code empty) on folder creation.

Only the records concerning the folder legislations are retrieved on folder validation.

The Legislation field is also used as a filter and checked upon movement selection and entry (entry of invoices, payments, journals etc.).

If the field is empty, the current record can be used whatever the legislation of the company concerned by the movement.

Common title of the current record.

The short description replaces the standard description when display or print constraints require it.

By default the short title, the long title or the column header of a data are recorded (on creation/update) in the connection language of the user.
You can add your translation in another language using the Translation function:

• Click Translation from the Actions icon in the corresponding field.
• In the Translation window, add a new language code with the translation in this language.

A user who logs on with this language will view the short description, long description or column header in their connection language if a translation exists. Otherwise, these descriptions will be available in the folder language.

The connection language must be defined as a default language for thefolder.

The field Group is used to keep a payment attribute for a specific company, a group of companies or a group of sites.
Upon selection and entry of movements, the program checks the site/company consistency.

Select this check box so that the data can be used in other records (documents, parameters, etc.) or during a mass processing. If not selected, the data is considered to be inactive and it cannot be used in other records.

This access code makes it possible to prohibit access to the current record for some users.

If the field is populated, only users that have this access code with read access rights (and write access rights respectively) can view (or with write access rights, modify) the record.

The generated entry can follow three different patterns:

• Bank-BP: where the cash account and the account of the Collective account-BP or Account have been posted with movements (used for postings on invoives/credit memos, or for the direct bank charges).
• Bank-account: where the cash account and the payment line account have been posted with movements (used for the recordings of bank charges in addition to a payment)
• Account-BP: where the Collective-BP account and the payment line account have been posted with movements (used for revenue or charge allocations to the BP, early discounts, late charges, etc.).

The payment line account is specified at the level of the payment attribute parameters via the accounting code (see documentation on Accounting codes), in the Pre-payment or Accountingcode fields.

The initialization of the code for the Control field depends on whether or not the BP/Company tab is present in the BP record (GESBPR).

Specify the posting sense of the payment lines entered for this payment attribute:

• Not determined: will depend on the payment sense (Expenditure or Revenue)
• Revenue: Irrespective of the payment sense, will be considered as a revenue
• Expenditure: Irrespective of the payment sense, will be considered as an expense.

Payment sense
If the sense of the entry is defined as the payment sense, the amounts entered for this payment attribute are considered as being expenditures or revenues based on the sense of the posted open item or the payment sense.

Expenditure/Revenue
If the sense of the entry is defined as being an expenditure or a revenue, the amounts entered for this payment attribute will always be considered as such, irrespective of the payment sense.
For instance, charges on a check are always considered as an expenditure, be it a check received or issued.

In the absence of a journal posted on the payment line, the payment sense prevails (see documentation on Payment transactions)

This field is optional and it can only be accessed for targets other than 'Bank <=> BP'. If it is filled, it refers to an automatic journal (see documentation Automatic journals). It specifies that the lines of a payment associated with this payment attribute should be posted to a separate journal, since the entry lines generated for payment attributes without "separate journal ref." are all regrouped in the same journal for a payment.

For instance: Payment of € 1.200 € for the Sigma customer

• Payment of €1.200 on a Customer invoice (Payment attribute ENC Bank <=> BP)
• Discount of €6 for the same invoice (Payment attribute ESC Account <=> BP, Account 665000)

Posting of line 1 (REG) and Posting of line 2 (ESC).

• If ESC is associated with a "Separate journal ref.", 2 journals each corresponding to a payment line are generated.
• SIGMA (C)                     1200
• SIGMA (C)                     6
• Bank (D)     1200
• 665000 (D)          6
• If the field " Ref. of separate document " is empty, the following entry is generated:
• SIGMA (C)                     1206
• 665000 (D)          6
• Bank (D)     1200

This field is only assigned if a separate journal has been entered, and the account structure implies a cash account (Bank).

The Inter-banking code is a coding used by all banks to indicate the type of banking operations on the lines of the bank statements that are sent to their customers. The list of codes available for selection is defined at the level of miscellaneous table 306.

Journals also have an inter-banking code. The latter is used to facilitate (sort, selection) and to control the bank reconciliation (RAPBAN function) between the postings of a bank account and the lines of the bank statements. The code entered here can be transmitted to the payment posting documents via the automatic payment journals.

The inter-banking code of the payment attributes can be used in the formula field "Inter-banking code" of the automatic journal specified as "Separate journal". This initializes the inter-banking code of the journals generated for the payment lines entered with this payment attribute.

The accounts in use can be fixed by the payment attribute or specified during payment entry:

• for bank attributes of type Bank<=>BP, it is possible to enter a collective pre-payment account by assigning an accounting code of type Payment in the Pre-payment field.
  The payment line are then posted on the specified pre-payment account and not on the payment header BP account.
    When setting up the accounting code, if the chart of accounts is associated with a main general ledger, the pre-payment account MUST be a collective account.
• for the other payment attribute types, it is possible to specify the account by entering an accounting code of Payment type in the Code field.
  The distinction is then made between two accounts based on the nature of the payment line (gain or loss).

The accounts in use can be fixed by the payment attribute or specified during payment entry:

• for the Bank <=> BP payment attributes, it is possible to enter a collective or general pre-payment account by specifying an accounting code of Payment type in the Pre-payment field.
  The payment lines are then posted to the specified pre-payment account and not on the BP account of the payment header.
• for the other payment attribute types, it is possible to specify the account by entering an accounting code of Payment type in the Code field.
  The distinction is then made between two accounts based on the nature of the payment line (gain or loss).

Specify if the payment attribute can be posted to an open item and, in this case, the default document type for this open item.

The Bank <=> Account payment attributes can never be posted.

This field can only be accessed for 'Account <=> BP' payment attributes and it makes it possible to have the early discount/late charge calculations available upon manual entry of payment lines.
This concerns only the reconciled open items having an early discount/late charge code, and for which the variance between the payment date and the due date justifies that these expenses are taken into account.
Thus for this open item type, entering an additional early discount/late charge line to a payment attribute ticked 'Early discounts/late charges' triggers the calculation of the Early discount/Late charge set up for the corresponding invoice rather than the open item closure proposal.

Update 8.0.0 and higher:

This check box is submitted to the FAS activity code.
It is used in the payment entry of a purchase invoice or supplier BP invoice. It is activated in order to indicate that the creation of an early discount line posted on this account must result in the creation of a capitalized expense in the Fixed asset module.
The setup of the accounting code but be in compliance with:
- the Early discount/Late charge box is checked,
- the generated entry matches this pattern: Account <=> BP.

This process can only operate if the following conditions 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).
• 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.
  

Enter the VAT management type associated with the payment attribute. As a function of which, a VAT code will be/will not be entered in the payment lines and different VAT posting structures that will be generated on the posting of a payment.

The user can specify -during setup- wether the payment attribute manages the VTA or not. If it does manage the VAT, different VAT posting structures will be generated upon posting a payment:

• Pre-payment VAT1 (D) VAT Account VAT2 (C) VAT
• VAT Recept. or VAT/Expenses Line Account (C) X-VAT
  (except for Bank <=> BP) Account VAT2 (D) VAT

The VAT accounts are defined from the VAT code indicated in the payment line and the associated accounting codes: