Payment/Receipt Entry

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.

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:

 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.

 Specify the title of the entry batch.

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

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.

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.

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

 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.

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.

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

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

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.

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

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.

 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.

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

 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.

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.

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.

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.

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

This field defaults to the currency rate listed in the Currency rates table.

If the Main ledger currency rate field is selected in Payment entry types, you can enter a currency different from the one in the rate table and this value is used as the final rate when the payment is posted.

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

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.

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

 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.
  

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

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

 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.

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

 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.

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.

 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.

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.

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

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.

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.

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.

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.

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.

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.

 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.

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.

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.

 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.

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.

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:

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.

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.

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.

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

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.

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.

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

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.