Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

 

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.

 

ProblemstellungBeschreibungBeispiel
ZuordnungslogikZuordnung 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.

Eindeutigkeitsprüfung

Existenzprüfung beim MT940-Import

Weitere Datensatzfelder sollen bei der Eindeutigkeitsprüfung während des Imports von

MT940-Dateien berücksichtigt werden.

ZahlungsbedingungenPrüfung, ob die Zahlungsbedingungen erfüllt sindDie Logik zur Prüfung, ob die Zahlungsbedingungen erfüllt sind, soll angepasst werden.

Tabelle 4.7.4: Übersicht, spezifische Anpassungen und Erweiterungen

 

4.8.1 Zuordnungslogik

ddd

 

4.8.2 Eindeutigkeitsprüfung

jkhkhk

 

4.8.3 Zahlungsbedingungen

sfdfs

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.

 

Codeblock
languagejava
titleorg.nuclet.mt940.rule.CheckBankTransactionRef
linenumberstrue
collapsetrue
/**
   * Check, if the changes done to the given bank transaction should result in further
   * changes and/or state changes of the references <code>BusinessObject</code>
   * 
   * @param context the current context
   * 
   * @throws BusinessException, in case an error or exception occurs
   */
  private void checkReferences(UpdateContext context) throws BusinessException
  {
      // @replace!
      //
      // This code segment needs to be filled with application specific behaviour.
      //
      //
  }