This function is used to generate a file containing a set of posted payments, to be sent to the Cash Management software.

This file is created by extracting data from a dedicated table loaded as payment posting takes place.

General principle

This table is loaded when the following conditions are met:

  • the payment comes from a transaction for which a triggering event has been set up (notes payable/receivable posting, intermediate posting or bank posting)
    SEEREFERTTO See the documentation on Payment transactions.
  • The posting phase completed for the payment corresponds to this triggering event. The bank to which the payment is posted is linked to a treasury interface code.
    SEEREFERTTO See the documentation on Bank account.

Specific cases:

  • The payments posted without any bank at the phase corresponding to the triggering event are taken into account in the dedicated table, but on an automatically generated fictitious bank.
    (example: the payments of a transaction for which the triggering event is the notes P/R posting, because the bank is not necessarily known at this stage).
  • Bank charges (Bank/account destinations) do not load the dedicated table.
  • Payment accounting deletions load the dedicated table, from the moment that they intervene after the triggering event signalling the taking into account of the payment.

SEEINFO The expected file is a file with a fixed length, without recording separator.
SEEREFERTTO  See the documentation on the Structure of the payment file.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

Generation

Generation type (field SIM)

Used to specify the execution mode of the payment export (local menu 2678).
To be noted:

  • In Actual mode
    • the payment file(s) is generated in the Directory mentioned as the destination
    • the same query number is then automatically assigned to the constituting payments of the various generated files
    • the transaction payments having the same regrouping file code are gathered in the same file called [Regrouping file code]+[Query number]
    • For instance:
      Let us consider the transactions of manually and automatically issued checks. Their regrouping file code is similar and is equal to CHQ.
      Let us consider the transaction of received transfers with a regrouping file code equal to VIR.
      The actual launch of the payment export will lead to the generation of 2 payment files called CHQ00000001 and VIR00000001, with CHQ and VIR using the file codes and 00000001 using the number of the export query.
  • in Simulation mode
    • No file is generated
    • The log file contains a synthesis of the payments likely to be taken into account, the aggregation being carried out at [Company/Bank/Account]+[Support/Transaction type]+[Operation date] level.
  • in regeneration mode
    • This mode is used to regenerate identically one or several payment files that have already been generated in actual mode.
      For that purpose, the query number associated with them upon initial generation in actual mode should be selected.
Query no. (field REQ)

In case of regeneration, the number of the query to be restarted must be selected.
The payments attached to this number are exported again, in the same way as for the initial generation in actual mode (same grouping, same file name, etc.).

Criteria

Group (field GRPCPY)

Enter the company group code to which the payment company must belong for the payments to be exported.
This is indeed a group of companies, legal companies or group of legal companies, and not a a site or a group of sites.

All transactions (field ALLTPY)

Used to select the payments to be taken into account in the export, irrespective of their original transaction or for a given original transaction.
Transaction (field TPY)

Destination

field TYPEXP

No help linked to this field.

Directory (field VOLFIL)
Log file (field TRC)

Used to view the execution trace of the payment export.
The content of the trace is different depending on the generation mode:

  • in Actual mode
    The trace specifies the number of generated files.
    Then, for each of them, the trace further specifies the number of exported lines, then by Company/Bank/Account combination, the total payment amount, in account/bank currency.
  • in Simulation mode
    The log file contains a synthesis of the payments likely to be taken into account, the aggregation being carried out at [Company/Bank/Account]+[Support/Transaction type]+[Operation date] level:

Company/bank/account 

Support/Transaction type

Number of payments

Operation date

Currency amount

Bank cash management interface code
or
fictitious bank code
(FIC+payment company+transaction currency)

Concatenation of the sense (Revenue or Expense)
and code of the payment transaction

Number of payments concerned by the aggregation line

Operation date of the payments

Sum of the payments in bookkeeping currency

 FICAPN..EUR

RCTRA.

0009

18/11/07

1620.50 EUR

 FICAPN..EUR

RCTRA.

0003

25/11/07

420.20 EUR

 ...

...

...

...

...
  • in regeneration mode
    The trace file is similar to the one displayed during the initial generation in actual mode.

Reports

By default, the following reports are associated with this function :

  REQEXPCASPAY : Query/treas. payment list

This can be changed using a different setup.

Structure of the payment file

The generated file has a fixed length, without field separator.

No. 

Field code
Sage Concept Cash Management module 

Field name
Sage Concept Cash Management module

Comments vs Sage X3

Examples

Position 

Length

1

2

3

BANCA

SOCIETA

CONTO

Bank code

Company code

Account code

(a) No bank is mentioned on the payment document.
Automatic creation of the triplet FIC + company code of the payment + ISO code of the payment currency (1)

(b) The bank is mentioned on the payment document. Taking into account of its cash management interface code.

(a) FICAPN..EUR.....



(b) BNPAPNEUR
(= Cash management interface code of the bank on 16 alphanumerical characters)

(a)     (b)

1         1

4

9
.....

(a)     (b)

3        16

5

3
.....

4

CAUSALE

Support code

Concatenation of the direction of the bank entry line and the payment transaction code
([F:DAE]SNS=1 equals Revenue) and
([F:DAE]SNS=-1 equals Expense)

 RCCHQR

17

6

5

IMPORTO

Amount in account currency (2)

Amount of the payment, in bookkeeping currency (2).
Takes into account the aggregation level of the payment entries (3).
Amounts in 13.2 max, without floating decimal.

1234567890123.12

23

16 

6

IMPDIVISA

Amount in operation currency

Amount of the payment, in operation currency (2).
Takes into account the aggregation level of the payment entries (3).
Amounts in 13.2 max, without floating decimal.

1234567890123.12

39

16

7

DIVISA

Operation currency

ISO code of the payment transaction currency

EUR

55

3

8

DOPE

Operation date

Loaded by default by the payment condition:
* generating fact = deposit to the bank
- DOPE = accounting date
* generating fact < deposit to the bank
- DOPE = due date if due date > accounting date
- DOPE = accounting date if due date < accounting date

18112007

58

8

9

DVAL

Value date

Value date of the payment entry

19112007

66

8

10

NUMOPE

Number of operations

Number of payments given the aggregation level (3).

0005

74

4 

11

12

13

14

15

NASS

CPTA

CDC

DESCR

CODRIF

Check number

Nature code

Annex code

Comment

Reference code

The content of these fields is defined by the setup from the Cash Management tab of payment transactions.
Pay attention to the check number: if the payment transaction contains the "Check number" field (CHQNUM of PAYMENTH), its content is automatically recovered.
Pay attention to the nature and annex codes: in the cash management software, these 2 fields point at value tables.

371B78A2

411000....

ASN...

DEL001.. payment

FR

78

86

102

118

150

8

16

16

32

8

 Number of characters/recording

=

158

(1) Attention: foresee the setup of a FIC fictitious bank in the cash management software.

(2) There are two different cases:
- the bank is known, it is mentioned on the payment: the amounts in account currency are expressed in bank currency (CUR of BANK) whereas the amounts in operation currency are expressed in transaction currency (that can be different from the bank currency)
- the bank is unknown, it is not mentioned on the payment: the fictitious bank is in transaction currency and the amounts in bookkeeping currency (IMPORTO) are expressed in this currency (along with the amounts in operation currency IMPDIVISA)

(3) Let us consider a payment transaction with an intermediate posting and a notes payable/receivable posting (e.g.: checks received and to be collected), with as the generating fact the bank deposit and as the grouping level, the slip. Upon bank deposit of N payments/checks, a single entry line is generated on the bank account. This amount is used at cash management interface level (on the other hand, the NUMOPE number of payments concerned is N, not 1).

The contents of the fields are aligned on the left, except for the amounts (IMPORTO et IMPDIVISA) that are aligned on the right.

On the Cash Management Module side, the Log file delivered to work with the export of the Sage X3 payments is the file OPR3.INI.

Structure of the payment file

The generated file has a fixed length, without field separator.

No.

Field name
Sage 1000 Cash Management

Comments vs Sage X3

Examples

Position 

Length

1

2

3

Bank code

Company code

Account code

(a) No bank is mentioned on the payment document.
Automatic creation of the triplet FIC + company code of the payment + ISO code of the payment currency (1)

(b) The bank is mentioned on the payment document. Taking into account of its cash management interface code.

(a) FICAPN..EUR.....

(b) BNPAPNEUR
(= Cash management interface code of the bank on 16 alphanumerical characters)

(a)     (b)

1         1

4

9
.....

(a)     (b)

3        16

5

3
.....

4

 Nature code

Concatenation of the direction of the bank entry line and the payment transaction code
([F:DAE]SNS=1 equals Receipt) and
([F:DAE]SNS=-1 equals Expense)

RCCHQR

17

6

5

Amount in account currency (2)

Amount of the payment, in bookkeeping currency (2).
Takes into account the aggregation level of the payment entries (3).
Amounts in 13.2 max, without floating decimal.

1234567890123.12

23

16

6

Amount in operation currency

Amount of the payment, in operation currency (2).
Takes into account the aggregation level of the payment entries (3).
Amounts in 13.2 max, without floating decimal.

1234567890123.12

39

16

7

Operation currency

ISO code of the payment transaction currency

EUR

55

3

8

Operation date

Loaded by default by the payment condition:
* generating fact = deposit to the bank
- DOPE = accounting date
* generating fact < deposit to the bank
- DOPE = due date if due date > accounting date
- DOPE = accounting date if due date < accounting date

18112007

58

8

9

Value date

Value date of the payment entry

19112007

66

8

10

Number of operations

Number of payments given the aggregation level (3).

0005

74

4

11

12

13

14

15

Transfer

Comment

Reference

LOC statement type

Budget code

The content of these fields is defined by the setup from the Cash Management section of payment transactions.
Pay attention to the reference: if the payment transaction contains the "Check number" field (CHQNUM of PAYMENTH), its content is automatically recovered.
Pay attention to the
budget code: in the cash management software, this field points at a value table.

VII...

DEL001.. payment

371B78A2...

None...

411000...

78

206

334

462

590

128

128

128

128

128

Number of characters/recording

=

718

(1) SEEWARNING Foresee the setup of a FIC fictitious bank in the cash management software.

(2) There are two different cases:
- the bank is known, it is mentioned on the payment: the amounts in account currency are expressed in bank currency (CUR of BANK) whereas the amounts in operation currency are expressed in transaction currency (that can be different from the bank currency)
- the bank is unknown, it is not mentioned on the payment: the fictitious bank is in transaction currency and the amounts in bookkeeping currency are expressed in this currency (along with the amounts in operation currency)

(3) Let us consider a payment transaction with an intermediate posting and a notes payable/receivable posting (e.g.: checks received and to be collected), with as the generating fact the bank deposit and as the grouping level, the slip. Upon bank deposit of N payments/checks, a single entry line is generated on the bank account. This amount is used at cash management interface level (on the other hand, the number of payments concerned is N, not 1).

The contents of the fields are aligned on the left, except for the amounts, that are aligned on the right.

No.

Field name
SFRP Treasury 

Comments

Examples

Position 

Length 

1

Treasury account

Case 1:
No bank is mentioned on the payment document. Automatic creation with FIC+company code+ISO code of the transaction currency. That is eleven characters.

FICAPN...EUR

1
6
9

3
5
3

 

 

Case 2:
The bank is mentioned on the payment document. TRECOD taken into account.

BNP512100APN

1

12

2

Sign

SNS of GACCENTRYD.

E

13

1

3

Flow code

Payment transaction (PAYTYP, five characters of PAYMENTH).

FVIRN

14

5

4

Account currency amount

Expressed in absolute values and round to two decimals.

1234567890123.45

19

16

5

Operation currency amount

Expressed in absolute values and round to two decimals.

1234567890123.45

35

16

6

Operation currency

ISO code for the currency.

EUR

51

3

7

Operation date

By default, corresponds to [F:HAE]DUDDAT or [F:HAE]ACCDAT.
Can be set up at the level of the payment entry transaction.

07092009

54

8

8

Number of operations

Number of operations contained in a payment.

3

62

4

9

Comment

Can be set up at the level of the payment entry transaction.

Inv. DELL001 Payment 07/09

66

32

10

Reference code

Can be set up at the level of the payment entry transaction.

DELL001_07/09

 98

16

(1) SEEWARNING

(2) There are two different cases:
- the bank is known, it is mentioned on the payment: the amounts in account currency are expressed in bank currency (CUR of BANK) whereas the amounts in operation currency are expressed in transaction currency (that can be different from the bank currency)
- the bank is unknown, it is not mentioned on the payment: the fictitious bank is in transaction currency and the amounts in bookkeeping currency are expressed in this currency (along with the amounts in operation currency)

(3) Let us consider a payment transaction with an intermediate posting and a draft management posting (e.g.: checks received and to be collected), with as the generating fact the bank deposit and as the grouping level, the slip. Upon bank deposit of N payments/checks, a single entry line is generated on the bank account. This amount is used at cash management interface level (on the other hand, the number of payments concerned is N, not 1).

The contents of the fields are aligned on the left, except for the amounts, that are aligned on the right.

Batch task

This function can be run in batch mode. The standard task EXPCASPAY is provided for that purpose.

Workflow Rules

The execution of the payment export to the cash management software can come along with the sending of an information e-mail if the CASHPAY workflow rule has been activated (event code CSP).

This message recaps the generation directory of the file(s) and the code of the user that has carried out the export function.
The generation log file is included as an attachment.

Purge of the dedicated table

The CASH purge formula is used to purge the PYHCAS table.
The recordings are the following:

  • recordings exported in real,
  • recordings whose original payment has itself been purged,
  • recordings with regards to the number of waiting days with respect to the original date of the request (DATPCH).

Specific Buttons