SEPA Komponente gesucht

[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 ….