schließen

Loginbox

Trage bitte in die nachfolgenden Felder Deinen Benutzernamen und Kennwort ein, um Dich einzuloggen.


  • Username:
  • Passwort:
  •  
  • Bei jedem Besuch automatisch einloggen.


  •  
   

Umsätze aus SFirm in eigener Software verarbeiten



Lutscher offline
Benutzer
Avatar
Ort:  
Beiträge: 2 seit: 07 / 2016
Private Nachricht
Betreff: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 25.07.2016 - 04:14 Uhr  -  
Hallo zusammen,

ich würde gerne die Umsätze von einigen Sparkassen-Konten aus SFirm(aktuelle Version) heraus exportieren lassen und diese dann in einem eigenen Programm verarbeiten.
Die Konten werden voraussichtlich alle 2 Wochen von einem einzelnen SFirm-Mandanten abgerufen, der Lese-Berechtigungen für diese Konten hat.
Dabei sind die Geschäftsvorfälle mit Lastschriften, den Rückgaben Selbiger sowie Gutschriften von besonderem Interesse.
Im Grunde möchte ich bestimmte relevante Konto-Umsätze den Kunden in einer Datenbank zuordnen, um deren Zahlungsstatus fortlaufend zu überprüfen.

Da ich selber einen Mac habe und mein eigenes Konto zudem NICHT bei der Sparkasse geführt wird, hoffe ich auf etwas Hilfestellung bezüglich SFirm.

Die wichtigsten Anforderungen bei der Verarbeitung der Umsätze sind meiner Ansicht nach folgende:
Die Umsätze eines Kontos dürfen NICHT versehentlich einem anderen Konto zugeordnet werden
Bereits importierte Umsätze dürfen NICHT versehentlich erneut importiert werden
Das exakte Zeitfenster der Umsätze(von ... bis ...) MUSS zwecks Plausibilitätsprüfung erkennbar sein
Das Export-Datenformat darf sich NICHT unbemerkt ändern
Die exportierten Daten SOLLTEN hinsichtlich ihrer Integrität überprüfbar sein, z.B. in Form einer Prüfsumme

Welche dieser Anforderungen nun mit SFirm erfüllt werden können, stelle ich mal als Frage in den Raum...
Im Grunde suche ich eine Möglichkeit, die Umsätze aus SFirm heraus so zu exportieren, dass in jedem Umsatz das beteiligte Sparkassen-Konto und so etwas wie eine einmalige ID zum Verhindern eines mehrfachen Imports enthalten sind.
Da es sich um mehrere Konten handelt und deren Anzahl später noch größer werden kann, wäre es schön, wenn man pro Export nur eine Datei mit den Umsätzen aller Konten generieren könnte.
Standards werden über die Zeit weiterentwickelt - dafür habe ich vollstes Verständnis - ich möchte aber in meinem Programm zumindest sicher erkennen können, ob die servierten Daten noch in dem von mir erwarteten Format vorliegen.

Es wäre sehr nett, wenn jemand die grundsätzliche Machbarkeit dieses Vorhabens kommentieren könnte und mir ggf. erklärt, wo in SFirm ich diesbezüglich ansetzen sollte.

Viele Grüße
Lutscher
Dieser Post wurde 6 mal bearbeitet. Letzte Editierung: 25.07.2016 - 04:51 Uhr von Lutscher.
nach unten nach oben
infoman offline
Benutzer
Avatar
Ort:  
Beiträge: 2773 seit: 06 / 2008
Private Nachricht
Betreff: Re: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 25.07.2016 - 08:46 Uhr  -  
Zitat geschrieben von Lutscher
diese dann in einem eigenen Programm verarbeiten.

welches Programm?
oder selbst geschrieben? und welches Format kann hier verarbeitet werden?
Zitat geschrieben von Lutscher
Die Konten werden voraussichtlich alle 2 Wochen

werden die Daten nur nachverarbeitet? weil sonst wären die 2 Wochen doch recht lang

Zitat geschrieben von Lutscher
Die wichtigsten Anforderungen bei der Verarbeitung der Umsätze sind meiner Ansicht nach folgende:

die sind doch teilweise so nicht machbar, da der Kunde evtl. auch falsche Daten (Zahlendreher) o.ä. liefert
der Dubletten-Abgleich müsste ja in deinem Programm vorgenommen werden
nach unten nach oben
Lutscher offline
Benutzer
Avatar
Ort:  
Beiträge: 2 seit: 07 / 2016
Private Nachricht
Betreff: Re: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 25.07.2016 - 16:10 Uhr  -  
Hallo infoman,

vielen Dank für Deine Antwort.

Zitat geschrieben von infoman

welches Programm?
oder selbst geschrieben? und welches Format kann hier verarbeitet werden?

Es handelt sich um ein selbst geschriebenes Programm. Beim Format bin ich als Programmierer relativ flexibel, ich kann z.B. CSV oder XML verarbeiten, oder zut Not auch ein proprietäres Datenformat.

Zitat geschrieben von infoman

werden die Daten nur nachverarbeitet? weil sonst wären die 2 Wochen doch recht lang

Es geht momentan vornehmlich darum, Zahlungseingänge zu verifizieren bzw. säumige Kunden zu finden.
Gezahlt wird überwiegend per Lastschrift, wobei die Beträge entweder zum 01. oder zur Mitte des Monats eingezogen werden.
Daher sind diese beiden Tage aus Sicht der Software besonders interessant. Das Abruf-Intervall wird also in der Regel nicht länger als 2 Wochen sein, möglicherweise aber kürzer.
Steht nach einem Kontenrundruf überhaupt sicher fest, das bis zu diesem Zeitpunkt sämtliche Umsätze in der Banking-Software erfasst sind? Ich bin mir nicht sicher, ob es im Bankwesen Konstellationen geben kann, wo z.B. früh morgens noch gar keine Umsätze vorhanden sind bzw. diese erst später gegen Mittag im Bank-Rechner ankommen. Oder gibt es Umsätze, die technisch bedingt vom System erst verspätet eingebucht werden, dann aber mit einem in der Vergangenheit liegendem Zeitstempel? Möglicherweise darf man dann aus Sicherheitsgründen die Umsätze immer nur bis zum Vortag oder noch weiter zurückliegend verarbeiten, um so etwas auszuschließen. Wobei man selbst dann in der Export-Datei immer noch die Information benötigt, wann denn der Kontorundruf durchgeführt wurde, denn dieses Datum muss ja nicht zwingend mit dem Datum des Exports übereinstimmen.

Zitat geschrieben von infoman

die sind doch teilweise so nicht machbar, da der Kunde evtl. auch falsche Daten (Zahlendreher) o.ä. liefert
der Dubletten-Abgleich müsste ja in deinem Programm vorgenommen werden

Das hat mit meinem Export-Problem bzw. mit den von mir definierten Anforderungen überhaupt nichts zu tun.
Ich verarbeite die Daten erstmal so, wie sie aus dem Bank-Programm kommen. Selbstverständlich gibt es anschließend eine Vorschau, in der man korrigierend eingreifen kann. Aber solche Dinge wie Zahlendreher in der Kundenreferenz sind wirklich nicht Gegenstand meines Export-Problems, denn das findet auf einer anderen Ebene statt. Mir geht es erstmal um andere Dinge, wie z.B. die Datenintegrität der mit SFirm generierten Umsätze. Oder anders ausgedrückt: Ich möchte mit den Anforderungen lediglich sicherstellen, dass ich die Original-Daten von SFirm bzw. vom Bankrechner in einem bestimmten Datenformat erhalte, und diesbezüglich sind alle von mir definierten Anforderungen aus technischer Sicht problemlos erfüllbar, sofern die Bank entsprechende Datenfelder bereitstellt. Genau diese Frage nach den Datenfeldern stelle ich zur Diskussion, also z.B. ob...
  • ...der Bankrechner der Sparkasse die in einem Datenbanksystem normalerweise ohnehin jedem Datensatz innewohnende eindeutige ID in Form eines zum Umsatz gehörenden Datenfeldes an SFirm weitergibt, welches ich dann beim Export bei sich überlappenden Umsatz-Daten zur sicheren Erkennung von Import-Duplikaten nutzen kann.
  • ...SFirm jeden Export mit einer Versions-Nummer versehen kann, um Änderungen am Datenformat erkennen zu können.
  • ...SFirm jeden Export mit einer Prüfsumme versehen kann, um inkonsistente Daten erkennnen zu können.


Viele Grüße
Lutscher
nach unten nach oben
Raimund Sichmann offline
Benutzer
Avatar
Ort:  
Beiträge: 7186 seit: 08 / 2002
Private Nachricht
Betreff: Re: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 26.07.2016 - 08:18 Uhr  -  
Hallo Lutscher,
gerade wenn es um Rücklastschriftverarbeitung geht, bietet sich das CAMT-Format (XML) für die Umsatzdaten an, die SFIRM euch sicherlich liefern kann, da hier Felder aus dem ursprünglichen Datensatz wieder an definierten Stellen auch in der Rücklast zu finden sind.
Das MT940-Format ist meines Erachtens technisch ziemlich veraltet und immer von den Banksystemen aus dem XML-Datensätzen konvertiert worden.

Mit der Doublettenprüfung ist das nicht so einfach, da es leider eben keine eindeutige ID in den Umsatzdaten gibt. Ob Sfirm sowas aus eigenem Datenbeständen mitliefert, kann ich nicht sagen. Zum Problem selbst gibt es bei uns einige Diskussionen, welche Wege man gehen kann, um Doubletten zu erkennen.

Es würde sich aber hier anbieten, die Tagesumsätze aus der EBICS-Schnittstelle zu verwenden, die aus dem Banksystem ohne Doubletten geliefert werden, da ihr ja eh keine Realtime-Verarbeitung benötigt. Diese Tagesumsatzdaten wird Sfirm abholen und in einen bestimmten Ordner ablegen können.

Ergänzung: Schau dir auf ebics.de mal die Spezifikationen an.

Gruß
Raimund
Dieser Post wurde 1 mal bearbeitet. Letzte Editierung: 26.07.2016 - 08:18 Uhr von Raimund Sichmann.
nach unten nach oben
bankboy offline
Benutzer
Avatar
Ort:  
Beiträge: 70 seit: 09 / 2005
Private Nachricht
Betreff: Re: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 26.07.2016 - 13:21 Uhr  -  
Hallo Lutscher,

wir haben recht ähnliche Anforderungen für Bankboy.
Wir setzen auf die auszug- und umsatz.txt auf.
Die wird nach einem Rundruf/Abruf automatisch erzeugt/vortgeschrieben bis wir sie einlesen und dann löschen.

Wir haben seit ca. 20 Jahren Erfahrung mit dem Thema.

Die Bankverbindung ist immer eindeutig gewesen.
Die Doppler sind, wie Raimund schreibt, leider immer mal wieder ein Problem.
Auch fehlen ab und an Umsätze...

Das sind aber Ausnahmen.

Gerne bei Bedarf mehr Details :-)


Gruß aus KA.

Michael
SysCommConsult GmbH
Mathystraße 20
76133 Karlsruhe
sales@syscomm.de
www.syscomm.de
nach unten nach oben
Raimund Sichmann offline
Benutzer
Avatar
Ort:  
Beiträge: 7186 seit: 08 / 2002
Private Nachricht
Betreff: Re: Umsätze aus SFirm in eigener Software verarbeiten  -  Gepostet: 26.07.2016 - 19:02 Uhr  -  
Michaels Info kann ich bestätigen,
Mit "bankboy" hatte syscomm schon ewig - afair - bereits unter BTX-Zeiten Lösungen entwickelt, um z.B. den Städten bei der Buchhaltung Hilfestellung zu leisten, wenn gerade die Politessen Unmengen an 10,00 DM Strafzettel verteilt hatten.
Da es für viele ein Art Sport war, die ohne Rechnungsnummer zu bezahlen oder auch mal nur 1,00 DM war das schon eine interessante Aufgabe ...

Gruß
Raimund
nach unten nach oben
 



Registrierte in diesem Topic
Aktuell kein registrierter in diesem Bereich

Cookies von diesem Forum entfernen  •  FAQ / Hilfe  •  Teamseite  •  Impressum   |  Aktuelle Ortszeit: 25.04.2017 - 08:44