[gnucash-de] Re: generic-exporter, KonzeptansatzfürmehrOnline-Integration

[C. Gatzemeier]

Hallo!

Danke für dein Feedback Christian (Stimming).
Erwartungsgemäß kritisch aber konstuktiv.

Die Idee mit einer ausgefüllten Überweisungformular GUI die dem Benutzer zur 
Sicherheit und zur Bestätigung (pineingabe) vor dem export nochmal angezeigt 
werden kann (analog zum importer) ist sehr gut.

Dann gab es noch den Hinweis auf den 08/15 Durchschnittsbenutzer. Der wird 
weiterhin in der Lage sein seine Überweisungen bequem mit der vorhandenen 
Einzelüberweisungs GUI zu erstellen.

Die Einzelüberweisungs GUI selbst könne ja eines Tages die Daten in der 
gleichen konsistenten Art und Weise in GnuCash Feldern speichern wie sie vom 
Exporter gefordert wäre.
Angenommen es wäre "Name" <kontonummer at Bankleitzahl> würde man das als 
Beginner sicher auch schnell nachvollziehen können.

Der Exporter soll ja kein Ersatz sein sondern nur ermöglichen, auch die vielen 
anderen Funktionen in GnuCash, tatsächlich, auch in zusammenhang mit HBCI 
verwendbar zu machen.
Und da sehe ich leider keine andere Alternative als den Exporter wenn man 
nicht alle add-ons extra hbci-aware machen möchte oder die prinzipielle 
Datenstuktur in GnuCash ändern möchte.
Weiterhin sollte der generic-exporter natürlich auch als Basis für andere 
Datei oder Schnittstellen exporte dienen können.

Auf gnucash-devel habe ich übrigens auch mal gelesen das Benoit sich auch für 
den export und DirectConnect oder so interessiert. Deshalb würden mich auch 
noch ander Meinungen und Ideen hier interessieren und dann mach ich mal eine 
Zusammenfassung auf englisch für -devel.


Am Samstag, 21. Juni 2003 11:50 schrieb Christian Stimming:

> Dein Vorschlag steht und fällt damit, ob es Sinn macht, Daten für die
> Online-Schnittstelle irgendwie in den normalen gnucash-Daten zu
> "verstecken" 

Gewissermaßen ja, jedoch sind die Daten schon immer dort vorhanden, 
schließlich macht es ausgesprochen Sinn sich Name,Kto und BLZ zur Buchung zu 
notieren.

Ich denke der Vorschlag steht und fällt mit der *Eindeutigkeit* mit der die 
Daten identifizierbar sind.
Es ist schon richtig und wichtig das diese Eindeutigkeit der Zuordnung *nicht* 
von vorneherein über Bord geworfen wird.
Wie Du schon sagtest es geht schließlich um Kohle.

Allerdings werden die Daten ja immer "geparsed" wenn auch auf einem anderen 
level (aus einer Datei). Soweit ich das richtig gesehen habe wird der 
Verwendungszweck einer Überweisungvorlage z.B. als
<slot:key>purp</slot:key>
              <slot:value type="string">Verwendungszweck</slot:value>
im GnuCash buch gespeichert.

Etwas kürzer und intuitiver dürfte es im Beschreibungs- und Buchungstextfeld 
natürlich schon zugehen. Gibt es noch mehr ideen?

Gruß
Christian