Hallo Leute,

ich habe folgendes Problem:

Ein Kunde sendet Überweisungen aus Sfirm per FTAM. Er möchte anschließend die Daten in ein Buchhaltungsprogramm exportieren. Es wird im Verwendungszweck der Überweisungen jedoch nur die Referenznummer angezeigt aber keine Umsatzdaten! Das ist so nicht gewünscht!

Gibt es hierfür eine eigene ZV-Protokollfunktion, die im Export die Umsatzdaten beinhaltet. Oder wie kann man das Problem sonst noch lösen?

Daten:

SFirm 32, FTAM/EU, Fiducia München (bayerische Volks-/Raiffeisenbank)

Hallo,
in den Umsatzdaten zeigt SFirm das, was es von der Bank bekommt. Eventuell sollte der Kunde mal die Bank ansprechen, ob hier die Daten komplett angezeigt werden können. Wenn das grundsätzlich nicht geht wird dir sicher gleich jemand hier im Forum kompetente Auskunft geben.
SFirm speichert alle gesendeten Daten im Verzeichnis sic. Die Dtaus haben den Namen IZVxxxxx.IZV, wobei in xxxxx eine laufende Nummer hochgezählt wird. Diese Datei könnte man in die Fibu des Kunden einlesen und der Sammelbuchung auf dem Auzug zuordnen. Das sollte die Fibu können.

CU
Frank

Er hat schon bei der Bank angefragt: "Eine Auflösung der Buchungen ist generell nicht möglich und wird auch nicht benötigt" ----> So die Auskunft der Rechenzentrale!

Weiter Ideen?

Leider nein.
Täglich Auszüge abholen und automatisiert exportieren und beim Versand von Zahlungen izv-Datei sichern und ebenfalls in Fibu importieren.

Was benötigt wird ist nach meinem eingeschränkten Urteilsvermögen noch immer Sache des Kunden.

Wie auch immer:

Was braucht die Fibu denn?
MT940? DTA? Eigenformat?

DTA hat Fellini schon aufgelöst, MT940 kann nur von der Bank kommen. Oder soll Sfirm die selber, virtuell erzeugen? Ich denke das kann nicht Sinn der Sache sein.

Also der Export muss nicht automatisch funktionieren. Das ist jetzt mal völlig nebensache.

Wichtig ist hier eigentlich nur der Export von Sammelüberweisungen (mit Auflösung) . Als Fibuprogramm wird "Winsolvenz von STP AG Karlsruhe" eingesetzt. Lt Kundenaussage importiert diese Software "die Umsätze der Bank" also normal MT940. Es geht hier nur um die Umsätze, die Überweisungen selbst werden schon im SFirm vorgenommen!

Mir kommt gerade noch eine spontane Idee:

Wenn der Kunde nicht viele Zahlungen übertagen muss (viel ist relavtiv; bis ca. 1000 pro Übetragung), würde ich zum senden HBCI-Chipkarte nehmen, und die Option "Einzelzahlaufträge senden" anhaken. Da ist die FiBu Einzelumsätze und kann diese kontieren....

Allerdings bekommt er dann einen ebendso großen Stapel an papierhaften Kontoauszügen (20x 1000 .... hmm, da kommen einige Blätter zusammen)

Tschau
Majo

Hallo bratt1,



Der uebliche Weg ist Dir ja bekannt !
Denn: Natuerlich werden die Zahlungsverkehrsdateien aus der FIBU erstellt. Warum erst mit SFIRM32 Zahlungen erfassen, an die Bank senden, wieder zurueckerhalten (MT940 Kontoumsaetze), und dann in die FIBU einlesen? Jede gute FIBU-Software erstellt die Zahlungsverkehrsdateien selber und uebergibt sie ggf. an SFIRM32 zum "Transport" in das Rechenzentrum. Das erspart der Buchhaltung eine Menge Arbeit. Dies zunaechst einmal grundsaetzlich - der Softwarehersteller WEISS das AUCH!! :roll:

Ich bin mir nicht sicher, ob WINSOLVENZ wirklich eine FIBU-Software ist. Aber auf der Internetseite STP steht immerhin (unter Leistungsbeschreibung, dass Schnittstellen zu DATEV oder anderer FIBU-Software vorhanden sind.

Ich empfehle ein direktes Gespraech mit der Hotline von WINSOLVENZ.

Und ich wehre mich mit Händen und Füssen dagegen, das eine Software für sich selber oder andere, Kontoauszüge erstellen soll, die die Bank so nicht geliefert hat.

Stellt euch mal vor, es werden am Tag 2 identische Sammler gesendet, wo möglicherweise nur der Verwendungszweck bei einem Empfänger anders ist.

Die VR-Bank oben liefert nur 2x einen Kurztext mit einer Referenznummer zurück. Soll die Software raten was welcher Auftrag war?

Und jetzt kommt nicht mit Doppeleinreichungen werden eh gelöscht...

Die separate Erfassung aus der FIBU Software macht für mich auch keinen Sinn aber das macht der Kunde so. Aber eine Lösungsmöglichkeit wäre ja wirklich den ZV in der FIBU zu erfassen und in SFirm zu versenden . Dann wäre zum einen die ZV-Dateien bereits in der Buchhaltung drin und alles andere kann er mit MT940 abdecken. Schauen wir mal ob er das so nimmt.

Dann würde Aufgrund der "Doppleprüfung" der Sammler abgelehnt.

Kannst du das denn für alle Banken zusagen?
Ganz bestimmt nicht, bei uns und möglicherweise auch woanders wird eine solche Zahlung nämlich nicht direkt gelöscht sondern zwischengespeichert und zur Ausführung vorgemerkt. Wir räumen dem Kunden eine Meldefrist ein, erfolgt keine Rückmeldung wird der Auftrag freigegeben.

Siche rgibt es auch noch Banken die gar keine Doppeleinreichungskontrolle haben oder diese abgeschaltet haben (könnten wir auch).

Es macht keinen Sinn sein eigenes System zu verallgemeinern. Wenn muss eine solche gewünschte Krückenlösung schon in jedem Fall sauber funktionieren.

Nein, kann ich nicht.
Hab ich wohl zu kurz gedacht.

Hallo,

der gesamte Thread zeigt wieder mal deutlich, daß man immer für wenig Geld/wenig Aufwand überproportional viel Leistung haben möchte. Dabei muß sich jeder Softwarehersteller (insbesondere bei Zahlungsverkehr oder Hausverwaltung) auf ein, zwei Kerngebiete beschränken, da Änderungen (egal ob technischer oder gesetzlicher Seite) immer berücksichtigt werden müssen.

Der Kunde sollte Verständnis dafür haben und sollte seine Abläufe auf Optimierungen hinprüfen (siehe CePe). Ansonsten soll er zu Excel greifen dort sich eine Maske zusammenstellen, diese als TXT- oder CSV-Datei auslesen und zum einen als Importdatei für die Buchhaltung und zum anderen für SFirm32 verwenden. Das ist m.E. nicht die Lösung - aber wem es weiterhilft.

Bei der Auflösung von Sammelposten ist außerdem zu beachten, dass einige Banken/Sparkassen den BuPo für FTAM-Aufträge anders bepreisen. Wird ein Sammelposten in die Einzelaufträge aufgesplittet, kann es ganz schnell (meistens nach einem Monat ) zu einem bösen Erwachen kommen - und zwar, weil die Einzelaufträge jetzt zu den Kosten des Sammelposten abgerechnet werden.

Gruß
Wilischgeist