Setup > A/P-A/R accounting > Payment entry transactions 

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

Fields

The following fields are present on this tab :

Single code identifying the payment transaction.

  • Description (field DESTRA)

Common title of the current record.

  • Short description (field SHOTRA)

 

 

Close

 

Tab General

Fields

The following fields are present on this tab :

Criteria

  • Active (field ENAFLG)

This access code is used to restrict access to data by user or group of users.
If this field is entered, 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, there is no selection to be made: the default entry screen opens directly.

  • Sign (field SNS)

Select the payment sign.

If you select Expense or Revenue, this field does not display 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 you select Unspecified, you make the selection in the payment header as Expense or Revenue. This makes it possible to create only one payment transaction used for both receipt and expenses as in cash entry for example.

Requiring payment authorization only applies to expenses or unspecified types and when the Remittances and Bank file check boxes are selected. Use the PAYAPP - Payment authorization parameter to grant users the ability to approve payments.

 

Block number 2

  • Bank or cash (field BANCSH)

Select Bank for a Bank register and Cash for a Cash register.

You can then select the appropriate Sign: Revenue or Expense.

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.

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.
In X3, this code refers to miscellaneous table 306.
The accounting journals also have an inter-bank code. It is use to facilitate (sort, selection) and to control the bank reconciliation (RAPBAN function) between the postings in a bank account with the lines in the bank statements.
The code entered here can be transmitted to the posting documents for the payments via the automatic payment journals.

  • Rate type (field RATTYP)

Specify here 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 (field RATINV)

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 the Main ledger currency rate check box on the Entry tab is selected, this field is disabled.
  • Due date management (field DUDFLG)

If this flag is checked:

  • the grouping code is forced to "payment" or "due date" according to the posting stages.
  • the automatic propositions generated are grouped by due date item (a open item per payment or a due date by payment).
  • the accounting date retained for the bank posting entry of the payment is equal to the payment due date when this is entered upon receipt. When using a remittance advice note, it is possible to confirm the choice made at cash receipt or otherwise to modify this in order that it is a receipt with discount ; in this latter case, the accounting date can be entered.
  • Endorsement (field FLGEND)
  • Cash payment (field SPACSH)

This flag is displayed only when the KSP activity code is activated.
It indicates that all payments made by this transaction have to be considered as Cash Payment.

  • Swiss payment type (field SWIPAYTYP)

This field requires the KSW – Swiss localization activity code to be active.

Use this field to select the generated file type:

Normal: No specific file type. Use this setting if no payment file will be created.

EZAG: Payment files are created in the EZAG format (specific format of the Swiss Postfinance).

DAT: Payment files are created in the DTA format (specific format of the Swiss banks/Swiss interbank clearing SIC).

ISO: Payment files are created in the ISO 20022 format.

Refer to the Swiss legislation guide on the How to tab for more details regarding payment and ISR setup.

  • Business partner (field BPRTYP)

 

  • Cash VAT (field CSHVATRGM)

 

Grid Payment method

  • No. (field NUMLIG)

 

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).
In effect, only the open items with a payment mode corresponding to one of those that have been entered will be likely to be paid automatically.

Close

 

Tab Entry

Presentation

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 theBPlevel.
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 theBPrecord, a code can be selected directly inpayment entry.
SEEWARNINGThe entry is mandatory if the setup of thepayment entrytransaction determines it.

 

 

Fields

The following fields are present on this tab :

Fields

  • Bank (field DACBAN)

No help linked to this field.

  • Mandatory (field BANOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Company (field DACCPY)

This field is displayed automatically on payment entry. It corresponds to the company which is linked to the site specified in the payment header.

  • Reference (field DACREF)

It is possible to enter an internal reference for the payment document.

  • Mandatory (field REFOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Remittance reference (field DACFRMREF)
  • Mandatory (field FRMREFOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Discount type (field DACFRMTYP)
  • Header description (field DACDES)

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

  • Mandatory (field DESOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Line description (field DACDESLIN)
  • Mandatory (field DESLINOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Payment method (field DACPAM)

This field is linked to Miscellaneous Table 3.

  • Source date (field DACORIDAT)
  • Mandatory (field ORIDATOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Due date (field DACDUDDAT)
  • Mandatory (field DUDDATOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Value date (field DACVALDAT)
  • Mandatory (field VALDATOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Date created (field DACBILDAT)
  • Mandatory (field BILDATOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Bank account number (field DACBID)

Click this check box if the Bank ID number field is to be displayed in the payment entry transaction.

 This field is mandatory if this payment type is used with electronic payments. You must click both this check box and the associated Mandatory check box. Electronic transmission payments have either the check box Bank file or SEPA generation in the Steps tab selected.

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

  • Mandatory (field BIDOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Paying bank 1 (field DACPAB1)

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)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Paying bank 2 (field DACPAB2)

 

  • Mandatory (field PAB2OBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Drawee reference (field DACBPRREF)
  • Mandatory (field BPRREFOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Payment reason (field DACEPARENP)

 

  • Mandatory (field EPARENPAYO)

 

Block number 2

  • Check type (field DACCHQTYP)
  • Check number (field DACCHQNUM)
  • Mandatory (field CHQNUMOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Pay-by branch (field DACCHQBAN)
  • Mandatory (field CHQBANOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Bank card number (field DACCRDNUM)
  • Mandatory (field CRDNUMOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Credit card authorized (field DACCRDAUZ)
  • Mandatory (field CRDAUZOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Purchase type (field DACPURTYP)
  • Main ledger currency rate (field DACCURRAT)

Select this check box to directly enter a currency rate at payment entry. This action overrides the default payment currency in the Currency rates table.

This check box is disabled if the Invoice rate application check box on the General tab is selected.

If you select this check box, the Invoice rate application field on the General tab is disabled.

  • Mandatory (field CURRATOBL)

Select this check box to make entering a currency rate at payment entry mandatory.

  • Bank amount (field DACAMTBAN)

Defines or not 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 (field AMTBANOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Bank date (field DACBANDAT)
  • Mandatory (field BANDATOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

  • Number of fixed columns (field NBRCOL)

Specifies the number of columns that will be frozen on the left
when scrolling the posting entry grid.

Tabs

  • Entry batch (field DACPYL)

Condition the management of the entry lots (Entry lot tab and header fields) in the payment entry.

  • Balance control (field LOTPROBALC)

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.
It is used to define the balance control for the Entry batch. Additional fields in tab "Entry batch” tab are added for the balance control of the batch.
The activation of the balance control has an impact on:

  • "Bank or Cash": Bank must be activated in tab "General".
  • "Sign" must be "Unspecified" in tab "General".
  • Field "Bank" must be "Mandatory" in tab "Input".
  • Step "Bank Posting" must be activated. No other steps should be selected in tab "Steps".
  • Payment entry transaction (field 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.

For Bank: Select N/A or Bank register. If you select N/A, the payment can only be created through Payment/Receipt entry (GESPAY). To create payment from the Bank register (GESBCREG), select Bank register.

For Cash: Select N/A or Cash register. If you select N/A, the payment can only be created through Payment/Receipt entry (GESPAY). To create payment from the Cash register (GESBCREG), select Bank register.

Bank or Cash register entry types are not available in Payment/Receipt entry (GESPAY).

Grid Extra fields

  • No. (field NUMLIG)

 

  • Input (field DACSUP)

This grid is comprised of optional fields that may have been added
upon installation. It is used to activate or not these fields in the
payment entry screen
.

  • Description (field LIBSUP)

This checkbox is used to make mandatory the corresponding field upon payment entry

  • Mandatory (field SUPOBL)

This checkbox is used to make the corresponding field mandatory upon payment entry
.

 

Tab Steps

Presentation

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.

Close

 

Fields

The following fields are present on this tab :

Processing

  • Auto proposal (field PAYPPS)

Specifies if the payment mode must be taken into account by the
automatic payment proposal function
.

Printing

Enter the report code to identify which payment types to include. This code is used for the printing reports relating to checks, drafts, and remittances.

For bank or cash register entry types, use the following codes:

PLKP for cash in

PLKW for cash out

  • Mandatory printing (field EDTFLG)

Specifies if the print associated with the code above is a
compulsory step before payment or
note validation.

Block number 2

  • Bank allocation (field STA4)

Specifies if an automatic bank assignment phase is
possible for this type of payment. In the event of this phase not being retained,
the bank will have to be entered manually for each payment.

  • Acceptance return (field STA2)

Specifies whether an approval stage is necessary before the first
payment validation. This approval consists in manually assigning a flag
specifying that the validation is possible.

  • Authorization (field PAYAPP)

Select this check box if authorization is required for payments.

Note: Authorization only applies to expenses or unspecified entry types and if the Remittance and Bank file check boxes are selected.

Intermediate posting

  • Posting (field STA8)

Specify if the remittance must be subjected to an intermediate posting before being posted to the bank (for instance, for posting notes payable/receivable on collection or discount).

 

  • Cash journal type (field JOU8)

 

  • Discount journal type (field JOU82)

 

Notes P/R posting

  • Posting (field STA3)

Specify if notes payable/receivable posting phase is required for this payment transaction. The notes payable/receivable posting consists in individually validating payments on an account different from the bank account.

  • Portfolio update (field UPDBIL)

Use this field to indicate if the payment type is linked to a Notes P/R field on the BP record.

The Notes P/R fields (1, 2, etc.) correspond to a group or "portfolio" of customer notes payable/receivable that are not due.

These notes can then be subject to a risk closing phase in a dedicated function.

 

  • Journal type (field JOU3)

 

Bank posting

  • Posting (field STA9)

 

 

  • Payment grouping (field ACETYP91)
  • Discount grouping (field ACETYP92)

 

  • Journal type (field JOU9)

 

Deposits/Remittances

  • Remittances (field STA5)

Select this check box if payments need to be regrouped onto deposit notes before bank posting.

When payment authorization is required, this check box must be selected.

  • Paying banks (field STA7)

Specify if payments must be grouped as paying bank notes before bank posting (issued notes payable/receivable).

  • Bank file (field STA6)

Select this check box if an electronic transmission of the deposit slip is possible with the bank (transfers, LOC, etc.).

For paying banks, select this check box to trace imported and exported files in payments and paying bank notes monitoring.

When payment authorization is required, this check box must be selected.

  • Electronic medium (field FILREF6)

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.

  • EDI (field FILREF71)

 

  • SEPA generation (field EPACDTTRF)

This box -when checked- 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.
SEEWARNING The SEPA term means SEPA Credit Transfer only.
SEEINFO This checkbox can be accessed if the box ‘Bank file’ has not been activated.

  • SEPA file (field FILREF8)

This field is used to select the 'pivot' text file from Sage X3 sent to Sage Connect for conversion into .xml.

  • Bank file group (field 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/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

 

  • Journal type (field JOU10)

 

Bank file split

  • Payment method (field GRPPAM)

Select this check box as a criteria to split bank files from one remittance group by payment method.

File splitting depends on the bank file format and must be evaluated for each type.

This is option is not available when EDI files are created.

  • Currency (field GRPCUR)

Select this check box as a criteria to split bank files from one remittance group by currency.

File splitting depends on the bank file format and must be evaluated for each type. For example, splitting by currency can be applied if a specific format supports multi-currency in general but requires separate files per currency.

  • Due date (field GRPDUD)

Select this check box as a criteria to split bank files from one remittance group by due date.

File splitting depends on the bank file format and must be evaluated for each type.

Close

 

Tab Cash Management

Fields

The following fields are present on this tab :

Export

  • Triggering event (field 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 documentation Payment export to Sage cash management).
The possible values are (local menu 2673):

  • None: the payments posted to the transaction are in no way taken into account in the export.
  • Draft management posting/Intermediate posting/Bank posting: payments are taken into account for the export whenever the posting phase that has been completed corresponds to the generating fact.
    In case of accounting cancellation, the cancellation is also transmitted from the moment that it took place after the generating fact.

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).
For instance, from the moment that two transactions have the same grouping file code, the payments taken into consideration by the export will be regrouped in a same file whose code will contain the grouping code as the first component of its name.

Grid Equivalence

  • Zone code (field CODCAS)

Code of the field of the payment export file whose content can be set up.
This code corresponds to that identifying the field in the cash management software:

  • local menu 2671, for the interface to the Sage Concept Cash Management software,
  • local menu 2674, for the interface to the Sage 1000 Cash Management software,
  • local menu 2686, for the interface to the Sage FRP Treasury software.

SEEINFO This code MUST be entered in uppercase letters.

  • Formulas (field CLCFOR)

The parameterization formula can be entered with the help of the formula assistant.

By default, the various accessible tables are proposed: 

  • payment tables (PAYMENTH, PAYMENTD),
  • the payment transaction table (TABPAYTYP),
  • the payment slip table (PAYFRM),
  • annex tables (TABCUR, BANK, BPARTNER)

As well as the main screens:

  • the journal entry screens (GACCENT0, GACCENT1, GACCENT2)
  • and the analytical distribution screens (VENTILE and VENTILE2)

Close

 

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

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

 SEEINFOThese 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

Menu Bar

This button is used to confirm the entry screen setup.

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