Zahlungsverkehr überschreibt xml-Export!?

A

Alex@GEKKO

Neues Mitglied
Wir arbeiten mit mehreren Hausbanken zusammen. Der Zahlungsverkehr lässt mich aber immer nur eine Bank für die geplanten Überweisungen auswählen. Wenn ich es in Schritten probiere (erst alle Überweisungen für Bank A, dann selber Prozess für Bank B) wird mit jedem neuen Durchlauf die xml im Transferverzeichnis (ohne Nachfrage oder Hinweis!) überschrieben und ich kann nur die der letzten Bank in unser Banking (sfirm) importieren. Hat jemand eine Idee, wie wir es erreichen können, dass mehrere xml erstellt werden, oder sonst alle Zahlungen gleichzeitig im Banking einlaufen?

Danke & Gruß
Alex
 
Nach meinem Stand ist es so:
Im Zielverzeichnis erhalten die Dateien keinen Zeitstempel o.ä. und werden ohne Nachfrage überschrieben. Also hier könnte/müsste man die Dateien nach Erstellung manuell umbenennen oder sie ggf. gleich in einen anderen Ordner kopieren, um sie vor dem Überschreiben zu sichern.

Gibt man ein Archivverzeichnis an, müssten die Dateien dort mit Zeitstempel (im Dateinamen) gespeichert werden, sollten also auch nicht überschrieben werden.
Ohne Gewähr, bitte mal ausprobieren.
Gruß zurück
 
Da gehe ich auch von aus, dass da nicht "erst alles erstellen und dann übertragen" geht.

Meine Empfehlung ist eh immer die, dass vor der Verarbeiten-Meldung die Übertragung erfolgt und nicht erst verarbeitet wird und man dann im bankingprogramm merkt, das was nicht klappt.
1744040356115.png

Daher: Datei erstellen => Meldung in der Sage100 stehen lassen => im SFirm die Datei versenden => in der Sage100 die Meldung bestätigen.
Dann die nächste Bank. ;-)
 
Ben schrieb:
Nach meinem Stand ist es so:
Im Zielverzeichnis erhalten die Dateien keinen Zeitstempel o.ä. und werden ohne Nachfrage überschrieben. Also hier könnte/müsste man die Dateien nach Erstellung manuell umbenennen oder sie ggf. gleich in einen anderen Ordner kopieren, um sie vor dem Überschreiben zu sichern.

Gibt man ein Archivverzeichnis an, müssten die Dateien dort mit Zeitstempel (im Dateinamen) gespeichert werden, sollten also auch nicht überschrieben werden.
Ohne Gewähr, bitte mal ausprobieren.
Gruß zurück
Zum Vergrößern anklicken....
Was ist ein Archivverzeichnis im Unterschied zum Zielverzeichnis?
 
Im Archivverzeichnis wird eine "Sicherheitskopie" der Datei erstellt, ist also einfach eine weitere Speicherung.
Über "Zahlungen wiederholen" lässt sich aber auch jede XML Datei nachträglich noch einmal erzeugen falls etwas nicht geklappt hat.
 
Nochmal zum Archivverzeichnis:
Der Ordner (Pfad) kann unmittelbat unter dem Zielverzechnis, also beim Erstellen der Datei, angegeben werden. Das ist, glaube ich, seit der 9.0.8 so.
Die Datei erhält einen Zeitstempel im Dateinamen, wird also nicht so einfach überschrieben.
Wird kein Archivverzeichnis angegeben, wird auch keine Archivdatei erzeugt.
 
Ben schrieb:
Nochmal zum Archivverzeichnis:
Der Ordner (Pfad) kann unmittelbat unter dem Zielverzechnis, also beim Erstellen der Datei, angegeben werden. Das ist, glaube ich, seit der 9.0.8 so.
Die Datei erhält einen Zeitstempel im Dateinamen, wird also nicht so einfach überschrieben.
Wird kein Archivverzeichnis angegeben, wird auch keine Archivdatei erzeugt.
Zum Vergrößern anklicken....
Ein Archivverzeichnis, für den Zahlungsverkehr sollte nicht notwendig sein, da die Dateien ja mit Zeit Stempel im eingestellten Zielverzeichnis landen. Das Problem ist das Sage nicht den vollständigen Zeit Stempel vergleicht sondern nur den Tag und damit die bereits vorhanden Datei überschrieben wird. Bei Beachtung des Zeit Stempels durch Sage wäre es nicht notwendig auf Überschreibungen zu achten, da die Zeit Stempel eindeutig sind und somit könnte der Anwender auch erst alle Stapel (unterschiedliche Banken) ablegen und im Anschluss übertragen. Auch ein umbenennen oder verschieben wäre so nicht notwendig, wen der Anwender nur weiß, zuerst Bank1 Zeit xx.xx.xx.0845 Bank2 xx.xx.xx.0850 und Bank3 xx.xx.xx.0900 somit auch für den Anwender eindeutig. Jetzt fehlt dann nur noch die Ab- Aufräum-Logik. Alle Dateien älter als Datum zu einem bestimmten Zeitpunkt aufräumen. Kann 1 Woche, 3 Tage etc. sein. Natürlich gehört für eine ausreichende Logik auch noch hinzu aus welcher Sitzung (Benutzer) die Datei erstellt wurde um Fehler zu vermeiden. Auch das ist nicht sauber, bzw. überhaupt nicht implementiert. Zur Zeit noch alles Handbetrieb durch den Anwender / Nutzer inkl. aller möglichen Fehlerquellen. Einfach nur Chaos was sich Sage da leistet und dem Nutzer für viel Geld aufs Auge drückt. .-).
 
Also entweder wir reden hier aneinander vorbei oder euer Programm funktioniert anders.

Beim Zahlungsverkehr wird eine XML Datei erzeugt, diese hat aber einen standardisierten Namen: pain.001.001.03_GBIC_3.xml z.B.
Da ist kein Zeitstempel dabei und diese wird natürlich von der nächsten Datei überschrieben beim nächsten Zahlungslauf.
Im Archivverzeichnis wird die Datei mit einem Zeitstempel versehen, hier werden sogar die Sekunden mit gespeichert. Da ist die Gefahr des überschreibens nicht gegeben...

Von daher ist die Aussage von Ben korrekt!
 
ja etwas reden wir aneinander vorbei. Natürlich könnte auch Sage die Zeit in der Datei erfassen so wie es auch fast alle anderen Programme machen und somit würde das mit dem Archiv entfallen. Warum sollte jemand seine Zahlungsverkehrsdateien archivieren, wen er das doch bereits in seinem Banking Programm bereits hat. Notfalls auch bei seiner Bank. .-)
Hier noch ein Beispiel wie das andere lösen.

1744200619456.png

Nur weil das Sage so macht, wie es momentan noch gemacht wird, heißt das ja nicht dass so etwas in Stein gemeißelt sein muss. Und eine Anpassung der Ausgabe ist doch ein Klacks für jeden einigermaßen handwerklich fähigen Programmierer. Muss ja nicht so fein sein, wie es andere können, dass der Anwender schon an der XML erkennt um was für Vorgangsart es sich handelt (LA für Lastschrift, ZA für Zahlungsausgang usw.).

Die Sage Lösung ist natürlich interessant für Betreuer die auch gerne Girostar mit verticken wollen, was eigentlich nicht notwendig ist. Weil die XML kann jedes Banking Programm oder gegebenenfalls auch die Bank direkt einlesen.

Und zur Aussage von Ben, ist insoweit nicht korrekt, weil der Zeit Stempel ja auch vom Anlage Datum gezogen werden könnte. Jede Datei die erstellt wird erzeugt im Dateisystem auch einen Zeit Stempel. Aber sollte eigentlich auch jedem bekannt sein.

1744201253603.png
 
Zuletzt bearbeitet:
KMoeser schrieb:
Das wäre aber sehr ungeschickt - zumindest für viele unserer Anwender, da dann ja das Bankingprogramm nicht automatisch die (immer gleiche Datei) verarbeiten könnte.
Zum Vergrößern anklicken....
Hier könnte das Auswahlfenster sich öffnen mit dem hinterlegtem Pfad zu den Dateien, bringt mehr Sicherheit und auch das Problem mit mehreren Banken etc. wäre gelöst. Das Auswahlfenster könnte man auch noch automatisch öffnen lassen, so das der Anwender nur eine Klick machen muss. Und er kann die entsprechende Bank wählen. So können auch Zahlungseingänge auf Abo etc. die immer auf ein spezielles Konto laufen sollen gut verwaltet werden. Kann mittlerweile doch jedes Programm, welches auch einen integrierten Zahlungsverkehr verwendet. Sage noch nicht, da ist noch Stand 1998. :)
 
Zuletzt bearbeitet:
Danke! Eure Infos, besonders zum Archiv haben sehr weitergeholfen. Ich habe das Problem für uns jetzt wie folgt gelöst:
Wir erzeugen in der Sage100 hintereinander weg die Zahlungen für 3 Banken und dabei jedes Mal eine normale Datei im Ziel- und eine im Archivverzeichnis. Im Zielverzeichnis haben wir nach den Durchläufen nun wegen des Überschreibens eine und im Archivverzeichnis 3 Dateien. Da Sfirm mehrere Dateien gleichzeitig einlesen kann, holt es sich diese 3 nun aber aus dem Archivverzeichnis (das wir für nix sonst brauchen) und löscht diese direkt nach Import.
Ergebnis: Buchhalterin kann hintereinander alle Zahlungen bereitstellen, diese können später zusammen in sfirm abgearbeitet werden und es entsteht kein Datenmüll (bis auf die eine jeweils letzte Datei im Zielverzeichnis).
Vielen Dank für die Unterstützung hier.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben