Eindeutige Identifizierung von Buchungen via Primanota?

Die PN bezeichnet einen "Buchungsstapel" und wird z.B. zur weiteren Kennzeichnung gebraucht. Z.B. Alle Barbuchungen von Terminal 1 der GS Parkstraße haben die PN 4711, Kasse 2 in der Schlossallee hat die 4712, alle Dauerauftragsbuchungen liegen in den PNs 931x ...
Das macht das Leben im ZV ein klein wenig leichter.
Die PN ist also für deine Zwecke leider nicht zu gebrauchen. Eindeutiges Merkmal jeder Buchung ist nur die Referenz. Die wird aber leider (zumindest bei den Spardosen) nicht im Homebanking übermittelt.

CU
Frank

Welche meinst du? Die MUR? Das ist eher ein bankinternes Gerät für das Interbanken-Clearing. Oder die Dateinumemr aus der Sammler-DB? Oder die A6 Kennung? Gibt so vieles....

Eine Primanota wird arbeitstäglich nur einmal vergeben, soweit richtig. Von 0:00 bis 24:00 Uhr und jeden Tag wieder Ist nur eine Art Umsatzkennzeichen, um welchen bakinternen Typ von Umsatz es sich handelt. Ist nichts Kundenspezifisches.

Ich sehe gerade - beide Lastschriften sind 005...

Die PN wird auch in deinem Fall in der Bank nur einmal pro Tag vergeben. Eine PN ist eine Sammlung von Buchungen gleichen Typs, z.B. alle Online-Einzelüberweisungen. Das können auch Millionen einzelne Stücke sein.

Würde die Bank nun Ihre Primanote abfragen, wären da dein beiden Buchungen drin und ganz viele andere anderer Kunden aber derselben Art.

Die Frage ist ja nur, wer vergibt die PN für was. Da gehst du von einer anderen Annahme aus als der Satz aus der Wiki eigentlich meint.

Ich meine, guck dir die Länge der PN-Nummer an: Soll das ne eindeutige ID prp Buchung sein? Unsere sind sogar nur 4-stellig.

Raimund hat es schon genau richtig dargestellt. Die PN war im beleghaften ZV enorm wichtig, weil sie einen Buchungsstapel buchungstäglich eindeutig bezeichnet hat. Sie diente damit aber lediglich der Recherche von der Zahlungsreklamation zum Beleg hin.
Sie diente noch nie der eindeutigen Identifizierung eines einzelnen Belegs. So kam es früher regelmäßig vor, dass sogar ein und die gleiche Buchung in der gleichen PN doppelt war, nämlich immer dann wenn Kunden den Durchschlag mit abgegeben haben und dies bei der Verarbeitung nicht aufgefallen ist.

Dies alles widerspricht auch nicht der Wiki-Aussage. Eine PN wird buchungstäglich tatsächlich nur einmal vergeben. Wieviele Zahlungen in ihr zusammengefaßt werden ist eine ganz andere Frage. Im vollelektronischen Bereich (Daueraufträge, Lastschriften) dürften es wohl annähernd alle des ganzen Buchungstages sein. Im Schriftenlesebereich kommt es auf die Verarbeitungsart an. Es gibt stapelgebundene Systeme (z.B. EBS2000 von Beteasystems, früher Kleindienst) wo i.d.R. (je nach Scanner) rund 100 bis 200 Belege in eine PN gepackt werden, sonst wird es zu unübersichtlich. Bei stapelungebundenen (z.B. AVIS von Unisys) werden die PN's mehr oder weniger virtuell erst bei der Datenausgabe gebildet. Und das kann sich dann von 50 bis 999 Stück bewegen, je nach dem, wie es konfiguriert ist. Beide Systeme haben - wie überall im Leben - gravierende Vor- und Nachteile. Ist ein bißchen ZV-Philosopie

Für den hier gewünschten Zweck ist die PN definitiv garnicht zu gebrauchen, nicht einmal ansatzweise.

Grüße

Meiner Meinung nach ist die einfachste Lösung die, den Abruf auf abgeschlossene Buchungstage zu beschränken (Abruf bis heute -1 Werktag) bzw. alles abzurufen und nur die Umsätze als endgültig zu betrchten und zu verarbeiten die eben älter als heute sind. Das Startdatum der Umsatzabfrage ist dann auch klar.

Alles andere kann man ja gesondert darstellen und von der Möglichkeit der Umsatzkategorisierung o. Notizfunktionen ausnehmen.

Bei EBICS funktoniert das in etwa so, weil einfach bankseitig nur minimal 1x täglich Umsätze geliefert werden und dort nur noch nicht ausgelieferte Umsätze enthalten sind. Das Verhalten müsste auf HBCI Ebene über die von/bis Zeitraumsteuerung nachgebaut werden.

Zumindest geht das ohne die 100% Doppelerkennung, ist aber natürlich auch mit dem Einsatz und Aufwand von Gehirnschmalz im Sinne anderer Programmierlogiken und Darstellungen verbunden.

Ich hab den Thread jetzt per Forensuche aufgetan und mit Spannung verfolgt - gibt es denn eine Lösung für das Problem?

Mein Team hier hat sich überlegt, einen Hash aus Kontonummer der Gegenseite, Betrag und Verwendungszweck und Buchungsdatum einen Hash zu errechnen aber wir fragen uns nun, ob das nicht einfacher ginge - und mit Datumsgrenzen beim Abrufen der Umsätze hatten wir eben auch das Problem, das Banken teilweise nachträglich Umsätze ausweisen und diese dann fehlen, bzw. teilweise Duplikate erscheinen.

Ich hatte kurz überlegt, ob man mit der Institutsreferenz (Feld "instref" im GVRKUmsatz) verwenden könnte, aber die scheint ja auch nur sporadisch belegt zu sein.

Irgendwelche Ideen?

Hallo Raimund,

danke für deine Antwort. Ich hab ja schon befürchtet der Thread wäre tot.
Also die Zielgruppe sind unglücklicherweise alle Banken die HBCI mit PIN/TAN anbieten (so ziemlich alle grossen, ausser Commerzbank soweit ich weiss) - und wir nutzen bislang EBICS nicht

Nach der Selbstverpflichtung zu gehen sollten das alle Banken in Deutschland und Frankreich tun, nicht nur diejenigen mit Geschäftskundensegment.


Quelle: http://www.ebics.de/

Raimund, es ist - wie überall - mal wieder in sich unstimmig formuliert. Denn weiter unten steht:

und

Wenn jetzt eine Bank tatsächlich keine Firmenkunden hätte würde sie sich vermutlich darauf zurückziehen.