Use this function to define payment transaction characteristics and payment methods used by the company:

  • General characteristics: sign (receipt or expense), payment method (transfer, check, etc.)
  • Entry screens: displayed fields, required fields
  • Posting stages and grouping methods: bank posting, bank receipt posting, splitting bank files, etc.

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management


Header

Tab General

Tab Entry

Additional fields

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.

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

SEEINFO The resident or non-resident status is defined at theBP level.
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).
SEEINFO 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.
SEEINFO 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:

SEEINFO If no value has been entered in the BPrecord, a code can be selected directly in payment entry.
SEEWARNING The entry is mandatory if the setup of thepayment entry

 

Tab Steps

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 mulit-currency in general by requires separate files per currency.

This option is not available when EDI files are created.

Intermediate posting

This is the last possible 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 STEP1 or STEP N.

You can specify the accounting journal used for the 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.
SEEREFERTTO See the documentation on Intermediate posting for more information.

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 STEP1 or STEPN.

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 check box is activated.
If the print code attached to the process code is "CHE" or "CHR" (miscellaneous table no. 304), 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 check box and make sure that the Remittances and Bank file check boxes 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

This last step is used to manage the posting of notes payable/receivable in particular for the Spanish or Portuguese legislations. Regardless of the legislation, this last step is used to generate an extra posting step from the Notes P/R risk closing function.

The journal entry group must be defined.

You need to 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.

Tab Cash Management

Fixed field length

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.

Concerning the interface to the Sage Concept Cash Management module:

  • for the Nature code (CPTA) = 16 characters max
  • for the Annex code (CDC) = 16 characters max
  • for the Comment (DESCR) = 32 characters max
  • for the Reference code (CODRIF) = 8 characters max
  • for the Check number (NASS) = 8 characters max

 SEEWARNING The setup of some fields must also take the following constraintsinto account:

  • the Nature (CPTA) and Annex (CDC) fields
    At the level of the cash management software, these fields point to a value table; it is thus recommended to load them in the same way for the export of the open items.
  • the Check number field (NASS)
    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 instance, 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, irrespective of the transaction and the bank:

  • for the Operation Date (DOPE) =
    • if the generating fact = deposit to the bank
      • DOPE = accounting date
    • if the generating fact < deposit to the bank
      • DOPE = due date if due date > accounting date
      • DOPE = accounting date if due date < accounting date
  • for the Check number (NASS) =
    • if the payment transaction contains the "Check number" field (CHQNUM of PAYMENTH), its content is automatically recovered.
    • to neutralize it, another content should be set up (including "" for the field to be transmitted empty).

Should these default values not be suitable, the setup of some fields must take into account the following constraints :

  • the Nature (CPTA) and Annex (CDC) fields
    At the level of the cash management software, these fields point to a value table; it is thus recommended to load them in the same way for the payment export.
  • The field Operation Date (DOPE)
    This field has a date format DDMMYYYY.
  • The field Check number (NASS)
    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, i.e. to retrieve additional information (for instance if CODRIF and DESCR are not sufficient).

Fixed field length

  • for the Transfer code (TRANS) = 128 characters max
  • for the Description code (DESCR) = 128 characters max

 SEEINFO These fields do not point to value tables, at Sage 1000 Cash Management module level.

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, irrespective of the transaction and the bank:

  • for the Operation Date (DOPE) =
    • if the generating fact = deposit to the bank
      • DOPE = accounting date
    • if the generating fact < deposit to the bank
      • DOPE = due date if due date > accounting date
      • DOPE = accounting date if due date < accounting date
  • for the Reference (REF) =
    • if the payment transaction contains the "Check number" field (CHQNUM of PAYMENTH), its content is automatically recovered.
    • to neutralize it, another content should be set up (including "" for the field to be transmitted empty).

Should these default values not be suitable, the setup of some fields must take into account the following constraints :

  • the Transfer zone (TRANS)
    It is used to know whether or not it is an international transfer and the content of this field is Yes or No. The values sent are free provided that they are only 2 distinct ones (Sage 1000 Cash Management then uses a transcoding table)
  • the Budget code (BUDG) field
    At the level of the cash management software, this fields point to a value table; it is thus recommended to load it in the same way for the payment export.
  • The field Operation Date (DOPE)
    This field has a date format DDMMYYYY.
  • The field Reference (REF)
    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, i.e. to retrieve additional information (for instance if CODRIF and DESCR are not sufficient).
  • The LOC type (LOC) field
    The expected values are Collection/Discount/None, or any other value, provided there are only three of them. Then the transcoding is carried out at the level of the Sage 1000 Cash Management module.

Concerning the interface to Sage FRP Treasury

  • for the Description code (DESCR) = 32 characters max,
  • for the Reference code (REFXRT) = 16 characters max.

 SEEINFO These fields do not point to value tables, at Sage FRP Treasury module level.

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, irrespective of the transaction and the bank:

  •  for the Operation Date (DOPE) =
    • if the generating fact = deposit to the bank
      •  DOPE = accounting date
    • if the generating fact < deposit to the bank 
      • DOPE = due date if due date > accounting date 
      • DOPE = accounting date if due date < accounting date

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.
 

Tables used

SEEREFERTTO Refer to documentation Implementation