projekt kivitendo

Die konzeptionelle Frage, die sich hier stellt: Warum benötigen wir amount_of_transaction?

Bspw.: # $invoice->open_amount may be negative for ap_transaction but may be positiv for negativ ap_transaction # if $invoice->open_amount is negative $bank_transaction->amount is positve # if $invoice->open_amount is positive $bank_transaction->amount is negative # but amount of transaction is for both positive

Die Annahmen probieren alle Datenzustände von Belegen zu definieren. Das find ich nicht gut gelungen.
Entscheidend ist doch der Datenzuständ des Bankbelegs, ob der Benutzer jetzt Zahlungsausgang mit einer Verkaufsrechnung verknüpfen möchten, kann ja richtig sein.
Der Ansatz ist hier falsch, entweder man definiert Zustände schon sauber bei der manuellen Eingabe (negative Verkaufsrechnugen sind immer verboten), aber nicht nachträglich beim Verbuchen von Bankbelegen.

Das Datenmodell von Kontenbewegung ist extrem simpel:

Eine Kontobewegung ist entweder positiv oder negativ, niemals 0.
Das Vorzeichen in der Tabelle bank_transactions ist wahr.

Wenn der Benutzer eine Kontobewegung mit einem Beleg verknüpft, darf man das a) verbieten (weil unlogisch) b) Warnen: Junge, kompletter Blödsinn, aber du bist hier Chef!

Aber was nicht in Frage gestellt werden sollte ist das Vorzeichen der Bankbewegung.

Das macht es nur kompliziert und nicht besser. Klar, an anderer Stelle benötigen wir den Betrag einer Buchung, da es je nach Kontentyp unterschiedlich ist.
Hier wird aber nur von Bankkonto auf ein FiBu-Umlaufkonto gebucht.

Das acc_trans Modell ist an dieser Stelle glücklicherweise genauso primitiv wie das Bankkonto.

Das Modell ändere ich jetzt nicht, ich erweitere jetzt einfach nur das bestehende um einen Testfall inkl. Fix.