Hallo,

wer kann mir helfen?

Folgender Sachverhalt: Wir hatten bisher ELKO/MultiCash bei unseren Kunden im Einsatz. Einige davon haben ein großes Volumen an Scheckeinreichungen und haben mit weiteren Banken vereinbart, Schecklagerstelle zu sein und die Daten beleglos per FTAM zum jeweiligen Bankrechner zu übertragen (z.B. Postbank, Commerzbank). Dazu wurden freie Sessiontypnummer verwendet und konnten in ELKO/MultiCash manuell angelegt werden.

Diese Option habe ich nicht in SFirm32 gefunden, obwohl es im Verzeichnis ...FPA32\DAT die Datei DADPROC.FPA mit der Angabe aller Sessiontypen gibt. Auf Nachfrage bei der BIVG wurde mir mitgeteilt, dass eine manuelle Erfassung nicht vorgesehen ist und eine individuelle Programmierung (kostenpflichtig) erfolgen müsste.

Mich würde jetzt interessieren:

Ist bereits jemand über diese Thematik gestolpert? Wenn ja, gibt es eine Lösung bzw. kennt jemand Genaueres, warum die BIVG diese Funktionalität außen vor läßt?

Danke im Voraus

Hallo Wilischgeist,

man müsste sich erinnern können. :roll:

Wir haben einen Kunden, der hat vor längerer Zeit auch mal Scheckdateien mittels Sfirm32 zur Dreba geschickt. Also die Dreba hatte da eine Software installiert mit der der Kunde die Schecks einlesen konnte und daraus wurde dann eine Art DTAUS erzeugt. Die Auftragsart hab ich mir leider nicht gemerkt.

Über Fremddateien versenden haben wir diesen Auftrag nur zur Dreba geschickt. Sfirm32 hat zwar einen Warnhinweis geliefert, dass der Textschlüssel 00 nicht vorhanden ist, hat den Auftrag aber trotzdem genommen und übertragen.

Hallo Testerin,

woher weiß SFirm, welche Auftragsart für diese Datei zu verwenden ist. Ich hatte den Punkt Fremddatei versenden bisher immer nur für DTAUS- bzw. DTAZV-Dateien verstanden (letzteres habe ich noch nicht geprüft).

Das Problem ist aber noch eine Stufe vorher. Ich muß diese neue Auftragsart erst mal im Programm definieren können. Hier fehlt mit noch der entscheidende Ansatz.

Ach jetzt weiss ich wieder. Die Aufträge wurden wohl einfach als Lastschriften erzeugt, hatten aber den Textschlüssel 00. Deshalb konnte man sie frei über Fremddateien versenden wegschicken mit der besagten Fehlermeldung.

Also, wie haben den Auftrag nicht über einen freien FTAM-Auftrag verschickt, sondern direkt über Fremddateien.

Hi ho....

hmmm ginge das nicht über den Punkt "FTAM-Auftrag erstellen". Und als Art "FTB Beliebige Datei" ?

Grüße vom Bodensee
Arne

Wenn ich dich richtig verstehe willst du eine neue FTAM-Auftragsart in SFIRM anlegen?

Kein Problem: erstelle bzw. suche die Datei "SFSESSIONS.DEF" im SFIRM32-Verzeichnis mit Notepad. Dort kannst du dir beliebige Auftragsarten erzeugen, die dann über "FTAM. Auftrag erstellen" zu benutzen sind.

Hier meine Datei, ich habe mir ein paar neue AAs gebastelt:

"Anfang"
[SSK123]

[100]
DIR=0
SESS=AES
DESC=Unterschriftenmappe

[101]
DIR=0
SESS=AAU
DESC=Unterschriften Details

[102]
DIR=0
SESS=XSD
DESC=Statistik abhholen1

[103]
DIR=0
SESS=XST
DESC=Statistik abholen2

[104]
DIR=1
SESS=YCV
DESC=Magnetbanddatei senden
"ENDE"

"Anfang" und "ENde" gehören natürlich nicht zur Datei!
Oben steht der Name der BPD, dann in eckigen Klammern Nummern vergeben (einfach hochzählen).

DIR=0 für empfangen, 1 für senden. SESS= Dreistelliges AA-Kürzel und DESC= ist die Beschreibung:

Viel Erfolg!

Hallo und ein gesundes neues Jahr,

welches für mich mit einem Thema aus dem vergangenen beginnt.

Ich beiß´ mir immer noch die Zähne an der Auftragsart ZZV (Senden Scheckdatei) zur Postbank aus. Seitens der Postbank habe ich die Parameter für die DADPROC.FPA bekommen und die Einstellungen dort und in der SFSESSIONS.DEF eingetragen.

Ich habe mal die Übertragung per ELKO/MultiCash und per SFirm32 protokollieren lassen und anschließend die Protokolle (sehr anstrengend Schritt für Schritt gegenübergestellt.

Die Übertragung per ELKO/MC funktioniert einwandfrei, SFirm liefert den Übertragungsfehler "Interner Ablauffehler in FTAM". Bei der Überprüfung der Protokolle habe ich bei den Parametern F_INITIALIZE_RESPONSE und F_BEGIN_GROUP_REQUEST Unterschiede festgstellt. Für den Datentransfer verwendet ELKO das Dateiformat (contents type) FTAM-3, Sfirm dagegen FTAM-1. Sobald das zwischen den beiden Rechner ausgehandelt wurde, beginnt ELKO ordnungsgemäß mit der Übertragung und Sfirm meldet dann den Fehler und beendet die Übertragung.

Kann jemand weiterhelfen?

Was genau hast du denn in die SFSESSIONS und die DADPROC eingetragen?
HL

Hallo Halber Liter,

folgende Einträge sind in der SFSESSION.DEF:

**Dateianfang**
[POSTBANK]

[100]
DIR=1
SESS=ZZV
DESC=Scheckdatei senden
**Dateiende**

Und in der der DADPROC.FPA:
**neuer Eintrag am Ende aller aktiven Sessiontypen**
ZZV,Zahlungsanweisung senden ,182,P, -1,8,0,OU D ,N ,N ,N,N,5,1, 0, 10, 1152,A,E, ,2


Zusätzlich habe ich die Auftragsart BPM mit * deaktiviert, da die gleiche Sessiontyp-Nummer 182 verwendet wird. Der Satzaufbau einer ZZV-Scheckdatei entspricht außerdem nicht dem einer normalen DTAUS-Datei.

Puhh, schwierig, nichts zu sehen...

Ich kenne Multicash nicht, ich meine aber da gibt es eine DADPROC.TYP, das SFIRM/FTAM ist ja auch von Omikron. Ist denn die Zeile in deiner DADPROC.FPA identisch zu der in der Multicash DADPROC?

Gruß
HL

Hallo Halber Liter,



..und bin deshalb von der Funktionstüchtigkeit ausgegangen. Scheinbar übermittelt SFirm zur Übertragung irgendetwas, womit das Modul nicht zurande kommt oder seitens Omikron wurde nicht alles bekanntgegeben, was zur Übertragung notwendig wäre bzw. einstellbar ist.

Um aber auf Deine Frage zurückzukommen, ELKO/MC bietet die Möglichkeit, Auftragsarten über die DADPROC zu definieren oder (und das habe ich gemacht) diese per Menümaske im Programm zu erfassen. Dort setzt man dann z.B. die Übertragungsarten, Satzlängen etc. ein. Und dann kommt das Gemeine: Es funktioniert auch noch

Ich werde wahrscheinlich doch mal an die BIVG herantreten, obwohl es lt. Dokumentation keinen Support für individuell angelegte Auftragsarten gibt:

Hast du mal versucht die dadproc aus MC in Sfirm32 zu verwenden?

Lt. Doku ist deine Auftragsnummer nicht sauber, aber die alte hast du ja auskommentiert - das sollte es eigentlich nicht sein.

Wie sieht denn so eine ZZV Datei überhaupt aus?

Hab übrigens gerade mal versucht mittels des MC AA-Editors unter Verwaltung die ZZV zu erstellen. Erstellung wird grundsätzlich angenommen und gespeichert, in der Liste steht die AA nun.
Nur: die Änderung ist weder in der dadproc.s01 noch in der dadproc.de zu finden. Dateierstellungsdatum ist bei beiden zudem unverändert (irgendwas in 03).
Weitere Dateien im Stil der dadproc gibt es nicht, Suche näch letztem Änderungdatum ergibt auch nichts sinnvolles.

Für mich ein Rätsel, oder MC speichert noch woanders Infos über die AAs.

ELKO/MC baut nach der Installation eine eigene Datenbank (DATEIART.Z*) für die Auftragsarten aus einer existenten DADPROC-Datei oder der individuell erstellen Konfigurationsdatei auf. Danach greift ELKO/MC auf diese zurück.

Deswegen werden an den DADPROC-Dateien keine Änderungen vorgenommen. Aber die Einträge, die man in ELKO/MC per Menü machen kann, sind exakt die, die als Parameter in der Zeile angegeben sind. Also - eigentlich kein Problem

Hast du ZZV nur über das Menü gepflegt oder auch mal tatsächlch wie angegeben über die dadproc?

Es könnte ja auch noch sein das in dem dir genannten Aufbau der dadproc ein Fehler ist, den MC erkennt und behebt bevor das ganze in der dateiart.z* eingestellt wird.
So ganz einheitlich ist es ja dann doch nicht, trotz gleichem Kommunikationsmodul. Schade...

Hallo Captain FRAG,

interessanter Ansatz - werde ich mal prüfen. Ich melde mich dann wieder

Test abgeschlossen.

ELKO/MC hat nach dem Einlesen der DADPROC.TYP die Auftragsart ZZV generiert. Parameter und Angaben waren identisch mit den manuellen Eingaben per Menü. Die Übertragung per ELKO/MC hat auch wieder geklappt. An irgendwas muß es doch liegen .

Ich nehme nächste Woche mal Kontakt zu unseren Kollegen der Postbank auf. Vielleicht ist die Meldung "Interner Ablauffehler in FTAM" bekannt und sie können den entscheidenen Hinweis geben. Ich melde mich dann wieder an dieser Stelle.

Hallo,

die Ursache ist gefunden.

Die Parametervorgaben waren okay gewesen, Einstellungen in SFirm32 ebenfalls. Einzig und allein der Parameterwert 2 (nichtsignifikante Satzlänge am Ende der Zeile) wird seitens SFirm32 "ignoriert". Der Auftrag/Job wird immer mit dem Wert 0 erstellt.

BIVG nimmt das in einem der nächsten Updates mit auf.

Gruß Wilischgeist

Querverweis: http://www.onlinebanking-forum…hp?p=65344