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.

Soll diese Regelung modifiziert werden (bspw. dahingehend, dass die Prüfung weniger strikt erfolgen soll), ist hier anzusetzen. Nach Möglichkeit sollte die Änderung nicht direkt in der Klasse AbstractMT940Logic vorgenommen werden. Die dafür vorgesehene Sourcecode-Stelle in der konkreten Implementierung MT940Logic ist entsprechend mit einem @replace!-Tag markiert.Tabelle 4.7.48: Übersicht, spezifische Anpassungen und Erweiterungen

4.8.1 Zuordnungslogik

Die Zuordnung von eingehenden Bankumsätzen zu Referenzobjekten (Rechnungen, o.ä.) ist in der Methode findMatchingReferences() der abstrakten Klasse org.nuclet.mt940.logic.AbstractMT940Logic realisiert. Die Zuordnung erfolgt standardmäßig auf Grundlage der herausgestellten Referenznummer der Referenzobjekte:

• Ist die Referenznummer im Verwendungszweck eines Bankumsatzes zu finden, erfolgt eine Zuordnung.
• Andernfalls erfolgt keine Zuordnung.

Diese Logik wird durch den Ausdruck boBankTransaction.getInformationToAccountOwner().indexOf(strReference) > 0 (aus dem Code-Segment, s.u.) beschrieben.

    /**
     * Matches the given bank transaction with a map of references: 
     * 
     * If the transaction's field "information to account owner" contains the reference, the related 
     * BusinessObject will be memorised, i.e. a list of all matching entries will be returned.
     * 
     * @note A more sophisticated, application specific, behaviour might be implemented in
     * dedicated subclasses
     * 
     * @param boBankTransaction a BusinessObject of type <code>BankTransaction</code>
     * @param mpReferences a map of references to be matched
     * @return a list of all BusinessObject that relate to a matching reference
     * 
     * @throws BusinessException might be thrown by implementing classes in case of errors or other exceptions
     */
    protected List<BusinessObject> findMatchingReferences(final BankTransaction boBankTransaction, 
        final Map<BusinessObject, String> mpReferences) 
    throws 
        BusinessException        
    {
        final ArrayList<BusinessObject> lstMatchingReferences = new ArrayList<BusinessObject>();
        final Set<BusinessObject> stReferencedBusinessObjects = mpReferences.keySet();
        
        // Check, if a matching reference exists...
        for (final BusinessObject businessObject : stReferencedBusinessObjects) {
            final String strReference = mpReferences.get(businessObject);
                
            if (boBankTransaction.getInformationToAccountOwner().indexOf(strReference) > 0) {
                log("matching reference found: " + strReference);
             
                lstMatchingReferences.add(businessObject);
            }
        }
        return lstMatchingReferences;
    }

4.8.2 Eindeutigkeitsprüfung

Die Prüfung, ob ein eingehender Datensatz aus dem MT940-Import bereits in der Datenbank vorhanden ist, wird in der Methode doesBankTransactionAlreadyExist() der abstrakten Klasse org.nuclet.mt940.logic.AbstractMT940Logic realisiert. Standardmäßig werden bei diesem Abgleich die folgenden Attribute berücksichtigt:

• Buchungsdatum (entry date)
• Valutadatum (value date)
• Betrag (amount)
• Soll-Haben-Kennzeichen (debit credit mark)
• Bankgeschäftsvorfall (business transaction type code/bank transaction type)
• Mehrzweckfeld (information to account owner)

Soll diese Regelung modifiziert werden (bspw. dahingehend, dass die Prüfung weniger strikt erfolgt), ist hier anzusetzen. Nach Möglichkeit sollte die Änderung nicht direkt in der Klasse AbstractMT940Logic vorgenommen werden. Die dafür vorgesehene Sourcecode-Stelle in der konkreten Implementierung MT940Logic ist entsprechend mit einem @replace!-Tag markiert.

...

...

4.8.3 Zahlungsbedingungen

sfdfs

...

...