Financials > Interfaces > Export payments to Sage treasury 

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

    Fields

    The following fields are present on this tab :

    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

    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.

     

    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.

    Close

     

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

    The following fields are included on the window opened through this button :

    • Memo code (field CODE)

    You use a memo code to save the criteria applied to an entry screen. Use this field to find out if a memo code has already been saved for the current screen values.

    Use the following buttons to manage memos:

    Recall: Recall a previously defined and saved memo.

    Memo: Save the current values of the screen in a memo file with a code to be specified.

    Del. Memo: Delete a previously saved memo.

    If a memo named STD (standard) is associated with the screen, it is loaded when opening the function.

    Close

    SEEREFERTTO See the documentation on the [Memo] button for further information.

    SEEREFERTTO See the documentation on the [Memo] button for further information.

    Error messages

    In addition to the generic error messages, the following messages can appear during the entry :

    "This is not a group of companies"

    The export can only concern a group of companies (a legal company or a group of legal companies).

    "No payments to propose"

    The payment export processing has not found any payments meeting the extraction criteria.

    Tables used

    SEEREFERTTO Refer to documentation Implementation