SEPA Komponente gesucht

[arnof]

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

[jobo]

Zitat:

Zitat von ele (Beitrag 1242673)

@jobo: Bold-Tags werden in einem Code-Block nicht unterstützt. Dein Beispiel ist deswegen nicht korrekt, denn

Code:

[B]FRST[/B]

ist kein gültiger SequenceType. Korrekt wäre

Code:

FRST

.

Zitat:

Zitat von DeddyH (Beitrag 1242675)

Wahrscheinlich wollte er die Stelle nur in der DP hervorheben, aber der Parser unterstützt das innerhalb von Code-Tags nicht.

So ist es, danke DeddyH!

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Zitat:

Zitat von arnof (Beitrag 1242861)

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

Das ist ja der Hit.
Ich sitze hier grad und frag mich, wo man in einer CAMT Datei die IBAN des Buchungssatzes findet. Es wurden gefühlt 10 neue TransaktionsID für die tollsten Infos eingeführt (plus der IBAN selbst), aber CAMT (oder sagen wir die Bank) liefert sie nicht zurück.
Dass man wenigstens eine Zuordnung über eine IBAN machen könnte, ist wohl nicht vorgesehen.
Wer soll auf einer solchen "Basis" denn Buchungen verarbeiten?

[ele]

Zitat:

Zitat von jobo

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Nicht nach meinem Verständnis. Das PmtTpInf-Element kann mehrere DrctDbtTxInf-Elemente (Buchungen) enthalten. Deswegen heisst es im ISO2022-Standard für das SequenceType-Element auch

Zitat:

Identifies the direct debit sequence, such as first, recurrent, final or one-off.

Beim CAMT kenne ich mich nicht so genau aus (ich müsste mal den Arbeitskollegen fragen). Aber es kann sehr gut sein, dass die Bank das nicht mitliefert. Wie ich schon erwähnt hatte, trotz Standard gibt es verschiedene Ausprägungen (je nach Land und Bank). Ist eigentlich zum heulen aber anderseits generiert das für uns Arbeit und sichert so unsere Arbeitsplätze :wink:.

[arnof]

Zitat:

Zitat:

Zitat von arnof (Beitrag 1242861)

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

Das ist ja der Hit.
Ich sitze hier grad und frag mich, wo man in einer CAMT Datei die IBAN des Buchungssatzes findet. Es wurden gefühlt 10 neue TransaktionsID für die tollsten Infos eingeführt (plus der IBAN selbst), aber CAMT (oder sagen wir die Bank) liefert sie nicht zurück.
Dass man wenigstens eine Zuordnung über eine IBAN machen könnte, ist wohl nicht vorgesehen.
Wer soll auf einer solchen "Basis" denn Buchungen verarbeiten?

Ja unsere Festellung war, dort wo bei elektronik Banking IBAN und BIC stehen sollte kommt von der Raiffeisenbank noch Kontonr und BLZ, dafür schießen die IBAN und Bic nochmals in den Verwendungszweck :pale: Von den ganzen ID's, die man benutzen könnte mal abgesehen (EndToEnd Id für die Eindeutige Zuweisung von Belegen)


[Update] SEPA Verlängerung beträgt 6 Monate

[jobo]

Zitat:

Zitat von ele (Beitrag 1242869)

Zitat:

Zitat von jobo

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Nicht nach meinem Verständnis. Das PmtTpInf-Element kann mehrere DrctDbtTxInf-Elemente (Buchungen) enthalten. Deswegen heisst es im ISO2022-Standard für das SequenceType-Element auch

Zitat:

Identifies the direct debit sequence, such as first, recurrent, final or one-off.

Du hast Recht, ich habe meinen eigenen Code falsch gelesen :oops:

Zitat:

Beim CAMT kenne ich mich nicht so genau aus (ich müsste mal den Arbeitskollegen fragen). Aber es kann sehr gut sein, dass die Bank das nicht mitliefert. Wie ich schon erwähnt hatte, trotz Standard gibt es verschiedene Ausprägungen (je nach Land und Bank). Ist eigentlich zum heulen aber anderseits generiert das für uns Arbeit und sichert so unsere Arbeitsplätze :wink:.

Ich glaub nicht, dass das Sinn macht. Ich bin mir zwar nicht sicher, ob das ein Schweizer Phänomen ist oder das einer Schweizer Bank, aber ich "forsche" nur etwas. Die Kunden wollen Auszüge weiter auf MT940 Basis abwicklen. Da dort ebenfalls "nichts" brauchbares rüberkommt, hab ich mal einen Blick auf CAMT geworfen.

[ele]

Die MT940er sind noch viel schlimmer. Da sind gar keine Felder für solche Informationen vorgesehen, d.h. jede Bank packt die zusätzliche Informationen einfach ins Feld 86, aber jede auf eine andere Art und Weise.

Beim CAMT sind die Felder wenigstens vorgesehen, aber ob eine Bank diese auch wirklich verwendet steht in den Sternen. ISO2022 und SEPA eigentlich eine gute Idee, aber meiner Meinung nach wurde das Ziel einer Vereinheitlichung völlig verfehlt. Der Formate-Dschungel wird nun einfach mit XML fortgeführt.

[arnof]

Ihr Redet ja hier von Schweiz und Co.; Vereinheitlichung, das Format könnten auch Politiker mit Lobbyisten zusammen gestellt haben. Jedes Land macht trotzdem seinen eigenen "scheiss". Wenn man die IBAN Sonder-Regeln in Deutschland anschaut dann könnte man echt "Kotzen".

PS: die Bundesbank hat eben wieder gemailt: "die ab 3. März 2014 gültige Version der Übersicht der IBAN Regeln im ExtraNet der Deutschen Bundesbank zur Verfügung"

Ah ha 3 März, muss man dann nochmals die IBAN berechnen, man sollte ja vorher umgestellt haben! Die sind schon nicht ganz sauber ......

[sh17]

Ist bezüglich der mehrere Sequenzen jetzt schon was angedacht?

Wie sieht es denn Arnof? Komponente erweitern? Den Nutzer selbst die Lastschriften in die 4 Lastschriftarten einordnen lassen oder vor dem Export die Lastschriften entsprechend vorsortieren und die Ausgabe anpassen. Dabei wird aber ggf die Reihenfolge verändert.

[herbstrot]

Moin,

ich hatte das mal in der Komponente verändert, so das verschiednen Typen und Termine in eigene Zahlblöcke gepackt werden. Ist laut Definition eigentlich zulässig, nur die Sparkasse hat mir da einen Strich durch gemacht. Pro Sepa wird nur ein Zahlblock akzeptiert.

Wer hat eigentlich gesagt, mit Sepa wird alles einfacher? :evil:

[sh17]

Da würde ich der Sparkasse mal eine Frist bis August stellen das zu unterstützen :duck:

[arnof]

Zitat:

Zitat von herbstrot (Beitrag 1243455)

Moin,

ich hatte das mal in der Komponente verändert, so das verschiednen Typen und Termine in eigene Zahlblöcke gepackt werden. Ist laut Definition eigentlich zulässig, nur die Sparkasse hat mir da einen Strich durch gemacht. Pro Sepa wird nur ein Zahlblock akzeptiert.

Wer hat eigentlich gesagt, mit Sepa wird alles einfacher? :evil:

Deswegen ist das so aufgebaut wie es ist, sonst hatten verschiedene Banken Zicken gemacht. Bei meinen zur verfūgung stehenden Banken war die Sparkasse die erste, die überhaupt sepa Lastschriften konnte (im Oktober ).

In meiner Doku steht ja das man nur eine art Lastschriften in eine sammeldatei packen darf. Das sollte in der Praxis kein Problem darstellen.

Vr Banken lehnen den ganzen Sammler direkt ab wenn denen was mit dem Datum nicht passt!

[arnof]

Zitat:

Zitat von sh17 (Beitrag 1243462)

Da würde ich der Sparkasse mal eine Frist bis August stellen das zu unterstützen :duck:

Die Sparkasse kann auch nichts dafür, das sind die Unfähigen im Rechenzentrum, die mit solchen Anforderungen garnicht gerechnet haben. Diese befinden sich aber in netter Gesellschaft da die Verschiebung sicher nichts mit Unternehmen zu tun hat, sondern mit buggy Bankensystemen!

[sh17]

Nur Verrückte....

Danke Arnof für die Erklärung.

Anders gefragt, interessiert die Bank eigentlich ob es die erste oder Folgelastschrift ist? Ich hatte da mal sowas raus gehört, das eigentlich alles Folgelastschriften sein könnten.

[arnof]

Zitat:

Zitat von sh17 (Beitrag 1243518)

Nur Verrückte....

Danke Arnof für die Erklärung.

Anders gefragt, interessiert die Bank eigentlich ob es die erste oder Folgelastschrift ist? Ich hatte da mal sowas raus gehört, das eigentlich alles Folgelastschriften sein könnten.

Ja Sparkasse lässt alles zurück gehen wenn nur folge lastschrift gesendet wird!

Ist mir zugetragen worden das man unbedingt darauf achten soll!

[arnof]

Wir (also meine Firma) wird erstmal nur Einzellastschriften machen bis einer meckert, da ich das mein Personal erstmal nicht zutraue alles richtig zu machen.

Ich habe heute erst die Gelangsbestätigung eingeführt, das sind sonst zu viele Baustellen :idea:

[jobo]

Zitat:

Zitat von arnof (Beitrag 1243509)

Die Sparkasse kann auch nichts dafür, das sind die Unfähigen im Rechenzentrum, die mit solchen Anforderungen garnicht gerechnet haben. Diese befinden sich aber in netter Gesellschaft da die Verschiebung sicher nichts mit Unternehmen zu tun hat, sondern mit buggy Bankensystemen!

Besonders der letzte Satz gehört unterstrichen! Als sich zuletzt die Warnungen der Banken (verbände) häuften, besonders die kleinen Unternehmen hätten Ihre "Hausaufgaben" nicht gemacht, wusste ich nie, ob ich lachen oder weinen soll.

Eine Bank, die weder ein halbes Jahr vor Stichtag noch 1 Monat vor Stichttag technische Fragen beantworten kann ist ein Unding.
Eine Spezifikation in der bei jedem 2. Wert steht: "Fragen Sie im Zweifel, wie es Ihre Bank hält" allerdings ebenso.

Ich schätze, die haben da alle IBM Großrechner im Keller und versuchen, die gemäß Ihre 50 Jahre Rahmenwartungs- und Mietverträge einfach nur am Laufen zu halten. Immer wenn was geändert werden muss, kommt ein IBM Techniker aus NSA , äh USA und die Verträge gehen wieder von vorne los.

[vagtler]

Hier möchte ich aber auch einmal die Gelegenheit nutzen und mal eine Lanze für die Sparkasse unserer Region brechen:

Als Anbieter von einer Standard-Software haben wir die SEPA-Integration im zweiten Halbjahr 2012 vollzogen. Dabei hat uns die Sparkasse schon damals umfassend mit Dokumentationen und Testläufen unterstützen können, so dass wir seit Mitte letzten Jahres SEPA-Transaktionen (sowohl Basis als auch Firmen) vollumfänglich unterstützen.

[jobo]

Ja, ich hab im letzten Absatz natürlich übertrieben. Es gibt auch die Guten. :)
An der Stelle muss man aber dann noch festhalten, dass es sich bei diesem Beispiel (Sparkasse) ja auch um ein spezielles "Business Modell" handelt.
Ein Unternehmen(?), dass keine Gewinne machen darf, müsste sich sehr schämen, wenn es an der Stelle pennt.

[arnof]

Ja die Sparkasse hat uns auch immer am besten Unterstützt (hatte ich ja auch geschrieben; die ersten die SEPA Lastschriften konnten). Mit den Formaten ist das so eine Sache, wer sich schon mal mit EDI (viele Konzerne haben auch solche Altlasten zum Heizen im Keller) beschäftigt hat, der braucht keine Nagelschere mehr!

[FrankJ28]

Hallo,
weiß jemand, ob es zu dem neuen Lastschrift-Eilverfahren (COR1) irgendetwas zu beachten gibt?
@arnof: Das wäre im einfachsten Fall ja eine neue Art (12?), die dann das Tag "Cd" mit "COR1" versorgen würde.
Jemand Einwände?
Danke und ciao
Frank

[arnof]

Zitat:

Zitat von FrankJ28 (Beitrag 1247780)

Hallo,
weiß jemand, ob es zu dem neuen Lastschrift-Eilverfahren (COR1) irgendetwas zu beachten gibt?
@arnof: Das wäre im einfachsten Fall ja eine neue Art (12?), die dann das Tag "Cd" mit "COR1" versorgen würde.
Jemand Einwände?
Danke und ciao
Frank

Du musst einfach statt CORE COR1 Ausgeben und die Kopfnummer die die Sepa Version angibt entsprechend auf V2.7 Einstellung erhöhen

Aber wie das so ist das geht noch nicht bei allen Banken

Ps ich habe es schon umgesetzt aber noch keine Zeit fuer ein offizielles Update gehappt!

[jobo]

Ich habe von unserer COR1 Implementierung sehr schlechte Rückmeldungen bekommen bezüglich eines Kreditinstitutes.
Systematisch zurückgewiesene Lastschriften (weil falsch interpretierte Weiterverarbeitung ) beim Zielkreditinstitut.
Beauftragung erfolgte allerdings aus Österreich soweit ich weiß.
Ich würde dringend zu Tests mit den großen "Anbietern" raten.

[arnof]

Sag ich doch, es ist grausam. Ich habe SEPA 2.7 umgesetzt und 2 Stunden später ist es mir schon um die Ohren geflogen. Also wieder alles auf 2.6 zurück:

z.B. von allen VR/Sparta usw die an dem Fiduciarechenzentrum hängen:

hier wird zwar via HBCI SEPA COR1 unterstützt (ist erst im SEPA V2.7 enthalten), aber bei normalen Überweisungen und Lastschriften wird V2.7 erst ab der 13 KW unterstützt!

Ob COR1 nicht nur was deutsches ist, kann ich noch nicht einmal abschätzen, die Anleitung ist hier nur von/für deutsche Banken. Ist das gleiche mit deutschen Umlauten die verpflichten sich die deutschen Banken das zu unterstützen, aber ins Ausland geht das nicht!

[sh17]

COR1 ist doch nur für Deutschland, oder nicht? d.h. doch nur frühestes Zahlungs/Buchungsziel 1 Tag

[jobo]

Ich kann nicht wirklich sagen, wie die Wege sind. Bin nicht mal sicher, dass es über Österreich ging. Falls ja, dort ist es seit bald einem Jahr aktiv, kann aber angeblich nicht zwischen den Ländern DE/AT genutzt werden.

[arnof]

Ich habe nun das Update bereit gestellt und allen als Mail gesendet. Falls jemand das nicht erhalten hat, so soll er im SPAM Ordner mal nachschauen!

Neuerungen:

- aktuelle Blz+Bic Datenbank die ab März 2014 gültig ist
- SEPA 2.7 fähig incl. COR1 Lastschriften (siehe XML_KOPF)
- IBAN Ermittlung: Sonderregel der Commerzbank integriert
- Neue Funktion Find_BIC_BANK sucht den Banknamen heraus

[aspettl]

Hallo zusammen,

da ich letzten August selbst SEPA-XML-Lastschriftdateien in einer Delphi-Anwendung benötigte, habe ich auch eine Implementierung erstellt. Umsetzung als einfache Unit. Unterstützt jetzt neu auch SEPA-Überweisungen, COR1/Standard 2.7 gibt es schon länger.

Die Lizenz ist GPL Version 2 oder höher - in der Hoffnung, dass es jemandem hilft. Eine Doku gibt es nicht, aber eine einfache Beispielanwendung, die mitgeliefert wird. Unter Lazarus funktioniert es außerdem ebenfalls.

URL: http://www.spettl.com/delphi-sepa-xml/

Viele Grüße
Aaron

PS:
- Getestet wurde nur in Deutschland, weitere Länder habe ich auch derzeit nicht eingeplant.
- IBAN/BIC-Konvertierung etc. ist nicht (!) enthalten.
- Unit-Tests sind mittlerweile teilweise vorhanden.

[dataspider]

Zitat:

Zitat von aspettl (Beitrag 1249037)

Hallo zusammen,

da ich letzten August selbst SEPA-XML-Lastschriftdateien in einer Delphi-Anwendung benötigte, habe ich auch eine Implementierung erstellt. Umsetzung als einfache Unit. Unterstützt jetzt neu auch SEPA-Überweisungen, COR1/Standard 2.7 gibt es schon länger.

Aaron,

dein Werk ist sehr löblich. Ich habe es mir mal angesehen, da ich nach etwas einfachem gesucht habe.
Allerdings ist deine Umsetzung ziemlich...Buggy.

Deine ganzen Validate - Methoden geben Stringlisten zurück, die niemals wieder freigegeben werden.
Du erzeugst im Constructor Objekte, die nicht wieder freigegeben werden.
Die Objekte (Belege), die du im Array speicherst, werden auch nicht freigegeben...

Memory Leak' s en Mass...

Da musst du noch einiges tun.

Frank

[aspettl]

Hallo Frank,

danke für das Feedback. Das kommt offenbar davon, wenn man zu lange nicht in der Delphi-Ecke war (Garbage Collection...). Ich habe jetzt aber eigentlich schon so gut wie alle Memory Leaks entfernt. Morgen schaue ich mir das nochmals an und erstelle dann vermutlich ein neues Release.

(In den Unit-Tests lasse ich manche in Bezug auf die Validation-Stringlisten allerdings bewusst drin, weil dort unwichtig und besser für Code-Lesbarkeit. Die Objekte im Array - da könnte man sich darüber streiten, ob diese überhaupt automatisch freigegeben werden sollten, da sie schließlich auch außerhalb der Klasse alloziert werden, also vor dem Hinzufügen. Ich habe es nun aber so gemacht, da das schon der übliche Anwendungsfall sein sollte.)

Gruß
Aaron

[sh17]

Moin,

ist das Feld

Initiating Party
<InitgPty>
Benennung Auftraggeber bei
SEPA Überweisung oder
Einreicher bei SEPA Lastschrift

mit Name <Nm>

pflicht?

Ebenso <Dbtr><Nm></Nm></Dbtr>

Falls nicht, könnte man in der Komponente, falls der String leer ist, die Ausgabe unterdrücken. Mit leerem Inhalt kommen manche nicht klar.

[Union]

<InitgPty><Nm> sowie <Dbtr><Nm> haben eine minimale Länge von 1, sind also Pflichtfelder. Wenn bestimmte Banken nicht mit Standard-XML-Syntax klarkommen, schick das fertige File eben nochmal durch einen entsprechenden Beautyfier.

[sh17]

OK, Danke.

[himitsu]

Wir versuchen seit 'ner Weile diese SEPA-Komponente bei uns zu implementieren.

Nja, seit heute darf ich mich nun damit "beschäftigen". :wall:
Kollege war letzte Woche krank, ist jetzt im Urlaub und nun darf ich rausfinden wie weit das bis jetzt umgesetzt ist.

Was ich aber so nebenbei mitbekommen hatte, also wo es wohl Probleme gab:

• Nirgendwo war scheinbar dokumentiert wie groß welche Felder sein müssen/sollten.
  Wir halten die Daten ja in der Datenbank und beim Design der Tabellen wäre das praktisch zu wissen.
• Scheibar sind die Bezeichnungen etwas uneindeutig. Es wäre sozusagen nicht schlecht, wenn die Property der Klassen aush so (ähnlich) heißen würden, wie die Felder in der SEPA-Doku.
• mehr weiß ich jetzt noch nicht ...

Sind eigentlich alle, welche sich zufällig arnof nennen, auf den Delphi-Tagen?

[jobo]

Feldlängen sind egal ;)

Die entscheidenden Daten sind scheinbar, Mandatsreferenz und ca 5 andere Referenznummern, die bei Debit und Credit auf Deine Original-Daten zeigen.
Am Ende bekommst Du mit viel Glück per CAMT eine dieser Referenzen zurück und kannst es wieder zuordnen, Hurra! Ansonsten gibt es in CAMT so tolle Felder wie "adtnlInfo" oder so ähnlich, wo ein Haufen mt940 Schmock drin steht, zumindest bis zu einer unsichtbaren Grenze (>Feldlänge). Daraus kann man per Wahrscheinlichkeitsrechnung und Patternmatching u.U. auch noch eine Zuordnung schaffen.
Was glaub ich ganz schlecht ist, wenn ein Kunde aus freien Stücken einen Überweisungsträger ausfüllt und das irgendwie eingeordnet werden muss..

[himitsu]

Man kann natürlich für alle Felder einfach VARCHAR(8000) nehmen, oder gar MEMO, aber wir wollten die Datensätze nunmal nicht sinnlos aufblähen. :stupid:
Aber wenn man ein Feld nun zu kurz macht und es dann später irgendwann mal beim Kunden knallt ... :?

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1266204)

Man kann natürlich für alle Felder einfach VARCHAR(8000) nehmen, oder gar MEMO, aber wir wollten die Datensätze nunmal nicht sinnlos aufblähen. :stupid:
Aber wenn man ein Feld nun zu kurz macht und es dann später irgendwann mal beim Kunden knallt ... :?

Ja, die SEPA Maxlänge sollte schon drin sein.
:)

[sh17]

Welche Felder meinst Du denn?

Verwendungszweck bekommst Du aus der SEPA-Doku.
Und Mandatsreferenzen wirst Du ja jetzt nicht 8000 Zeichen nehmen wollen. Einfach ne sinnvolle BEnutzergreundliche Länge festlegen.

[himitsu]

Zitat:

Zitat von sh17 (Beitrag 1266209)

Welche Felder meinst Du denn?

Am Einfachsten wäre es, wenn ich den aktuell nicht verfügbaren Kollegen fragen würde ... ist nur nicht ganz so einfach.

Zitat:

Zitat von sh17 (Beitrag 1266209)

Verwendungszweck bekommst Du aus der SEPA-Doku.

Jaaaa, da war auch das Problem mit der Benamung, also daß man erstmal suchen mußte welches Feld zu den Property gehört. :stupid:

[add]
Ich schau auch lieber nicht mehr in den QuellCode.
(das tut ja teilweise weh, aber egal ... Hauptsache es läuft :stupid:)

Aber ein paar Kleinigkeiten erwähn ich schonmal:

• Viele Funktionen bieten eigentlich alle Compiler (Delphi, FPC/Lazarus), so daß man sie auch ruhig verwenden darf, also vorallem F_Round und p_Str.
• Auch der Code im DoubleToXML kann locker mit vorhandenen Standardfunktionen erfüllt werden, wie z.B. FloatToStr oder Format, mit passendem FormatSettings.
• Zeile ... sLineBreak kennt man? Wobei es nicht ganz optimal ist, dieses in der XML zu verwenden. Nimm besser nur #10. (falls die Gegenseite ebenfalls das XML manuell behandelt und keine XML-Libs nutzt)
• die Fehlerbehandlung: Wenn schon Fehlermeldungen, dann könnte man auch alles Melden.
  Und bitte die Meldungen etwas aussagefähiger/zuordenbarer benennen, denn in größeren Programmen wäre es nett, wenn man halbwegs erkennt wo die Meldung her kommt.
  
  Delphi-Quellcode:

  function IBAN_Check(IBAN: AFS_String):Boolean;
  ...
  begin
   ...
   if not ok then begin
    Warnung:='Land der IBAN ist falsch oder unbekannt';
    Exit;
   end;
   ...
   if Length(IBAN)<>4+sk+sb then begin
    Warnung:='Länge der IBAN ist falsch (Soll:'+IntToStr(4+sk+sb)+', Ist:'+IntToStr(Length(IBAN))+')';
    Exit;
   end;
   ban:=Copy(IBAN,5,255);
   ban:=ban+Copy(IBAN,1,4);
   ban:=SEPA_AplhaToInteger(ban);
  
   //LG: Wenn wir Warnungen ausgeben, dann machen wir das immer.
   if ModuloXY(ban,97) <> 1 then begin
     Warnung:='Prüfsumme der IBAN ist nicht korrekt.';
     Exit;
   end;
  
   result:=True;
  end;

• Und ich empfehle dir, dich mal mit Conditional-Expression auseinanderzusetzen. Delphi versteht die bestimmt schon seit mindestens Delphi 7.
  
  Delphi-Quellcode:

  {$IF CompilerVersion >= 23.0}  // XE2
  [ComponentPlatformsAttribute(pidWin32 or pidWin64 or pidOSX32
    {$IF CompilerVersion >= 25.0} or PidiOSDevice or PidiOSSimulator {$IFEND}  // XE4
    {$IF CompilerVersion >= 26.0} or pidLinux32 or pidAndroid        {$IFEND}  // XE5
  )]
  {$IFEND}
  TAFS_SEPA = class(TComponent)

  Erstmal wird der Code dadurch kürzer und Übersichtlicher.
  Und der Code ist grundsätzlich schonmal auf Delphi XE7+ vorbereitet. (abgesehn von neuen Features, aber das Alte läuft wenigstens weiterhin, zu bestimmt 95%, solange Emba nicht wieder etwas aus- oder komplett umbaut)

[mm1256]

Zitat:

Was ich aber so nebenbei mitbekommen hatte, also wo es wohl Probleme gab:
Nirgendwo war scheinbar dokumentiert wie groß welche Felder sein müssen/sollten.
Wir halten die Daten ja in der Datenbank und beim Design der Tabellen wäre das praktisch zu wissen.

Das ist doch im Web zig-fach dokumentiert. Guckst du zum Beispiel hier http://www.hettwer-beratung.de/sepa-...licher-aufbau/

[arnof]

Zitat:

Zitat von himitsu (Beitrag 1266195)

Wir versuchen seit 'ner Weile diese SEPA-Komponente bei uns zu implementieren.

Nja, seit heute darf ich mich nun damit "beschäftigen". :wall:
Kollege war letzte Woche krank, ist jetzt im Urlaub und nun darf ich rausfinden wie weit das bis jetzt umgesetzt ist.

Was ich aber so nebenbei mitbekommen hatte, also wo es wohl Probleme gab:

• Nirgendwo war scheinbar dokumentiert wie groß welche Felder sein müssen/sollten.
  Wir halten die Daten ja in der Datenbank und beim Design der Tabellen wäre das praktisch zu wissen.
• Scheibar sind die Bezeichnungen etwas uneindeutig. Es wäre sozusagen nicht schlecht, wenn die Property der Klassen aush so (ähnlich) heißen würden, wie die Felder in der SEPA-Doku.
• mehr weiß ich jetzt noch nicht ...

Sind eigentlich alle, welche sich zufällig arnof nennen, auf den Delphi-Tagen?

arnof ist leider nicht auf den Delphitagen, da ich an diesen Termin schon was anderes habe (für die Veranstalter ohne Kinder/klein Kindern: schaut doch einfach mal nach den Schulferien bei der Planung )

Die Doku ist dabei zum einen meine zum anderen die Org SEPA Anleitung. Was ist denn das Problem? varchar 8000 ist ja wohl hochgradig unsinnig …..
Daneben sind Beispiele vorhanden mit einer Access Datenbank, dort sieht man einen möglichen Aufbau für eine Datenbankanbindung!

PS: es gab auch mehrere Updates und fixes, die sind immer an die Besteller Mailadresse versendet worden!


Zu deinen Quellcodetipps: nicht jeder benutzt XE5/XE6 50% der Anwender (aus diesem Forum) benutzen Delphi5 einige ältere Versionen, da ich dynamische Arrays benutze ist die kleinste mögliche Version Delphi 4, da gaben es noch kein DoubletoXML und vieles mehr ….