Seitenhistorie
In diesem Abschnitt werden die Stellen aufgezeigt, an denen spezifische Anpassungen und Erweiterungen vorgenommen werden können. Mögliche Anpassungen werden entlang aus der Praxis bekannter Problemstellungen dokumentiert. Alle diese Änderungen sind optional.
| Problemstellung | Beschreibung | Beispiel |
|---|---|---|
| Zu berücksichtigende Referenzobjekte | Datenbankabfrage zum Einsammeln aller zu berücksichtigenden Referenzobjekte (z.B. alle Rechnungen im Status X) | Es sollen weitere Bedingungen an die Referenzobjekte gestellt werden als nur auf den Status einzuschränken |
| Zuordnungslogik | Zuordnung von Referenzen zu Bankumsätzen | Anstelle der Referenznummer (Rechnungsnummer) soll eine modifizierte Referenznummer im Verwendungszweck der Bankumsätze gesucht werden. Bsp.: Bei der Referenz "R13.101" wird zusätzlich nach "R13101" und "R13 101" gesucht. |
| Existenzprüfung beim MT940-Import | Weitere Datensatzfelder sollen bei der Eindeutigkeitsprüfung während des Imports von MT940-Dateien berücksichtigt werden. | |
| Zahlungsbedingungen | Prüfung, ob die Zahlungsbedingungen erfüllt sind | Die Logik zur Prüfung, ob die Zahlungsbedingungen erfüllt sind, soll angepasst werden. |
Tabelle 4.8: Übersicht, spezifische Anpassungen und Erweiterungen
4.8.1 CheckBankTransactionRef
Bei der Klasse CheckBankTransactionRef handelt es sich um eine UpdateFinalRule. Sie ist der Entität „Bankumsatz“ („Bank Transaction“) zugeordnet. D.h. sie wird im Anschluss an ein Update eines Objektes vom Typ „Bankumsatz“ aufgerufen.
Ihre Methode checkReferences() ist dafür vorgesehen, im Rahmen eines solchen Update-Events notwendige Änderungen an den zugeordneten Referenzobjeten des Bankumsatzes auszulösen. Denkbar wäre dies bspw. für die folgenden Anwendungsfälle:
einem zuvor nicht referenzierten Bankumsatz wird eine Referenz hinzugefügt
aus einem zuvor referenzierten Bankumsatz wird die Referenz wieder entfernt
in einem zuvor referenzierten Bankumsatz wird alte Referenz gegen eine neue Referenz ausgetauscht
Diese Beispiele beziehen sich auf die Variante, in der jedem Bankumsatz maximal eine Referenz zugewiesen werden kann (MT940_REFERENCE_TYPE = SINGLE). Für den Modus MULTIPLE (ein Bankumsatz mehrere Referenzen besitzen) sind analog vergleichbare Anwendungsfälle denkbar.
Möglicherweise passende Anweisungen wären an dieser Stelle bspw.
ein Markieren des Referenzobjekts als „zugeordnet“/“nicht zugeordnet“
ein Statuswechsel für das Referenzobjekt
das Auslösen von Berechnungsschritten, o.ä. auf dem Referenzobjekt
weitere Modifikationen auf dem Referenzobjekt oder auf Bezugsobjekten des Referenzobjekts (referenzierte Objekte, Unterformulareinträge, etc.)
Unter Umständen wäre es sinnvoll, die zu implementierende Logik mit der Logik aus Punkt b) (MT940Importer) von oben abzugleichen.
Empfehlenswert wäre der Ansatz, die Funktionalität dafür in die Klasse MT940Logic (oder einer eigenen Unterklasse der AbstractMT940Logic) einzugliedern.
...
| language | java |
|---|---|
| title | org.nuclet.mt940.rule.CheckBankTransactionRef |
| linenumbers | true |
| collapse | true |
...
Überblick
Inhalte