SEPA Komponente gesucht

[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)

[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/