SEPA Komponente gesucht

[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".
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.
Aber wenn man ein Feld nun zu kurz macht und es dann später irgendwann mal beim Kunden knallt ...

[jobo]

Zitat von 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.
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 von sh17:

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 von sh17:

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.

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

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)