The setup of payment transactions is used to define the characteristics and the methods of exploitation of the different payment transactions used by the company:
Refer to documentation Implementation
The setup of the payment transactions is performed in three tabs, even four if the cash management interface is activated.
Fields
The following fields are present on this tab :
|
Single code identifying the payment transaction. |
|
|
Standard title of the current record. |
|
  |
|
  |
Close
Fields
The following fields are present on this tab :
Criteria
|
|
|
Access code that is used to restrict access to data by user or group of users. |
|
Specifies the payment sense. If the payment sense is defined as Expense or Receipt, the "Sense" field is not visible in the payment header screen (in payment entry). In this case, the user knows that the payment transaction is always an expense (issued cheque for example) or always a receipt (cheque receipt for example). If the sign is not determined, the "Sign" field is entered in the payment header as Receipt or Expense. This makes it possible to create only one payment transaction used for both receipt and expenses (Cash entry for example). |
Block number 2
|
This field determines whether the treasury account linked to this payment transaction is a cash management account or a bank account. If the payment management is associated with a petty cash:
|
|
Defines the payment attribute submitted by default upon entry of a payment for this transaction. |
|
The Inter-banking code is a coding used by all banks to indicate the bank operation type on the lines of the bank statements that are sent to their customers. |
|
Specify here the exchange rate type to be used to perform the currency conversions which are being entered or whose payments are being posted. |
|
If this check box is selected for an invoice in a currency different from the company currency, the exchange rate applied between the open item currency for the closing of the BP account (closed during the first posting step) is the same as the rate on the invoice. There is no exchange rate variance journal reported in the company currency. If this check box is not selected, the exchange rate applied between the open item currency and the company currency for the closing of the BP account is the exchange rate on the posting date. For an exchange rate variance, an exchange rate variance journal in company currency is generated. Note: This check box is also relevant for the reporting currency for which an exchange rate variance journal in the reporting currency can be generated, or not, depending on whether it is selected or not. This exchange rate is applicable to the Bank or BP payment type attributes and uniquely for the cases where one (or more) invoice is posted. For other payment attributes or non-posted Bank or BP payment attributes, the retained exchange rate is fixed with respect to the exchange rate type previously specified. At the same time as the application of this original invoice exchange rate, several rates can co-exist. In this case, the accounting journal displays a blank exchange rate and suggests an exchange rate as an inlay on the screen. |
|
If this flag is checked:
|
|
|
This flag is displayed only when the KSP activity code is activated. |
|
This field requires the KSW – Swiss localization activity code to be active. Use this field to select the generated file type:
|
|
  |
|
  |
Grid Payment method
|
  |
|
This grid is used to specify the payment modes that will be considered for the automatic payment proposal (refer to documentation on the Automatic payment proposal). |
Close
Presentation
It is possible to add data in entry mode (up to 30 fields). These fields must be defined in the PAY2 screen; once created, they can be used optionally in the transaction screens according to the response data existing in this grid.
These fields can be linked to the activity code KSW - Switzerland, for instance.
The economic reason code is used by the Banque de France when determining the Balance of payments.
It is necessary for all operation that fits into the following operations contexts:
The resident or non-resident status is defined at the BPlevel.
The declaration thresholds are determined by the parameter values AMTVIR1, AMTVIR2 and AMTVIR3 in the chapter BP / Default values.
The entry of this code and its mandatory nature are determined at the level of the payment entry transaction setup.
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 setup).
If it is not the case, the value that will be suggested is the value defined at the BP level (BP record setup). This code can be modified.
This value is retrieved in the bank files (AFB160, AFB320, SEPA Credit Transfer).
Functioning of the Economic reason code
If the company is the direct declaring company, the Economic reason code '060' must be entered in the Accountingtab of the Company record.
This code is automatically applied to any payment destined for non resident BPs that is generated from this company. This field is not filled in the case of operations with residents.
If the company is not the direct declaring company, the economic reason code must be entered for each non-resident BP.
According to the declaration thresholds, this code is taken into account:
If no value has been entered in the BPrecord, a code can be selected directly in payment entry.
The entry is mandatory if the setup of thepayment entrytransaction determines it.
Close
Fields
The following fields are present on this tab :
Fields
|
No help linked to this field. |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
This field is displayed automatically on payment entry. It corresponds to the company which is linked to the site specified in the payment header. |
|
It is possible to enter an internal reference for the payment document. |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
The user can enter a description for information. This description will be taken by default in the line texts at payment entry (if the "line text" field has been selected). |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
This field is linked to Miscellaneous Table 3. |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
Click this check box if the Bank ID number field is to be displayed in the payment entry transaction.
The Bank ID number is typically initialized from the payment address code. If the payment entry transaction is for a direct debit however, the Bank ID number is obtained by default from the mandate entered in the header payment (see the How to...manage SEPA mandates in AR processes in Sage X3 document in the 'How to', 'Financials' area of the Sage X3 Online help center). |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
Field to specify the bank name. The paying bank is initialized from the payment address code. |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
  |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
Fields
|
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
Defines or not the presence of the "bank amount" field. This field |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
|
Specifies the number of columns that will be frozen on the left |
Tabs
|
Condition the management of the entry lots (Entry lot tab and header fields) in the payment entry. |
|
If parameter PROBALCTL - Progressive balance control (chapter TRS - group PAY) is set to ‘Yes’, the balance control field is displayed. It is enabled if box "Entry batch" is activated.
|
Grid Extra fields
|
  |
|
This grid is comprised of optional fields that may have been added |
|
This checkbox is used to make mandatory the corresponding field upon payment entry |
|
This checkbox is used to make the corresponding field mandatory upon payment entry |
Close
Presentation
The steps tab is used to define the account posting steps belonging to the payment transaction. The order of the steps cannot be changed. If, for a payment transaction, all the account posting steps are selected, each process must be completed before moving to the next step.
This is the last possible accounting step for payments before deposit in the bank, an entry can be passed to an intermediate deposit account on collection or for discount for example.
This step is only accessible for payments placed on a remittance note.
It is possible to associate the intermediate deposit step with a group of automatic journals (see the Automatic journal groups) : Following either the first posting step or the second, the journal group proposed as standard can be respectively STEP1 or STEPN.
The accounting journal for the intermediate deposit is specified. It is possible to generate different accounting structures depending on whether the payment will be deposited on collection or with discount. The choice of journal, follows the setup, can be determinant for the search of the intermediate account. The selected journal type is linked to the Bank definition.
A process is used to carry out a mass intermediate deposit of payment remittances. See the documentation on intermediate deposit transfers for further information.
This penultimate step is mandatory for all payment transactions. It is makes the payment bank posting possible.
It is possible to associate the bank posting with a group of automatic journals (see the Automatic journal groups). Following either the first posting step or the second/third, the journal group proposed as standard can be respectively STEP1 or STEPN.
The "Group if payment" and "Group if discount" fields are accessible when the transaction contains a advice note entry or paying bank advice note entry step.
The group code is used to define by discount type, if an accounting document is generated.
The grouping of the remittance by due date is only possible when the "remittance" flag is activated.
If the print code attached to the process code is "CHE" or "CHR" (miscellaneous table no. 304), there is no access to the "group if discount" field.
The accounting journal for the bank posting is specified. The choice of journal, according to the setup, can be determinant in the search of the bank account. The selected journal type is linked to the Bank definition.
A specific process is used to carryout the deposit in the bank of the payments (see the Deposit in bank). It is also possible to deposit a payment in a bank from the deposit entry or the paying bank entry (following the set up stages) which also allow the validation of this step for a single payment/remittance/advice note.
This last step is used to manage the posting of drafts in compliance with Spanish or Portuguese legislations. Apart from legislations, this last step is used to generate an extra posting using the draft devaluation function.
The document group to be used requires setup.
The accounting journal for the intermediate deposit is specified. It is possible to generate different accounting structures depending on whether the payment will be deposited on collection or with discount. The choice of journal, according to the setup, can be determinant for the search of the account(s). The selected journal type is linked to the Bank definition.
Close
Fields
The following fields are present on this tab :
Processing
|
Specifies if the payment mode must be taken into account by the |
Printing
|
This code enables the reports to identify which payment types |
|
Specifies if the print associated with the code above is a |
Block number 2
|
Specifies if an automatic bank assignment phase is |
|
Specifies whether an approval stage is necessary before the first |
Intermediate posting
|
Specify if the deposit slip must be subjected to an intermediate posting before being posted to the bank (for instance, used for drafts received upon deposit for cash receipt or discount). |
|
  |
|
  |
|
  |
Notes P/R posting
|
Specify if a draft management phase is necessary for this payment transaction. Draft management consists in individually validating payments on an account different from the bank account. |
|
Specifies if a "Draft management" field on the BP record must show movements |
|
  |
|
  |
Bank posting
|
  |
|
  |
|
|
  |
|
  |
Deposits/Remittances
|
Specifies if payments need to be regrouped onto deposit notes before bank posting. |
|
Specifies if payments must be regrouped as paying bank notes before bank posting (case of the issued drafts). |
|
Specifies if an electronic transmission of the deposit slip is possible wiith the bank (transfers, LOC, etc.). For paying banks, used to trace imported and exported files in payment and paying bank note monitoring. |
|
For France is it the ETEBAC file. Specify the name of the file to be generated, if the transaction only generates this type of file. Otherwise leave the field blank for the file to be selected at the electronic deposit stage. |
|
  |
|
This box -when checked- is used to generate bank files with the SEPA format for the current payment entry transaction. |
|
This field is used to select the 'pivot' text file from Sage X3 sent to Sage Connect for conversion into .xml. |
|
The nature of the payment identifies the bank file formats that can be generated by the payment transaction. According to the bank establishment or the national/international character of the payment, the file format is different. The nature of the payment is used to associate a payment transaction, a group of possible of bank files. This field is mandatory if the transaction generates a bank file. |
Notes P/R risk closing
|
  |
|
  |
Close
Fields
The following fields are present on this tab :
Export
|
Used to mention the generating fact for taking into account the payments of a transaction in the payment export file, towards the cash management software (see documentation Payment export to Sage cash management).
|
|
This field points to the miscellaneous table 325 and it represents a grouping/splitting criterion for the payments upon generation of the payment export file(s). |
Grid Equivalence
|
Code of the field of the payment export file whose content can be set up.
|
|
The parameterization formula can be entered with the help of the formula assistant. By default, the various accessible tables are proposed:
As well as the main screens:
|
Close
The export file of the open items has a fixed length (see the documentation Export of the Sage cash management payment schedule).
Therefore, the content of a field can be truncated if, because of the setup, it contains too many characters with respect to its maximum length in the cash management software.
The setup of some fields must also take the following constraints into account:
If the setup is not specified for all or part of the treasury file, the following default values are applied, irrespective of the transaction and the bank:
Should these default values not be suitable, the setup of some fields must take into account the following constraints :
These fields do not point to value tables, at Sage 1000 Cash Management module level.
If the setup is not specified for all or part of the treasury file, the following default values are applied, irrespective of the transaction and the bank:
Should these default values not be suitable, the setup of some fields must take into account the following constraints :
These fields do not point to value tables, at Sage FRP Treasury module level.
If the setup is not specified for all or part of the treasury file, the following default values are applied, irrespective of the transaction and the bank:
This button is used to confirm the entry screen setup. |
This button is used to copy the setup of the transaction to another folder. |
In addition to the generic error messages, the following messages can appear during the entry :
This message appears when the control checking the coherence between the entry transaction sign and the selected payment method fails.