Clearing Interface Oracle FLEXCUBE Universal Banking Release 22.214.171.124.0EU [April]  Oracle Part Number E51534-01 Clearing Interface Table of Contents 1. ABOUT THIS MANUAL................................................................................................................................ 1-1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 2. INTRODUCTION ........................................................................................................................................... 1-1 AUDIENCE .................................................................................................................................................. 1-1 ACRONYMS AND ABBREVIATIONS .............................................................................................................. 1-1 ORGANIZATION .......................................................................................................................................... 1-1 CONVENTIONS USED IN THIS MANUAL ....................................................................................................... 1-2 GLOSSARY OF ICONS .................................................................................................................................. 1-2 RELATED DOCUMENTS ............................................................................................................................... 1-3 CLEARING INTERFACE – DTA MESSAGES .......................................................................................... 2-1 2.1 INTRODUCTION ........................................................................................................................................... 2-1 2.1.1 File Format ........................................................................................................................................ 2-1 2.1.2 File Name........................................................................................................................................... 2-1 2.1.3 Structure and Specifications of DTA Messages ................................................................................. 2-1 2.1.4 Definition of a Return Direct Debit ................................................................................................. 2-28 2.1.5 Maintaining Clearing Message Types ............................................................................................. 2-30 2.1.6 Viewing Clearing Message Type ..................................................................................................... 2-31 2.1.7 Maintaining Clearing Interface derived UDFs................................................................................ 2-32 2.1.8 Viewing Clearing Interface Derived UDF ....................................................................................... 2-33 2.1.9 Maintaining Group Details .............................................................................................................. 2-34 2.1.10 Mapping sub-nodes with the corresponding nodes in the External System ..................................... 2-39 2.1.11 Maintaining Transaction Group ...................................................................................................... 2-43 2.1.12 Viewing Transaction Group Details ................................................................................................ 2-49 2.2 OUTGOING CLEARING UPLOAD ................................................................................................................ 2-50 2.3 INCOMING CLEARING UPLOAD .................................................................................................................. 2-53 2.3.1 Viewing the details of Files that were Handed-off ........................................................................... 2-53 2.3.2 Ignoring Clearing Log Details......................................................................................................... 2-55 2.4 PROCESSING FOR THE INTERFACE ............................................................................................................. 2-56 2.4.1 Incoming Message Processing ......................................................................................................... 2-56 2.4.2 Outgoing Message Processing ......................................................................................................... 2-56 3. SCREEN GLOSSARY .................................................................................................................................... 3-1 3.1 FUNCTION ID LIST...................................................................................................................................... 3-1 1. About this Manual 1.1 Introduction This manual is designed to help acquaint you with the interface between Oracle FLEXCUBE and the relevant clearing networks. This manual provides you extensive explanations about the various maintenances required for the smooth exchange of data between Oracle FLEXCUBE and the networks applicable. It also gives you an insight into the processes involved in the actual exchange of data. Besides this User Manual, while maintaining the interface related details, you can invoke the context sensitive help available for each field. This help encapsulates the purpose of each field within a screen. Placing the cursor on the relevant field and striking the <F1> key on the keyboard can obtain information specific to a particular field. 1.2 Audience This manual is intended for the following User/User Roles: 1.3 1.4 Role Function Back office data entry Clerks Input functions for maintenance related to the interface Back office Managers/Officers Authorization functions Acronyms and Abbreviations Abbreviation Description System Unless and otherwise specified, it shall always refer to Oracle FLEXCUBE system UDF User Defined Fields ACH Automated Clearing House Organization This document talks about the maintenance required for data exchange between Oracle FLEXCUBE and the relevant clearing networks. This includes the following Maintaining Clearing Message Types Maintaining File Formats Maintaining Clearing Message Groups Derived and Rejection UDF Maintenance Message Status Browser The manual also talks about the following processes: Message hand-off to the clearing network Message upload into Oracle FLEXCUBE Online message processing 1-1 1.5 Conventions Used in this Manual Important information is preceded with the 1.6 symbol. Glossary of Icons This User Manual may refer to all or some of the following icons. Icons Function New Copy Save Delete Unlock Print Close Re-open Reverse Template Roll-over Hold Authorize Liquidate Exit Sign-off Help Add Delete 1-2 Refer the Procedures User Manual for further details about the icons. 1.7 Related Documents You can refer to the XML Interface document, which outlines the details of the interface mechanism between Oracle FLEXCUBE and an External System. 1-3 2. Clearing Interface – DTA Messages 2.1 Introduction All the customer payments (normal) and direct debit notes within Germany will be handled in DTA format. Oracle FLEXCUBE handles the DTA messages through the clearing interface. There is usually a single file, one for credit notes and one for debit notes, transfer containing mass data. It is called EMZ (Electronic Mass Transfer). 2.1.1 File Format The DTA format is as shown below: A – Header C – All the payment records E – End 2.1.2 File Name DTAUS (in HDR1 Field 3). The file name must invariably appear at the start of Field 3 of the HDR1. The entry of additional information (maximum 11 positions) after the file name ‘DTAUS’ is permissible. Such additional information should be separated from the file name ‘DTAUS’ with a point (X ‘4B’). 2.1.3 Structure and Specifications of DTA Messages The structure and specifications of the DTA messages are explained in the subsequent sections. 126.96.36.199 A – Header Data record A (data carrier set) The data record A contains the mention of the tape transmitter and receiver. Field Length in bytes Data format Content Description Comments 1 4 binary Data record length The mention of the length of the data record shall be according to the conventions for variable data record lengths (data record length field 4 bytes, of which 2 bytes shall be left-justified, the remaining bytes X ‘40’ or X ‘00’) Hard code to 150 2 1 alpha Type of data record Constant “A” To be hard coded to A 2-1 3 2 alpha character “GK” or 1 “LK” “GB” or 2 “LB” 4 5 numerically packed Bank code number Reference to credit entries (=G), or debits and / or cheque collections (=L), bank tape (=B), client tape (=K) G- credit Entry, L – debit entry For inward delivery: Bank code of the bank receiving the file. For outward delivery: Bank code number of the accountcontrolling authority in the bank K – Customer disk/file, B –Bank disk/file. Zero (packed) Zero (packed) 5 5 numerically packed Bank code number For inward delivery: For outward delivery: 6 27 alpha Bank designation / client name Zero (packed) Bank code number of the accountcontrolling authority in the bank For inward delivery: Remitter / presenter or receiving client, max 10 positions. The counter-value shall be calculated over this account For outward delivery: “NATIONAL CENTRAL BANK” 7 4 numerically packed Date [date of creation of tape (DDMMYY), right-justified] 8 4 numerically packed Serial number of the file Number for unique identification of the file (right-justified) 2-2 Sending bank code if the bank is sending the diskette. If the customer is sending the file this should be Zero packed. Name of the sender. If bank, then bank name else customer name. For outward delivery the German equivalent of NATIONAL CENTRAL BANK has to be printed which is Landeszentalbank. This is an optional field. This can contain a valid For inward delivery: it should be kept in mind that the number circle is between “0001”, and “9999”, and that no number dependent on Field A 7 (date) is used multiple times. The numbers must neither be entered without spaces nor in ascending order. number between 0001 and 9999. For outward delivery: the number shall be entered in ascending order starting from “0001”, and the entry must not be without spaces 9 6 numerically packed Giro account number Remitter / presenter or receiving client, max 10 positions 10 91 ---------- X ‘40’ Reserve 11 1 ------ X ‘40’ Reserve If Bank is making a payment then this field is left blank. But if the bank is making a payment on behalf of a customer then the customer account needs to be filled in this field. 150 alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign 188.8.131.52 Data Record C (Payment Exchange Record) The data record C contains particulars concerning the assignments to be carried out (credit entries, debits or direct cheque collections). It is sub-divided into a constant and a variable part. 1. Constant part Field Length in bytes Data format Content Description 2-3 Comments 1 4 binary Data record length Length specification of the data record as per the conventions for variable record length (record length field 4 bytes, of which 2 bytes are with binary leftjustified entry, remaining bytes X ‘40’ or X ‘00’) Specify the length of the data record. Consider the variable record length also. Max possible value is 585 (150 for constant part and 15*29 variable part) 2 1 alpha Type of data record Constant “C” To be hard coded to C 3 5 Numerically packed Bank code number For EZÜ/EZL: Firstparticipating bank (released insofar as identical with remitting bank / first collection agency) For BSE: Cheque safekeeping agency Cheque converting agency For GSE: Otherwise: 4 5 Numerically packed Bank code number Firstparticipating bank, released Bank of the beneficiary / paying agency for BSE/GSE: concerned bank (Field 2 of the coding line) 5 6 Numerically packed Account Number Beneficiary / party liable to pay For BSE/GSE: cheque drawer (Field 4 of the coding line) Right-justified, maximum 10 positions 2-4 Optional field. This field is the first collecting agent in the chain of transfer. Ultimate beneficiary bank code/paying agency. Beneficiary account number 6a 6 Numerically packed without prefix st DTA/EZÜ/ EZL/BZÜ/ 1 half-byte BSE/GSE/ ONB/SWIF T/ For DTA payments = “0” EDIFACT identifier and First half byte is the type of the payment and then the reference number. The type of the payment is always 0 or 1. Xxxx 2 Ref. no. For EZÜ/EZL payments = “1” For EZÜ payments = “2” For BSE cheque collections = “3” For GSE cheque collections = “4” For ONB payments = ”6” For converted SWIFT payments = “7” For converted EDIFACT payments = “8” nd th 2 -12 half-byte: reference number of the payment or zero 6b 7 numerical Zero Reserve data alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign 1 Online Banking 2-5 2 to 12 half bytes can contain the reference number of the transaction. would require 0 for all payment and collection items that are getting uploaded would require 1 for all payment and collection items that are getting entered directly into FC would require 6 for all payment and collection items that are getting into FC from the [email protected] 2 Only permissible in the case of data records of banks 3 Only permissible in the case of data records of the German Federal Bank Structure and clarifications concerning DTA messages st 1 Constant part (continued) Field Length in bytes Data format Content Description Comments 7a 1 Numerically packed without prefix Text code Identification of the type of payment (for BSE/GSE: Field 1 of the coding line) Identification of type of the transaction. Type of transaction is uniquely identified with the combination of fields 7a and 7b. There is a list available which is given in the Section. And text code supplements as per Section 2 7b 2 Numerically packed Text code supplement 8 1 -- If not used X ‘40’ 9 6 Numerically packed Zero 1 Identification of type of the transaction. Type of transaction is uniquely identified with the combination of fields 7a and 7b. There is a list available which is given in the Section. Internal bank field Not used. Reserve, rightjustified Not used. 2-6 10 5 Numerically packed Bank Code number Remitting bank / 1 collection agency st Remitting bank code. Or For BSE/GSE: st Remitting bank / 1 collection agency (from field 5 of the coding line of the consolidated voucher, positions 613 or from Field 1 of the individual data record of the tape accompanying the voucher, positions 18) For BZÜ: Remitting bank or remitting bank 11 6 Numerically packed Account number Remitter / payee, right-justified, Maximum 10 positions. Or For BSE and GSE: Internal number For example, presenter number from Field 5 of the coding line of the consolidated voucher (positions 15) or bundle/ daybook number or from Field 1 of the individual data record of the accompanying voucher tape, positions 9-13, rightjustified, maximum 10 positions 12 6 Numerically packed Amount in Euro including decimal places Right-justified 2-7 Remitter’s account number. 13 3 ---------- If not used X ‘40’ Bank-internal field In DTA this field is optional. While generating the DTA message, FLEXCUBE UBS can generate all the transactions in to a single file containing one ACE record irrespective of the value date. At PAS the HVB system will use this field to group the transactions with same value date to generate the proper DTA message that can be send out. Interface requirement, section 5 (outgoing) for more details. 14 27 alpha Name Beneficiary/ party liable to pay (leftjustified) Beneficiary name Or For BSE/GSE: text constant “CHEQUE DRAWER” Left-justified alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign 1 The DM amount is entered in this field for purpose of information Structure and clarifications concerning DTA messages st 1 constant part (continued) Field Length in bytes Data format Content Description 2-8 Comments 15 27 alpha Name Or Remitter / payee (left-justified); the shortest possible designations should be used In the case of BSE/GSE: text constant “CHEQUE NUMBER”, empty space; 13 digit cheque number (from Field 5 of the coding line) Left-justified 2-9 Remitter name 16 27 alpha Purpose of payment Or: In case of BSE: X ‘40’ In case of GSE: text constant “EINR BEI LZB” (inward remittance to national central bank); 13-digit presenter number of the presenter to the LZB (from Field 5 of the coding line of the consolidated voucher or from Field 8 of the individual data record of the tape accompanying the voucher ) The shortest possible entries should be made. The details at the start of this field should be leftjustified, and should be such that the beneficiary would intend to access mechanically in the case of remittances (for example building society account number, insurance number, invoice number) or which the payee requires for debits, if the payment is sent back to him as unpaid or nonexecutable In the case of BZÜ: exactly 13 positions Left-justified 17a 1 ---------- X ‘40’ Reserve 17b 2 ---------- X ‘40’ Reserve 2-10 Free format text. This field can contain a short description of the payment- In case of rejection of direct debit the reason for rejection can be entered I this. 18 2 Numerically packed Extension identifier BSE, GSE and BZÜ: 00 For return remittances: 01 00 = no extension part follows 01-15 = number of extension parts up to 29 bytes If no extension is used then put 00 and the C record ends here. Otherwise put the number of extensions used in this field 150 alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign Structure and clarifications concerning DTA messages 2. Variable part The variable part forms one unit together with the constant part. It is only present if the data fields in the constant part are insufficient for recording information. A maximum of 15 extension parts can be appended to the constant part of the data record C, taking into account the ascending sequence of the extension sign. The following may occur: one extension part for “ “beneficiaries ” or “party liable to pay” (01); up to 13 extension parts for “purpose of payment” (in each case 02) and 1 extension part for “remitter” or “payee” (03). In the case of return remittances, the content of extension parts cannot be given by the banks. All the ‘purpose of payment’ details required for the processing of such return remittances and reverse debits should therefore be included by the payee or the client in the constant part of the data recorded C (see explanations concerning Field C 16). This means that when the payment/direct debit is initiated by the customer in DTA format the customer should not use any of the extension part for describing the purpose of payment. This is because if the bank rejects the same for any reason bank will use the extension records to give the reason for rejection, date of rejection etc. So there is a risk of purpose of payment getting over written by the rejection message if customer uses the extension part. The purpose of payment should be intact as much as possible even in the rejection message. Also there is a specific format in which the rejection details need to be written which is given in Section 4. Field Length in bytes Data format Content Description 1 2 numerical Identifier of the extension part 01 = name of beneficiary or party liable to pay 02 = purpose of payment 03 = name of remitter or payee 2-11 Comments 2 27 alpha Beneficiary or party liable to pay / purpose of payment / remitter or payee Left-justified 29 alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign Structure and clarifications concerning DTA messages Data record E (end of file label of data carrier) The data record E is for reconciliation; it is present only once for every logical file Field Length in bytes Data format Content Description 1 4 binary Length of data record Length specification of the data record as per the conventions for variable record length (record length field 4 bytes, of which 2 bytes are with binary leftjustified entry, remaining bytes X ‘40’ or X ‘00’) 2 1 alpha Type of record Constant “E” 3 5 ---------- X ‘40’ Reserve 4 4 Numerically packed Number of C data records Reconciliation document 5 7 ---------- Null Reserve, rightjustified 6 9 Numerically packed Total of the Account numbers for beneficiaries/parties liable to pay/Cheque Drawer Reconciliation document 1 2-12 Comments 7 9 Numerically packed Total of Bank Code numbers of the banks of the beneficiaries/ paying agencies/ concerned lending institutions Reconciliation document 8 7 Numerically packed Total of Euro amounts from the C data records (Field 12) Reconciliation document 9 104 ---------- X ‘40’ Reserve 150 alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) numerical = numerical data, unpacked numerically packed = numerical data, packed, plus sign 1 The DM amounts from the data records C (Field 9) may be entered in this field if in exceptional cases DM payments are still made. Section 2 b Control measures (plausibility and field content tests) for DTA messages Data Record A Field Content Data Format Consequences of errors Tape number in label record Same as the tape number in the order Alpha Tape return Block length Variable, maximum 32,000 bytes incl. block length field Binary Tape return Record length Equal to 150 Binary Notification to presenter Same as constant “A” alpha Tape return (Field A 1) Type of record (Field A 2) 2-13 Comments Identifier (Field A 3) Bank Code number of the accountcontrolling authority in the bank st 1 position “L” or ”G” alpha Tape return same as the Bank Code number of the account-controlling authority in the bank Numerically packed Tape return equal to 0 Numerically packed Tape return same as permitted date (current date or date of one of the past 10 business days) Numerically packed (rightjustified) Tape return same as valid file number (the file number may be given only once in connection with field A 9 as well as A 7) Numerically packed (rightjustified) Tape return same as client entitled to remit Numerically packed Tape return (Field A 4) Bank Code number of the person sending the magnetic tape (Field A 5) Date (Field A 7) Serial number of the file (Field A 8) Account number of the remitter / presenter (Client) (Field A 9) alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) Control measures (plausibility and field content tests) for DTA messages (continued) Data Record C Field Content Data Format 2-14 Consequences Commets of errors Text code Cheque collections Debits Credit entries (Field C 7a) Same as 01, 02, 03, 11,12 (only permissible in connection with identifier 3 or 4 in the first half-byte of Field C 6a; in the case of fixed code 01, 02, 11 or 12, the amount limit for BSE-cheque collections shall be checked) Numerically packed without prefix Record return Numerically packed Record return Same as 04, 05, 14, 15 (only permissible in connection with identifier 0, 1 or 6 in the first half-byte of Field C 6a) Same as 09 or 10 (only permissible in connection with identifier 0, 1, 3, 4 or 6 in the first half-byte of Field C 6a) Same as 51-54 or 56, 59, 65 and 67-69 (only permissible in connection with identifier 0, 1, 2, 6, 7 or 8 in the first half-byte of Field C 6a) Text code supplement Same as or greater than zero (Field C 7b) 2-15 Reserve* If the content is not equal to zero, it should be possible to 1 calculate the corresponding Euro amount (Field C 12) from the DM amount that has been mentioned for information (Field C 9) Bank Code number of the remitting bank / of the first collection agency / of the presenter st 1 position X ‘0’ nd 2 position not equal to 0 or 9 1 Numerically 2 packed Record return 2 Tape return Numerically packed Record return (Field C 10) alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) * If this test cannot be carried out by the presenter for technical reasons, it should be carried out by the German Federal Bank ** This is only permissible for data records from Bank Institutes *** Only in the case of data records of the German Federal Bank **** ONB = Online Banking Control measures (plausibility and field content tests) for DTA messages (continued) Data Record C Field Content Data Format Consequences of errors Text code Same as 01, 02, 03, 11,12 (only permissible in connection with identifier 3 or 4 in the first half-byte of Field C 6a; in the case of fixed code 01, 02, 11 or 12, the amount limit for BSE-cheque collections shall be checked) Numerically packed without prefix Record return Cheque collections Same as 04, 05, 14, 15 (only permissible in connection with identifier 2-16 Commets 0, 1 or 6 in the first halfbyte of Field C 6a) Debits Same as 09 or 10 (only permissible in connection with identifier 0, 1, 3, 4 or 6 in the first half-byte of Field C 6a) Same as 51-54 or 56, 59, 65 and 67-69 (only permissible in connection with identifier 0, 1, 2, 6, 7 or 8 in the first half-byte of Field C 6a) Credit entries (Field C 7a) Text code supplement Same as or greater than zero Numerically packed Record return If the content is not equal to zero, it should be 1 possible to calculate the corresponding Euro amount (Field C 12) from the DM amount that has been mentioned for information Numerically 2 packed 1 (Field C 7b) Reserve* (Field C 9) Bank Code number of the remitting bank / of the first collection agency / of the presenter st 1 position X ‘0’ nd 2 position not equal to 0 or 9 Record return 2 Tape return Numerically packed Record return 2-17 (Field C 10) alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) * The DM amount may be entered in this field for purpose of information 2-18 Control measures (plausibility and field content tests) for DTA messages (continued) Data Record C Field Content Data Format Consequences of errors Account number of the remitter / payee 1 position X ‘0’ Numerically packed Record return Amount not equal 1 to zero Numerically 2 packed 1 not equal to X ‘40’ alpha Record return not equal to X ‘40’ alpha Record return st Rest not equal to zero st 1 position X ‘0’ For BSE/GSE cheque collections: Rest not equal to zero Internal number (Field C 11) Amount in Euros (Field C 12) Name of the beneficiary / party liable to pay or text constant for BSE/GSE record return 2 tape return (Field C 14) Name of the of the remitter / payee or text constant for BSE/GSE (Field C 15) alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) 2-19 Comments Control measures (plausibility and field content tests) for DTA messages (continued) Data Record C Field Content Data Format Consequences of errors Extension identifiers same as 00-15 Numerically packed Record return numerical Record return with extension part For BSE/GSE cheque collections same as 00 same as 00, if Field C 7a = 67 same as 01, if For BZÜ payments For return debits (Field C 18) Field C 7a = 59 equal to 03 or 04 if Field C 7a = 09 (for extension identifier “02” = purpose of payment) for voucher-less unpaid cheque bookings or equal to 00 for unpaid cheque bookings via return cover Identification of the extension part Same as 01, 02 or 03 in ascending order (Field C 1 variable part) Maximum 1 times 01 Maximum 13 times 02 Maximum 1 times 03 2-20 Commets The check totals from the addition of the unit counts of the data records C, the fields “Reserve” (C9)* and “amount” (C 12), “account number of the beneficiary/party liable to pay/person writing cheque” (C 5) and “bank code number/of the bank of the beneficiary/the paying agency/the relevant bank” (C 4) should correspond to the details given in the data record E. if the Field C9 is filled with a value that is greater than 0, the bank of the beneficiary is advised to notify the original amount from Field C9 in DM in addition to the amount in Euros, from the Field C12, for information purposes. Numerically packed Tape return alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) * From the field C9 only in exceptional cases where DM payments are still made. Control measures (plausibility and field content tests) for DTA messages (continued) Data Record E Field Content Data Format Consequences of errors Length of data record Equal to 150 Binary Notification to the presenter Same as constant “E” alpha Tape return Comments (Field E 1) Type of record (Field E 2) alpha = alpha-numerical data (left-aligned, blank positions X ‘40’) Section 3 1) Details concerning the remitter, payee, party liable to pay The details should not exceed the 27 positions provided in the data field C 15 or C 14 (see Section 1a or 1b). Explanations concerning Field 7 a and 7 b of the data record C 2-21 For identifying the type of payment in Field 7 a, use the text codes specified in the “Guidelines for standardised payment forms”. The payment types mentioned below should also be identified with a special text code supplement in Field 7 b: 2-22 Text key Field 7a Text key supplement Field 7 b Explanation Content of the data field 7 01 000 Euro bearer cheque ‘01000’ 01 888 Euro bearer cheque deposited from abroad ‘01888’ 02 000 Euro order cheque ‘02000’ 02 888 Euro order cheque deposited from abroad ‘02888’ 03 000 Euro traveller’s cheque ‘03000’ 04 000 Debit ‘04000’ 1 1 2 1 1 2 (pre-authorised payment process) 05 2 000 Debit 2 ‘05000’ (direct debit process) 05 001 Debits due to supra-institutional withdrawals from EC ATM’s abroad ‘05001’ 05 002 Debits due to EC ATM withdrawals by foreign persons ‘05002’ 05 003 Debits due to supra-institutional EC /EMV ATM withdrawals within the country ‘05003’ 05 004 Debits due to EC ATM withdrawals via credit cards or CIRRUS and PLUS debit cards ‘05004’ 05 005 Debits due to POS withdrawals - ‘05005’ Electronic cash 05 006 Debits due to POS withdrawals - ‘05006’ (with foreign card) - Maestro 05 007 Debits due to EMV ATM withdrawals by foreign persons using debit cards ‘05007’ 05 008 Debits due to credit card transactions ‘05008’ 05 009 Debits due to EMV ATM withdrawals using credit cards ‘05009’ 05 010 Debits due to POS withdrawals (with foreign card) Maestro/EMV ‘05010’ 05 015 Debits due to POS withdrawals - POZ ‘05015’ 05 200 Cash card – debits for debiting cash card transactions by the dealer/the merchant bank to the merchant bank/the clearing bank of the merchant bank information centre ‘05200’ 05 201 ‘05201’ 05 202 Cash card – debit for debiting the cash card transactions by the clearing bank of the merchant bank information centre, to the clearing bank of the card issuer information centre 2-23 Cash card – debit for debiting cash card transactions by the clearing bank of the card issuer’s information centre, to the stock exchange clearance account of the card issuer ‘05202’ Text key Field 7 a Text key supplement Field 7 b Explanation Content of the data field 7 05 210 Cash card – debit for debiting dealer payments through the clearing bank of the merchant bank information centre / the merchant bank, to the dealer ‘05210’ 05 222 Cash card – debit for debiting the charges by the card issuer’s apex agency, to the card issuing institution ‘05222’ 05 230 Cash card – debit for debiting the charges of the card issuing institution to the terminal operating institution while charging against other currencies ‘05230’ 05 240 Cash card – debit for debiting the charges and compensation payable to the card issuing institution, to the client account ‘05240’ 05 242 Cash card – debit for debiting the charges and compensation payable to the terminal operating institution, to the debit of the EC card issuing institution ‘05242’ 05 nn9 Reverse entry in view of accidental double DTA payment ‘05nn9’ 09 000 Reverse entry of GSE election documents via return credit cover ‘09000’ 09 nnX 4 Return account of BSE / GSE data records ‘09nnX’ 4 09 04X 5 Return debit (pre-authorised payment process) ‘0904X’ 5 09 05X 5 Return debit (direct debit process) ‘0905X’ 5 09 056 Charge back / Maestro or Euro pay ATM systems ‘09056’ 10 000 Charges for delivery of cheque copy or original cheque ‘10000’ 11 000 Eurocheque in Euro ‘11000’ 11 888 Euro cheque in Euro sent in from abroad ‘11888’ 12 000 Clearance payment order (ZzV) ‘12000’ 14 000 Debit for giro cheque in foreign currency ‘14000’ 14 001 Debit due to EC ATM withdrawals abroad ‘14001’ 14 002 Debit due to online POS withdrawal abroad - ‘14002’ 3 1 2-24 3 1 Maestro nd 14 003 Maestro 2 presentation of a debit due to online POS withdrawal abroad ‘14003’ 14 005 Charges due to withdrawals from EMV ATM’s abroad ‘14005’ 14 006 Debit due to online POS withdrawal abroad – Maestro / EMV ‘14006’ 14 007 Maestro / EMV, 2 presentation of a debit due to online POS withdrawal abroad ‘14007’ 14 082 Debit due to offline POS withdrawal abroad Maestro ‘14082’ 14 083 Maestro 2 presentation of a debit due to online POS withdrawal abroad ‘14083’ 14 084 Debit due to offline POS withdrawal abroad – Maestro / EMV ‘14084’ 14 085 Maestro / EMV, 2 presentation of a debit due to offline POS withdrawal abroad ‘14085’ 15 000 6 Charges due to international standard remittance within the reporting limits ‘15000’ 6 51 000 2,7 Remittance credit entry (for example, commercial utility) ‘51000’ 2,7 nd nd nd Text key Field 7a Text key supplement Field 7 b Explanation Content of the data field 7 51 200 Cash card – credit entry for cash card transactions by the merchant bank / clearing bank of the merchant bank information centre in favour of the dealer / merchant bank ‘51200’ 51 210 Cash card – credit entry for dealer charges by the merchant bank in favour of the clearing bank of the merchant bank information centre ‘51210’ 51 211 Cash card – credit entry for dealer charges by the clearing bank of the merchant bank information centre in favour of the clearing bank of the card issuer’s information centre ‘51211’ 51 212 Cash card – credit entry for dealer charges by the clearing bank of the card issuer’s information centre in favour of the card issuing institution ‘51212’ 2-25 51 220 Cash card - credit entry for charges by the apex agency of the terminal operator in favour of the charging terminal operating institution ‘51220’ 51 221 Cash card - credit entry for charges by the apex agency of the card issuer in favour of the charging apex agency of the terminal operator ‘51221’ 51 230 Cash card – credit entry for a wrongly debited debit amount by the card issuing institution, in favour of the terminal operating institution ‘51230’ (Cancellation of 05230) 51 Cash card – credit entry for a wrongly debited debit amount by the card issuing institution, in favour of the client account 240 ‘51240’ (Cancellation of 05240) Cash card – credit entry of an amount released by the stock exchange by the card issuing institution in favour of the client account ‘51241’ 3 Reverse entry in view of accidental double DTA payment ‘51nn9’ 2 Standing order credit entry ‘52000’ 2,7 Credit entry for salary, wages, interest ‘53000’ 8 Asset-creating action (VL) ‘54XXJ’ Asset-creating action (under EZÜ collection) ‘54777’ Remittances by public cash offices ‘56000’ Return remittances ‘59YYZ’ 6,10 Remittance credit from abroad ‘65000’ 2,7 Remittance credit with check digit-protected classification data ‘67000’ 2,7 Credit entry for neutral remittance / payment slip ‘68000’ 2,7 Credit entry for a donation payment ‘69000’ 51 241 51 nn9 52 000 53 000 54 XXJ 54 777 56 000 59 YYZ 65 000 67 000 68 000 69 000 1 7 9 3 2 2,7 8 7 9 6,10 2,7 2,7 2,7 There is no obligation on the part of the Bank to enter the text code supplement ‘888’. 2 If the remitter / payee is a non-resident within the meaning of the Foreign Trade and Payments Ordinance, the text code supplement ‘000’ should be supplemented by ’888’ if the payment amount exceeds 12,500 Euros. The text code supplement ’888’ should be changed by the bank of the beneficiary/the paying agency while printing out the account statements or the debit / credit vouchers in the indication text “Follow AWV Disclosure Requirements; Information under 0800/1234111”. As for all remittances, it also applies to remittance of a non-resident to a resident, there is an identification obligation if there is a negative check-digit calculation or a missing target account number: in the case of a negative check-digit calculation, the payment exchange record must be identified with the text code supplement ‘444’ for payments up to 12,500 Euros; for payments exceeding 12,500 Euros, the text code 2-26 supplement ‘844’ should be used. Remittances in which the beneficiary account number is not mentioned should be marked with the text code supplement ‘445’ (account number missing) for payments up to 12,500 Euros. For payments exceeding 12,500 Euros, such remittances from a nonresident to a resident should be identified with the text code supplement ‘845’. 3 The alphabets ‘nn’ should be replaced by the original text code of DTA payments that have been executed twice by mistake. Thereafter, the reverse entry for the accidental double DTA entry should be identified with ‘05519’. 4 The alphabets ‘nn’ should be replaced by the original text code from Field 7 a of the BSE/GSE data record. The alphabet ‘X’ should be replaced by the relevant number of the encoded Ground for Return: ‘0’ for “RETURNED CHEQUE”, ‘1’ for “ACCOUNT CANCELLED”, ‘2’ for “ACCOUNT NO./BANK CODE NUMBER WRONG”, ‘5’ for “STOPPED CHEQUE”; ‘6’ for “DATA ERROR TRAVELLER’S CHEQUE”, ‘7’ for “GSE DOCUMENT NOT PRESENTED”. 5 The alphabet ‘X’ should be replace by the relevant number of the encoded Ground for Return: ‘0’ (no entry), ‘1’ for “ACCOUNT CANCELLED”, ‘2’ for “ACCOUNT NUMBER FALSCH” or “SAVINGS ACCOUNT.” “ACCOUNT NO/NAME NOT IDENTICAL” (the relevant text constant is to be allocated) ‘3’ for “NO PAYMENT PRE-AUTHORISATION” or “NO DIRECT DEBIT AUTHORISATION”, ‘4’ for “RECALL”, ‘5’ for “DUE TO INCONSISTENCY” (this is only possible in the case of debit reversal entries from the direct debiting procedure), ‘6’ for “RETURN/CHARGEBACK FOR EXAMPLE MAESTRO”, ‘7’ for the absence of GSE cheques, no special provision as per Footnote 4. 6 For amounts up to 12,500 Euros, the numerical ISO country code of the country of the remitter can be used instead of the text code supplement ’000’, for example: 056 Belgium 826 Great Britain 442 Luxembourg 620 Portugal 208 Denmark 372 Ireland 528 Netherlands 752 Sweden 2-27 246 Finland 352 Iceland 578 Norway 756 Switzerland 250 France 380 Italy 040 Austria 724 Spain 300 Greece In addition, the stipulations contained in Footnote 2 shall apply. 7 EZÜ remittances in which the calculation of the check-digit for the account number of the beneficiary leads to a negative result, should be marked with the text code supplement ‘444’ (check-digit calculation negative). Remittances in which the account number of the beneficiary is not present should be identified with the text code supplement ‘445’ (account number missing). 8 The alphabets ‘XX’ should preferably be replaced by ‘00’ or by the relevant % percentage of the savings bonus, the alphabet ‘J’ should be replace by the last digit of the year for which the payment is valid. For example: in the case of a payment for 2001 with 10% savings bonus, the correct entry for the data field 7 shall be: ‘54001’ or ‘54101’. 9 The alphabets ‘YY’ should be replaced by the original text code of the DTA remittance. The alphabet ‘Z’ should be replace by the respective digit of the encoded Ground for Return: ‘1’ for “ACCOUNT CANCELLED”, ‘2’ for “ACCOUNT/BANK CODE NUMBER WRONG”, ‘3’ for “CONTRACT PERMISSIBLE”, EXECUTED” or “CONTRACT INTERRUPTED”. “CREDIT NOT ‘4’ for “RECALL”, ‘5’ for “ACCOUNT NUMBER/NAME NOT IDENTICAL”. 10 Remittances in which the account number of the beneficiary is not specified should be identified with the text code supplement ‘445’ (account number missing). 2.1.4 Definition of a Return Direct Debit If a direct debit is returned by the bank or by the customer, a DTA message will be generated to intimate the originating bank. The reject DTA message will change from the original DTA message mainly in terms of the following explained fields. The reason for rejection is written in the first 4 lines of the C extension record with identifier of the extension part as 02. If there is already some data in the extension part of the original DTA message it will be over written by this. So, the DTA standards suggest the customers to put the purpose of payment in the original record field C16 with the least text possible. The original C-record of a non payed direct debit has some changes: C4 (BLZ Bank-Code) changes with C10 C5 (Account-#) changes with C11 C14 (Name) changes with C15 2-28 C12 contains the sum of the original amount + foreign charge + own charge (the highest charge: 3,5 € each C16 contains the old C16 C6 contains the old C6 Field C7a contains '09' Field C7b contains the old C7a-field (04 or 05) with an extension of the code number indicating the reason for return: 0 – No details given - keine Angabe 1 – Account no longer exists – Konto erloschen 2 - Details not clear – account# is wrong – account # differs from name – ' KTO-Nr. Falsch' KTONr/Name nicht identisch 3 – No instruction to pay debit notes – Kein Abbuchungsauftrag (C7a old = 04) – Keine Einzugsermächtigung ( c7a old = 05) 4 – Recall – Rückruf 5 – Due to objection by debtor – Wegen Widerspruch 6 – Return / chargeback EDC – Rückgabe (1) If the bank rejects the direct debit the first 4 extensions (reason for payment) should contain: 123456789012345678901234567 first: VORGELEGT AM dd.mm.yy NICHT second: BEZAHLT EU 123456789,12ENToriginal amount third: GELT FREMD12,12EIGEN12,12EU foreign charge/ own charge forth: xxxxxxxxxxxxxxxxxxxxxxxxxxx reason for return (2) if the customer rejects the direct debit then the first 4 extensions (reason for payment) should contain – (case of due to objection by debtor) 123456789012345678901234567 first: BELASTET AM dd.mm.yy ZURÜCK date of debit 2-29 second: dd.mm.yyEU 123456789,12ENTdate of return third: original amount GELT FREMD12,12EIGEN12,12EU foreign charge/ own charge forth: xxxxxxxxxxxxxxxxxxxxxxxxxxx reason for return The reason for rejection ranged from values 1 to 6. Only 1 to 6 other than 5 can be used if bank rejects the same. If bank rejects the direct debit, then the first format will be used in the first four extensions part of the C record. First line contains original date, second line original amount, third line the foreign charge and local charge and fourth line the reason for rejection. The reason for rejection ranged from values 1 to 6. Only 5 can be used if customer rejects the same. If customer rejects the direct debit, then the second format will be used in the first four extensions of the C record. First line contains the original date, second line the return date and original amount, third line the foreign charge and local charge and forth line the reason for rejection. The text along with the data as above mentioned should be the same. 2.1.5 Maintaining Clearing Message Types A Clearing Transaction/Message Type is a Payment Order belonging to a Transfer Category. These Clearing Message Types / Categories will be specific to the Network (example BankGiro etc). You can maintain the clearing message Type/Category details through the ‘Clearing Msg Type’ maintenance screen. You can invoke this screen by typing ‘IFDTXNTY’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. 2-30 In this screen you can capture the following attributes about the clearing message Type/Category: Network ID – a valid network code from a pre-defined set of Network Codes. For instance you can define a network code called DTA. Clearing Message Type – a valid name to identify the clearing message type which is to be associated with the Network ID. You can also capture a brief description to identify the clearing message type. Process Direction – specify whether the payment order which you are defining belongs to the Incoming transfer order or whether it belongs to the Outgoing transfer category. Product Category/Product Restriction – If the process direction of the transaction type, which you are defining, is Incoming, you will associate existing PC Product Categories with each transaction type. Conversely, if the process direction is Outgoing, you will need to associate existing PC Products with each transaction type. You can specify product category/product restrictions in the form of allowed lists or disallowed lists. 2.1.6 Viewing Clearing Message Type You can view clearing message type details using ‘Clearing Msg Type Summary’ screen. You can invoke this screen by typing ‘IFSTXNTY’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. In the above screen, you can base your queries on any or all of the following parameters and fetch records: Authorization Status Network Code Process Direction Record Status 2-31 Clearing Msg Type Select any or all of the above parameters for a query and click ‘Search’ button. The records meeting the selected criteria are displayed. Authorization Status Record Status Network Code Clearing Msg Type Description Process Direction 2.1.7 Maintaining Clearing Interface derived UDFs As part of maintenance, you have to establish a mapping between the Local Payments module of Oracle FLEXCUBE to fields that are required by the clearing network. In other words, Oracle FLEXCUBE tags are mapped to the corresponding external system tags. Sometimes, you may not find a direct relationship between an external system tag and the Oracle FLEXCUBE tags. For such tags, with no corresponding tags in Oracle FLEXCUBE, you can define an UDF (User Defined Field) and obtain a value by writing derivation logic. Likewise, you can also write rejection logic. If a particular contract in the hand-off message satisfies the rejection criteria, the system will reject the entire contract. The rejection logic will filter the contracts within the message that is being handed-off. During mapping, you can map the external tag with the corresponding UDF name. Example The external system may have a tag called – Account Type. A corresponding tag does not exist in Oracle FLEXCUBE. Instead, Oracle FLEXCUBE has a tag called ‘Account_No’. Therefore, to obtain a value for ‘Account Type’, you can derive a logic such that if the first character of the Account No. is ‘C’, the Account Type would be ‘Normal’ else it will be considered as a ‘Special’ account. Therefore, when you actually handoff a message, the Account Type would be associated with the value ‘Normal’ or ‘Special’ as the case may be. You can maintain the UDFs in the ‘Clearing Interface Derived UDF’ screen. You can invoke this screen by typing ‘IFDCLDUD’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. 2-32 In this screen, you have to specify the following details: UDF Name and UDF Description You can specify a unique name to identify the UDF. A brief description can also be provided in the adjacent field. UDF Type Additionally, you should also specify the type of the UDF being defined – whether you are writing a logic to derive a tag value or for filtering the transactions (in a message file) based on a rejection criteria. Network Specify the network for which you are writing the derivation/rejection logic. To execute the logic, click on the ‘X’ button. If you encounter any error during execution, you can view the same by clicking on the ‘E’ button. Make the necessary corrections before you reexecute the logic. The UDFs defined through this screen will be available in the drop-down menu of the ‘Derive Type’ field in the ‘Clearing Message Type’/’Group Details Maintenance’ screen. This is discussed in the section that follows. You can maintain only 25 derived logics (UDFs) for all the networks that are applicable for data exchange with Oracle FLEXCUBE. Likewise, you can maintain only one rejection logic per network. 2.1.8 Viewing Clearing Interface Derived UDF You can view clearing interface derived UDF using ‘Clearing Interface Derived UDF Summary’ screen. You can invoke this screen by typing ‘IFSCLDUD’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. 2-33 In the above screen, you can base your queries on any or all of the following parameters and fetch records: Authorization Status Record Status UDF Name UDF Type Network Code Incoming/Outgoing Select any or all of the above parameters for a query and click ‘Search’ button. The records meeting the selected criteria are displayed. Authorization Status Record Status UDF Name UDF Description UDF Type Network Code Rule 2.1.9 Maintaining Group Details 2-34 Each network and clearing message type/category has a fixed format that needs to be handed off from or uploaded into Oracle FLEXCUBE. Therefore you will need to specify the format in which data is to uploaded and handed-off. You can do this through the ‘Group Details Maintenance’ screen. You can invoke this screen by typing ‘IFDTXNDT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. Through this screen you can establish a mapping between the Local Payments module of Oracle FLEXCUBE to fields that are required by the network. A predefined set of Clearing Message Types will be shipped along with the software. You can change the default attributes of these message types to suit the requirements of your bank. Network ID The Oracle FLEXCUBE Clearing Gateway is a common channel for data exchange between Oracle FLEXCUBE and the local clearing networks applicable. The details of the applicable local clearing networks are maintained in Oracle FLEXCUBE. You can define the process direction for each of these clearing networks, through the ‘Clearing Message Type Maintenance’ screen You can select the ID assigned to the Network whose tag names need to correspond with those maintained in Oracle FLEXCUBE. On selection of the network from the available option-list, the description gets defaulted alongside. Process Direction The format for hand-off from Oracle FLEXCUBE is different from the format for upload into Oracle FLEXCUBE. Therefore, you need to indicate the process direction for which the format is being defined. The options are: Incoming (for upload into Oracle FLEXCUBE) Outgoing (for hand-off from Oracle FLEXCUBE) 2-35 Clearing Message Group / Type Incoming message (uploads) formats are defined for a Clearing Message Group. When you select the ‘Incoming’ option, the set of Clearing Message Groups supported in Oracle FLEXCUBE are made available to you in the option-list provided. Select the appropriate Group from the list. The format will be applicable to all product categories belonging to the transaction types linked to the selected Message Group. Likewise, outgoing message (hand-offs) formats are defined for a Clearing Message Type. On selection of the ‘Outgoing’ option, all the Clearing Message Types supported in Oracle FLEXCUBE become available in the option-list provided. The outgoing message forma Oracle FLEXCUBE t being defined will be applicable to all products that fall within the selected Clearing Message Type. Number Padding/Direction The messages that are uploaded to or handed-off from Oracle FLEXCUBE consists of fields of a specific length. Most often, the maximum field length is not utilized when you capture the actual field values. Therefore, you need to specify a padding character to fill the gaps. You also need to indicate the direction of the padding characters – whether you would like to pad to the left of the actual field value or to its right. Normally, for numeric fields, you would choose to pad to the left of the numeric value. Example Assume that the length of a numeric field, say ‘Amount’ is 10 and the actual field value is ‘100’, consisting of only 3 digits. Further, you select ‘0’ (zero) as the padding character and choose to pad to the left of the field value. If the message consists of this numeric field, zero will be used to fill the gaps and the value will be displayed as: ‘0000000100’. Alpha Padding/Direction Similarly, you have to select the padding character for the alphanumeric fields in Oracle FLEXCUBE. You also need to indicate the padding direction for the same. Normally, for alphanumeric fields, you would choose to pad to the right of the actual value. Oracle FLEXCUBE Nodes Just like in Oracle FLEXCUBE, the clearing network too may have a set of its own Tag definitions. Consequently, it becomes necessary to maintain a mapping between the information tags within Oracle FLEXCUBE with those required by the clearing network. The Oracle FLEXCUBE node represents a set of tags grouped together. It is known as the parent node/record from which the sub records/sub nodes (tags) are derived for mapping to the external tags. Format Type As stated earlier, the messages that are handed off and uploaded into Oracle FLEXCUBE are in the ASCII file format. An ASCII file consists of the following sections (in the order specified): 1. File Header 2. Batch Header 3. Batch Body 4. Batch Footer 2-36 5. File Footer You can maintain a format for each section of the ASCII file. The file header marks the beginning of a file. Every batch begins with a batch header and ends with the batch footer. The batch body is the actual content of the message that is being handed off or uploaded. The file footer marks the end of the file. A file can consist of several file headers, file footers, batch footers and so on. You can maintain a format for each occurrence of a format type within the ASCII file. Format Seq. No The format of an ASCII file is as shown below: File Header Batch Header Batch Body Batch Footer File Footer To recall, a file can consist of multiple file headers, batch headers, file footers and so on. The sequence number determines the manner in which multiple formats (of the same format type) appear in the ASCII file. Oracle FLEXCUBE automatically sequences these formats for you. If you are maintaining more than one file header format for a combination of Clearing Network and Oracle FLEXCUBE Node, the sequence number will start with one and get incremented by one for each subsequent file header format. External Node Just as the Oracle FLEXCUBE node represents a set of tags grouped together, the external node is a unique name for identifying the set of tags belonging to the external system (clearing network in this case). You will need to map each tag identified by the external node to the corresponding tag belonging to the selected Oracle FLEXCUBE node. You can enter a brief description of the external node in the adjacent field. External Node Counter Multiple occurrences of the same ‘External Node’ for a network and format type combination are tracked by means of an external tag counter. This is required if a single external tag has to hold multiple columns of data when mapped to the corresponding Oracle FLEXCUBE tag. 2-37 The following example will illustrate this concept: In the Oracle FLEXCUBE node ‘Cust_Add’, the following child tags represent the address details: Add1 Add2 Add3 Add4 The value for each tag is required to upload or handoff the complete customer address details. The External Node ‘211’ consists of maintenance required for customer address details. It consists of a single tag ‘Address’. In order for the external system tag ‘Address’ to hold multiple columns of data (from the corresponding Oracle FLEXCUBE tags Add1, Add2, Add3 and Add4), you need to map ‘Address’ with each of the Oracle FLEXCUBE tags. Add1 Address Add2 Add3 Add4 To achieve this, you need to create a new record in the Clearing Msg Type/Group Details Maintenance for each mapping, for the same combination of: Clearing Network, External Node, Oracle FLEXCUBE Node, and Format Type The external node counter will track each occurrence of the above combination. The count starts from one and gets incremented by one for every new record. The Format Sequence Number will also get incremented by one for the same combination of Clearing Network, Format Type and Oracle FLEXCUBE Node. IS Optional On occasion you may need to send additional payment information with an ACH payment by using extended record formats called addenda. Addenda may include payment related information such as Customer Addresses or Reject Codes. While maintaining Clearing Message Group/Type maintenance record for addenda you can indicate whether the record is optional or mandatory. Check the option box to indicate that the format you are maintained is an optional one. Leave the box unchecked to indicate that it is a mandatory record. Length check required You have the option to indicate whether you want to calculate the length of each line in the file. If you specify that line check is required, you can maintain line attributes such as start position and length for the clearing message group in the ‘Clearing Msg Group Maintenance’ screen explained later in this manual. Date and Time Format For date related fields, you need to identify the format in which the date value will be sent from and received into Oracle FLEXCUBE. By default, Oracle FLEXCUBE sends all date fields in ‘RRRRMMDD’ format. 2-38 Similarly, for time related fields you have to identify the format in which the time value is to be sent from and received into Oracle FLEXCUBE. For instance, you can maintain a format like HHMMSS. This format will continue to apply for the entire line of the message format. Value Translation For each Oracle FLEXCUBE Node and External Tag combination, you have to indicate whether translations should be performed for all tag values associated with the tag names. A value translation is required only if the values sent by Oracle FLEXCUBE do not match with the external system specifications and vice versa. Example Assume that Oracle FLEXCUBE recognizes only USD (for US Dollars). The external system requires the value of US dollars as Dollar. When you upload into Oracle FLEXCUBE, if the value of the tag ‘CCY’ is Dollar, it gets translated to USD. Likewise, during handoff, USD gets translated to Dollar. However, it takes place only if translation is set for the external system and Oracle FLEXCUBE tag combination. 2.1.10 Mapping sub-nodes with the corresponding nodes in the External System As part of the format maintenance, you need to ensure that each child tag defined in the External Node corresponds to a pre-defined tag in Oracle FLEXCUBE. Step I After capturing the name of the ‘External Tag’ of the clearing network, identify the corresponding ‘Oracle FLEXCUBE Node’. Step II After you select the Oracle FLEXCUBE node, the sub-nodes/child nodes (also called child tags) linked to the selected node will be displayed in the drop-down list available for the ‘Oracle FLEXCUBE Tags’. You can key in the appropriate external sub-node (belonging to the External Node specified earlier) and map it to the corresponding Oracle FLEXCUBE sub-node/tag. Example Assume that the External Node is ‘10’ and consists of the following tags: RECORD CODE CONTRACT_NUM BRANCH CUSTOMER The corresponding Oracle FLEXCUBE node is PAYMENTS_COLLECTIONS and the following are the Oracle FLEXCUBE tags that belong to it: CONTRACT_REF_NO BRANCH_OF_INPUT CUSTNO CPTY_NO CUST_AC_NO Therefore, you need to maintain the following mappings: CONTRACT_NUM - CONTRACT_REF_NO BRANCH - BRANCH_OF_INPUT CUSTOMER - CUSTNO 2-39 If for an external tag, there is no corresponding Oracle FLEXCUBE tag, you can use the derivation logic to obtain a value for such tags, if required. Indicating whether data pertaining to a specific tag should be made Mandatory You have the option of specifying whether the data pertaining to a specific information tag should necessarily be made available in the incoming/outgoing message. Check the box available under the column head titled Mandatory. Specifying the Default Value You can associate a default value with each information tag. While uploading or handing off messages suppose an information tag within the incoming/outgoing message does not have a value associated with it, the system automatically appends the default value with the particular information tag only if the translation type is set up for it. Translation details for the specific Oracle FLEXCUBE and external tag combinations If you have indicated that ‘Value Translation’ is required for all Oracle FLEXCUBE and external tag combinations, this specification will be defaulted to all the tag mappings within the Oracle FLEXCUBE and external node combination. However, you have the option of changing this for individual tag mappings by choosing the appropriate translation option from the available list. The seven options available are: 1. No Translation 2. Translation, null return error 3. Null returns default, else no translation 4. Null returns default, else no translation 5. Null returns Null, else translation 6. Derivation 7. System Elements 8. Temporary Data In case of choosing derivation, the derivation has to be selected from the drop down. In case of choosing system elements, the element from drop down system element has to be selected. Let us assume, that you are maintaining the translation details for an information tag called CCY (currency). The value of this tag in Oracle FLEXCUBE is USD. But the external system uses Dollar for the same. 2-40 In the ‘Translation Values’ screen, the information that you capture will look as follows: Oracle FLEXCUBE Value External Value USD Dollar The example given below illustrates the manner in which the system will behave when you choose any one of the Translation options: Example We have specified the following parameters for the External Tag named CCY (currency). The Translation Value for: Oracle FLEXCUBE – USD External System - Dollar The Default Value is GBP, which is the local currency. Case I If you select the option No Translation, the system will not perform any translation. As a result, if the message involves the tag ‘CCY’ with value USD, both the incoming and the outgoing messages will retain the value USD. Case II If you select the option: Translate, null returns error Condition The tag value will be translated based on your maintenance in the ‘Translation’ screen. If you fail to send the corresponding value to the system (i.e. if the value of the tag is null), an error message will be displayed informing you of the same. Suppose you had failed to associate a corresponding Oracle FLEXCUBE value (USD) for the External Value (Dollar) in the ‘Translation’ screen, the system would have displayed an error message informing you of the same. You would have been allowed to maintain the record only after having maintained the corresponding translation value. Case III If you select the option: Null returns default, else no translation. Condition If the tag value is null, the system will not translate it. However, the default value associated with the tag will be used. Result As stated earlier the Tag Value associated with the external system is Dollar and the corresponding tag value in Oracle FLEXCUBE is USD. Let us assume that the Tag Value associated with the Tag Name ‘CCY’ is Null. In such a case, the system will use the default value GBP. Case IV If you select the option: Null returns default, else translate. 2-41 Condition If the tag value is null the default value associated with the tag will be used else the value will be translated based on your maintenance in the ‘Translation’ screen. Result If the tag value in the external tag is ‘Dollar’, during upload, the system will translate this value to USD. Similarly, or hand-off, USD will get translated to Dollar. If the Tag Value is Null, the default value GBP will be used. Case V If you select the option: Null returns Null, else translate Condition If the tag value is Null, the Tag Value will be retained as Null. If the value is present, it will be translated. Result Since the Tag Value is Dollar, it will be translated to USD for upload. For hand-off, the tag value will be translated to Dollar. Suppose the Tag Value is Null, it will be retained as null. Case VI If you select the option: Derivation Logic To recall, you use a derivation logic if for an external tag, there is no corresponding tag in Oracle FLEXCUBE. The logic is identified by a unique UDF (User Defined Field). You will need to map the name of the corresponding UDF, to the external tag. During handoff, the system will associate the value obtained from the derivation logic maintained for the associated UDF. Case VII If you select the option System Element The external tag will inherit the value of the system element to which it is mapped. Data Type In addition to mapping the Oracle FLEXCUBE tags with the external tags, you should also specify the type of data for each tag. The Data Type indicates the nature of the data – whether it is numeric or a character format. The following options are available: CHAR. NUMBER DATE, and TIME Start Position and Data Length To differentiate the data of one tag from another, you will need to indicate the position from where a particular tag begins. The length of the data within the tag should also be captured. 2-42 For instance let us assume that you have specified the following details: Tag 1 Start Position – 1 Data Length – 10 Tag 2 Start Position – 11 Data Length - 10 As a result, while processing data, the system will identify the first 10 characters as Tag 1 and the next 10 characters (11 to 20) for Tag 2. Derive Type For an external tag, if you choose the translation option as ‘Derivation Logic’ you have to map it to the corresponding UDF name. You would have already maintained the UDF in the ‘Derived UDF Maintenance’ screen. The external tag will get the value based on the logic that you have maintained for the selected UDF. All the UDFs that you maintain in Oracle FLEXCUBE will be available in the drop-down list. You can select the appropriate one from the list. System Elements If you need to hand-off the system (Oracle FLEXCUBE) derived values, you have to select the translation option System Element. Further, you are also required to map the external tag with a system element. The set of system elements are available in the drop-down menu. You can select the appropriate element to map to the external tag. For instance, the clearing network may want you to hand-off transactions that were entered in Oracle FLEXCUBE on a specific calendar date (System Date - the current date as shown in your machine). The Oracle FLEXCUBE date may be different from the current system date. Therefore, you will need to map the external tag say ‘Date’ to the system element – SYSDATE. The hand-off file will contain the actual date of the transactions. 2.1.11 Maintaining Transaction Group Transaction types having common attributes should be grouped together into Clearing Message Groups for ease of processing. For each clearing message group that you maintain you will need to define a set of uniquely identifying specifications. These specifications will determine the parameters for the manner in which contracts (also referred to as records) are arranged within ASCII files. Invoke the ‘Transaction Group Maintenance’ screen from the Application Browser to group transaction types into clearing message groups. You can invoke the ‘Transaction Group Maintenance’ screen by typing ‘IFDTXNGR’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. 2-43 Indicating the Network ID In the ‘Clearing Networks’ screen, you can maintain the networks (such as INTERPAY and HLAYOUT) through which you communicate with other banks and financial institutions for local currency funds transfers. You can identify the Network ID for which you are grouping transaction types. When you select the relevant Network ID from the available option list, the associated description will be defaulted to the adjacent field. Identifying the Clearing Message Group You will have to uniquely identify each clearing message group that you define with an appropriate name. Additionally, you can also specify a brief description to identify the group. Specifying the Key Start Position and Key Length The ASCII file consists of multiple lines of messages. A unique ‘key’ identifies each line of data within a message. You have to indicate the start position of the key and the length of the key. This will help you in identifying the key in the message, and subsequently in deciphering the data that follows. The key actually denotes an External Node. The values that appear after the key are assigned to the external tags, as per the format maintained for that external node in the Clearing Message Type/Group Details Maintenance screen. Consider the sample shown below: Here, ‘210’, ‘211’, ‘212’, and ‘213’ are the keys (or external nodes). Each key is used to identify the line of data that follows. The external tag values will be picked up from the data as per the specifications in the ‘Clearing Message Type’/’Group Details Maintenance’ screen. 2-44 Identify the Record Separator The details of each contract are displayed as separate records within an ASCII file. To differentiate the details of one contract (record) from another within the file, you will need to identify the key (external node) that would be used to indicate the beginning of a new record within the ASCII file. For instance let us assume that you have specified the following details: Key Start Position – 1 Key Length – 3 Record Separator - 210 Consequently, while processing data the system will differentiate between one record and the next only after verifying whether the first three characters of the record is three characters in length and is 210. Given below is a sample of how record separators are used to distinguish between details of one contract and another. Going by our example, in the sample shown above, the details from line 1 to line 10 are construed to be details of a single record or contract. The details available from line 11 to 21 will be treated as a second record/contract and so on. Specifying the Masks and other attributes of the File The File Mask is the nomenclature in which the external system names the ASCII file. You will need to capture the corresponding Process File Mask, which is the format in which you have named the file in Oracle FLEXCUBE. Example File Mask: BETOPD04 Process File Mask: BETOPD%d%t### (d is the date, t denotes the time and ### indicates a running serial number) 2-45 If you check the ‘Use Process File Mask’ box, the external system will name the ASCII file based on the file mask specified for Oracle FLEXCUBE. File Extension In addition to specifying the file masks you have to indicate the manner in which each file is to be stored. Typically, you can store these files with a ‘btc’ extension. However, you have the choice of specifying any extension you wish to generate these files in. File Path The file path is the directory or area in your system where the ASCII files are to be stored. Field Separator You have the option of using delimiters to separate data within a file. The options available are: $ S – indicating that a space needs to be used as a delimiter. S T – indicating that a tab needs to be used as a delimiter. Alternatively, you can also choose to have a comma, a semi-colon, a hyphen etc. Clearing Message Type Separator To recall, in this screen you are grouping clearing transaction/message types which share similar attributes. You have the option of differentiating messages within a group with delimiters. Session Timeout The session timeout is the maximum time limit that Oracle FLEXCUBE will wait for a response to a request sent to the external system. You can indicate in terms of minutes, the time within which an outgoing file should be processed by the External System and sent back to Oracle FLEXCUBE. Each time the external system fails to send a response to a request sent by Oracle FLEXCUBE, within the maximum time limit maintained, Oracle FLEXCUBE will recreate the message and send it to the external system again. You can maintain a count for the number of times a message can be resent. Resend Count An outgoing message can be resent any number of times. You have to indicate the resend count in this field. As a result, all messages for the given Network ID and Clearing Message Group combination can be resent only the specified number of times. For instance, you have indicated 3 as the resend count. A specific message has failed to parse through all three times. Since the resend count has been busted you will not be able to send the message one more time. The message will be logged as an error message. Click ‘Handoff’ tab to invoke the following screen 2-46 Specifying the Handoff Parameters Since a single hand-off file can have multiple batches you can indicate the number of batches that should be sent in a single file. Similarly, you have to indicate the number of transactions/messages types, which should be sent within a batch. Additionally, you can also specify manner in which message/transaction types are to be sorted. The options available are: 1. By Clearing Message Type 2. By Account Number If you select the second option, the transactions/messages will be sorted by the Account Number involved in the transaction. Else, the sorting will be based on the transactions themselves. For instance, assume there are 12 transactions within a file. Out of these 12 transactions four involve the same account number and the other eight involve a different account number. For the given Clearing Group you have indicated that messages should be sorted as per the Account Number. As a result the details of eight messages involving the same account will be listed first and the details of the other four messages will be listed subsequently. Restricting specific Clearing Transaction Type from a group A list of all the transaction types you have maintained in the system are displayed in the Available column. For each Clearing Group that you define you can choose to restrict or allow specific transaction types in the form of allowed or disallowed lists. Indicating the Process Direction and the related attributes A Message Group can be defined to group transaction types maintained for the upload of messages into Oracle FLEXCUBE (Incoming) or for the hand-off of messages from Oracle FLEXCUBE (Outgoing). You have to indicate the process direction of the message group. You will need to specify the process attributes depending upon the process direction that you specify. Click ‘Incoming Attributes’ tab to invoke the following screen: 2-47 Outgoing attributes: If you are maintaining the details of an outgoing message group you have to specify the attributes of the batch hand-off file that is sent. These include: Include/Reject – indicates whether the details of the rejected contracts need to be part of the outgoing file. Block Enabled – indicates whether the outgoing file needs to be block enabled. Line Length – indicate the length of a line within a block. Block Filler – specifies the identifier, which should be used to identify the block. Block Factor - specifies the factor by which the line length should be multiplied. This in turn will provide the total number of characters in the block. Incoming attributes: Automatic Auth – if enabled indicates that the incoming file should be automatically authorized upon receipt. Transaction Basis – specifies the basis on which transactions are grouped in an incoming file. The options available are: Record Based Batch Based If the records are batch based you have to capture the Batch Key Start position and the Batch Key Length to uniquely identify the batch. Length Attributes Length Check Required If you have opted for this facility in ‘Clearing Message Type’ screen and also check this box here, the system will calculate the length of the particular line and subsequently writes the calculated value from the length starting position maintained for the particular message group. Starting Position This field indicates the position from which the calculated value has to be written into. Length 2-48 This indicates the length for the line. Example: Let us assume that the length of the transaction line is about 300. The line attributes indicated are: Start position - 6 Length of position – 5 The calculated value will be 300 and positions 6 to 10 will denote the length of the line. Oracle FLEXCUBE automatically writes the calculated value from position 6 to 10 as 00300. Click ‘Clearing Msg Type Allowed’ tab invoke the following screen: 2.1.12 Viewing Transaction Group Details You can view the transaction group details using ‘Transaction Group Summary’ screen. You can invoke the ‘Transaction Group Maintenance’ screen by typing ‘IFDTXNGR’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. 2-49 In the above screen, you can base your queries on any or all of the following parameters and fetch records: Authorization Status Record Status Network Id Clearing Message Group File Mask File Extension Select any or all of the above parameters for a query and click ‘Search’ button. The records meeting the selected criteria are displayed. Authorization Status Record Status Network Id Clearing Message Group File Mask File Extension 2.2 Outgoing Clearing Upload For the actual message hand-off, you have to manually trigger the event from Oracle FLEXCUBE. You also need to specify the network and the clearing message group for which the hand-off file has to be created. This file (in ASCII format) is eventually handed-off by Oracle FLEXCUBE. 2-50 You can trigger the message hand-off event through the ‘Outgoing Clearing Upload’ screen invoked from the Application Browser. You can invoke the ‘Outgoing Clearing Upload’ screen by typing ‘IFDHFDET’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. For message hand-off, you need to select the network and the clearing message group as mandatory information. Additionally, you can also specify one or all of the following options for hand-off: Single Branch – if you want to hand-off messages from a specific branch for the selected network and message group combination. You can select the branch from the option-list available. Single Customer – if you want to hand-off transactions for a specific customer, for the selected network and message group combination, choose the name of the customer from the option-list provided. Transactions involving all the accounts of the selected customer will be handed-off. Single Account – select this option if you want to hand-off transactions involving a specific customer account, for the selected network and message group combination. You can select the account from the option-list provided. Single Contract – will hand-off details of a specific contract. If you select only the network and message group, the system will hand-off all the contracts (irrespective of the branches, customers, and accounts involved) for the selected combination. For hand-off, you should also specify the following: File Path You can also specify the path for storing the hand-off file. When you trigger the process, the hand-off file will be picked up from the path you specify here. If you do not specify a path, the file will be picked up from the path specified for the selected message group. At the time of implementation of Oracle FLEXCUBE, the implementer will create the following five folders in the file path that you specify in the Handoff of ‘Clearing Details’ screen (if not specified, the folders will be created in the path maintained for selected message group): 2-51 in folder out folder wip folder (work in progress) fccarea folder (for Internal logging) debug folder Handoff Grouping You also have the option of grouping the transactions within the hand-off file. The following options are available for grouping: By Clearing Message Type – if you select this option, the transactions will be grouped as batches of different clearing message types that are allowed for the selected clearing message group. By Account Type – this option will do the grouping based on the customer accounts involved in the transactions. All contracts involving a specific customer account will be grouped under a single batch file. After you trigger the hand-off process, the system will pick up the relevant tag values for all the transactions from the database table and display the contents of the hand-off file in the Outgoing Message Browser (‘Dispatch Outgoing Clearing Log Summary’ screen). The following details will also be available: Network – the name of the network to which the file is hand-off is triggered Transaction Group – the clearing message group for which the hand-off is taking place 2-52 File Name – The name of the hand-off file (in ASCII format) Amount Total – the sum total of the amount involved in all the transactions that are handed off Account Total – the sum total of all the accounts in the transactions. The account number is a numeric value. The system will add the account numbers involved in each transaction to display this value. On confirmation (click the ‘Ok’ button) of the details displayed in the ‘Dispatch’ screen, the upload file gets created in the path specified. The system will then move the file from the ‘wip area’ to the ‘out’ folder. Prior to moving the file, it will retain a copy of the hand-off file in the ‘fcc’- area as backup. This marks the successful completion of the hand-off process. At this stage if you want to cancel the hand-off process, click on ’Exit’ or ‘Cancel’ button. 2.3 Incoming clearing upload Just like the hand-off process, the upload process too needs to be manually triggered from Oracle FLEXCUBE. You can trigger the message upload event through the Incoming ‘Incoming Clearing Upload’ screen invoked from the Application Browser. You can invoke the ‘Incoming Clearing Upload’ screen by typing ‘IFDINDET’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. In this screen, you need to identify the network and the message group for which the message needs to be uploaded. If you do not want to use the file path specified for the Message Group, you can enter a different path here. This path will take precedence over the one maintained for the Message Group. The three folders (mentioned earlier) will be created in the file path specified in this screen. After you trigger the upload process, the system will pick up the ASCII file from the ‘in’ folder and move it to the ‘wip’ area. It retains a copy of the file in the ‘fcc’ -area as backup. 2.3.1 Viewing the details of Files that were Handed-off 2-53 You can view the details of all files that were handed-off through the ‘Dispatch Incoming Clearing Log Summary’ screen. You can invoke this screen, click ‘View Log’ button in 'Incoming Clearing’ screen. You can either choose to view the details of files with a particular status or view the details of all files that were handed-off. The details of each file within a network will be displayed in a different color depending on its status. For instance, a file with errors will be displayed in red. The system displays the following details: Contract Reference Number Product Code customer No Account Number Account Branch Foreign Ccy Amount Transaction Amount Exchange Rate Account Number Name Customer Account LCF Network Transaction Group File Name Total Amount 2-54 Account Total 2.3.2 Ignoring Clearing Log Details After you trigger the hand-off process, the system will pick up the relevant tag values for all the transactions from the database table and display the contents of the hand-off file in the Outgoing Message Browser. To invoke the ‘Ignore Clearing Log’ screen, type ‘IFSIGCLG’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button. The system displays the following details: Network – the name of the network to which the file is hand-off is triggered Transaction Group – the clearing message group for which the hand-off is taking place File Name – the name of the hand-off file (in ASCII format) Amount Total – the sum total of the amount involved in all the transactions that are handed off Account Total – the sum total of all the accounts in the transactions. The account number is a numeric value. The system will add the account numbers involved in each transaction to display this value. 2-55 2.4 Processing for the Interface The interface can either be Online or in a Batch format. For the online mode each contract in Oracle FLEXCUBE will be handed off as a separate file. 2.4.1 Incoming Message Processing While processing incoming messages, contracts are uploaded using the following process stages: You will initiate the process of uploading files. The system checks if any recovery operation is required. If required, it is handled first. The file name is logged into the log table before the contents of the file are processed. The file name can be used for recovery and reporting. After this, the entire file is read into memory in chunks. The key identifier for the message is derived from the position and the number of characters maintained at the file level. For the Identifier thus derived, the subsequent details are picked from the message maintenance. Next, the system processes each line and populates it into a row type. Whenever the beginning of a new contract is found, the system inserts the row type into the corresponding table with a particular flag. This process goes on till the end of file is reached. The following totals will be kept for each file (driven by a flag) Total for Debits Total for Credits Total for Accounts Total of Amounts No of Records in the Message After processing all the records, the file is moved into the ‘fcc’-area. All the status for the contracts uploaded will be changed for booking and these data are processed using a batch function. 2.4.2 Outgoing Message Processing While processing outgoing messages, the following stages are involved in the creation of Clearing files: You will have to specify the File / Clearing Message Type that needs to be created On initiation, the system first checks if there is any recovery operation is required. If required, it is handled first. For the given clearing message type, all products for which the file needs to be created will be picked up from the Product Mapping- Clearing Message Type maintenance. Since it is possible for the file to have a batch grouped on an account too, the system will pick up the corresponding flag for the file. The system will select the relevant records from the Message Maintenance for a given message type. The file level attributes that are maintained will be picked up from File/Clearing Message Type. These are: File Name File Extension 2-56 File Path Session Timeout Number of Resends Number of Transactions in a file Number of Transaction in a Batch Contracts pertaining to each product selected from the Product Mapping- Clearing Message Type maintenance will be picked up for processing for the Clearing File. The sequence that is followed during the processing is: File Header Records (FH) Message Header Records (MH) Message Records (MR) Message Footer Records (MF) File Trailer Records (FF) The following batch totals are assumed for the trailer records: Total for Accounts Total of Amounts No of Records in the Message Each record is locked before the data in the record is processed. If the record is locked successfully, then the details of the record are passed on to the Business Rule layer to update the record to the dispatch status. Based on the flag passed from the Business layer, the message is formatted on the basis of the maintenance done. A preset number of contracts is processed and committed and written to the file based on the maintenance done. After all the contracts are processed the file is moved to the area specified in the maintenance. The above processes are also responsible for converting the data formats and tag formats from the Oracle FLEXCUBE standard format to the formats as required by the external systems. The above set of processes also translates the fields that require a translation as per the maintenance for the particular interface. 2-57 3. Screen Glossary 3.1 Function ID List The following table lists the function id and the function description of the screens covered as part of this User Manual. Function ID Function Description IFDTXNTY Clearing Msg Type IFSTXNTY Clearing Msg Type Summary IFDCLDUD Clearing Interface Derived UDF Summary IFDTXNDT Group Details Maintenance IFDTXNGR Transaction Group Maintenance IFDHFDET Outgoing Clearing Upload IFDINDET Incoming Clearing Upload IFSIGCLG Ignore Clearing Log 3-1 Clearing Interface [April]  V ersion 184.108.40.206.0EU Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com/ financial_services/ Copyright ©  Oracle Financial Services Software Limited. All rights reserved. No part of this work may be reproduced, stored in a retrieval system, adopted or transmitted in any form or by any means, electronic, mechanical, photographic, graphic, optic recording or otherwise, translated in any language or computer language, without the prior written permission of Oracle Financial Services Software Limited. Due care has been taken to make this document and accompanying software package as accurate as possible. However, Oracle Financial Services Software Limited makes no representation or warranties with respect to the contents hereof and shall not be responsible for any loss or damage caused to the user by the direct or indirect use of this document and the accompanying Software System. Furthermore, Oracle Financial Services Software Limited reserves the right to alter, modify or otherwise change in any manner the content hereof, without obligation of Oracle Financial Services Software Limited to notify any person of such revision or changes. All company and product names are trademarks of the respective companies with which they are associated.