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/07/13 19:32] Patrick Wacker benötigte Vorgehensweise beschrieben |
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's sind ab jetzt [[todo|hier]] zu finden | ||
+ | |||
+ | ===== Notizen ===== | ||
+ | |||
+ | ==== Speicherung der Daten ==== | ||
+ | |||
+ | 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 ** | ||
+ | |||
+ | |||
+ | Zum Nachdenken: | ||
+ | |||
+ | <code cpp-qt> | ||
+ | ai=AB_ImExporterContext_GetFirstAccountInfo(ctx); | ||
+ | while(ai) { | ||
+ | this->parseImExporterAccountInfo_Status(ai); | ||
+ | this->parseImExporterAccountInfo_DatedTransfers(ai); | ||
+ | this->parseImExporterAccountInfo_NotedTransactions(ai); | ||
+ | this->parseImExporterAccountInfo_StandingOrders(ai); | ||
+ | this->parseImExporterAccountInfo_Transactions(ai); | ||
+ | this->parseImExporterAccountInfo_Transfers(ai); | ||
+ | |||
+ | ai=AB_ImExporterContext_GetNextAccountInfo(ctx); | ||
+ | } /* while ai */ | ||
+ | </code> | ||
+ | |||
+ | bei Anlegen und Ändern von DatedTransfers wird die while nicht durchlaufen, beim löschen schon (das funktioniert auch). Somit müssten wir beim Anlegen und Ändern auch die aktuellen DatedTransfers abfragen, sonst nicht? | ||
+ | |||
+ | Ich war eigentlich davon ausgegangen das auch beim Ändern einer datedTransfer die while Schleife durchlaufen wird, da in der Terminueberweisungen.ini auch Transactions existieren die einen Status zum löschen und geändert etc. besitzen. [NEIN! nach Anlage und nach Löschen ist dort dokumentiert!] | ||
+ | |||
+ | |||
+ | => Schlussfolgerung | ||
+ | * Bei Anlegen und Ändern muss zwingend ein getDatedTransfers() ausgeführt werden. (nach Anlage oder Änderung) | ||
+ | * Löschen funktioniert ohne erneute Abfrage | ||
+ | * Beim Ändern muss die alte Transaction gelöscht werden, dies darf aber nur geschehen wenn beim Ändern keine Fehler aufgetreten sind! | ||
+ | * wie kann überprüft werden ob fehler aufgetreten sind? | ||
+ | |||
+ | |||
+ | => Umbau des Parsens --- //[[sod@schmufu.dyndns.org|Patrick Wacker]] 2011/10/26 19:46// | ||
+ | * Es sollte die JobListe durchgegangen werden und je nach JobType und JobStatus der Context entsprechend geparst werden. | ||
+ | * Einzelne Typ und Stati haben keinen context! (z.B. Anlegen von Terminierten Überweisungen) | ||
+ | * Werden Terminierte Überweisungun mit Status "pending" angelegt? | ||
+ | * Was ist mit "normalen" Überweisungen? | ||
+ | * wenn type=modifiyDatedTransfer und status=finished dann die Transaction des entsprechenden Jobs löschen | ||
+ | * kommen wir da über den job ran oder müssen wir und die Transaction merken? | ||
+ | |||
===== aqBanking ===== | ===== aqBanking ===== | ||
- | Verwendet wird die aqBanking ((link erstellen)) library | + | Verwendet wird die AqBanking ((link erstellen)) Bibliothek. |
Zeile 36: | Zeile 119: | ||
* AB_JOB * AB_JobCreateStandingOrder_new (AB_ACCOUNT *a) | * AB_JOB * AB_JobCreateStandingOrder_new (AB_ACCOUNT *a) | ||
* AB_JOB * AB_JobModifyStandingOrder_new (AB_ACCOUNT *a) | * AB_JOB * AB_JobModifyStandingOrder_new (AB_ACCOUNT *a) | ||
- | * AB_JOB * AB_JobDeleteDatedTransfer_new (AB_ACCOUNT *a) | + | * AB_JOB * AB_JobDeleteStandingOrder_new (AB_ACCOUNT *a) |
* AB_JOB * AB_JobGetStandingOrders_new (AB_ACCOUNT *a) | * AB_JOB * AB_JobGetStandingOrders_new (AB_ACCOUNT *a) | ||
=== 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 ImExporterContex (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! |