Entwicklungs-Informationen

ToDo's sind ab jetzt hier zu finden

Erste Überlegungen und Entscheidungen für das lokale Speichern der Daten und wie dies am sinnvollsten realisiert werden kann.

• 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.

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

• 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)

Ab hier ist einiges veraltet und Bedarf einer Überarbeitung! Momentan fehlt allerdings die Zeit um dies vernünftig neu zu dokumentieren

Zum Nachdenken:

	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 */

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 — 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?

Verwendet wird die AqBanking ¹⁾ Bibliothek.

• AB_JOB * AB_JobSingleTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobSingleDebitNote_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobEuTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobInternalTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobSepaTransfer_new (AB_ACCOUNT *a)

• AB_JOB * AB_JobCreateDatedTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobModifyDatedTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobDeleteDatedTransfer_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobGetDatedTransfers_new (AB_ACCOUNT *a)

• AB_JOB * AB_JobCreateStandingOrder_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobModifyStandingOrder_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobDeleteStandingOrder_new (AB_ACCOUNT *a)
• AB_JOB * AB_JobGetStandingOrders_new (AB_ACCOUNT *a)

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!

Dasselbe gilt für Terminierte Überweisungen.

Basis-Klasse für Terminierte Überweisungen und Daueraufträge?