Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
ab_transfer:dev:info [2011/10/26 19:51] Patrick Wacker [ToDo] |
ab_transfer:dev:info [2012/04/08 09:04] (aktuell) Patrick Wacker Überlegungen zur Speicherung von Daten |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Entwicklungs-Informationen ====== | ====== Entwicklungs-Informationen ====== | ||
| - | ===== ToDo ===== | + | ToDo's sind ab jetzt [[todo|hier]] zu finden |
| - | * <del>Abgeleitete Klasse des ÜberweisungsWidget für Sonderedits (z.B. Datum, Zyklus bei Daueraufträgen, Terminüberweisungen)</del> (erledigt --- //[[sod@schmufu.dyndns.org|Patrick Wacker]] 2011/08/31 21:50//) | + | ===== Notizen ===== |
| - | * über ein "enum" beim Constructor ist wählbar welches "extraWidget" zusätzlich angezeigt werden soll. | + | |
| - | * Bekannte Daueraufträge anders gestallten | + | |
| - | * TopItem: Begünstigter - Verwendungszweck - Betrag - Währung | + | |
| - | * ChildItem: Alle Details des Dauerauftrags | + | |
| - | * <del>AB_VALUE und GWEN_TIME umwandlung in QVariant/QDate aqb_banking als static functions</del> (erledigt --- //[[sod@schmufu.dyndns.org|Patrick Wacker]] 2011/08/31 21:50//) | + | |
| - | * Bekannte Empfänger: | + | |
| - | * Bearbeiten ermöglichen (rechtsklick->edit) | + | |
| - | * Wenn ein neuer Dauerauftrag oder eine neue Überweisung durchgeführt wurde den Empfänger in "bekannte Empfänger" speichern (sofern dort noch nicht vorhanden) | + | |
| - | * evt. als eigenständigen Dialog (DockWidget) anzeigen (hinzufügen als Drag'n'Drop realisiert) | + | |
| - | * getätigte Überweisungen | + | |
| - | * Anzeige von getätigten Überweisungen (automatisch wenn eine Überweisung ausgeführt wird) | + | |
| - | * Manuelles Löschen (rechtsklick->löschen) | + | |
| + | ==== Speicherung der Daten ==== | ||
| - | Für getätige und angelegte Terminüberweisungen und Daueraufträge | + | Erste Überlegungen und Entscheidungen für das lokale Speichern der Daten und wie dies am sinnvollsten realisiert werden kann. |
| + | |||
| + | === Was soll erreicht werden === | ||
| + | |||
| + | * Speicherung der aktuellen Daten und der Historie in lokaler Datei. | ||
| + | * getätigte Aufträge (Historie). | ||
| + | * Alles was gesendet wurde (Anlegen/Ändern/Löschen/Aktualisieren) in chronologischer Reihenfolge. | ||
| + | * Daueraufträge (in separater Datei). | ||
| + | * Terminüberweisungen (in separater Datei). | ||
| + | * //aktueller Kontostand/Dispo// (evt. später). | ||
| + | * Export von getätigten Überweisungen. Dazu sollte die Export-Funktionalität von AqBanking genutzt werden. | ||
| + | |||
| + | === Überlegungen / Noch Testen === | ||
| + | |||
| + | Die vorhandenen Daueraufträge und terminierten Überweisungen werden zur Zeit mit in der ini-Datei gespeichert, dies sollte später nicht mehr stattfinden.\\ | ||
| + | Für Daueraufträge und terminierte Überweisungungen existieren bereits Objekte die die Daten für die interne Bearbeitung zur Verfügung stellen (abt_StandingInfo bzw. abt_DatedInfo). Jedes Account-Objekt (abt_AccountInfo) enthält jeweils eine Liste wo die entsprechenden Standing-/DatedInfo Objekte referenziert werden. | ||
| + | |||
| + | Die Dated- und StandingInfo Objekte könnten die Liste selber verwalten, somit kann hier dann auch ein löschen, ändern, anlegen implementiert werden (momentan geschieht dies in abt_settings). Dann braucht in abt_AccountInfo auch keine Liste mehr verwaltet werden, sondern es kann einfach das entprechende Objekt verwendet werden.\\ | ||
| + | Dieses Objekt könnte als Basis-Klasse ausgelegt werden und dann auch für die Historie verwendet werden. | ||
| + | |||
| + | Interresant wäre das Speichern mithilfe der AqBanking_ImExporter* Funktionen. Die Funktion zum parsen müsste dann so erstellt werden das sie sowohl die Historie und lokal gespeicherten Daueraufträge/terminierten Überweisungen importieren kann, als auch die Daten die von der Bank zurückkommen.\\ | ||
| + | Diese Funktion müsste die Daten in den entsprechenden Objekten zur Verfügung stellen. Beim Beenden müssen dann alle Daten der Objekte in einen Context gepackt werden und Exportiert werden. | ||
| + | |||
| + | |||
| + | ** Überlegungen noch nicht abgeschlossen, wird noch erweitert werden ** | ||
| + | |||
| + | |||
| + | == weiteres == | ||
| + | |||
| + | * Beim export des context über AB_Banking_ExportToFile(banking->getAqBanking(), ctx, "ctxfile", "default", "/tmp/exporterTest_ctxfile.ctx") wird anscheinend der Status und der Typ der Transaction des Auftrages nicht gepeichert ('type' und 'status' werden mit ="unknown" gespeichert) | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ==== Ältere Überlegungen ==== | ||
| + | |||
| + | ** Ab hier ist einiges veraltet und Bedarf einer Überarbeitung! Momentan fehlt allerdings die Zeit um dies vernünftig neu zu dokumentieren ** | ||
| - | * Wenn eine DatedTransfer oder StandingOrder neu angelegt wird muss dies auch einen Abruf der aktuell hinterlegten Daten ausführen | ||
| - | * Dies muss zwingend NACH dem anlegen geschehen! | ||
| - | * Überprüfen ob die Abholungen die neu angelegte Transaction beinhalten. | ||
| - | * Bei Änderung muss die Alte in den Settings gelöscht werden und die neue gespeichert werden! | ||
| - | * wie unterscheiden wir, wenn mehr als 1 geändert wird, welche gelöscht und neu gespeichert werden muss? | ||
| - | * es kann auch der Empfänger geändert werden! | ||
| - | * eigentlich kann alles bis auf den Absender geändert werden! | ||
| - | * Einfach zu Beginn alle geänderten löschen und hoffen das kein Fehler beim Ändern auftritt? | ||
| Zum Nachdenken: | Zum Nachdenken: | ||
| Zeile 68: | Zeile 86: | ||
| ===== aqBanking ===== | ===== aqBanking ===== | ||
| - | Verwendet wird die aqBanking ((link erstellen)) library | + | Verwendet wird die AqBanking ((link erstellen)) Bibliothek. |
| Zeile 106: | Zeile 124: | ||
| === Brainstorming === | === Brainstorming === | ||
| - | Jede Überweisung muss in einem separaten AB_JOB gespeichert werden ((wir wollen keine Sammelüberweisungen)) und dieser AB_JOB dann einer JOB_LIST hinzugefügt werden. Wenn alle Transactionen vorhanden sind wird die JOB_LIST zur Bank übertragen und danach der ImExporterContext (CTX) ausgewertet, im CTX können auch Meldungen und Logs vorkommen, nicht nur die Transaktionen und das ganze muss separat für jeden empfangenen Account erledigt werden. | + | Jede Überweisung muss in einem separaten AB_JOB gespeichert werden und dieser AB_JOB dann einer JOB_LIST hinzugefügt werden. Wenn alle Transactionen vorhanden sind wird die JOB_LIST zur Bank übertragen und danach der ImExporterContext (CTX) ausgewertet, im CTX können auch Meldungen und Logs vorkommen, nicht nur die Transaktionen und das ganze muss separat für jeden empfangenen Account erledigt werden. |
| + | |||
| + | Sammelüberweisungen können durch die Anwendung selber __nicht__ beeinflusst werden, dies ist abhängig vom jeweiligen Institut und dem verwendeten Backend in AqBanking. | ||
| Erstellte und/oder geänderte/gelöschte Daueraufträge müssen dann in der lokalen Datei auch eingetragen/gelöscht werden, diese Daten müssen dem CTX entnommen werden! | Erstellte und/oder geänderte/gelöschte Daueraufträge müssen dann in der lokalen Datei auch eingetragen/gelöscht werden, diese Daten müssen dem CTX entnommen werden! | ||
