S T U Z Z A
EDI_F1
ERWEITERTE VERSION
für die Erzeugung von
Zahlungsaufträgen in EDIFACT
January 2002
What the enhanced Version of EDI_F1.xls does
EDI_F1.xls is an EXCEL Workbook which contains VBA1-code and several Worksheets. In two of the Worksheets
("to_pay" and "to_collect") the data of payment and debit orders can be prepared (one order per line) and the VBA
Code produces an EDIFACT Interchange where these payment and debit orders are assembled in one Interchange
consisting of one or more PAYMUL and DIRDEB messages.
In addition this enhanced Version includes a V2 to V3 (EDIFACT) converter feature2. It can convert both, domestic
V2 orders (IZV, either payment orders or direct debits) and V1294 for cross border payment orders (AZV).
What EDI_F1 can be used for
(1) as free (=gratis) V2-to-EDIFACT-converter-utility
For those who have not got a better solution today it can serve as an escape. It allows to produce EDIFACT
messages PAYMUL and DIRDEB from V2 (120 character records) and V1294 (128 char records) input. The V2
input is assumed to be correct, i.e. it is not checked for consistency and formal compliance. The single order data
is just taken as it is, check-sums are calculated afresh for the EDIFACT output.
(2) as tool to produce electronic Direct Debits:
From Jan 2002 on, submission of direct debits via paper forms is obsolete too – although some banks still accept
direct debits in Euro on paper there is no standard for Euro-debit-paper forms!. EDI_F1 can be used to produce
DIRDEBs instead of printed forms, just transfer the data into the sheet "to_collect" - or if you have very few
transactions fill them in by hand - and press the button "EDIFACT Interchange erzeugen".
(3) as preprogrammed utility to allow the direct output of EDIFACT messages from accounting applications
which either do not have a V2 capability or where the information quality of the payment order data should be
improved (e.g. structured remittance information for the business partner). This was infact the original intention of
the introduction of EDIFACT, not just the mapping of V2 texts into a new format.
It is the right tool if so far you have produced your pament order files from an ACCESS or ECXEL application.
(4) as a test and correction tool.
One can read EDIFACT Interchanges into a spread sheet, where they are displayed in a better readable form, can
correct them there manually and rewrite them to disk. This can be very helpful in cases where an application
cannot read the EDIFACT input for a silly and minor error or when you want to generate a test Interchange with
specific coding.
1
2
Visual Basic for Applications
EDI_F1 is not a general purpose EDIFACT converter, it is just specialized on the production of PAYMULs and DIRDEBs
starting from the old Austrian domestic data formats.
EDI_F1 Beschreibung STUZZA Erweiterte Version vom Jänner 2002
D:\533567610.doc
How EDI_F1.xls works
The VBA Code in EDI_F1.xls takes the information needed to build a PAYMUL from different Worksheets, all
contained in EDI_F1.xls:
Constants
country- and company specific data
and also
environmental parameters
to_pay
to_collect
Your single
payment/debit
orders
(one per line)
these data elements can be considered to
remain more or less constant
Tabs
a Currency Code Table which includes
also conversion rates
a Country Code table
Codes used are ISO, the tables are not
complete and have to be possibly expanded.
Also the conversion rates should be updated
from time to time if orders in these
currencies are made.
a BLZ (national BankCode) table
which makes reference to a table for
EDI_Kenng (EDI-Id's of receiving banks)
to_transfer
EDIFACT INTERCHANGE
OUTPUT File
Step 0
The data of the payment orders has to be put into sheet "to_pay", the data of the direct debit orders has to be put
into the sheet "to_collect". Each order takes exactly 1 line in the sheet. As it is possible to combine PAYMULs
and DIRDEBs in one Interchange, one can fill both.
This can be done by hand or via a small program which takes the data from your accounting application.
How it can be done by a program is demonstrated in Modul3 where you find the VBA routines which read a V2
file and put its data into the two sheets.
if you want to use EDI_F1 only for V2 to V3 Conversion
select sheet "Constants"
press the command button
"um diese V2-Daten in EDIFACT zu konvertieren, drücke mich"3
missing information in sheet "Constants"
will be prompted when you use the program the 1st time
As an alternative you can call the V2_to_V3 Converter function of EDI_F1 also from another program. The
required Code to do so in VB would look as such:
Dim konverter As Object, rc As Variant
Set konverter = GetObject("directory_where_you_stored_it\EDI_F1.xls")
rc = konverter.V2_to_V3("path_of_V2_input_file","path_of_V3_output_file")
3
maybe you have to scroll down to see the button on the screen
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 2 von 13
Step 1
the payment orders in "to_pay" and "to_collect" are ordered in batches4 according to the established and
documented rules. Therefore you need not worry about a special order when filling the payment orders into
"to_pay" or "to_collect".
Domestic payment orders are automatically separated from foreign (=cross border) payment orders, the countrycode of the beneficiary's country being the criteria to distinguish between both: whenever the country code is not
empty and not equal to the "default" country 5 then the payment order is considered to be "cross border". Within
this rough order batches (separate LINs) are built for each different currency of the ordered amount. Thus for
domestic payment orders those in EUR (=default currency) will form a batch separate from those in ATS 6. If the
way of paying (e.g. PostBar) requires a separate LIN, this is catered for as well.
In addition to that, x-border7 payments are checked if they qualify for "Europe Payments" 8 and these payment
orders will also go into separate batches. Similar applies to cross border payment orders of which the amount is
given as "equivalent amount".
The ordered payments – respectively the batches of payment and debit orders - will be stored in the worksheet
"to_transfer"
Here again each payment/debit order occupies one line of the spread-sheet. Additional lines are inserted at the
begin of each batch, which show the sum of the ordered amounts of the batch and its equivalent-value in default
currency (this is calculated and shown just to give you a incling of the total amount in one currency. It is not
used fo anything else)
These additional lines also contain the "batch-reference9" which is generated automatically. The way reference
numbers are generated is explained in the description of the sheet "Constants", field "current_order_no".
However this is an arbitrary method and you could replace it by another logic. (see "automatic generation of
references")
Step 2
The EDIFACT Interchange is produced directly from the entries in the sheet "to_transfer".
VBA
Code
to_transfer
in the sheet "TRF_DDT" there are
formulas and named fields which
assemble segments and sequences
of segments. It is used by the VBA
Code as string assembler.
TRF_DDT
EDIFACT Interchange File.
The path-name of it You have
to supply in the sheet
Constants, field:
"new_order_file_path"
before writing the new EDIFACT File to the
path "new_order_file_path" the file which
directory:
already exists under this name is saved in this
old_order_files_dir
directory being renamed into
"old_interchange_ref.txt"
The directory whereto write the old
EDIFACT files you define in the field "old_order_files_dir" in the sheet "Constants".
If field "old_order_files_dir" is empty, old interchanges are NOT saved.
Step 1 and Step 2 actually run in a row without having to be triggered separately.
4
5
batched orders ~ Sammelaufträge
see description of sheet "Constants"
6
this feature was needed in the Euro Transition phase.
7
x-border = cross-border
these are orders into other European countries under a certain amount threshold and normally one pays lower fees for them.
9
the batch reference marks uniquely each batched order. On the statement of account you get from your bank each batch
should be reflected as one debit entry the debited amount being the sum of the single payment orders of the batch. The
entry in your statement of account should also show the batch reference you supplied in the message ( the batch reference is
transferred in the PAYMUL on B-Level as RFF+AEK:.... )
8
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 3 von 13
After Step 2 the work is done and one could submit the Interchange File to the bank as PAYMENT ORDER(s)
or DIRCT DEBITs or both (together).
How to use EDI_F1.xls
(1) Fill the right data into the sheet "Constants"
This sheet contains specific data of your company (e.g. name and accoutn-no) which you supply with each
payment order. Apart from that some fields are environmental (see above) and ought to be set correctly before
running the VBA Code. Some of the fields are pre-set (e.g. country, currency) and should fit also for you. If a
field is missing, when you first run the VBA Code, its value is prompted and put in table "Constants". Make sure
you save the file EDI_F1.xls after that, otherwise you are asked to type them in again next time.
All fields in the sheet are named and are referred to by that name. You also see the name in the first column of
the sheet (green). In the second column of the sheet you put the desired values. The third column contains brief
descriptions of the fields.
As text is limited in Cells [of older Versions of EXCEL] here the complete description of the fields
Field Name
Contents / Meaning / Use
country specific
this_country
def_currency
alt_currency
low_value_EU_limit
txt_ln_len_limit_dom
max_txt_lines_dom
txt_ln_len_limit_for
max_txt_lines_for
BLZ_internatl_coding
10
parameters10
Your Country (i.e. the country of the ordering party). Since we live in Austria the code should be AT.
If the beneficiary is located in "this_country", the remittance is considered to be domestic
("Inlandszahlungsverkehr"), otherwise x-border remittance (AuslandsZahlungsVerkehr) is assumed.
If the beneficiary's address does not contain a country code, "this_country" is the assumed default
value.
default-currency: all amounts not carrying a currency code are understood as amounts in this
currency. This currency should be identical to the currency with which the company's accounting
system works.
Currency codes must be ISO !
alternative currency: for the countries of the Monetary Union (MU) during the transition period (19992001) the EURo and the NCU (in Austria = ATS) were both considered as domestic currency.
If the conversion to EUR is complete then this field is pointless.
This amount must be expressed in EUR ! It represents the threshold up to which the banks of your
country provide cheaper payment services into other European countries. [in Austria these payments
are called Europa-Überweisungen]. Normally this threshold depends on the reporting requirements
within the country. There are also other criteria which have to be fulfilled in order to qualify as
"Europa-Überweisung" (e.g. the currency of the ordered amount must be in the national currency of
the beneficiary's country, the account-no of the beneficiary must be specified by domestic codes,
e.g. Bankleitzahl + Kontonummer for DE, or must be an IBAN+BIC)
maximum length of text in one line of the remittance-info which the domestic clearing system of
"this_country" allows. The values provided in the table are the limits of the "Austrian IZV" system.
Some domestic systems of other countries allow for much less. Even if the electronic transfer in
EDIFACT would allow remittance text lines longer than this (i.e. 70 char's), there would be no
straightforward way to print it in case the beneficiary does not take the EDIFACT messages
CREMUL etc. Therefore EDI_F1.xls checks the remittance Text-lines for this limit and if the limit is
exceeded it splits the text in 2 lines.
this is the maximum number of lines allowed for domestic payments in the length above.
in case the cross border (=foreign) payment transfer is passed through SWIFT-FIN or other similar
services the system of transport imposes this maximum line length for remittance information. In
order to make sure that the payment orders submitted can be treated automatically, EDI_F1 checks
the length of the text-lines.
this is the maximum number of lines allowed for foreign payments in the length above
according to international Coding Rules the BLZ (=national Bank Code) should be put into field 3434
of the FII segment (field 3433 would be reserved for the BIC). As in domestic payment instructions
today there is no BIC, the Austrian banks accept the national BankCode also in field 3433.
Unfortunately some banks understand it only if the BLZ is in field 3433.
To avoid problems for the user, we have defined this switch: (BLZ_internatl_coding:
if it is empty then the BLZ goes always to field 3433 (except for x-border payments)
if it is = "1" then the BLZ will be put correctly into field 3434
if you use EDI_F1.xls in Austria you can leave the country-specific parameter-values already set as they are.
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 4 von 13
name_structured
In the NAD segment the Name and Address of the Beneficiary (Debtor in case of direct debits) can
be presented in 2 ways:
structured or Unstructured
The standard function of this filter is to avoid NAD segments by squeezing the data you put into the
fields "Beneficiary's Name, Beneiciary's Addr Line 1 and Line 2" into 2 lines of 35 characters each
and by putting these 2 lines into the FII segment (field 3192).
Only if this squeezing is not successful, then a NAD+BF segment is produced. Only in this case:
If the switch "name_structured" is empty then name and address go to the unstructured part of the
NAD segment, otherwise they fill the structured part of the NAD.
A t t e n t i o n : the current version of MBS-Telebanking (Sparkassen, Volksbanken) rejects NADs
with unstructured info only. If you "import" or "upload" (=weiterleiten) data there, you must set this
switch to "1"
Company-specific parameters
my_EDIFACT_ID
my_short_name
my_contact_person
communication_no
communication_type
my_banks_name
my_banks_code
my_account_no
my_banks_EDI_ID
my_charge_acct_no
this value will be transmitted as "Sender-Identification" in the UNB Segments of the Interchanges
you produce. It should also be the "Receiver-ID" in the UNB in the Interchanges you get from your
bank. Get in touch with your bank to agree!
it is the name of Your company - but it should not be the full length of the legally correct name. It
serves only, that your bank and your beneficiaries can identify you by it and it should not exceed 35
char's. The best would be an acronym if your company has something like it, e.g. instead of
"Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr GmbH" just "STUZZA GmbH".
this is the name of the person with whom the bank should get in touch, if there are any problems
executing the sent payment order.
The above person can be reached under this communication number. The type of communication
you define underneath. (Make sure that the number is preceded by the required zeros by putting a '
in front. This is an advice also applicable to other numeric string-values which ought to have leading
zeros, e.g. account-numbers)
TE = telephone, EM = e-mail (then the above entry should be the e-mail address of the contact
person), FX = Fax number
This (and the next four entries) define the account to which your payment order will be debited or the
direct debit order will be credited.
Usually you will not supply the full bank's name but just the acronym which is commonly used.
this is the national code of your bank. In Austria (and in Germany) this is the BLZ (Bankleitzahl)
this is your account with the above bank. In Austria it should be an 11 digits number, in Germany a
10 digits number. So if your account is shorter, pad it with leading Zeros at the left. Do not forget the
leading ' to make it a string..
this value will be transmitted as "Receiver-Identification" in the UNB Segments of the Interchanges
you produce for your bank.
If you make payments abroad you might wish to have the charges debited to a separate account
the above block of 5 fields is repeatable because you can have more account-relationships (e.g. with different banks) and you
use them alternatingly for payment or debit orders.
The line after the last repetition MUST be EMPTY, so the program recognizes where the list of accounts ends.
If there is more than one account-relationship, then when pressing the button "EDIFACT Interchange erzeugen" you are
prompted to select the wanted account.
charges_option
current_order_no
if you have x-border payment orders you can provide here the charging option you want to be
applied to payments generally. (This will be coded at B-Level)
Alternatively you can provide different charges-options individually for each payment order, but then
you have to leave this field empty.
this number (nnnn) is increased by one before generating a new Interchange and will start again
from 1 when you exceed 9999.
(as this number is increased by one for each interchange, make sure EDI_F1.xls is stored after each
successful run – otherwise you use again the old value)
This number is used in the automatic construction of the various reference numbers submitted
together with your payment orders. Which reference numbers are built automatically and how they
are constructed, is explained further down in the box "automatic generation of reference-numbers".
Since the automatic construction of the references was an arbitrary choice of "us" you may not like it.
To do it your own way you must modify the VBA Code.
You find the Code to replace or modify in Modul1 – looking for procedure "create_intchgref". All
reference numbers are generated in neatly separated functions and these functions are all there.
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 5 von 13
environmental parameters
new_order_file_path
old_order_files_dir
V2_path_to_convert
to this File_NAME (complete path required) whereto EDI_F1 will write the Interchange.
before killing (overwriting) an old Interchange-file of the above name, the old one will be saved under
this directory (the value must be an existing directory!). The old file will change its name to
"Date_InterchangeRef.txt" where Production_date and InterchangeRef are extracted from the old
File (more precise: of its UNB segment)11.
Thus you automatically save all EDIFACT files you submit to your bank.
If this field is empty, old interchanges are not saved.
this is the file from where V2 data is read, when you want to convert it to EDIFACT.
Underneath there are some fields in "Constants" which are only used for V2 to V3 conversion. Ignore them but
leave them as they are.
11
if you have already saved another file with same creation_date and interchange_reference than it will be overwritten by
the newer version!
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 6 von 13
Unless you want to understand it in detail, skip this page and read on.
Automatic generation of reference numbers by EDI_F1.xls:
Four (=4) types of reference numbers are generated automatically by EDI_F1:
the InterchangeRef
Segment UNB, field 0020
the abstract message reference
Segment UNH, field 0062
the applicational message reference
Segment BGM, field 1004
the batch reference
Segment RFF in Segm.Group 4, field 1154 (Qual.=AEK)
How the reference numbers are constructed:
InterchangeRef:
M M M y y y y d d d n n n n
"current_order_no" (see Constants)
the number of the day (counted from one up to 365 12)
the current year
letters 3 to 513 of "my_short_name" (see Constants).
abstract message reference
M M M P y y y y d d d n n x
number of messages within Interchange (the first message
would have a "1", the second a "2" and so on. If there are
more than 9 messages it continues with A, B and so on ...
2 rightmost (low order) digits of "current_order_no"
day number (between 1 and 365 resp 366)
current year
"P" as a constant. It is thought as "P"aymul. If you create
also DIRDEBs14 you should have a "D" here to distinguish.
letter 3 to 5 of "my_short_name" as above
applicational message reference
M M M P y y y y m m d d h h m m n n n n x
as above
"current_order_number" in full
time of message creation in hours and minutes
date of message creation in year month (mm) and day (dd)
as above
as above
batch reference
P y y y y m m d d n n n n x b t
Type: ="I" if the batch contains domestic payment orders,
="A" if it contains cross border payment orders15
number of batch (=LIN-section) within this message (here
again counting continues with A, B etc after 9)
number of message within this interchange
"current_order_number" (in full 4 digits)
date in form yyyymmdd
"P" as a constant (see comment above)
12
or 366 if we are in a leap year. Thus first of January would be 001, first of February 032.... and so on
13
if my_short_name is shorter than 5 characters, then the last 3 characters are used.
something which would have to be added as function, EDI_F1 as it is creates only PAYMULs.
14
15
apart from putting domestic and x-border orders into separate batches, EDI_F1 will also put cross border orders in a
separate PAYMUL.
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 7 von 13
(2) Fill the data of your payment orders into the sheet "to_pay"
Each row in "to_pay" corresponds to one single payment order.
The heading-fields in row 1 of the columns are named and the fields in each row are accessed by this name (plus
the row offset).
Normally you will import the data of your payment orders from another application (i.e. from your accounting
SW package, which keeps track of your "payables"). There are many easy to produce data formats which can be
directly imported into an XLS sheet. However make sure that you do not delete row 1 of the sheet, as it contains
the headings. So let your first payment order take row 2, and erase also the lines on the bottom which have
possibly "survived" from earlier runs (EDI_F1 takes everything until it does not find a value in the column
"ordered amount").
W h a t d a t a e l e m e n t s h a v e t o b e / c a n b e i m p o r t e d ? The following is a description of the fields in
column order:
name of column16 meaning and use in the applicational context
t_I_A_ZV
this is the name of column A. Column A is used internally only (and must not be filled
with data). In the sheet delivered the column A of "to_pay" is set to "not visible".
t_belnr
this field gets your internal reference number which you attach to the single transaction,
e.g. the number under which the corresponding invoice has been registered in your
accounting system. This internal accounting-reference number has not got anything to do
with the invoice number your supplier wrote on the invoice. (The invoice number is a
reference which serves the beneficiary for reconciliation of the incoming payments)
The value in this column is passed on as RFF+CR in the corresponding C-level entry of
the PAYMUL.
t_betrag
this is the equivalent amount (expressed in def_currency) of the ordered amount.
You need not supply this value since EDI_F1 will compute it anyway (for MUM
currencies exactly, for other currencies of the ordered amount with the conversion rate
you have left in the currency-table in sheet "Tabs")
The field is not transferred to the EDIFACT ouput. It serves only to provide an inkling of
the total value of orders.
t_amount
this is the ordered amount of this single transaction
t_currency
this is the currency in which t_amount has to be understood (if you do not supply it,
def_currency is assumed)
Three hidden fields are following. They are used only for x-border payment orders when converting from
V2. You can ignore them. The first is the transfer currency for so-called "equivalent amount orders" (i.e.
you give the order "transfer the value of x EUR in USD") and we do not think this is needed for every day
life.
t_ben_name
Name of the beneficiary. If this name is longer than 35 characters then EDI_F1 will try to
split it into lines <= 35 characters. If you want to control line separation yourself, then put
a "|" character at the intended point.
t_adr1
Line 1 of the address of the beneficiary. If this field exceeds 35 characters then EDI_F1
will try split it into 2 lines <= 35. If you want to control the line-split put a "|" char at the
point of line-split.
t_adr2
Line 2 of the address of the beneficiary. If Line 1 has already been split in two lines then
this will be the third line.
Be aware that EDI_F1 does not support Name and Addresses in structured form !
t_land
ISO Code of the country of the beneficiary. If you do not fill this field "this_country" is
assumed.
EDI_F1 distinguishes between domestic payment orders and those going abroad on the
value of this field.
t_bank
short name of the bank servicing the account of the beneficiary. In domestic payment
orders you could omit this value (but in case your BLZ is false then it might be helpful to
forward the order correctly)
t_BIC
to be filled only for x-border payment orders.
BIC is identical with the SWIFT Code of the bank of the beneficiary.
You can use this field also for other 2 routing types, if
the Bank_Code is the Fedwire ID: put a /FW before the code
the Bank_Code is the CHIPS ID of the bank: put a /CH in front
16
i.e. name of the field in the first row of this column. These names have been chosen arbitrarily (and sometimes reflect a
partial meaning only in German). However we prefer to refer to the columns by this name instead of the column number.
Also you could insert extra columns without disturbing the logic, since access is by name only. [ Attention: if you insert a
column you have to insert the column in the same position in all 3 sheets "to_pay", "to_collect" and "to_transfer" ! ]
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 8 von 13
t_blz
t_kto
t_reason
t_oenb_pos
t_rep_text
t_charges_optn
Bank-Code of above.
In domestic payment orders staying in Austria (or Germany) this would be the "Bankleitzahl" (=BLZ).
If no special character is in front, domestic Code of the foreign bank is assumed. (if the
country code is GB or IE the domestic bank code is considered to be the "sorting code").
Be aware that in most countries in Europe there is no such thing as a separate domestic
bank-code. The bank code is part of the account-no. In this case this field is not filled at
all. The same applies when you supply an IBAN !
the account number of the beneficiary.
if this field contains 2 letters in the beginning, EDI_F1 assumes that this is an IBAN.
the following 4 fields apply EITHER only to payment orders abroad (cross border)
OR to "cash per post" (POSTBAR) payments
For POSTBAR the fields have a superposed, second name shown here ------->
this is an Austria-specific legacy code (inherited from the old format
t_clauses
V2):
"1" import
"2" transfer into another account held by yourself
"3" other. In this case you have to supply either the OeNB reporting
position number (in field "t_oenb_pos" ) or further details in text
(in field " t_rep_text ") so your bank can report the transaction
correctly to OeNB.
central bank (=OeNB in Austria) reporting code (in Austrot_clause_dates
German="Positionsnummer") for this type of transaction (according to
underlying business)
explanatory attachment in text if you do not know the right reporting
code
not used
if you need more than 1 line, then separate them by a "|" character.
"who pays the charges?". There are 3 options:
t_cash_order
"2"
YOU pay all the charges
you can also code OUR
"3"
the beneficiary shall pay all the charges
also code BEN
"1"
YOU pay the charges incurring in your country and the
beneficiary will pay the charges incurring in his country. You
can also code SHA.
Be aware that for transfers into European countries NOW the
banks assume OUR in case you have not submitted a value in this
field17.
for Cash per Post orders, these fields have the following meaning
t_clauses
a string of the Clause numbers ( 1,3,4 or 8 ) to apply.
You can code it as 138 or 1_4_8 or 1/3/4 the way ou prefer
t_clause_dates
the date for clause 1 or the date for clause 8 in form yyyymmdd
if you have both clauses code yyyymmdd/yyyymmdd where the first
date is the one for clause 1.
not used for CPP
t_cash_order
this field MUST contain the ZIP code (PostleitZahl) of the beneficiary.
If this field is filled for domestic orders – Cash Per Post is assumed.
17
t_reason
t_oenb_pos
t_rep_text
t_charges_optn
this is due to the EU-directive and its national implementation called "Überweisungsgesetz"
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 9 von 13
all following fields from here on concern remittance information (i.e. information for the beneficiary)
t_ref_for_ben
Reference number for the beneficiary. This reference number is passed as RFF+PQ if it
does not exceed 35 charcters, otherwise as FTX+VWZ.
It ought to be something which provides a clue to the beneficiary of who is paying and/or
what the payment is for. What you fill in this field depends on the reason of payment (the
underlying business). You could fill in:
INVOICE Number (which the vendor generated): if you pay just one invoice
CUSTOMER Number: if you pay more than one invoice and supply the invoice numbers in the further
remittance information (structured or unstructured). The customer-number is the number your
supplier allocated to you and under which he registers all the business he does with you.
Usually this customer number figures on all invoices.
TAX-ACCOUNT-Number: if you pay taxes either to the federal tax authorities or to local authorities.
Both keep track of your debts and payments under a certain number.
SOCIAL SECURITY [ACCOUNT] Number: if you pay contribution. Each company has at least one if
not several of these account numbers allocated by the soc.sec. authorities. As an individual
you have a unique social security ID number.
NOTIFICATION Number: if some authorities send you a notification they usually want you to pay a fee
or a tax. (e.g. if you have established a rental contract and announce it duly to the authorities)
FINE-IDENTIFICATION Number: if the friendly police has put a fine under your windscreen wiper. In
Austria these forms show an identification number ( this number is – apart from its check-digit
at its right end – identical to the leftmost field in the code line).
INSURANCE POLICE Number for which you pay the premium herewith
CONTRACT Number if you haven't got anything else to identify by one number the context of your
payment
Naturally there are also OTHER possibilities. We have listed the most common ones. In any way try
to use something which is a computerised ID-No at the beneficiary's side and is not in contradiction
with or a superposition of the data elements you supply in the structured remittance information.
the next 5 fields allow for remittance information in plain text
a t t e n t i o n : EDI_F1 treats structured remittance information and text remittance information as mutual
exclusive in one payment order. You cannot combine both in a single line of "to_pay" !
t_rem_text_line_1 first line of remittance text
t_rem_text_line_2 second line of remittance text
t_rem_text_line_3 third line of remittance text
t_rem_text_line_4 fourth line of remittance text
t_rem_text_line_5 fifth line of remittance text18
the following fields allow for encoding structured remittance information in your payment order.
t_struct_type
defines to which structure the following data-elements have to be mapped and how the
subsequent fields have to be interpreted.
Currently EDI_F1 supports only 2 types of structured remittance information:
INV
detailed specification for payment of invoice(s)
TAX details provided together with a tax payment
t_rem_stru_1
in this column starts an array of seven fields19. The meaning of these fields depends on
the value in "t_struct_type". The seven fields do not carry own names – only the first one
(i.e. name = t_rem_stru_1 ). The single fields in the array are accessed through the offset
relative to the first field of the array;
e.g. third field would be addressed as " t_rem_stru_1 with column-offset 2"
here follows the meaning of the fields depending on the value in "t_struct_type":
column-offset
in case "t-struct_type" = "INV"
in case "t-struct_type" = "TAX"
of field
0
invoice number
tax period starting date
1
invoice date
tax period end date
2
invoice amount20
code of type of tax21
18
it might seem too limited to allow only for 5 lines of remittance text. O.K. for those who really need more (a bad habit
though) there is always the possibility to fill one line with more text and separate the lines with a "|" character. In case the
text in one line exceeds the limit defined in the sheet "Constants" (see fields txt_ln_len_limit_dom and txt_ln_len_limit_for)
EDI_F1 will try by itself to split the text. Thus you can create up to the maximum of text lines allowed (see again
"Constants") which is set to 15. This is enough to filll almost a whole C-form (C-Beleg) and should suffice. If you want to
send books of text going beyond that, you have to slightly modify the VBA code.
19
of which actually only 5 are used now (room for extension).
20
if you enter a negative amount (minus sign in front) then this invoice will be treated as credit note.
21
as for the possible codes to use see the STUZZA EDIFACT documentation "strukturierte Kunden zu Kunden Information"
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 10 von 13
3
4
5
6
t_rem_stru_2
t_rem_stru_3
t_rem_stru_4
t_rem_stru_5
currency of invoice amount
discount amount subtracted from invoice22
not used (so far)
not used (so far)
tax amount for this type of tax
currency of amount above
not used (so far)
not used (so far)
this array (of seven fields) can now be repeated up to 5 times 23:
see description of "t_rem_stru_1"
see description of "t_rem_stru_1"
see description of "t_rem_stru_1"
see description of "t_rem_stru_1"
When you import the data of your payment orders in the sheet "to_pay" you need not care for a special order or
sequence of them. EDI_F1 will aggregate the payment orders in "permitted" batches according to the coding
rules established by the Austrian banks, e.g.: orders in ATS separate from orders in EUR, domestic payments
and cross border payments in separate PAYMULs , cross border payments only with equal currency of ordered
amount in one batch and also those qualifying for "Europe" payments separated from those not qualifying 24.
(2a) Fill the data of your debit orders into the sheet "to_collect"
The fields in this sheet correspond to fields in sheet "to_pay" with the only difference that. the beneficiary's
account is the debtor's account and so on.... We therefore do not add a detailed description.
There is one field which does not have a correspondent one in "to_pay": t_belegart which must be filled with 82
or 83 – according to the type of direct debit you perform.
(3) Run the VBA Code to produce an Interchange
After you have filled the right data into the sheet "to_pay" just bring the sheet to the screen and press the button
make
Interchange
and that's it.
If You do the above steps by program-Code and want to start the EDIFAT Output also from your program then
You call the necessary function like this:
Dim xlsedi As Object, rc As Variant, bank_no as integer
Set xlsedi = GetObject("directoryWhereYouStoredEDI_F1xls\edi_f1.xls")
rc = xlsedi.produce_V3_from_xls(bank_no, "PathWhereYouWantToWriteTheEdifactOutputTo")
if you have stored more than one bank accounts in Sheet "Constant" then bank_no
must be the number against which you intend to run the order. Counting starts with
with ZERO ! If You have only 1 bank account stored in "Constants" so bank_no
must be 0.
For those who would like to tinker around with the code, some more helpful information:
The first thing the program does is to copy the lines (which are not empty) from sheet "to_pay" into the sheet
"to_transfer". So if you add additional columns in "to_pay" you also have to add them in the sheet "to_transfer".
Now the single payment orders are checked to find out which orders can go together in one batch (=LIN
section). To do so an internal mark is written to column 1 of the sheet (that's why this column is reserved) and
afterwards all orders are sorted into the collating sequence established by the content of column 1.
The next step is to insert an additional line in "to_transfer" at the top of the orders which make up one batch. In
these additional lines the total amount of the batch is written and also the automatically generated batch
22
must be in same currency as invoice amount
if you need more complex or abundant structured remittance information (e.g. if you want to pay more than 5 invoices with
on payment order) then you have to expand the model and adapt the VBA code correspondingly. As we stated in the
introduction: EDI_F1 is not a fully fledged general solution but only a (very) limited demo model.
24
for more details about this "batching" algorithm, see description of activity (3)
23
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 11 von 13
reference (RFF+AEK) in column 3 where in the single payment orders you have written your own reference
(RFF+CR).
As your bank will (should) debit your account with one debit entry for each batch, the total amounts of the
batches – or better the automatically computed equivalent amounts in def-currency - could be used for
reconciliation of your bank account.
After these preparative measures the data contained in "to_transfer" is transcribed into an EDIFACT Interchange
the physical file of which is written to the path you have specified in "Constants". The code takes advantage of
the XLS-inherent formatting capabilities by temporarily creating strings of segments through formulas in the
sheet "TRF_DDT". These preformatted strings are just concatenated in order to produce the whole file.
If you look into the VBA-code you will notice that the file is produced as "BINARY" output. This is important.
If you write a normal text-file after each write operation an end-of-line sequence (X'0d0a) would be inserted and
this is not compatible with the EDIFACT standard !
If you want to break into it deeper just look into the VBA code of EDI_F1.xls ........ and have a nice time.
(4) Read the EDIFACT Interchange back into EDI_F1.xls
This is a step you will only perform when you are testing. You certainly will like to give a look at the
Interchange you have produced. Therefore we have added a "Read-back" feature:
Go to the sheet "edi_msg" and press the button:
Read the EDIFACT file into table
The EDIFACT Interchange will be read from data-path specified as "new_order_file_path" in sheet "Constants"
and each segment will be written into a separate row of the sheet to make it better "readable". Thus you can see
(also print) the Interchange in a formatted way.
You can also make corrections and write the file back to disk. If a converter has just given the byte-position
where it found an error, the button "find byte position" will allow you to locate exactly this point in the message.
The program that does it you will find in Modul2 whereas all the code necessary for creating the interchange is
in Modul1 and the one reading V2 date is in Modul3.
Functional limits of V2 to V3 converter
Die Bestandskontroll-Nr wird generell ignoriert. V3 Referenzen für Interchange, Messages, und LIN-Abschnitte
werden nach vorhandener Logik in EDI_F1 neu erstellt.
(A) domestic V2 (recordlength = 120)
Vorstaz:
"Erstellungsdatum" wird nicht aus V2 übernommen sondern neu genereriert
UMSA1:
fields "Funktionsschlüssel", "Formularart" und "Buchungsdatum werden nicht übernommen.
Die Kontonummer und BLZ für die Bankverbindung des Auftraggebers muß mit den "Sender"
Daten übereinstimmen.
Textsätze: es werden maximal 15 Textzeilen übernommen, darüber hinausgehende Textzeilen werden
ignoriert
Summensatz: es erfolgt keine Prüfung ob die Summen im V2 Summensatz richtig sind, sie werden für den
V3 neu errechnet.
(B) cross-border V1294 (recordlength = 128)
SA 00:
Durchführugsdatum und Erstellungsdatum werden nicht übernommen.
SA 01:
Orderscheck- und Wechseldruck (Überweisungsart 90, 95) nicht unterstützt.
Durchführungsart wird ignoriert (nur Standard)
SA 02
Das Abrechnungskonto muß zwar nicht mit der Kontonummer (Haupt-Konto des Auftraggeberkunden) übereinstimmen, sie muß aber – ebenso wie Spesenverrechnungskonto und
Abrechnungswährung – über den ganzen Bestand gleich bleiben.
SA 03 und SA 04
von der Bezeichnung der Bank des Begünstigten wird nur eine Zeile übernommen !
SA 06 und SA 08
die Daten diesen Satzarten werden ignoriert, da sie aus anderen Angaben (zB
"Constants" und BLZ Tabelle) bereits ergänzt werden.
SA 08
Keine Übernahme der Identnummern (Feld 73 und 75) sowie der Felder Bank-TX-Kennzeichne
(77) und Bank-TX-Referenz (78).
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 12 von 13
Conclusive but v e r y i m p o r t a n t remark:
This document and the source code included is for free. If you can use it (maybe it came too late for you)
then this is your personal advantage. We made the effort mainly to provide a better guiding to the low-end
SW market and to those who have themselves developed their accounting routines on top of standard SW
packages like EXCEL and ACCESS – most of all because we understand from questions and requests put
forward to us, that in this area there has been little EDIFACT exposure so far.
However we do not take any responsibility as for the 100 % correctness of the code and we do not feel
obliged to smooth out immediately all bugs or weaknesses that might become apparent by wider use.
Nevertheless if you report us an error (nobody is perfect) we will try to provide a fix.
We do not mind to have some feed back from those who could make positive use of it.
EDI_F1 -SW Beschreibung STUZZA Version vom Jan. 2002
Seite 13 von 13