Dear Joey, thanks for replying.
Dear Bhart, it has just came to my mind that the HBCI specification (German homebanking standard) in appendix VIII.9 also contains a short description of the DTAUS format. Fortunately, the HBCI standard is avaibable in English also (they are also lagging behind with the translation but this will not affect at all the quite old DTAUS format). You can find HBCI documents via http://hbci.bankverlag.de (this will require a user password and a login but this seems purely formal data grabbing, just register an account, then click on standard and download e_hbci201_d.doc).
The following extract is from that document (appendix VIII.9 also contains DTAZV and other formats which may be interesting to you), the formatting in the attached text may sometimes seem ugly, see the above-mentioned original for more details.
Hope this is still useful, please keep us informed what you are doing,
regards, Holger
============================
DTAUS Format
Character code
The following are approved:
? the numeric characters 0 to 9 (X'30' - X'39')
? the capital letters A - Z (X'41' - X'5A')
? the special characters:
Space ``~Z`` = X'20'
Full stop ``.'' = X'2E'
Comma ``,'' = X'2C'
Ampersand'' ``&'' = X'26'
Hyphen ``-`` = X'2D'
Plus sign ``+'' = X'2B'
Asterisk ``*'' = X'2A'
Percent sign ``%'' = X'25'
Oblique stroke ``/'' = X'2F'
Dollar sign ``$'' = X'24'
? as well as the umlauts Ae, Oe, Ue and the ss. For these the codings
codes ``Ae'' = X'5B', ``Oe'' = X'5C', ``Ue'' = X'5D', ``ss'' = X'7E'
apply.
The banks accept no liability for the correct printing of characters
deviating from the above.
The bank can convert lower-case letters in data records into upper-case
letters or return these data records to the presenter; it can convert
non-permitted special characters to blanks.
File structure
The logical file is to be structured as follows:
Record A = File header
Record C = Payment exchange record
Record E = File trailer
A logical file may contain only credits or only direct debits.
Record A (File header)
Record A contains the sender and receiver of the file, and exists only
once in each logical file. Record A is 128 bytes long.
Field Length in bytes DataformatData format Contents Explanation
1 4 numeric Record length `0128'
2 1 alpha Record type Constant "A"
3 2 alpha Identifier "GK" or "LK", ``GB'' bzw. ``LB'' Reference to
credits (=G) or debits (=L); (K=Customer fileiskette), Bankdatei (=B)
4 8 numeric Bank sort code Bank sort code of bank (File receiver)
5 8 numeric X'30' -
6 27 alpha Customer name Sender of file
7 6 numeric Date Date file created (DDMMYY)
8 4 ------ X'20'
9 10 numeric Account number Receiver/sender Customer, max 10 digits.
The countervalue is invoiced via this account.
10 10 numeric Reference number of payer Statement optional
11a 1548 alpha- X'20' Reserve (Abgrenzung des Satzabschnitts)
11b 8 alpha Execution date (DDMMYYYY) Statement optional. Niot earlier
than file creation date (Field A7), but at most 15 calendar days more
than creation date from Field A7. If an execution date is given in this
data field, it must be made certain that the time period of at least 10
calendar days for furnishing of documents named in the Special
Conditions is not to be calculated until after the named execution date.
11c 24 alpha X'20' Reserve
12 1 alpha Currency code X'20' = DM
1 = Euro (permissible from the start of stage 3 of the ECMU)
128
Record C (Payment exchange record)
Record C contains details of the orders to be executed (credits or
debits). It divides them into a constant and a variable part
1. Constant part, 1st record section
Field Length in bytes DataformatData format Content Explanation
1 4 numeric Record length Die SatzlÄngenangabe bezieht sich mit Ausnahme
des konstanten Teils nicht auf die SektorenlÄnge der Disketten, sondern
auf die logische SatzlÄnge (Constant part 187 bytes + extension part(s)
to 29 bytes), max. `0622')
2 1 alpha Record type Constant "C"
3 8 numeric Bank sort code First bank involved, discretionary
4 8 numeric Bank sort code Final beneficiary bankI/place of payment
5 10 numeric Account number Remittance beneficiary/ person liable to
pay, right justified
6 13 numeric If not used: zeros Field C6 can be filled-in as follows:
1st byte = 0
2nd - 12th bytes: internal customer number or zeros
13th byte = 0
1. Constant part, 2nd record section
Field Length in bytes DataformatData format Content Explanation
15 27 alpha Name Client (order party)/payee (left justified), names used
should be as short as possible
16 27 alpha Payment purpose Information given should be as brief as
possible. At the beginning of this field such information should be
included, left justified, that the beneficiary may possibly intend to
make use of (e.g. building savings account number, insurance number,
invoice number) or which the payee needs with direct debits in case the
payment is sent back to him unpaid or not deliverable
17a 1 alpha Currency code X'20' = DM
1 = Euro (permissible from the start of
Stage 3 of the ECMU
17b 23
X'20' Reserve
18 2 numeric Extension character 00 = no extension part following
01-15 = number of extension parts
2. Variable part, still 2nd record section
The variable part forms a single unit with the constant part. It only
exists if the data fields in the constant part are not sufficient to
accept all information. A maximum of up to 6 record sections @ 128 bytes
can be filled for Record C. It can happen as follows: 1 extension part
for ``Remittance beneficiary'' or ``Person liable to pay'' (01), up to
13 extension parts for ``Payment purpose'' (all 02) and 1 extension part
for ``Client'' or ``Payee'' (03).
Field Length in bytes DataformatData format Content Explanation
19 2 numeric Identifier of extension part 01 = Name of the remittance
beneficiary/person liable to pay
02 = Payment purpose
03 = Name of client or payee
20 27 alpha Remittance beneficiary or person liable to pay/Payment
purpose/Client or payee Left justified. With returned remittances and
returned direct debits the content of extension parts fundamentally
cannot be given by the banks on the form under ``Payment purpose''. All
payment purpose information necessary for the processing of such return
forms must therefore be included by the payee or client in the constant
part of Record C (see explanations to Field C~Z165).
21 2 numeric Identifier of the extension part (as for Field 19)
22 27 alpha Data extension part (as for Field 20)
23 11 - X'20' Only for dividing up the record section (should not be
taken into account when stating the record length in Field C~Z1)
128
2. Variable part, 3rd record section
Field Length in bytes DataformatData format Content Explanation
24 2 numeric Identifier of extension part (as for Field 19)
25 27 alpha Data of extension part (as for Field 20)
26 2 numeric Identifier of extension part (as for Field 19)
27 27 alpha Data of extension part (as for Field 20)
28 2 numeric Identifier of extension part (as for Field 19)
29 27 alpha Data of extension part (as for Field 20)
30 2 numeric Identifier of extension part (as for Field 19)
31 27 alpha Data of extension part (as for Field 20)
32 12 - X'20' Only for dividing up the record section (should not be
taken into account when stating the record length in Field C~Z1)
128
Record E (File trailer)
Record E is used for agreeing of parts. It occurs only once in each
logical file.
Field Length in bytes Data
format Content Explanations
1 4 numeric Record length `0128'
2 1 alpha Record type Constant "E"
3 5 - X'20' Reserve
4 7 numeric Number of the C records Agreement proofs
5 13 numeric Total of the DM amounts from Field 9 of the C records
Agreement proofs, if order currency in data fields A12 and C17a = X'20',
otherwise zeros
6 17 numeric Total of the account numbers from Field 5 of the C records
Agreement proofs
7 17 numeric Total of the bank sort codes from Field 4 of the C records
Agreement proofs
8 13 numeric Total of the euro amounts from Field 12 of the C records
Agreement proofs, if order currency in data fields A12 and C17a = X'20',
otherwise zeros
9 51 - X'20' Only for dividing up the record section
128
Appendix: Explanations to Field 7a and 7b of Record C
To identify the type of payment uniform text keys have been defined by
the banking industry. Where special text keys have been specified for
individual types of credit these should in all cases be used. This
applies especially to wages, salaries and pension credit payments (Text
key ``53'') and for capital-building employment benefits (Text key
``54'').
Public savings banks can identify the wages and salaried remitted by
them with the text key ``56''.
The following entries for data fields 7a and 7b can occur.
At the customer end: (Identifier ``GK'' or ``LK'' in Field 3 of Record
A)
Text key Field 7a Text key addition Field 7b Explanation Content of
Data Field 7
04 000A Direct debit
(Preauthorised payment order procedure) `04000'
05 000A Direct debit
(Direct debit authority procedure) `05000'
51 000A Remittance credit
(e.g. commercial payment) `51000'
53 000A Wages, salary, pension credit `53000'
54 XXJC Employment benefit `54XXJ'
56 000 Remittances of public savings banks `56000'
67 000A Remittance credit with checksum-protected assignment data
(BZø remittance) `67000'
69 000A Credit of a donation remittance `69000'
05 005B Lastschrift aus POS-VerfØgung - electronic cash `05005'
05 006B Lastschrift aus POS-VerfØgung mit auslÄndischer Karte - edc
`05006'
05 015B Lastschrift aus POS-VerfØgung - POZ `05015'
Appendix: Check measures ( Plausibility and field contents checks)
The C data records are to be checked as follows::
Field Contents Data format
Bank sort code of the final beneficiary bank/of place of payment (Field
C 4) for existence of the bank sort code acc. bank sort code directory
of the Deutsche Bundesbank, first digit not equal to 0 or 9 numeric
Account number of the remittance beneficiary/ person liable to pay
(Field C 5) not equal to zero numeric
Internal customer number (Field C 6) 1st byte equal to 0 numeric
Text key
-- Cheque debits
-- Direct debits
-- Credits (Field C 7a)
- equals 04, 05,
- equals 51-59, 67-69 numeric
Amount (Field C 9) not equal to zero numeric
Bank sort code of the first bank instructed/the first bank for
collection (Field C~Z10) 1st digit not equal to 0 or 9 numeric
Account number of the client (order party)/ payee (Field C 11) not equal
to zero numeric
Name of the remittance beneficiary/ person liable to pay (Field C 14a)
not equal to X'20' alphanumeric
Name des of the client (order party)/ payee (Field C 15) not equal to
X'20' alphanumeric
Extension identifier (Field C 18) equals 00-15 numeric
Identifier of extension part (Field C~Z19; C~Z21; C~Z24; C 26 etc.,
variable part) equals 01, 02 oder 03 in ascending order
max. 1 times 01
max. 13 times 02
max. 1 times 03 numeric
The check sums from the addition of the number of the C records, the
``Amount'' fields (C~Z9), ``Account number of the remittance
beneficiary/person liable to pay'' (C~Z5) and ``Bank sort code of the
final beneficiary bank/ place of payment'' (C~Z4) must agree with the
data in Record E.
In addition, when the ECMU format (Segment version 3) is supported, the
following must be tested:
Field Contents Data format
Amount (Field C 9) not equal to zero at X'20' in the data fields A12 and
C17a or
equal to zero at `1' in the data fields A12 and C17a (permissible from
the start of stage 3 of ECMU) numeric
Amount (Field C 12) not equal to zero at X'20' in the data fields A12
and C17a (permissible from the start of stage 3 of ECMU) or
equal to zero at X'20' in the data fields A12 and C17a numeric
Currency code (Field C 17a) equal to X'20', if data field A12 = X'20'
equal `1', if data field A12 = `1' (permissible from the start of stage
3 of ECMU) alphanumeric
The check sums from the addition of the number of C records, the
``Amount'' fields (C~Z9 and C12), ``Account number of the remittance
beneficiary/person liable to pay'' (C~Z5) and ``Bank sort code of the
final beneficiary bank/ place of payment'' (C~Z4) must agree with the
data in Record E..
On Tue, Jun 06, 2000 at 04:34:07PM +0200, Martin Schulze wrote:
> Holger Blasum wrote:
> > Dear Bhart,
> >
> > Honestly, I just know that two people have implemented DTAUS but
> > have no ideas about the details nor where they found the specs. I would like
> > to forward them your email as soon as possible, but it would
> > be helpful if you gave more details on the kind of research
> > work (that also might be interesting for the people answering you). If you can give any, please include all CCed persons in your reply.
> >
> > On Tue, Jun 06, 2000 at 12:09:55PM +0200, bhart nagpal wrote:
> > > sir
> > > I need file format of DTAUS in english.
>
> It's not available in english. The entire system is only available in
> Germany, so it does not make much sense anyway.
>
> > > It is available at net only in german.
>
> Also printed, I only got it in German.
>
> > > can it be available?
>
> If you translate it, I'd include it in english as well.
>
> > Which site have you been (please give an URL or describe)?
>
> http://www.infodrom.north.de/dtaus/dtaus.html
>
> I'm sorry, but you'd have to translate.
>
> Regards,
>
> Joey
>
> --
> Beware of bugs in the above code; I have only proved it correct,
> not tried it. -- Donald E. Knuth
This archive was generated by hypermail 2b30 : Tue Jan 02 2001 - 12:10:57 CET