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.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.
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.
| Hinweis |
|---|
Es wird empfohlen, die Änderungen in der konkreten Implementierung MT940Logic oder in einer eigenen Klasse vorzunehmen, die von der abstrakten Klasse AbstractMT940Logic erbt. |
| Codeblock | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
/**
* 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
jkhkhk
4.8.3 Zahlungsbedingungen
sfdfs
Überblick
Inhalte