Wie werden Transaktionen, Schulden, Zinsen und Strafzahlungen verwaltet?

Question

Ich mache ein BI System für eine Bank-ähnliche Institution. Dieses System sollte Kreditverträge, Rechnungen, Zahlungen, Strafen und Zinsen verwalten.

Jetzt muss ich eine Methode erstellen, die eine Rechnung erstellt. Ich muss berechnen, wie viel der Kunde gerade bezahlen muss. Er hat eine Schuld, für die er bezahlen muss. Er muss auch für die Zinsen bezahlen. Wenn er mit der fälligen Zahlung zu spät kam, werden für jeden Tag, an dem er sich verspät, Strafen verhängt.

Ich dachte, gab es 2 Möglichkeiten dies zu tun:

1. von nur 1 ursprünglichem Zustand mit - dem ursprünglichen Zustand Vertrag. Und jedes Mal, um die monatliche Zahlung zu berechnen, die der Kunde vornehmen muss, berücksichtigen Sie die tatsächlich getätigten Zahlungen.
2. Indem man ständig Zwischenzustände macht, vom letzten Zwischenzustand ausgeht und nur die Ereignisse berücksichtigt, die zwischen der Zeit dieser beiden Zwischenstaaten stattgefunden haben. Dies bedeutet, einen Job zu haben, der periodisch (täglich, monatlich) arbeitet, den letzten gespeicherten Status übernimmt, die Änderungen anwendet (fällige Zahlungen, tatsächliche Zahlungen, Änderungen in globalen Konstanten wie der von der Zentralbank kontrollierte Strafzins) und speichert der resultierende Zustand.

Die Vorteile der ersten Variante:

• Immer aktuell. Wenn Änderungen mit einem Datum aus der Vergangenheit vorgenommen wurden (ein Typ kam mit einer bezahlten Rechnung 5 Tage, nachdem er die Zahlung an die Bank geleistet hat), werden sie korrekt in den Ergebnissen wiedergegeben.

Die Mängel der ersten Variante:

• nimmt lange
• Dokumente mit den aktuellen Ergebnissen gedruckt berechnen abweichen können, wenn die richtigen Datenänderungen aufgrund Operationen mit einem Rück Datum eingegeben.

Die Vorteile der zweiten Variante:

• Arbeitet schnell und aggregierten Daten für die Suche und Berichte jederzeit zur Verfügung.
  • Anfällig für Fehlgeschlagene Jobs:
  • Einfachere

  die Mängel der zweiten Variante zu berechnen.

• Fehler in der Vergangenheit propagieren bis zum Ende, zu den endgültigen Ergebnissen.
• Ein Zwischenergebnis kann nicht geändert werden, wenn neue Daten aus früheren Transaktionen eintreffen (es kann, aber es ist schwer und mit vielen Implikationen, also würde ich es lieber als Tabu markieren)
• Jobs können nicht erfolgreich und ohne Probleme ausgeführt werden Wenn eine noch nicht abgeschlossene Transaktion vorliegt (eine ausgestellte Rechnung, die noch nicht bezahlt wurde)

Gibt es einen anderen Weg? Kann ich die Vorteile dieser beiden kombinieren? Welche wird in anderen ähnlichen Systemen verwendet, die Sie kennengelernt haben? Bitte teilen Sie jede Erfahrung.

Answer 1

Probleme dieser Art sind immer komplizierter als sie zuerst erscheinen. Diese ist eine Konsequenz dessen, was ich gerne Rumsfeldian problem of the unknown unknown nennen möchte. Grundsätzlich, was auch immer Sie jetzt tun, seien Sie bereit, Anpassungen für beliebige zukünftige Regeln vorzunehmen.

Dies ist ein schwieriger Vorschlag. Einige zukünftige Möglichkeiten, die einen signifikanten Einfluss auf Ihr Berechnungsmodell haben können, sind zurück datiert Zahlungen, Anpassungen und Gebühren. Vergebene Zinsperioden können ebenfalls ein Problem werden (insbesondere wenn sie zurück datiert sind). Anforderungen , um verschiedene Point-in-Time (PIT) -Berechnungen basierend entweder auf dem, was bei "bekannt war", dass PIT (Vergangenheitsansicht der Vergangenheit) oder unter Berücksichtigung Transaktionen nach der Referenz PIT, dass wurden zurück datiert zu bieten PIT vor der Referenz (aktuelle Sicht der Vergangenheit). Berechnungen dieser Art können ein echter Schmerz im Kopf sein.

Mein Rat wäre, von "Scratch" (dh. Erste Variante) zu berechnen. Implementieren Sie Optimierungen (z. B. zweite Variante) nur , wenn dies erforderlich ist, um Leistungseinschränkungen zu erfüllen. Die Berechnung von Anfang an ist ein rechenintensives Modell, ist aber im Allgemeinen flexibler in Bezug auf unerwartete Linkskurven.

Wenn die Leistung ein Problem ist, aber die Häufigkeit der komplizierenden Faktoren (z. B. zurückdatierte Transaktionen) ist relativ niedrig, könnten Sie ein Hybridmodell erkunden, das das Beste aus beiden Varianten verwendet. Hier speichern Sie den aktuellen Status und berechnen vorwärts , indem Sie nur die Transaktionen verwenden, die seit dem letzten gespeicherten Status gebucht wurden, um einen neuen aktuellen Status zu erstellen. Wenn Sie eine "Komplikation" treffen, wiederholen Sie den gesamten Account von , um den aktuellen Status wiederherzustellen.

In der Lage zu sein, das Unerwartete aufzunehmen, ohne ein Umschreiben auszulösen, ist auf lange Sicht wahrscheinlich wichtiger als die Rasierberechnung im Moment. Beschränken Sie Ihr Berechnungsmodell erst, wenn Sie es müssen. Saving aktuellen Zustand bringt oft eine Reihe von eingebauten Annahmen und Einschränkungen, die Spielraum für zukünftigen Anforderungen zu reduzieren.