Payment/Receipt Entry

• Payment no. (field 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 (field 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:

• Entry batch (field PAYLOT)

 Specify the entry batch which the payment is linked to.

• By default, the payment will be 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 counter of the entry batches for payments needs to be defined.

The batch elements can be viewed at payment entry in the "Entry batch" tab; selecting a batch payment automatically updates the "payment" tab in order to view the one that has been selected.

A range on "entry batches" is available in the various functions associated with the payments: draft management, deposit to bank, note generation, etc.

• Description (field LOTDES)

 Specify the title of the entry batch.

• Site (field 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.

• BP (field BPR)

The choice for payment posting is made:

• On a BP: the control account code and the associated account are displayed by default.
• On a control account: the account that is associated with it is displayed by default, the BP must be specified.
• On a GL account.

 Specify the BP issuing or receiving the payment. When the payment should be posted to a general account (rent, electricity, etc.), this field should be left blank and the general account subsequently entered.

• Mandate reference (field UMRNUM)

• Control (field 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.

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).

No BP/Company  tab on the BP record.

When the customer or supplier code is specified, the Control account defined on the Financial tab on the first line of the accounting code is used.

P BP/Company tab present on the BP record.

For a document, the site and the customer or supplier code are the first information entered. The BP record is searched on the BP/Company tab to see if an exception line has been created for the entry site company and, if required, finds the customer or supplier accounting code.

The account of the first line of the accounting code is then used. When the exception line is absent for the entry site company, the Financial tab of the BP record is referenced to identify its code.

• Account (field 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.

• Address code (field BPAINV)

The mandatory field Address code   is used to specify a payment address code.

• If the BP is specified, the field will be initialized from the address code that has been set up:
• in the supplier or customer record if the BP is only supplier or customer,
• if the BP is both customer and supplier: in the customer record if the transaction is of type 'revenue" and in the supplier record if the transaction is of 'expense' type.
• If the BP is not mentioned, the field will be initialized using the address code set up in the "Address" tab of the account record when the payment is entered on a general account.

This address will be used to initialize field Bank ID number when it is present in a transaction.
If the payment transaction is of 'Unspecified' type, the address code is not initialized.

In the specific case of SDD, after selecting the Mandate reference, the address code associated with the selected mandate is displayed but cannot be modified.

• field BPRNAM

• No. (field LIN)

• Total allocated to BP (field TOTIMPUT)

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

• Remaining for allocation (field 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.

• Bank amount (field TOTBQE)

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

• BP account balance (field SOLDE)

• Company (field CPY)

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

• Accounting date (field 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.

• Payment method (field 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.

• Sign (field SNS)

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

• Remittance reference (field 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.

• Entry reference (field 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.

• Payment reason (field 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).

• Description (field 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.

• Bank (field 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 zone: each bank includes a set of journals (bank, draft payable/receivable, intermediary deposit, 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.

• Currency (field 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.

• BP amount (field 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 bank curr (field 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).

• Check type (field 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".

• Check number (field 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.

• Pay-by branch (field CHQBAN)

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

• Due date (field 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.
  

• Discount type (field FRMTYP)

Specify the deposit site (Cash receipt, Discount) corresponding to the payment.

• This field is only entered and used for those transactions whose print code is not associated with CHE or CHR.
  For the other transactions where the deposit type can be entered, this field is used as grouping criterion of payments upon generation of the deposit notes. The deposit type can also be used as selection crierion during intermediate posting and bank posting of the deposit notes.
   
• If the payment transaction is managed by "due date", it is considered that the draft deposit is made by default on the due date (type discount on cash) and the deposit to the bank date is thus the open item due date. On exception, at deposit note entry level, it is possible to deposit certain drafts for discount. In this case, even if the transaction is managed by open item due date, the entry of the "accounting date" for the deposit to the bank becomes available.

• Source date (field ORIDAT)

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

• Drawee reference (field 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.

• Bank date (field 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".

• Value date (field 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.

• Payment nature (field 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.

• Date created (field 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.

• Card type (field 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.

• Economic reason (field 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 the BP 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).

• Purchase type (field PURTYP)

Specify whether it concerns the payment of a purchase of goods/services or fixed assets. The values of this field are defined in the local menu 646. 

Depending on the case, the VAT accounts with possible movements upon posting of the payment will be different. Consequently, via the payment transaction and the automatic journals, it is possible during draft management to define different posting structures depending on the purchase type.

• Bank acct. country (field BIDCRY)

Specify the banking information of the BP or general account in the payment header:

• Country code: provides the entry format and the control algorithm of the Bank ID number subsequently entered. The "Bank ID no. information" button is used to display and/or modify the information on bank tansfers. This button depends on the VII activity code. 
• Bank ID number with the key: selection of one of the BP's bank ID numbers. Part of the content of this field can be initialized and controlled. The bank ID number can be initialized from the payment address code.
• 2 lines of paying banks: These fields specifies the paying bank relating to the Bank ID no. These pieces of information are used to make up the transfer, deduction and draft 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 right click

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 ID no. field.

Intermediary Paying Banks (1, 2, 3 & 4) - Accessible by right click

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 ID no. field.

• IPI code (field 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.

• Instruction key EZAG (field 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.

• Instruction key DTA (field 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.

• Bank charge bearer (field 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.

• Bank statement (field BSITRS)

• Attribute (field 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.

• Type (field 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.

• Entry (field 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.

• Site (field 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.

• Curr. (field 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.

• Withholdings (field 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:

• Amount (field AMTLIN)

Specify the paid amount corresponding to the payment line, expressed in the invoice currency.
If the BP amount field has been entered, the selected open item loads this field by default with the global amount of the open item up to the limit of what has been entered in the payment header.

• Allocated to BP (field AMTLIN2)

Specify the paid amount corresponding to the payment line, expressed in the payment currency.

Only payment attributes of the Bank <=> BP type can affect the Amount posted column, expressed in payment currency.
To be able to save the entry of a payment, the sum of the posted amounts of the payment must be equal to the amount of the payment specified in the BP amount field in the header information.
If it is not the case, the Unbalanced payment window is automatically displayed. This window displays the header amount, the amount of lines and the variance amount.
You can choose the terms for correcting this variance:

• BP amount adjustment: this choice applies when errors of entry are recorded on the header amount. This amount is automatically modified in order to include this variance.
  
• Rounding variance: this choice applies to cases where the sum of the line converted amounts is different from the BP amount. Two additional 'technical' posting lines are automatically added to the payment corresponding to the generation of two rounding variance entry lines:
  
• One line is created on a payment attribute of the Bank <=> BP type so as to get the required correspondence between the entered BP amount and the sum of the converted amounts related to posted invoices. This attribute is characterized by the value of the PAYRNDCDA1 - Bank - BP rounding variance parameter (TRS chapter, PAY group).
  
• One line is created on an Account <=> BP payment attribute in order to balance the BP account and record the variance in the revenue or expense account. This attribute is characterized by the value of the PAYRNDCDA2 - Account - BP rounding variance parameter (TRS chapter, PAY group).
  
• Manual correction: this choice is used to go back to the screen modification mode in order to be able to modify the amount yourself.

• Discount date (field DISDAT)

• Tax (field 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.

• Description (field DESLIN)

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

• Unit (field 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.

• Quantity (field 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.

• Distribution (field 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.

The default dimension setup is not used when you enter a distribution in an amount or in a percentage.

• field 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.

• field LIGFLG

• Number (field PAYNUM)

• Date (field PAYDAT)

• Site (field PAYFCY)

• Bank (field PAYBAN)

• Payment method (field PAYPAM)

• Ctrl. (field PAYBPRSAC)

• BP (field PAYBPR)

• Currency (field PAYCUR)

• Amount (field PAYAMTCUR)

• Status (field PAYSTA)

• Slip no. (field PAYFRMNUM)

• No. of payments (field NBRPAY)

• Total (field TOTLOC)

• field CPYCUR

• Start balance (field STRBAL)

This field is displayed only if the "Balance control" is activated in the entry transaction. It is entered only if the balance control of the bank is set to "Yes". In this case, the start and end balances can be modified using the button .

• Difference (field PRODIF)

This field is displayed only if the "Balance control" is activated in the entry transaction. It is entered only if the balance control of the bank is set to "Yes".
Any change within an “Entry batch” causes to recalculate the difference for the balance (progressive balance - end balance).

• field CHGBAL

This button is displayed only if the "Balance control" is activated in the entry transaction. It can be accessed only if the balance control of the bank is set to "Yes".
It opens a window used to modify the start and end balances of the bank statement.

• End balance (field ENDBAL)

This field is displayed only if the "Balance control" is activated in the entry transaction. It is entered only if the balance control of the bank is set to "Yes". In this case, the start and end balances can be modified using the button .

• Progressive balance (field PROBAL)

This field is displayed only if the "Balance control" is activated in the entry transaction. It is entered only if the balance control of the bank is set to "Yes".
Any change within an “Entry batch” causes to recalculate the progressive balance (start balance + entries).

• field BANCUR

This field is displayed only if the "Balance control" is activated in the entry transaction. It is entered only if the balance control of the bank is set to "Yes".
The currency from the bank is shown.

• field DVCRNUM

This field displays the document number.

• Remaining amount (field RMNAMT)

This field displays the amount remaining to be authorized for the document.

• Customer (field BPCNUM)

This field is used to display the customer that will be used upon adding or saving payment cards.

• Company (field DOCCPY)

This field is used to display the company linked to the processing code.

• One time use card (field ONETIME)

This check box is automatically selected if a saved payment card does not exist on the customer record.

If the customer record is assigned a default card, this check box is cleared and the primary card information for the account nickname displays.

If a saved payment card exists on the customer record, but a default card does not exist, this check box is cleared and the account nickname must be entered or selected.

If the customer's BPC type is miscellaneous, this check box is automatically selected.

Select the check box for One time use card to add a payment type to use one time for this order or shipment. The data for payment and billing information is not stored and you do not need an Account nickname.

• Account nickname (field ACCNCKNAM)

Enter a unique account nickname to identify this payment card. You can select an existing payment card for this customer or you can create a new payment account by entering a new account nickname.

• The account nickname can include alpha and numeric characters with a maximum length of 15 characters.
• If a customer has multiple payment cards on file, the account nickname must be unique. However, two different customers can have payment card records that use the same name.
• If the One time use card check box is selected, this field is not available. If the check box is not selected, this field is required.

 When adding a new payment card, click Create after entering a unique nickname to enter the payment card information for this Account nickname.

• Processing code (field PRCCOD)

Enter a processing code defined by the user. This code identifies the link to the company and account defined in the Payment gateway setup.

• If a default processing code exists, use this field to create a new payment card.
• If a payment card already exists, recorded and selected in the customized account name field, the default value of this field is automatically displayed and cannot be modified.

• Payment type (field PYMTYP)

This field is used to display the payment type used. The valid values include Visa, MC, AMEX, and others.

• Last four digits (field ACCL4D)

This field displays the last four numbers of the payment card.

• Expiration date (field EXPDAT)

This field displays the expiration date of the payment card.

• Manual entry (field MANAUT)

Select this check box to enter transaction information for Sage Exchange transactions that are processed manually outside of Sage X3.

This field is available only if the parameter MANAUTH is set to Yes at the user level.

• Amount (field AUTAMT)

This field displays the authorized amount of the payment card processed by Sage Exchange.

• Code (field AUTID)

This field displays the authorization code for the transaction.

• Date (field AUTDAT)

This field displays the authorization date of the payment card.

• Status (field STAFLG)

This field displays the status of the transaction by payment card.

• Name (field ACCNAM)

Enter the cardholder name.

If a saved payment card is selected, the cardholder name displays and cannot be changed.

If the One time use card check box is selected, the cardholder name must be entered and the information is saved to the payment card transaction.

• Billing address (field USEBILLADR)

Check this box to display the default billing address of the customer.

• If this box is checked, the lines corresponding to the billing address of the customer are displayed and cannot be changed.
• If this box is unchecked, the information of the billing address can be modified in the address fields of the card.

• Country (field CRY)

Enter the country of the invoicing address of the cardholder.

• If the 'Billing address' check box is selected, the country from the customer bill-to address appears and cannot be modified.
• If the 'Billing address' check box is not selected, the country from the customer bill-to address cannot be modified.

• Address (field ADDLIG)

Enter the billing address of the cardholder.

• If the 'Billing address' check box is selected, the address from the customer bill-to address appears and cannot be changed.
• If the 'Billing address' check box is cleared, the billing address can be changed.

• field SAT

Enter the invoicing status of the cardholder.

• If the 'Billing address' check box is selected, the status from the customer bill-to address appears and cannot be changed.
• If the 'Billing address' check box is cleared, the invoicing status can be changed.

• Postal code (field POSCOD)

Enter the postal code of the cardholder.

• If the 'Billing address' check box is selected, the postal code of the customer displayed on his/her bill-to address appears and cannot be modified.
• If the 'Billing address' check box is not selected, the postal code from the customer bill-to address cannot be modified.

• City (field CTY)

Enter the town of the invoicing address of the cardholder.

• If the 'Billing address' check box is selected, the town from the customer bill-to address appears and cannot be changed.
• If the 'Billing address' check box is not selected, the town from the customer bill-to address cannot be changed.

• Email address (field EMAIL)

This field displays the contact e-mail address of the customer from the transaction.

• Amount (field PAYAMT)

This field displays the payment amount to be applied to the payment card during the invoice allocation.

• Date (field PAYDAT)

This field is used to display the payment date used during the transaction.

• Number (field PAYNUM)

Payment number associated with the transaction.

• Document (field HVCRNUM)

This field displays the document number that was processed against the selected payment card.

• Sequence (field HVCRSEQ)

This field displays the sequence number counter of the document, processed or the selected payment card.

• Transaction type (field HTXNTYP)

This field displays the transaction type of the document, processed for the selected payment card.

• Amount (field HAUTAMT)

This field displays the invoiced amount of the document processed for the selected payment card.

• Original amount (field HORIGAUTH)

This field displays the amount of the document that was originally authorized or, if it was rejected, the amount attempted to authorize.

• Date (field HAUTDAT)

This field displays the processing date of the transaction for the selected payment card.