Registo pagamentos

• Nr. pagam. (campo NUM)

The payment number is the unique identifier for a payment. Upon creating a new payment, this number is automatically attributed thanks to the counter defined for payment transactions; this counter can be different for the revenue and the profit. By default, this counter is PY1.

• Status (campo STA2)

The payment status is generated automatically. It will take different values (defined in local menu 689), based on the level of progress of its processing.

Example: For a payment by check.

• If the payment has been created but not processed, the Status field will have the value Entered.
• If the check has been posted to the bank, the Status field will have the value In the Bank.

This ensures that the user can see the level of progress of the payment processing. For information, the various stages reached in the payment processing are the following:

• Lote registo (campo PAYLOT)

Specify the entry batch the payment is linked to:

• By default, the payment is attached to the current batch (the value of the field is initialized with the current batch number).
• Leave this field blank if the payment should not be attached to any entry batch.
• To assign the payment to a new entry batch, enter "*" in this field. In this case, the payment entry batch sequence number needs to be defined.

Entry batches can be viewed in payment entry in the Entry batch section. Selecting a batch payment automatically updates the Payment section where you can view the selected payment.

You can define a range of entry batches in the functions related to payments: notes payable/receivable posting, bank posting, remittance generation, etc.

• Descr. (campo LOTDES)

 Specify the title of the entry batch.

• Nº reg. caixa/banco (campo REGNUM)

• Aprovado (campo PAYAPPFLG)

This field displays the payment approval status. If a payment has been approved and you make any changes, the status reverts to not approved.

• Estab. (campo FCY)

Specify the site to which the payment should be made or from which it should be issued. It is initialized by the site associated with the user code. it can be modified provided it is chosen from the list of authorized sites.
If the payment is assigned to an entry batch, the specified site must belong to the company of the entry batch.

When the payment is posted, entry of the cash account will be made on the site specified here.

• Terceiro (campo BPR)

Le choix de l'imputation du règlement se fait :

• Sur un Tiers : le code de collectif et le compte associés s'affichent par défaut.
• Sur un collectif : le compte qui lui est associé s'affiche par défaut, le Tiers reste à préciser.
• Sur un compte général.

 Indiquez le tiers émetteur ou récepteur du règlement. Lorsque le règlement est à comptabiliser sur un compte général (Loyer, EDF, etc. ), laissez cette zone à vide et renseignez ensuite le compte général.

• Referência mandato (campo UMRNUM)

• Colectivo (campo BPRSAC)

Specify the control account associated with the payment BP. By default, the submitted control account is: 

• the 'Purchase' control account of the accounting code of the suppliers, 
• the 'Sales' control account of the accounting code of the customers, 
• the default control account of the accounting code of the miscellaneous BPs
  not forgetting that a BP being both a customer and a supplier is considered as customer for a transaction of revenue type and as supplier for a transaction of expenditure type.

O modo de inicialização da zona "Colectivo" depende da presença, ou não, do separador "Terceiros/Sociedade" da ficha Terceiros.

Ausência do separador "Terceiros/Sociedade" na ficha Terceiros.

Quando o código cliente/fornecedor está indicado, o programa remonta no separador "Financeiros" da sua ficha e proposta por defeito a conta colectiva se encontrando em linha 1 do seu código contabilístico.

Presença do separador "Terceiros/Sociedade" na ficha Terceiros.

Sobre um documento, o estabelecimento e o código cliente/fornecedor são as primeiras informações registadas. Sage X3 remonta sobre a ficha Terceiros e no separador "Terceiros/Sociedade" pesquisa se uma linha de excepção foi criada para a sociedade do estabelecimento do movimento, e se for caso disso, encontra-se o código contabilístico cliente/fornecedor. O programa recupera a conta da linha 1 do código contabilístico.
Em ausência de linha de excepção para a sociedade do estabelecimento do movimento, o programa remonta no separador "Financeiros" da ficha do terceiro para aí identificar o seu código.

• Conta (campo ACC)

 This field can only be entered if no BP or control account has been previously entered. It is used to specify the general account (rent, electricity, etc.) to post the payment to.

• Código endereço (campo BPAINV)

Le champ obligatoire Code adresse  permet d'indiquer un code adresse de règlement.

• Si le tiers est indiqué, le champ sera initialisé à partir du code adresse paramétré :
• dans la fiche fournisseur ou client si le tiers est uniquement fournisseur ou client,
• si le tiers est à la fois client et fournisseur : dans la fiche client si la transaction est de type 'recette' et dans la fiche fournisseur si la transaction est de type 'dépense'.
• Si le tiers n'est pas indiqué, le champ sera initialisé à partir du code adresse paramétré dans la section 'Adresse' de la fiche compte lorsque le règlement est saisi sur un compte général.

Cette adresse permettra d'initialiser le champ RIB  lorsqu'il est présent dans une transaction.
Si la transaction de règlement est de type 'Indéterminé', le code adresse n'est pas initialisé.

Dans le cas spécifique du SDD, après la sélection de la Référence mandat, le code adresse relatif au mandat sélectionné est affiché et n’est pas modifable.

• campo BPRNAM

• Total imputado terc. (campo TOTIMPUT)

Field updated in real time based on the open item selection.

• Rest. a imputar (campo RSTIMPUT)

When the header field 'BP amount' is entered, this field is used to identify the progressive amount remaining to be posted to the invoices in real time.

• Montante banco (campo TOTBQE)

Amount passed to the bank account. The latter is determined on payment creation.

• Saldo conta terceiro (campo SOLDE)

• Socied. (campo CPY)

This field is automatically displayed after entry of the operation site. It corresponds to the company containing the site.

• Data contab. (campo ACCDAT)

• It corresponds to the payment entry date. It is initialized by the system date (current date) and it is modifiable. It is used as the accounting date at the time of the first payment posting.
  As a consequence, all validity checks with respect to the dates of the natures, dimensions, analytical allocations and amount conversions in various currencies on payment management are carried out using this date.
   
  This date corresponds to a period and a fiscal year open for the company mentioned in the payment.
   
• If the payment transaction is managed by 'due date', the accounting date for the deposit to the bank is forced to the payment due date.

• Modo pagamento (campo PAM)

The payment method corresponds to the method used to carry out the payment (check, credit card, exchange of goods, etc. The payment methods are defined in miscellaneous table no. 3).
If the payment transaction is set up as having several possible payment methods, it is possible in this field to select the payment method to use. The first payment method assigned to the transaction appears by default.

• Sentido (campo SNS)

Specify if the payment is a revenue or an expense. It only appears if the sign is not indicated at payment transaction level.

• Ref. desconto (campo FRMREF)

It is possible to enter an internal reference for the discount applied to the payment. 
This reference can be used as grouping criterion for the payments upon generation of the deposit slips.

• Ref.documento (campo REF)

 An internal reference can be entered for the payment document.
This information is used to elaborate bank deduction and transfer files, and to select payments via the extension and doubtful receipt functions. It can also be used in the payment posting journals via the 'Journal reference' formula of the automatic journals.

• Motivo regularização (campo EPARENPAY)

A payment reason code is used when generating bank files in SEPA Credit Transfer and SEPA Direct Debit formats.
It corresponds to the 'Remittance information' data from the ISO 20022 standard messages.
This field can be entered provided the payment entry is associated with a payment transaction accepting SEPA format. It can be used to enter a reason for each payment (maximum length = 140 characters).

• Descrição (campo DES)

 It is possible to enter a formula : This information is used by default as the titles of the payment lines and postponement lines (if the 'line description' field has been selected at the time of setup of the payment transaction). It is also used upon setup of the bank files.

• Banco (campo BAN)

The entry transaction used will determine if cash operations apply to bank or cash funds. The entry transaction also defines if it is mandatory or optional.

• When the information is mandatory, it is initialized based on the following order of priority: the customer or supplier bank/cash funds, the bank entered on the site, the value of the user parameter BANKDEF - Bank by default, for banks, and of the user parameter CAISDEF - Default cash (chapter TRS, group DEF) for cash funds.
• When the entry is optional, you can allocate a bank to a payment later, using the bank entry or allocation functions.

Each bank or cash fund is linked to a general ledger account (see the Bank accounts documentation).

The cash account to be posted is determined with respect to this field: each bank includes a set of journals (bank, notes payable/receivable, intermediary posting, etc.), which is used to locate the cash account to be used according to the posting phase. Each cash fund includes a journal and an account used to generate the associated entry.

• Divisa (campo CUR)

Specify the payment currency. By default, it is the business partner currency. A few cases to be highlighted:

• The payment currency is different from the invoice currency (payment lines): other that the main posting (automatic journals PRINC or STEPN), an MO journal is generated via the PYODD automatic journal.
• The payment currency is different from the bank currency (the bank currency is set up at cash general account level): other that the main posting (automatic journals PRINC or STEPN), an MO journal is generated via the automatic journal PYODD or PYDVN.

• Montante Terc. (campo AMTCUR)

Specify the payment amount. This amount is expressed in the payment currency. The currency in which the amount is expressed is displayed beside the field.
It is important to enter this amount because the open items selected on the payment will then have a default amount equivalent to that of the open item, up to the amount entered in this field.

• C/T val div. Banco (campo AMTBAN)

This field contains the effective amount of the payment expressed in the bank currency. This field is used to express a counter-value when the payment currency is different from the bank currency. If the counter-value entered is different from the counter-value found by the software, a warning message requests the confirmation of the entry and displays the counter-value found (based on the exchange rate type in force on the accounting date).

• Câmbio (campo CURRAT)

Le champ prend par défaut la valeur du cours de devise listé dans la table des Cours de devise.

Si le champ Cours référentiel principal est sélectionné au niveau des Transactions de saisie de règlements, vous pouvez saisir une devise différente de celle de la table des Cours de devise. Cette valeur sera utilisée comme cours définitif au moment de la validation du règlement.

• Tipo de cheque (campo CHQTYP)

Specify the check type (On-site, Off-site, Foreign, Euro) corresponding to the payment. This field is used as grouping criterion for the payments upon generation of the deposit slips for:

• the transactions defined with entry of the check type and a print code associated with the CHR or CHE processing code.
• the banks defined with 'On/Off site deposit'.

• Nr. Cheque (campo CHQNUM)

The check number is used to provide payment traceability. It is taken as a reference in the journal entry generated by the payment processing (defined at payment journal setup level).
For expenses associated with the transactions defined with 'Mandatory printing' and the print code associated with the CHE (issued checks) processing code, the check number must necessarily be entered before posting to the bank. This can be done by printing checks or check letters.

• Estab.pagador (campo CHQBAN)

 Specify the paying organization for the received checks. The information (check number and paying organization) is used during the printing of the checks.

• Data de vencim. (campo DUDDAT)

 Specify the due date of the payment. This is the date from which the amount is due.

If payment transaction is managed by 'open item due date':

• the item due date is initialized in different ways based on how the payment is entered (in this case, it is up to the user to control the value of this date that is by default initialized to the due date) or generated from the automatic payment proposal (the due date is then initialized to the date closest to the open items which make up the payments).
• the accounting date for the deposit to the bank is forced to the payment due date. It is possible to enter a different posting date during the deposit note phase if the deposit is discounted.

In the specific case of SDD (SEPA Direct Debit):

• The due date must be later than the mandate signature date.
• The due date of a payment having a sequence of Recurring (RCUR) type must be later than the date of the payment associated with a sequence of First (FRST) type.
• The due date of a payment having a sequence of Recurring (RCUR) type must be earlier than the date of the payment associated with a sequence of Last (FNAL) type.
  

• Tipo desconto (campo FRMTYP)

Specify the remittance type (collection, discount) corresponding to the payment.

• This field is only entered and used for transactions whose print code is not associated with CHE or CHR.
  For other transactions where the remittance type can be entered, this field is used as a grouping critera for payments when generating remittances. The remittance type can also be used as a selection crieria when remittances are subject to an intermediate posting or bank posting.
  
• If the payment transaction is managed by open item due date, the notes payable/receivable posting is done by default on this date (remittance type on collection) and so, the bank posting date is also the open item due date. Exceptionally, on the remittance, you can also process some notes payable/receivable on discount. In this case, even if the transaction is managed by open item, you can enter an accounting date for the bank posting (the field is available).

• Data origem (campo ORIDAT)

This is the payment creation date. By default, it is the current date.

• Ref.do sacado (campo BPRREF)

 Specify the reference of the drawee, that is, the debtor. This piece of information is useful to elaborate the LOC deposit files and to select a payment in the manual reconciliation function.

• Data banco (campo BANDAT)

The bank date resembles a management by value date but on the financial organization side. Legal date for all print-outs linked to a Bank. In certain countries the 'accounting date' is different from the 'bank date' that itself can be different from the 'value date'.

• Data do valor (campo VALDAT)

 Specify the value date of the payment. This is the date from which the payment amount deposited to the bank will be actually available from this bank, without additional costs. The value date is initialized by default to the due date.

• Natureza pagamento (campo EPANATPAY)

This field is linked to miscellaneous table 313.
It is displayed only for payment entry transactions accepting SEPA format and qualifies the nature of the SEPA Credit Transfer and SEPA Direct Debit.

• Data criação (campo BILDAT)

 Specify the creation date of the payment. By default, this is the current date. This piece of information is recalled in the file transmitted to the bank.

• Tipo de cartão (campo CRDTYP)

This field appears when the option 'Bank card no.' has been chosen when setting up the payment transactions. Specify the information relating to the payment by credit card:

• Type of card: if this field is not entered, the others are not entered either.  The values of this field are defined in miscellaneous table no. 314.
• Card number: a control algorithm is set up for VISA cards.
  The credit/bank card number provides payment traceability. It is taken as a reference in the accounting document generated by the payment processing (defined at payment journal setup level).
• Validity end date: mentioned on the credit/bank card. Month on 2 numbers/Year on 2 numbers
• Authorization number This is a code for internal use, non managed as standard by Sage X3.

• Motivo económico (campo BDFECOCOD)

The economic reason code is used by the Banque de France when determining the Balance of payments.
It is necessary for any operation that fits into the following contexts:

• transactions in euro to a bank within the European Union, including France, for non-resident's accounts, starting from €50,000,
• transaction in euro to a bank outside the European Union, starting from €12,500,
• transactions in a currency -other than the euro- to a bank within the European Union, including France, starting from €12,500.

 The resident or non-resident option is defined at theBP level.
The declaration limits are determined by the parameter values 'Payment balance Threshold': AMTVIR1, AMTVIR2 and AMTVIR3 (chapter TRS - BP, group DEF - Default values).

The entry of this code and its mandatory entry are determined at the level of the payment entry transaction parameter.
If the company from which the payment is made has the status of general direct declaring site to the balance of payments, code 060 'General direct declaring site' will be proposed (Company record parameter).
Otherwise, the value suggested will be that defined at BP level (BP record parameter).
 This code can be modified.
This value is retrieved in the bank files (AFB160, AFB320, SEPA Credit Transfer).

• Tipo de compra (campo PURTYP)

Indicate if the payment is linked to a purchase of goods and services or to fixed assets. The possible values of this field are defined in local menu 646.

In this case, the VAT accounts with movements created on payment posting can vary. Using the payment transaction and automatic journals, you can also define various posting structures for the notes payable/receivable posting depending on the purchase type.

• País NIB (campo BIDCRY)

Specify the bank details of the BP or of the general account in the payment header:

• Country code: provides the entry format and the control algorithm of the bank details subsequently entered. The Bank details button is used to display and/or modify the information on bank tansfers. This button depends on the VII activity code.
• Bank account number with key: selection of one of the BP bank account numbers. Part of the content of this field can be initialized and controlled. The bank account number can be initialized from the payment address code.
• 2 lines of paying banks: These fields specifies the paying bank relating to the bank account number. This information is used to create the transfer, the deduction and the notes payable/receivable files to be transmitted to the banks.

Specific case for SDD: After selecting the Mandate reference, the country code associated with the bank account of the pay-by BP for the selected mandate is displayed but cannot be modified.

Paying Banks of the beneficiary (3 & 4) - Accessible by Actions icon

These fields are used to manage the intermediary banks within the framework of commercial exchanges with non-western countries. They are accessible from the Bank account no. field.

Intermediary Paying Banks (1, 2, 3 & 4) - Accessible by Actions icon

These fields are used to manage the intermediary banks within the framework of commercial exchanges with non-western countries. They are accessible from the Bank account no. field.

• Cód. IPI (campo SWIIPI)

This field is related to the activity code KSW – Switzerland.
This is an extra field which can be activated in the Payment entry type definition. It allows to enter the IPI code (International Payment Instruction) for a payment, if IPI transactions are used.

• Chave instrução EZAG (campo SWISUP1)

This field is related to the activity code KSW – Switzerland.
This is an extra field which can be activated in the Payment entry type definition. It can be used when PostFinance bank files (EZAG/OPAE format) are generated. It allows to enter additional paying instructions like Personally or Urgent.
Possible usage also depends on the payment transaction type to be generated in the bank file as not all PostFinance payment transaction types support additional instructions.

• Chave instrução DTA (campo SWISUP2)

This field is related to the activity code KSW – Switzerland.
This is an extra field which can be activated in the Payment entry type definition. It can be used when Swiss bank files (DTA format) are generated. It allows to enter additional paying instructions like Salary.
Possible usage also depends on the payment transaction type to be generated in the bank file as not all Swiss bank payment transaction types support additional instructions.

• Despesas bancárias à custa de (campo SWISUP3)

This field is related to the activity code KSW – Switzerland.
This is an extra field which can be activated in the Payment entry type definition. It can be used when Swiss bank or PostFinance files are generated. It allows to enter additional bank charge instructions like Shared, Beneficiary or Applicant.
Possible usage also depends on the payment transaction type to be generated in the bank file as not all payment transaction types support bank charge instructions.

• Extracto bancário (campo BSITRS)

• Dest. (campo DENCOD)

 Specify the payment attribute of the payment line. This piece of information specifies how the payment line will be subsequently posted (account structures to use).  The payment attribute defined at the time of the payment transaction setup is the one displayed by default.

Example: a payment attribute of Cash receipt type impacts a bank account and a BP account.

• Tipo (campo VCRTYP)

Specify the open item to be allocated to the payment line by specifying its type and journal number. This information can be entered only if the payment attribute entered is 'chargeable' ('matchable').
It enables payment posting to perform for example the matching between payment and paid invoice.
The document type and the document can be directly selected using one of the two left lists: 'Open items' or 'Grouped open items' The selected open item must:

• come from the payment company
• come from the payment site, if inter-site MOs are prohibited
• come from the control account and payment BP, if inter-BP MOs are prohibited
• be validated if it is associated with a purchase or sale invoice
• not be factored
• be approved for payment for creditor open items 
• not be associated with a BP blocked for payment, for expenses.

The document type given by default comes from the payment attribute. The document number corresponds either to the invoice number of to an open item on the invoice (case of a multi open item invoice). It can also be an order journal type (see general parameters BPSORDTYP - Supplier order doc type and BPCORDTYP - Customer order doc type) and in that case it will be necessary to enter the order number. No matching is triggered when a payment is reconciled to an order.

In the specific case of SDD: the open items to be allocated must have the same mandate reference as the one selected in the header.

• Doc. (campo VCRNUM)

Specify the open item to be allocated to the payment line by specifying its type and journal number. This information can be entered only if the payment attribute entered is 'chargeable' ('matchable').
It enables payment posting to perform for example the matching between payment and paid invoice.
The document type and the document can be directly selected using one of the two left lists: 'Open items' or 'Grouped open items' The selected open item must:

• come from the payment company
• come from the payment site, if inter-site MOs are prohibited
• come from the control account and payment BP, if inter-BP MOs are prohibited
• be validated if it is associated with a purchase or sale invoice
• not be factored
• be approved for payment for creditor open items 
• not be associated with a BP blocked for payment, for expenses.

The document type given by default comes from the payment attribute. The document number corresponds either to the invoice number of to an open item on the invoice (case of a multi open item invoice). It can also be an order journal type (see general parameters BPSORDTYP - Supplier order doc type and BPCORDTYP - Customer order doc type) and in that case it will be necessary to enter the order number. No matching is triggered when a payment is reconciled to an order.

In the specific case of SDD: the open items to be allocated must have the same mandate reference as the one selected in the header.

• Estab. (campo FCYLIN)

 Specify the site of the payment line. The site must belong to the payment company.
When the payment is posted, posting of the payment line for the counterpart of the cash account (BP account, charge account, VAT account) will be made on the site specified here.

The site proposed by default is the site of the allocated open item or the payment header site.

It is possible to modify the site on the line and also to carry out the inter-site operations for the same legal company. The link postings are automatically generated for the link accounts previously set up. No specific automatic journal is necessary.

• Divisa (campo CURLIN)

Specify the currency in which the paid amount corresponding to the payment line will be entered.

• If the payment line refers to a document/invoice: it is the invoice currency. By default, the submitted currency is:
• the currency of the allocated open item.
• the bank or company currency for the Bank<=>Account payment attributes 
• otherwise the payment header currency.
   
• If the payment line does not refer to a document/invoice: it is the currency of the entry header, that is, that of the 'Amount in currency'. In this case the currency can be modified. Where-used:
• Bank account kept in EUR.
• Payment in £ for an invoice in £.
• Bank charges in EUR.
   
• If the transaction specifies that the exchange rate for the payment is the 'invoice exchange rate' and that several invoices having different rates are selected within the same payment, the journal entry will specify the theoretical exchange rate on the payment date, and will leave empty the field for the actual exchange rate used.

In the specific case of SEPA, only the EURO is authorized and field Currency cannot be modified.

• Retenções (campo RITAMT)

This field concerns the Italian legislation: KIT activity code and ITARTZ - Italian deduction at source parameter (chapter LOC, group ITA).

This column is never entered and according to the Retention code setup, it can be empty. It indicates in negative and in retained currency the amount retained on the payment posted to the Cash/Status account(s) for the invoice indicated in the line. The BP amount is deducted from the retention calculated and the amount entered.

• For example: Invoice FAC001 for 1055 EUR 10% retention on the payment.

Payment entry:

Payment document:

• Montante (campo AMTLIN)

Indiquez le montant règlé correspondant à la ligne de règlement, exprimé dans la devise de facture.
Si le champ Montant tiers a été renseigné, l'échéance sélectionnée propose par défaut dans ce champ, le montant global de l'échéance à concurrence de ce qui a été saisi en en-tête de règlement.

• Imputado terc. (campo AMTLIN2)

Indiquez le montant réglé correspondant à la ligne de règlement, exprimé dans la devise de règlement.

Seules les destinations comptables de type Banque <=>Tiers mouvementent la colonne Montant imputé, exprimée en devise de règlement.
Pour pouvoir enregistrer la saisie d'un règlement, il faut que la somme des montants imputés du règlement soit égale au montant du règlement saisi dans le champ Montant tiers en en-tête.
Si ce n'est pas le cas, une fenêtre Règlement déséquilibré s'affiche automatiquement. Elle vous présente le montant de l'en-tête, le montant des lignes ainsi que le montant de l'écart.
Vous pouvez choisir la modalité de correction de cet écart :

• Ajustement montant tiers : ce choix s'applique en cas d'erreur de saisie du montant de l'en-tête. Ce montant est automatiquement modifié pour intégrer cet écart.
  
• Ecart d'arrondi : ce choix concerne le cas où la somme des montants convertis des lignes est différente du Montant tiers. Deux lignes 'techniques' d'imputation complémentaires sont automatiquement ajoutées dans le règlement et se traduisent par la génération de deux lignes d'écriture d'écart d'arrondi :
  
• Une ligne est créée sur une destination comptable de type Banque => Tiers, de façon à obtenir l'égalité souhaitée entre le Montant tiers saisi et la somme des montants convertis pour les factures imputées. Cette destination est indiquée par la valeur du paramètre PAYRNDCDA1 - Ecart arrondi Banque - Tiers (chapitre TRS, groupe PAY).
  
• Une ligne est créée sur une destination comptable de type Compte => Tiers, afin d'équilibrer le compte de tiers et d'enregistrer l'écart dans le compte de produit ou de charge. Cette destination est indiquée par le paramètre PAYRNDCDA2 - Ecart arrondi Compte - Tiers (chapitre TRS, groupe PAY).
  
• Correction manuelle : ce choix permet de revenir en modification sur l'écran afin que vous puissiez modifier vous-même le montant.

• Data desconto (campo DISDAT)

• Taxa (campo VATLIN)

Specify the tax code to be used to post the payment line. The tax code defines the rate, the rules and the terms for the tax deduction applicable to the operation. 
 This code is only entered if:

• The payment attribute of the line makes use of an account subject to VAT,
• for Bank<=>BP payment attributes, the pre-payment account or the payment header account is defined with VAT management,
• for the other payment attributes (Account<=>BP and Bank<=>Account), the payment line account, either coming from the accounting code of the payment attribute, or previously entered, is defined with VAT management.

The tax code proposed by default is that of the open item allocated to the payment line, or that of the account determined as specified above.

• Descrição (campo DESLIN)

 Specify the title of the payment line. This title is initialized with the payment header description, if it has been entered.

• Unid. (campo UOM)

During the setting up of an analytical nature, non-financial unit entry is confirmed or not. As required, a unit is allocated to it, by specifying its default value (in reporting currency). It is this unit that will appear during document entry. The quantity is automatically calculated by dividing the Ex-tax amount (converted into reporting currency) by the non-financial unit value. The quantity can be modified.

• Quantid. (campo QTYLIN)

During the setting up of an analytical account, non-financial unit entry is confirmed or not. As required, a unit is allocated to it, by specifying its default value (in reporting currency). It is this unit that will appear during document entry. The quantity is automatically calculated by dividing the Ex-tax amount (converted into reporting currency) by the non-financial unit value. The quantity can be modified.

• Repartição (campo DSP)

- If the accounting amount has been allocated over several analytical dimensions, specify the analytical allocation to post the payment line to. The methods of allocation must be compatible with the accounting date of the payment, the site and the analytical nature of the payment line.

These methods are defined as follows:

• Entry of an analytical budget weighting code previously configured (see documentation on Prior allocation keys)
• In amount. It is then possible to allocate the amount to as many sub-amounts as required.
• In percentage. A calculation is performed based on the sum of the coefficients used for the allocation.

Example: on a basis of 100, a coefficient of 10 will be read as 10%. But, on a basis of 50, a coefficient of 10 will be equivalent to 20%.

For these two later cases, it is possible to pre-initialize the allocation with an already existing key. The final display will be ' $ '. 

- If the accounting amount has not been allocated over several analytical dimensions, the 'allocation' field does not need to be assigned. The entry is achieved directly in the following columns, in the dimension concerned, for each of the dimension types.

The initialization of the dimensions is carried out by means of the default dimension codes and more particularly the default dimension code PAYMENTD.

• campo CCE1

Specify the dimensions to which the payment line should be posted. Depending on the setups of chapter CPT and the analytical nature of the payment line, entry of this field can be mandatory, optional or prohibited.

The entered dimension mut be compatible with the site and the analytical nature of the payment line, and the payment date.
By default, the submitted dimension comes in priority from: 

• the header of the invoice/order allocated to the payment line,
• the PAYMENTD default dimension code,
• the default dimension codes of the analytical nature of the payment line.

• campo LIGFLG

• Número (campo PAYNUM)

• Data (campo PAYDAT)

• Estab. (campo PAYFCY)

• Banco (campo PAYBAN)

• modo pag. (campo PAYPAM)

• Colectivo (campo PAYBPRSAC)

• Terceiro (campo PAYBPR)

• Divisa (campo PAYCUR)

• Montante (campo PAYAMTCUR)

• Status (campo PAYSTA)

• Nr.Documento (campo PAYFRMNUM)

• Nr. pagamentos (campo NBRPAY)

• Total (campo TOTLOC)

• campo CPYCUR