Payment entry transactions
Use this function to define payment transaction characteristics and payment methods used by the company such as receipt or expense, payment method, banking information, and displayed and required fields for the transaction.
Screen management
Header
General tab
Criteria block
| Active (ENAFLG) |
| When this checkbox is selected, you can use the payment transaction method. |
| Access code (ACS) |
|
This access code is used to restrict access to data by a user or group of users. Only users with this access code in their profile can use this transaction. If several transactions are available, you can choose the transaction you want to use to open the function. If only one transaction is available, the default entry screen opens. |
| Sign (SNS) |
|
Select the payment sign. If you select Expense or Revenue, this field does not display in the payment header screen in the payment entry. The payment transaction is always an expense, issued check for example, or always a receipt, check receipt for example. If you select Unspecified, you make the selection in the payment header as Expense or Revenue. This allows you to create only one payment transaction used for both receipt and expenses as in a cash entry for example. Requiring payment authorization only applies to expenses or unspecified types, and when the Remittances and Bank file checkboxes are selected. Use the PAYAPP - Payment authorization parameter (TRS chapter, AUZ group) to grant users the ability to approve payments. |
| Bank or cash (BANCSH) |
|
Select Bank for a bank register and Cash for a cash register. You can then select the appropriate Sign: Revenue or Expense. |
| Default payment attribute (DENDEF) |
|
Defines the payment attribute submitted by default upon entry of a payment for this transaction. This payment attribute is usually set up with Payment sense for the accounting sense. |
| Interbank code (CIB) |
|
The Interbanking code is used by all banks to indicate the bank operation type on the lines of the bank statements that are sent to their customers. This code refers to the miscellaneous table 306. The accounting journals also have an interbank code. It is used to facilitate sorting and selecting and to control the bank reconciliation between the postings in a bank account with the lines in the bank statements. This code can be transmitted to the posting documents via the automatic payment journals. |
| Rate type (RATTYP) |
|
Enter the exchange rate type to be used to perform the currency conversions which are being entered or whose payments are being posted. |
| Invoice rate application (RATINV) |
|
Select this checkbox to apply the invoice rate on a payment line if:
If these conditions are met, it implies that the exchange rate applied to convert the invoice or open item from its currency to the company currency (or main general ledger currency) is the same as the rate found in the journal entry of the invoice. This converted amount is then stored in the related payment line when the payment is created or saved. It is used during the first payment posting step and it results in no exchange rate variance journal reported in the company currency (the main general ledger currency) for the related invoice. This amount is also applied to the line on other ledgers of the company when these ledgers are held in the same currency as the main general ledger, thanks to automatic journal entry setup. When one of these conditions is not met:
When posting a payment with several invoices where invoice rate application has been applied, it implies that several rates can co-exist within the same journal entry. In this case, the accounting journal entry displays a blank exchange rate and suggests an exchange rate as an inlay on the screen. Note - informationThe invoice rate is also calculated if the payment attribute of the payment line is defined with an account structure equal to Bank<=>BP or Account<=>BP and if the payment line is allocated to a document with a journal entry number.
Note - warningIf the Main ledger currency rate field on the Entry tab is selected, this field is disabled.
|
| Due date management (DUDFLG) |
|
If you select this checkbox:
|
| Cash payment (SPACSH) |
|
This field only displays when the KSP - Spanish localization activity code is activated. It means that all payments made by this transaction must be considered as cash payments. |
| Swiss payment type (SWIPAYTYP) |
|
This field requires the KSW – Swiss localization activity code to be active. Use this field to select the generated file type:
Note - tipRefer to the Swiss legislation guide for more details regarding the payment and ISR setup.
|
Payment method grid
| Payment method (PAM) |
|
This grid is used to specify the payment modes that will be considered for the Automatic payment proposal. Only the open items with a payment method linked to one in the grid are likely to be paid automatically. |
Entry tab
It is possible to add data in entry mode up to 30 fields and, for most fields, you can decide if the data is mandatory by selecting the associated checkbox. These fields must be defined in the PAY2 screen. 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 like KSW - Switzerland, for example.
Economic reason
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:
- Transactions in euro to a bank within the European Union, including France, for non-resident 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 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 is suggested in the Company record setup.
If it is not the case, the value that is suggested is the value defined at the BP level (BP record setup).
This value is retrieved in the bank files (AFB160, AFB320, SEPA Credit Transfer).
If the company is the direct declaring company: The Economic reason code 060 must be entered on the Accounting tab in the Company record.
This code is automatically applied to any payment destined for non-resident BPs that is generated from this company.
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 in the payment entry and can be modified.
The declaration thresholds are defined by the AMTVIR1 - Threshold 1 payment balance and the AMTVIR2 - Threshold 2 payment balance parameters values (PAY chapter, RGL group) in automatic proposals according to the declaration thresholds.
If no value has been entered in the BP record, a code can be selected directly in the payment entry.
Fields block
| Bank (DACBAN) |
|
No help linked to this field. |
| Mandatory (BANOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Company (DACCPY) |
|
This field is displayed automatically on the payment entry. It corresponds to the company which is linked to the site specified in the payment header. |
| Reference (DACREF) |
|
You can enter an internal reference for the payment document. |
| Mandatory (REFOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Remittance reference (DACFRMREF) |
| Mandatory (FRMREFOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Discount type (DACFRMTYP) |
| Header description (DACDES) |
|
You can enter a description for information. This description will be taken by default in the line texts at the payment entry, if the line text field has been selected. |
| Mandatory (DESOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Line description (DACDESLIN) |
| Mandatory (DESLINOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Payment method (DACPAM) |
|
This field is linked to the TABPAM table. |
| Source date (DACORIDAT) |
| Mandatory (ORIDATOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Due date (DACDUDDAT) |
| Mandatory (DUDDATOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Value date (DACVALDAT) |
| Mandatory (VALDATOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Date created (field DACBILDAT) |
| Mandatory (field BILDATOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Bank account number (DACBID) |
|
Select this checkbox if the Bank ID number field is to be displayed in the payment entry transaction. Note - informationThis field is mandatory if this payment type is used with electronic payments. You need to select the checkbox and the associated Mandatory checkbox. Electronic transmission payments either have the Bank file checkbox or SEPA generation on the Steps tab selected.
The Bank ID number usually defaults from the payment address code. If the payment entry transaction is for a direct debit, the Bank ID number is obtained by default from the mandate entered in the header payment. Refer to the SEPA - Manage mandates in A/R processes how-to guide. |
| Mandatory (BIDOBL) |
|
Select this checkbox to make the corresponding field mandatory on payment entry. |
| Paying bank 1 (DACPAB1) |
|
Select this field to specify the bank name. The paying bank is initialized from the payment address code. If the VII - International bank transfer activity code is active, activating these fields is also used to make accessible other paying bank references for the intermediate banks. |
| Mandatory (field PAB1OBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Paying bank 2 (field DACPAB2) |
| Mandatory (PAB2OBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Drawee reference (DACBPRREF) |
| Mandatory (BPRREFOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Payment reason (DACEPARENP) |
| Mandatory (EPARENPAYO) |
| Check type (DACCHQTYP) |
| Check number (DACCHQNUM) |
| Mandatory (CHQNUMOBL) |
|
Select this checkbox to make the corresponding field mandatory on payment entry. |
| Pay-by branch (DACCHQBAN) |
| Mandatory (CHQBANOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Bank card number (DACCRDNUM) |
| Mandatory (CRDNUMOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Credit card authorized (DACCRDAUZ) |
| Mandatory (CRDAUZOBL) |
|
Select this checkbox to make the corresponding field mandatory on payment entry. |
| Purchase type (DACPURTYP) |
| Main ledger currency rate (DACCURRAT) |
|
Select this checkbox to directly enter a currency rate at payment entry. This action overrides the default payment currency in the Currency rates table. This checkbox is disabled if the Invoice rate application checkbox on the General tab is selected. If you select this checkbox, the Invoice rate application field on the General tab is disabled. |
| Mandatory (CURRATOBL) |
|
Select this checkbox to make the entry of a currency rate at the payment entry mandatory. |
| Bank amount (DACAMTBAN) |
|
Defines the presence of the bank amount field. This field features the payment amount expressed in the bank account currency. If this field is not present, the amount will be calculated automatically. |
| Mandatory (AMTBANOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Bank date (DACBANDAT) |
| Mandatory (BANDATOBL) |
|
Select this checkbox to make the corresponding field mandatory upon payment entry. |
| Number of fixed columns (NBRCOL) |
|
Specifies the number of columns that will be frozen on the left when scrolling the posting entry grid. |
Tabs block
| Entry batch (DACPYL) |
|
Conditions the management of the entry lots (Entry lot tab and header fields) in the payment entry. |
| Balance control (LOTPROBALC) |
|
This field displays if the PROBALCTL - Progressive balance control parameter (TRS chapter, PAY group) is set to Yes. It is enabled if the Entry batch checkbox is selected. Use it to define the balance control for the entry batch. Additional fields on the Entry batch tab are added for the balance control of the batch. Activating balance control requires the following settings. On the General tab:
On the Entry tab:
On the Steps tab, Bank posting block:
|
| Payment entry transaction (DACPAYTYP) |
|
This field is available if Bank or Cash is selected for the Bank or Cash field on the General tab for a Polish or South African legislation.
Note - warningBank or Cash register entry types are not available in Payment/Receipt entry (GESPAY).
|
Extra fields grid
Steps tab
The Steps section is used to define the account posting steps specific to the payment transaction. The order of the steps cannot be changed. If all the account posting steps are selected for a payment transaction, each process must be completed before moving to the next step.
Splitting bank files
You can create a payment entry type for bank file splitting using the fields in the Bank file split section. You can then use this entry type to create remittances and start the bank file generation in either Manual remittances (GESFRM) or Electronic remittances (FICMAG). When generating bank files, either one or several are creating depending on the payment data and splitting criteria.
Bank file splitting depends on the bank file format and must be evaluated. For example, splitting by currency can be applied if a specific format supports multi-currency in general but requires separate files per currency.
This option is not available when EDI files are created.
Intermediate posting
This is the last accounting step for payments. Before bank posting, an entry can be posted to an intermediate account on collection or discount for example.
This step is only available for payments included in a remittance.
You can associate the intermediate posting step with a group of automatic journals (see the Automatic journal groups). Following either the first posting step or the second, the journal group suggested by default can be STEP 1 or STEP N.
You can specify the accounting journal used for an intermediate posting. You can also generate accounting structures depending on whether the payment is posted on collection or discount. The journal you select, depending on the setup, will influence the intermediate account definition. The selected journal type is linked to the Bank definition.
You can use a dedicated process to perform a mass intermediate posting of remittance payments.
Bank posting
This step is mandatory for all payment transactions. It is required before you can perform a bank posting.
You can 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 suggested by default can be STEP 1 or STEP N.
The Group if payment and Group if discount fields are available when the transaction includes a step for remittance entry or paying bank advice entry.
The group code is used to define if a journal entry is generated by remittance type:
- By payment (1 payment, 1 journal entry)
- By remittance (1 remittance, 1 journal entry)
- By due date (1 journal entry by due date)
The grouping by remittance or by due date is only possible when the Remittance checkbox is activated.
If the print code attached to the process code is CHE or CHR (TABCODEDT table), the Group if discount field cannot be accessed.
You need to specify the accounting journal for the bank posting. The journal you select, depending on the setup, will influence the bank account definition. The selected journal type is linked to the Bank definition.
You can use a dedicated process to perform the bank posting of payments (see Bank posting). You can also post a payment to a bank from the remittance entry or paying bank notice entry (depending on your set up steps), which also allows you to validate this step for a single payment/remittance/paying bank notice.
Authorization required
You can require approval for payments that are expenses or unspecified. In that case, you can select the Authorization checkbox and make sure that the Remittances and Bank file checkboxes are also selected. Authorized approvers are users who have the PAYAPP - Payment approval parameter (TRS chapter, AUZ group) set to Yes.
Notes P/R risk closing
Use this last step to manage the posting of notes payable/receivable, especially for the Spanish or Portuguese legislations. Regardless of the legislation, you can use this last step to generate an extra posting step from the Notes P/R risk closing function.
The journal entry group must be defined.
You must specify the accounting journal for the intermediate posting. You can generate different accounting structures depending on whether the payment will be posted on collection or discount. The journal you select, depending on the setup, will influence the account(s) definition. The selected journal type is linked to the Bank definition.
Processing
| Auto proposal (PAYPPS) |
|
Specifies if the payment mode must be considered by the automatic payment proposal function. |
Printing
Block number 2
Intermediate posting
Notes P/R posting
Bank posting
| Posting (STA9) |
| Group entry (AUTACE9) |
| Payment grouping (ACETYP91) |
| Discount grouping (ACETYP92) |
| Journal type (JOU9) |
Deposits/Remittances
| Remittances (STA5) |
|
Select this checkbox if payments need to be regrouped onto deposit notes before bank posting. When payment authorization is required, this checkbox must be selected. |
| Paying banks (STA7) |
|
Specifies if payments must be grouped as paying bank notes before bank posting (issued notes payable/receivable). |
| Bank file (STA6) |
|
Select this checkbox if an electronic transmission of the deposit slip is possible with the bank, such as transfers, LOC, and so on. For paying banks, select this checkbox to trace imported and exported files in payments and paying bank notes monitoring. When payment authorization is required, this checkbox must be selected. |
| Electronic medium (FILREF6) |
|
For France it is the ETEBAC file. Specifies 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. |
| EDI (FILREF71) |
| SEPA generation (EPACDTTRF) |
|
This checkbox, when selected, is used to generate bank files with the SEPA format for the current payment entry transaction. Generating such a file is only possible if the option is activated. Note - warningThe SEPA term means SEPA Credit Transfer only.
Note - informationThis checkbox can be accessed if the Bank file checkbox has not been selected.
|
| SEPA file (FILREF8) |
|
Use this field to select the pivot text file sent from Sage X3 to Sage Connect for conversion into XML. |
| Bank file group (NATPAY) |
|
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 or international character of the payment, the file format is different. The nature of the payment is used to associate a payment transaction with a group of possible bank files. This field is required if the transaction generates a bank file. |
Notes P/R risk closing
| Group entry (AUTACE10) |
| Journal type (JOU10) |
Bank file split
Treasury tab
Export block
| Triggering event (FLGCAS) |
|
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 the documentation on Payment export to Sage cash management). The possible values are (local menu 2673):
In case of accounting cancelation, the cancelation is also transmitted from the moment that it took place after the generating fact. |
| File grouping code (FICCAS) |
|
This field points to the miscellaneous table 325 and represents a grouping or splitting criterion for the payments upon generation of the payment export file or files. For example, when two transactions have the same grouping file code, the payments considered by the export are regrouped in a same file. Its code will contain the grouping code as the first component of its name. |
Equivalence grid
| Zone code (CODCAS) |
|
Code of the field of the payment export file whose content can be set up. This code helps identify the field in the cash management software:
Note - warningYou need to enter this code in uppercase letters.
|
| Formulas (field CLCFOR) |
|
This formula can be entered with the help of the formula assistant. By default, various accessible tables are proposed:
And the main screens:
|
Fixed field length
The export file of the open items has a fixed length.
Because of that, 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.
Concerning the interface to the Sage Concept Cash Management module
- The Nature code field can contain 16 characters max.
- The Annex code field can contain 16 characters max.
- The Comment field can contain 32 characters max.
- The Reference code field can contain 8 characters max.
- The Check number field can contain 8 characters max.
The setup of some fields must consider the following constraints:
- The Nature and Annex fields
At the level of the cash management software, these fields point to a value table; it is recommended to load them in the same way for the export of the open items. - The Check number field
This field should not be used to recover a check number which does not exist at this stage in the life cycle of the open items, but rather to recover additional information, if, for example, CODRIF and DESCR are not sufficient.
Default values and entered values
If the setup is not specified for all or part of the treasury file, the following default values are applied regardless of the transaction and the bank:
The Operation date field:
- Is equal to the accounting date if the generating action is the deposit to the bank.
- Is equal to the due date if due date is after accounting date.
- Is equal to the accounting date if due date is before the accounting date.
The Check number field:
- Displays a default value if the payment transaction contains the Check number field from the Payment header table (PAYMENTH).
- To prevent this, another setting is needed, including for the field to be transmitted empty.
If these default values are not be suitable, the setup of some fields must consider the following constraints:
- The Nature and Annex fields
At the level of the cash management software, these fields point to a value table. It is recommended to load them in the same way as for the payment export. - The Operation datefield
This field has a date format corresponding to DDMMYYYY. - The Check number field
The purpose of this field is to retrieve a check number, but it can also be used for an entirely different purpose on some transactions, such as retrieving additional information. For example, if CODRIF and DESCR are not sufficient.
Fixed field length
- The Transfer code field can contain 128 characters max.
- The Description code field can contain 128 characters max.
Default values and entered values
If the setup is not specified for all or part of the treasury file, the following default values are applied regardless of the transaction and the bank.
The Operation date field:
- Is equal to the accounting date if the generating action is the deposit to the bank.
- Is equal to the due date if due date is after accounting date.
- Is equal to the accounting date if due date is before the accounting date.
The Reference field:
- Displays a default value if the payment transaction contains the Check number field from the Payment header table (PAYMENTH).
- To prevent this, another setting is needed, including for the field to be transmitted empty.
If these default values are not be suitable, the setup of some fields must consider the following constraints:
- The Transfer zone field
It is used to define if it is an international transfer or not. The values sent are provided that they are only 2 distinct values. Sage 1000 Cash Management then uses a transcoding table. - The Budget code field
At the level of the cash management software, this fields point to a value table. It is recommended to load it in the same way for the payment export. - The Operation date field
This field has a date format corresponding to DDMMYYYY. - The Reference field
The purpose of this field is to retrieve a check number, but it can also be used for an entirely different purpose on some transactions, such as retrieving additional information. For example, if CODRIF and DESCR are not sufficient. - The LOC type field
The expected values are Collection/Discount/None, or any other value, provided there are only 3. The transcoding is carried out at the level of the Sage 1000 Cash Management module.
Concerning the interface to Sage FRP Treasury
- The Description code field can contain 32 characters max.
- The Reference code field can contain 16 characters max.
Menu Bar
|
Validation |
This button is used to confirm the entry screen setup. |
|
Copy |
This button is used to copy the setup of the transaction to another folder. |
Error messages
In addition to the generic error messages, the following messages can appear during the entry:
SEPA type transaction: inconsistency between payment sign and associated payment methods ($1$)
This message appears when the control checking the coherence between the entry transaction sign and the selected payment method fails.