13283 SAP OSS Note - Description of electronic bank statement formats

Keyword:  Elec. bank statement






This note provides an overview of the electronic bank statement formats


supported in Germany. But it also refers to all countries (Swi

tzerland, Austria, Netherlands, etc...) offering Multicash banking


software or supporting the Multicash format.

The following formats are described:


Multicash


SWIFT MT940


DTAUS


BAZ


MAOBE


SAP.TXT and SAPKURZ.TXT






Cause of the problem and Pre-requisites

Consultation






Solution instructions

Multicash format


================






recommended, available since Release 2.1






This format is generated from SWIFT MT940 formats by using BCS software


(Banking Communication Standard). SAP recommends this format f

or posting electronic bank statements.






The format is the same for all banks and is easy to control by using a


table calculation or text processing program. The format consis

ts of two files in AUSZUG.TXT and UMSATZ.TXT format. AUSZUG.TXT contains


the header information from bank statements, and UMSATZ.TXT c

ontains the line item information. This format enables you to import


several bank statements from various banks at the same time.

Multicash is usually used as BCS software. Many banks offer Multicash


software, however, calling it a different name (Cotel by Commerz

bank, Dretec by Dresdner Bank, ELKO by Sparkassen, ...). If you use the


BCS program from Deutsche Bank, you must install the "db-direc

t" program.










SWIFT MT940


===========






partially recommended, available as of Release 3.0






Banks basically deliver account statements in SWIFT MT940 format (with


or without structured field 86).

From prior experience, SAP recommends not importing these files directly


into the SAP system because many banks deliver this format in

 an unstandardized form. Therefore, you should convert these formats to


Multicash format by using BCS software (see Multicash format).

DTAUS format


============






not recommended, available as of Release 3.0






Many banks recommend posting account statement data via DTAUS format.


Banks make this recommendation because they are unfamiliar with

SAP functionality and because of their internal, bank accounting


procedures.

Accounting is usually structured at banks so that only one record (the


total of the line items) is stored when the DTAUS file is trans

ferred. If all data integrated with the account statement is


transferred, which all banks can do, an accounting record is saved for

ch line item in the account statement in the bank's accounting


department. Banks want to avoid this because otherwise their accounting

 systems would become overloaded and extraodinary costs would arise.


This argument, however, is no longer valid since these postings a

re automatically generated by DP programs and storage space per 1MB hard


disk is no longer a relevant cost factor.

This procedure considerably deteriorates the overall optimum of the SAP


user in order to obtain a less than optimum condition at the b

ank.






The SAP System is different from other products and especially from


in-house-developed systems in such a way that the SAP System can p

ost ALL business transactions that are in an account statement.


DTAUS format contains only one business transaction (i.e. cash inflow)


per file, and therefore constitutes only a partial number of th

e line items posted to a bank account. When using the DTAUS format, you


usually have to import several files as well as post some busi

ness transactions manually since they can not be transferred with this


format. This procedure requires you to continue to carry out pe

rsonnel-intensive comparisons of transactions. As an SAP user, you


cannot take full advantage of SAP's functionality.

DTAUS format has other weaknesses too. A reference to a specific bank


statement (statement date, statement number) to which the record

 belongs does not exist in the header records. Without this reference,


the program cannot check whether the statement is complete or w

hether it is already imported and thus avoid duplicate import


transactions. These checks must then be established with organizational

rules.


Since DTAUS format was used with mainframes and individual data records


are not separated by the special character for a "new line" (C

arriage Return Line Feed <(><<)>CR><(><<)>LF> ), troubleshooting is


extremely laborious if the bank transfers faulty files.

Unfortunately this occurs often because during the conversion from ASCII


to EBCDIC code and back, umlauts (ie, �, �, �) frequently bec

ome special characters which are not transferred.


If a byte is missing in DTAUS, you cannot process the entire file


because each record that follows is moved one byte. The worst scenar

io in Multicash is that a single data record is damaged, which you can


easily repair.

Banks are able to transfer via electronic bank statement all information


transferable via DTAUS format. Only the electronic bank state

ment offers complete and integrated processing.






DTAUS format is only recommended for posting bank statement information


if there are no other alternatives. 99% of SAP customers, howe

ver, have other alternatives.






BAZ format


============






not supported by SAP






BAZ format is a special format used only be the German postal bank.


The same problems exist with this format as with the DTAUS format.






MAOBE


=====


not recommended, no longer offered as of Release 3.0






MAOBE format is used predominantly to transfer data on cashed checks.


Since banks will not support MAOBE format in future and data on cashed


checks can be posted with the electronic bank statement as of R

elease 2.1, the RFSHRU00 program for posting data on cashed checks is no


longer offered as of Release 3.0.

By using the electronic bank statement, you can post all cash


transactions to a bank account. The bank statement offers more options t

han program RFSHRU00, which only posts data on cashed checks.










SAP.TXT or SAPKURZ.TXT


========================


not supported






SAP.TXT and SAPKURZ.TXT only exist due to certain conditions pertaining


in the past. They were originally created in response to restrictions


in the R/2 System. Since then they have been used less and are now


not even recommended in the R/2 System.


For this reason the formats for SAP.TXT and SAP.KURZTXT will not be


delivered with the next version of MultiCash software (Release after


1.24).

The R/3 System does not support these formats because they do not


contain all necessary and available fields on a bank


statement. With a fixed record format, users are advised to work with


the standard MultiCash files, AUSZUG.TXT and UMSATZ.TXT, which c

an be further processed.










These files have the following advantages:


a) AUSZUG.TXT and UMSATZ.TXT have become an industry standard


   (same format for all banks).


b) If formats are enhanced (new fields), the customer


   does not have to make any modifications.


c) They hold more information than SAP.TXT and SAPKURZ.TXT


   (e.g. business transaction code, customer's bank details).






Description of problem