projekt kivitendo

Folgendes müsste passieren:

a)
Buchung erstellen macht wirklich nur das was es sagt: Es erstellt eine Buchung aus einer Vorlagen und macht KEINE zusätzliche Zahlungsverbuchung

oder

b)
Buchung wird erstellt. Zahlung wird gebucht. Zahlung wird verknüpft. bank_transactions.invoice_amount wird gesetzt. Liste der aktuell zu verbuchenden Bankbewegungen wird aktualisiert.

Für den Fall b) fände ich es trotzdem besser, beide Schritte zu trennen, sodass das Zahlungsfeld nicht im Beleg gesetzt wird, sondern durch den Aufruf von assign_invoice im Controller BankTransactions.pm

Ich tendiere zu a), da einfach zuviel im Hintergrund bei dem Prozess passiert OHNE eine wirkliche Rückmeldung an den Benutzer zu geben.

Ich hab folgendes zum Testen ausprobiert:

i) Zahlungswert und Zahlungskonto nicht an ap.pl übergeben
ii) Callback dann nach ajax_accept_invoices anstatt nach list und die gerade generierte id übergeben

In einem Optimal-Fall lande ich direkt beim Vorschlag Rechnung verbuchen und kann noch einmal kontrollieren sowie Beleg und Memo setzen.
Alle weiteren Fehlerroutinen und Rückmeldung an dem Benutzer aus dem Controller werden DANACH sauber durchgeführt.

Offen wäre dann noch:
a) Eingabe von Zahlungen in ap.pl verhindern
b) Die erstellte Buchung so verhunzen, dass sie nicht mehr zur Bankbewegung passt, um zu sehen ob BankTransactions umkippt oder ggf. auch nicht.

Hier der diff:

BankTransactions.pm

304a305,313
> #  $self->callback($self->url_for(
> #    action                => 'list',
> #    'filter.bank_account' => $::form->{filter}->{bank_account},
> #    'filter.todate'       => $::form->{filter}->{todate},
> #    'filter.fromdate'     => $::form->{filter}->{fromdate},
> #  ));
> 
> 
> 
306c315
<     action                => 'list',
---
>     action                => 'ajax_accept_invoices',
309a319,321
>      bt_id                => $::form->{bt_id},
>      invnumber            => $::form->{invnumber},
>      invoice_id           => $::form->{id},
311a324
> 
899,901c912,914
<     'form_defaults.paid_1'     => $::form->format_amount(\%::myconfig, -1 * $self->transaction->amount, 2),
<     'form_defaults.currency'   => $self->transaction->currency->name,
<     'form_defaults.AP_paid_1'  => $self->transaction->local_bank_account->chart->accno,
---
>     #'form_defaults.paid_1'     => $::form->format_amount(\%::myconfig, -1 * $self->transaction->amount, 2),
>     #'form_defaults.currency'   => $self->transaction->currency->name,
>     #'form_defaults.AP_paid_1'  => $self->transaction->local_bank_account->chart->accno,

So wie das Verfahren in der beta ist, ist es nicht sinnvoll.

Ich implementiere Variante a), da sind die beiden Schritte klar getrennt und die Zahlungsverbuchungen kann vorher nochmal visuell kontrolliert werden und Warnungen, bzw. Fehlerbehandlung wird auch durchgeführt.

Der Rücksprung scheint doch noch nicht ganz sauber zu sein.

Folgendes Szenario:

a) Einige Rechnungen zuweisen aus der Liste
b) Danach eine Rechnung über Buchung erstellen ->
c) Rücksprung landet auf Vorschlagsauswahl,die vorherige Auswahl wurde vergessen
c.1) Vorschlag speichern löst keine Aktion mehr aus