KM client format supported by KB valid from 13 May 2015

Transcription

1 supported by KB valid from 13 May /16 VRSION 1.2. UPDATD:

2 1 Introduction Purpose of tis document Caracteristics of te KM format Formal ceck of KM format KM format - domestic payments XPORT - electronic statement KM format - electronic statement KM 78, 79 formats - electronic statement KM 76 format - VZP - electronic statement Introduction 1.1 Purpose of tis document Services provided by KB witin te framework of te application server (AS) and enabling operation wit batces in te KM format: Mojebanka Business Profibanka (providing also KM76 and KM78,79 mutations): Direct cannel Te purpose of tis document is to describe te KM format and required validations wen IMPORTING data and to define te procedure of XPORTING data in relation to accounting applications of clients. Te above-mentioned IMPORT and XPORT concerns KB Direct banking services (DCS). Te description is divided into te following sections: Import xport format field declarations - domestic payments list of field validations - domestic payments format field declarations - foreign payments list of field validations - foreign payments format field declarations - electronic statements Tere are two types of detected errors: = error - tis will cause rejection W = warning - tis is merely a warning and will not cause rejection of te batc. Te client decides weter to keep te batc in processing (it is not applied in DC). 1.2 Caracteristics of te KM format Brief description of te KM format: Basic KM format includes: Domestic payment orders: main accounting data in domestic payment orders (payment and collection in CZK only). Te is variable and te format allows te entering of single and multiple POs. See te IMPORT KM capter for details. 2/16 VRSION 1.2. UPDATD:

3 lectronic statement: main accounting data and 20-caracter additional text in te electronic statement. See XPORT of KM for details. KM76 format (te export file format is modified - includes anoter type of record. It is a modification of te KM format) includes: Domestic payment orders: main accounting data in domestic payment orders (payment and collection in CZK). Te is variable and te format allows te entering of single and multiple POs. See te IMPORT KM capter for details. lectronic statement: main accounting data and 20-caracter additional text in te electronic statement. In addition, it as te 076 type of record and different date fields layout. See XPORT of KM76 for details. KM78, 79 format (a modification of te KM format - added AV field for exporting) includes: Domestic payment orders: main accounting data in domestic payment orders (payment and collection in CZK). Te is variable and te format allows te entering of single and multiple POs including te AV field (advice to te partner). See te IMPORT KM capter for details. lectronic statement: main accounting data and 20-caracter additional text in te electronic statement. Optional downloading of te partner s message (AV field) using new record types (078 and 079). See XPORT of KM78, 79 for details. Code page DC - requires windows-1250 Windows astern uropean (Windows CRLF line feed) PCB - requires windows-1250 Windows astern uropean (PCB line feed can be managed by bot CRLF (#13#10) and Unix LF (#10) or MAC CR (#13) MBB - requires windows-1250 Windows astern uropean (Windows CRLF line feed) 2 Formal ceck of KM format 2.1 KM format - domestic payments Te main structure of batces of payment orders Payments transferred via KM format may only be in CZK. Te constant symbol in KM allows you to enter only 4 positions since information on te bank code and priority is also transferred witin KM. Te sequence of processing in KB central system can be influenced by setting te Priority. It can be transferred at te 2nd position from te left in te Constant symbol. Te priority values are 0 to 9, were 0 to 2 are disabled system priorities not permitted for te client (if used, tey will be replaced by te standard value - 5). Te igest priority value available to clients is 3, te lowest is 9. By default, all batc-transferred payments are processed under priority 5. Data files start wit UHL1 and contain one or several accounting files. Note: Te file is identified by its number and can be transferred only once in a day. maximum size of data files a data file in te KM format may contain up to items if more payment orders sould be sent, tey must be divided into more data files recommended size of data files in spite of te fact tat accounting files may contains up to items, it is recommended to reac tis upper limit only in exceptional cases. It is recommended to send up to items in a single data file. Accounting files start wit HSO and end wit KSO. Tey contain one or several item groups. ac accounting file as its defined common data type (eiter sole collections or payments are in one accounting file). Item groups start wit HSK and end wit KSK. ac group contains one or more items. ac item group as a defined common due date and cecksum of amounts in te group. Tere are two forms of items: multiple payment order it as a pre-defined account in HSK 3/16 VRSION 1.2. UPDATD:

4 actual items ave only contra-accounts, amounts, VS, CS and optional SS single payment order it as no account in HSK (or te account is zero) te actual item as a contra-account, amount, VS, CS and optional SS Uniqueness of items witin a day is defined by: te date of creation in UHL1 + te number of te accounting file in HSO + te sequential number of te payment assigned to te payment according to its sequence position in te file during IMPORTing. unique identification will be extended to processed transactions and availability in XPORT will be secured (sss file number generated by te client and nnnn sequential number of an item added according to te sequence position during importing). Account numbers are in edit format (witout swapping positions) and consist of two parts: ante-number 0-6 caracters (optional) number 2-10 caracters separator - is allowed between te account number and ante-number te amount is given wit alers (wit te exception of weak currencies tat ave 00 in te last two positions), te sign is not specified - it is set by te data type ( payment, collection) Individual fields are separated by a separator - space Some fields are optional and may not be specified (e.g. Specific symbol) Lengt of fields is free, witin te specific minimum and maximum limit of cars set directly in te format. Individual rows end wit CRLF. Note: fields in a KM item are separated by a separator - space. Specific symbol and AV need not be specified; excess zeroes may but need not be added to numeric values. Records are ended wit CRLF. Spaces may be put between te last compulsory field of items and CRLF: In te KM format, it is not possible to transfer cancellation batces, Invalid Constant symbols according to ČNB order (for te latest list, see elp for Mojebanka and Profibanka) 0178 Guaranteed ceques 1178 Payment cards 2178 Ceques exceeding CZK Bank ceques awaiting clearance???9 Cas???3 Ceques in sort way???5 Cancellations 0006 non-existing account???1 execution??51 execution 0898 CHARGS 4/16 VRSION 1.2. UPDATD:

5 IMPORTing in te KM format UHL1 Data file eader HSO start of acc. file HSK item start of group group of items 1 1st accounting file Data file KSK end of group group of items n KSO end of acc. file 0 to n more accounting files KM format: UHL1 record - te first record in a file: Ser. no. Name min. max. List of content s offset link valida tion Note if te assumption is not valid, errors occur in validated fields 1. Type of 4 4 UHL1 0 UHL1 missing message 2. Creation date 6 6 ddmmy y 4 2 current date of creating data - DDMMYY te date as no relation to due dates of items in files 1. illegal date 2. te creation date is not te current date date (if validation of Creation date = current day is activated) 3. creation date can only be witin te range of -31 to +364 days, if te option of no validation of Creation date is cosen 3. Abbrev. client name aaaaaaa aaaaaaa aaaaaa 10 used by te client, not cecked 4. Client number nnnnnn 30 not used, ignored nnnn 5. Beginning of te range of acc. files 3 3 nnn 40 Range of acc. files - used to ceck acc. file eaders. Te beginning is defined by clients (form: ) 6. nd of te range of acc. files 3 3 nnn Range of acc. files - used to ceck acc. file eaders. Te end is defined by clients (form: ) not used, ignored 7. Fixed part of security 8. Private part of to security File sentinel 2 2 CRLF 46 to 58 not used, ignored 1. Te beginning of range of acc. files is not defined 1. Te end of range of acc. files is not defined error type 5/16 VRSION 1.2. UPDATD:

6 Comment 1: It is recommended to set te range of files to 1 to 999 since in electronic statements (GPC files), te file number is zero in case te transaction was not entered via input batc files via Mojebanka, Profibanka or DC. It is necessary to pair items on te side of te client accounting system. Accounting file: Input data of te data file is grouped into accounting files according to its nature. Te Data type item defines te data nature (collection x payment). HSO record - te eader of accounting files: Ser. no. Name min. max. List of content s offset Link Note if te assumption is not valid, errors occur in validated fields 1. Type of Te eader of an accounting message file is missing 2. Separator 1 1 space 1 3. Data type or =payments, Invalid data type =collections 4. Separator 1 1 space 6 5 Acc. file number 6 6 sssppp 7 sss must be witin te range of files in UHL1 te specified number may only be imported successfully once in te current date ppp is not validated 1. Te number is not witin te range defined in UHL1 2. Duplicate file number witin te date of creation 6. Separator 1 1 space Prefix bank Invalid bank code code 8. File sentinel 2 2 CRLF 18 KSO end - end of accounting files: Ser. no. Name min. max. List of contents offset Note if te assumption is not valid, errors occur in validated fields 1. Type of message Te end of an accounting file is missing 2. Separator 1 1 space 1 3. Plus sign Invalid KSO format 4. File sentinel 2 2 CRLF 3 Group of items: Accounting files are grouped into groups. ac group witin an accounting file is separated by a eader and end of te group. Te amount specified in te group eader must equal te sum total of individual items of te group. Te due date specified in te eader applies to te wole group. One accounting file may contain groups wit various due dates. Due dates must not be over; tey must not be more tan 364 days in advance. Te payer s account number will only be specified in te group eader in groups of multiple orders (ten it is not specified in actual orders). In groups of single orders, te Account number field can be skipped or filled wit zeroes. Te eader of a group of multiple orders consists of 4 fields. Te eader of a group of single orders consists of 3 fields. (if te account number is filled wit zeroes, ten 4 fields) HSK record - te eader of a group of items: Ser. no. Name min. max. List of content s offset link Note if te assumption is not valid, errors occur in validated fields 1. Type of message Te eader of te group of items is missing 2. Separator 1 1 space 2 3. Payer s 2 17 (nnnnn 3 11 te payer s account 6/16 VRSION 1.2. UPDATD: error type error type error type

7 account number n- nnnnnn nnnn)n n antenumber - number 4. Separator 1 1 space 5 to 20 5 Sum total of individual items 1 14 (nnnnnn nnnnnn nn)n 6 to Separator 1 1 space 7 to Due date 6 6 ddmmy 8 to y File sentinel 2 2 CRLF 14 to 42 number for a group of multiple orders only (it is no longer specified in items) Tis field is not available in groups of single orders or it is filled wit zeroes (n to 17n) initial excess zeroes may but need not be added to te number It may contain te - separator to separate te ante-number from te number. Bot elements may but need not contain initial zeroes; owever, tey must not contain spaces. a) Only one ypen can be used. b) Max. number of positions before te ypen is 6. c) Max. number of positions after te ypen is 10. d) Min. number of digits after te ypen is 2. See te Validations table. Te sum total in te group must equal tis value. 3 Due date - ddmmyy See te Validations table. Invalid account Te sum total in te group does not matc te value in te group eader. Invalid format of te due date in HSK KSK end - te end of a group of items: Ser. no. Name min. max. List of contents offset Note if te assumption is not valid, errors occur in validated fields 1. Type of message Te end of te group of items is missing 2. Separator 1 1 space 1 3. Plus sign Invalid KSK format 4. File sentinel 2 2 CRLF 3 error type Payment Imported files may contain single or multiple payment orders. Te type (collection/payment) is defined in te eader of accounting files; te type (single/multiple) is defined in groups of items. Due dates are also defined in groups of items. Single payment orders ave 5 to 7 fields: Debit account number, credit account number, amount, VS, CS, (SS), (AV). Multiple payment orders ave 4 to 6 fields: Credit account number for payments or debit acc. number for collections, amount, VS, CS, (SS), (AV). For detailed validations, see te Validation table in capter 3. Ser. no. Name min. max. List of content s offset link Note if te assumption is not valid, errors occur in validated fields error type 7/16 VRSION 1.2. UPDATD:

8 1. Debit account 2 17 (nnnnn number n- nnnnn nnnnn) nn antenumbe r - numbe r 2. Separator 1 1 space 2 to Credit account number 2 17 (nnnnn n- nnnnn nnnnn) nn antenumbe r - numbe r 4 to Separator 1 1 space 6 to 35 5 Amount 1 14 (nnnnn nnnnn nnnn)n 7 to Separator 1 1 space 8 to Variable 1 10 (nnnnn 9 to symbol nnnnn) 51 n 8. Separator 1 1 space 10 to Constant 8 10 (nnnnn 11 to symbol nnnnn) 62 nnnnn nnn 0 11 te payer s account number for an individual order only (unless it is specified in HSK). Tis field is not available for groups of multiple payments. initial excess zeroes may but need not be added to te number It may contain te - separator to separate te ante-number from te number. Bot elements may but need not contain initial zeroes. a) Only one ypen can be used. b) Max. number of positions before te ypen is 6. c) Max. number of positions after te ypen is 10. d) Min. number of digits after te ypen is 2. See te Validations table. 16 If te separator ( - ) is used, te ante-number and te number may but need not contain initial zeroes Te number will be converted to a 16-byte numeric field and cecked for te following: e) Only one ypen can be used. f) Max. number of positions before te ypen is 6. g) Max. number of positions after te ypen is 10. ) Min. number of digits after te ypen is 2. See te Validations table. 5 xcess zeroes may but need not be added. (owever, tey must not be replaced wit spaces) te amount must not be zero See te Validations table. 12 xcess zeroes may but need not be added. (However, tey must not be replaced wit spaces.) If VS is not used, zero will be used instead. 8, 15 xcess zeroes may but need not be added. (However, tey must not be replaced wit spaces.) Must not be 0. At least 8 positions are necessary, since Invalid account Invalid account Invalid amount VS missing Te beneficiary s bank code is missing CS is missing 8/16 VRSION 1.2. UPDATD:

9 10. Separator 1 1 space 11 to Specific 0 10 (nnnnn 12 to symbol nnnnn) 73 n 12 Separator 1 1 space 12 to AV field AV:AV 13 to 1 AV2 84 AV3 A V4 14. File sentinel 2 2 CRLF 13 to 230 File example: te rigt-and positions 5-8 represent te beneficiary s bank code. If te SS does not follow, te separator need not be used. 13 xcess zeroes may but need not be added. (However, tey must not be replaced wit spaces.) If te SS is not used, zero is used instead or te field is skipped. If te AV does not follow, te separator will not be used. A text comment tat can be attaced. It consists of 4 independent sub-fields of 35 cars eac, separated by symbol (ASCII 124) Te field starts wit AV: constant. If a part of a sub-field is used only, te rest need not be used. Invalid SS UHL ZKUSBNI KLINT AV:Payment for electricity - January. Invoice number 89aj Rules of detecting accounting fields according to te type of order (multiple/single): Number of validation (link) Te name in te format Te sequence of te field in records of te multiple order Te sequence of te field in simple order records Te rule used for validation 1 Date of code 2nd UHL1 field 2nd UHL1 field 1. valid date YYYYMMDD 2. equal to te current date 2 Acc. file number (sss) 3rd HSO field (positions 1-3) 3rd HSO field (positions 1-3) sss must be witin te range of files in UHL1 te specified number may only be imported successfully once in te current date remaining positions of tis field (4-6) - ppp - are not validated 3 Payment sequential number is generated during IMPORT accounting file number + code date + payment sequential number must be unique and is returned in te electronic statement in te Document number. 4 Due date te last HSK te last HSK 1. valid date YYYYMMDD 2. not older tan te current date 3. equal to te current date or up to days 4. must not be a oliday or calendar 9/16 VRSION 1.2. UPDATD:

10 day off 5 Amount of payment 2nd Payment field 3rd Payment field 1. numeric 2. not zero 6 Data type 2nd HSO field 2nd HSO field If 1501 ten = payment; if 1502 ten = collection 7 Constant symbol 4t Payment field 5t Payment field Positions 7-10 (from te left) must not contain invalid CS. (see te information below te table for details) 8 AV field 5t or 6t Payment field (depends on existence of SS) 6t or 7t Payment field (depends on existence of SS) Not validated; it is transferred for processing only in services offering te KM78,79 formats. 9 Prefix bank code Te last HSO field Te last HSO field Payer s account number 2nd HSK field 1st Payment field for payment 2nd Payment field for collection 1. numeric 2. modulo is not 0 4. access rigts 5. must not be equal to te contraaccount, if it is witin KB 6. Account status must be A (active); te type of account must be CK (current) or TD (term) 11 Variable symbol 3rd Payment field 4t Payment field must be numeric 12 Specific symbol (optional 5t Payment field 6t Payment field must be numeric field) 13 Contra-account bank code 4t Payment field 5t Payment field Included in te library of banks 14 Contra-account number 1st Payment field 2nd Payment field for payment 1st Payment field for collection 1. numeric 2. modulo is not XPORT - electronic statement xport is a form of electronic bank statement. Te electronic statement contains: one turnover record for an account and processing day; it includes te number of te statement, wic is derived from numbering of daily statements upon movement from 2nd January 2002 (numbering is performed witin te given year and will be set to zero at te turn of te year). N transactions related to te specific account and processing day. Transactions in a statement are sorted by processing sequential numbers assigned during processing in te central system. Is sorted by te Processing date, Type of record and Transaction serial number assigned during processing in te central system. very transaction entered by IMPORT from a batc includes an identification entered by te client too. In te KM format, tis is represented by te file number transferred to te input file (sss) and sequential number assigned during IMPORTing according to te order of te payment in te file (nnnnn). Tis identification is returned to te client in te KM format in te Document number (positions sss 40-42, nnnn 43-48, aligned to te rigt wit initial zeroes). Te identification will only be returned if input consistency is maintained (te same format for bot IMPORT and XPORT). Oterwise, sss=000 and nnnn=sequential number assigned during processing in te KB central system will be used in tese positions. Te constant symbol in KM allows you to enter only 4 positions since information on te bank code is also transferred witin KM. Terefore, you will receive te 4 last caracters of CS defined as compulsory by ÈNB for some types of payments witin te framework of GPC. 10/16 VRSION 1.2. UPDATD:

11 lectronic statements = XPORT can be created for every type of account (CK, SV, TD, PL, BL, CL and RL). Several processing days and several accounts can be marked and compression into a single file specified. In suc a case, data are sequenced as follows: Processing date 1 Account 1 Account 2 Account n Processing date 2 Account 1 Account 2 Account n Processing date n Account 1 Account 2 Account n 2.3 KM format - electronic statement GPC file of fixed, of te following structure: account numbers are in te internal format, were: dit format N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 internal format N1 6 N14 N15 N12 N7 N8 N9 N10 N11 N13 N1 N2 N3 N4 N5 N6 Te recipient of te medium can verify te KM content by, for example, performing te following cecksums for individual records of te "75" type: NB = OB - DT + CT, DT = sum of AMO wit AC=1 or 4 (for AC=1 +, AC=4 -), 11/16 VRSION 1.2. UPDATD:

12 CT = sum of AMO wit AC=2 or 5 (for AC=2 +, AC=5 -), were: NB - new balance, OB - old balance, DT - debit turnovers, CT - credit turnovers, AMO - records of te type of "turnover entry in CZK" AC - accounting code. 1 - debit entry, 2 - credit entry, 4 - debit entry cancellation (redebit), 5 - credit entry cancellation (recredit). XPORTing in te KM format Balances: record 074 transaction 1 record 075 statement of account 1 0 to n transactions for te particular account and processing day transaction n 1st day Data file statement of oter accounts 0 - n 0 to n more days Turnover record = record 74 Ser Te name in te Len Positio Type of constant. format gt n field 1. Record type Constant Client s account number N(16) 16-caracter numeric field wit account number in te internal format 3. Abbrev. client s account A(20) name 4. Date of te old balance ddmmyy ddmmyy format 5. Old balance N(14) New balance - credit turnovers + debit turnovers 6. Sign of te old balance Constant previous field > 0 = + < 0 = - 7. New balance N(14) Current balance after nigt processing in te KB central system 8. Sign of te new balance Constant previous field > 0 = + < 0 = - 9. Debit turnovers N(14) Debit transactions - Debit cancellation transactions 10. Sign of debit turnovers Constant previous field > 0 = 0 < 0 = Credit turnovers N(14) Credit transactions - Credit cancellation transactions 12. Sign of credit turnovers Constant previous field > 0 = 0 12/16 VRSION 1.2. UPDATD:

13 13. Statement serial number Accounting date IBAN (te part before te actual account) DCS cannel identification Filler nd field NNN ddmmyy Constant < 0 = - serial number of te statement upon movement since te beginning of te year Date of accounting (= Processing date) in te KB central system. ddmmyy format country code, modulo97, bank code If generated in PCB= PB, in DC= DC, in MB= MB Spaces CRLF Transaction record = 75 Ser Te name in te Lengt Type Position constant. format of field 1. Record type 3 Constant Client s account number 16 N(16) caracter numeric field wit account number in te internal format 3. Contra-account number 16 N(16) caracter numeric field wit account number in te internal format 4. Document number (part 1) 4 NNNN nter date in te mmdd format 5. Document number (part 2) 3 Constant for orders not entered in a batc by te client 5. Document number (part 2) 3 NNN te sss value entered in te imported KM for orders entered in a batc by te client as KM - file number 6. Document number (part 3) for orders not entered in a batc by te client - DI number 6 NNNNN N nnnnnn - serial number assigned during processing in te central accounting system 6. Document number (part 3) for orders entered by te client as KM - assigned sequential number during IMPORT 6 NNNNN N nnnnn sequential number generated during IMPORT of te particular KM file 8. Amount 12 N(12) amount of payment in alers (two imaginary decimal positions) 9. Accounting code 1 N =debit,2=credit,4=debit cancellation,5= credit cancellation 10. Variable symbol 10 N(10) Constant symbol 10 N(10) Bank code 4 N(4) in Constant symbol, in positions 3-6 from te left 13. Specific symbol 10 N(10) Value Date 6 ddmmyy If te Value Date = Accounting Date (record 74), ten te value is , oterwise it contains real Due Date (= Value date), te DDMMYY format 15. More information 20 A(20) Beneficiary s name or additional data of te bank. 16. Code of item cange 1 Constant always Data type 4 NNNN r=1 for CZK, 2 for foreign currency m=0 if not entered electronically, 5 if processed in a batc, 7 if it came via clearing; oo=02 if collection, oo=01 for payment 18. Deduction date 6 ddmmyy Deduction date (= Cleared date) related for: Incoming payments from partner s account in KB or OB Outgoing payments from client s account in KB 19. nd field CRLF File example: KLINT TST /16 VRSION 1.2. UPDATD:

14 ADAMOVSK STROJIRNY KM 78, 79 formats - electronic statement A GPC file were two oter types of records - 78 and 79 - are joined freely. Te contents of te AV field can be downloaded in tese records. Te file structure is tus standard: per 1 account and 1 day, 1 turnover record and n item records: turnover record = 74 item record = 75 item record = 78 (if te AV field is filled in, one of te first two rows) item record = 79 (if te AV field is filled in, one of te second two rows) XPORTing in te KM 78,79 format Balances: record 074 transaction 1 record 075 record 078 record to n transactions for te particular account and processing day transaction n statement of account 1 1st day Data file statement of oter accounts 0 - n 0 to n more days Note: rows 078 and 079 are filled in only in case te transaction contains a text in te AV field 074 record - identical wit te one in KM 075 record - identical wit te one in KM 078 record created only if te first 70 bytes of te AV field from te left are oter tan spaces Se Te name in te Lengt Type of Position constant r. format field 1. Record type 3 Constant AV1-2 field 2x35 A(70) 4-73 AV field (te first 70 caracters) 3. CRLF CRLF 079 record created only if te second 70 bytes of te AV field from te left are oter tan spaces S Te name in te Position Constant er. format 1. Record type 3 Constant AV3-4 field 2x35 A(70) 4-73 AV field (te last 70 caracters) 3. CRLF CRLF 14/16 VRSION 1.2. UPDATD:

15 File example: KLINT TST ADAMOVSK STROJIRNY Payment for electricity for January.Invoice numb 89aj KM 76 format - VZP - electronic statement GPC file of fixed for VZP, of te following structure: XPORTing in te KM 76 format Balances: record 074 transaction 1 record 075 record 076 statement of account 1 0 to n transactions for te particular account and processing day transaction n 1st day Data file statement of oter accounts 0 - n 0 to n more days Te following differences can be found in te 074 record account numbers are in te edit format Te following differences can be found in te 075 record: account numbers are in te edit format Value is always Data type is always 0203 Deduction date contains Value_dt (i.e. due date of te payment) VZP record = record 76 Se Te name in te Lengt Type of constant r. format field 1. Record type 3 Constant Filler 26 spaces 3. Deduction date 6 ddmmyy date of deduction of te amount in anoter financial institution, te DDMMYY format 15/16 VRSION 1.2. UPDATD:

16 4. Comment 93 A(93) AV field (te first 93 caracters) 5. CRLF 2 File example: KLINT TST ADAMOVSK STROJIRNY /16 VRSION 1.2. UPDATD: