Revision ed9b1bfb
Von Jan Büren vor mehr als 6 Jahren hinzugefügt
| SL/Controller/BankTransaction.pm | ||
|---|---|---|
| 262 | 262 |
|
| 263 | 263 |
$self->transaction(SL::DB::Manager::BankTransaction->find_by(id => $::form->{bt_id}));
|
| 264 | 264 |
|
| 265 |
# This was dead code: We compared vendor.account_name with bank_transaction.iban. |
|
| 266 |
# This did never match (Kontonummer != IBAN). It's kivis 09/02 (2013) day |
|
| 267 |
# If refactored/improved, also consider that vendor.iban should be normalized |
|
| 268 |
# user may like to input strings like: 'AT 3333 3333 2222 1111' -> can be checked strictly |
|
| 269 |
# at Vendor code because we need the correct data for all sepa exports. |
|
| 270 |
|
|
| 271 | 265 |
my $vendor_of_transaction = SL::DB::Manager::Vendor->find_by(iban => $self->transaction->{remote_account_number});
|
| 272 | 266 |
my $use_vendor_filter = $self->transaction->{remote_account_number} && $vendor_of_transaction;
|
| 273 | 267 |
|
| ... | ... | |
| 299 | 293 |
TEMPLATES_GL => $use_vendor_filter && @{ $templates_ap } ? undef : $templates_gl,
|
| 300 | 294 |
TEMPLATES_AP => $templates_ap, |
| 301 | 295 |
vendor_name => $use_vendor_filter && @{ $templates_ap } ? $vendor_of_transaction->name : undef,
|
| 296 |
BT_ID => $::form->{bt_id},
|
|
| 302 | 297 |
); |
| 303 | 298 |
} |
| 304 | 299 |
|
| ... | ... | |
| 900 | 895 |
} |
| 901 | 896 |
|
| 902 | 897 |
sub load_gl_record_template_url {
|
| 903 |
my ($self, $template) = @_; |
|
| 898 |
my ($self, $template, $bt_id) = @_;
|
|
| 904 | 899 |
|
| 905 | 900 |
return $self->url_for( |
| 906 | 901 |
controller => 'gl.pl', |
| ... | ... | |
| 909 | 904 |
'form_defaults.amount_1' => abs($self->transaction->amount), # always positive |
| 910 | 905 |
'form_defaults.transdate' => $self->transaction->transdate_as_date, |
| 911 | 906 |
'form_defaults.callback' => $self->callback, |
| 907 |
'form_defaults.bt_id' => $self->transaction->id, |
|
| 912 | 908 |
); |
| 913 | 909 |
} |
| 914 | 910 |
|
Auch abrufbar als: Unified diff
Kontoauszug verbuchen -> Dialogbuchungsentwürfe verbessert
Nette Idee aus odyn (Start des Gedankens #f09c2b407faa7 Ende des Gedankens #765a3d421e7).
Zwei Sollbruchstellen in odyn, deshalb in kivi neu formuliert:
Sollbruchstellen:
a) Ein Aufruf von BankTransaction::action_list kann Zustände im Datenmodell verändern
b) Der Benutzer kann beliebige Zahlenwerte oder neue Konten in der Dialogbuchungsmaske eingeben
Konsequenz:
-> Zustände des Datenmodells in gl.pl post_transactions ändern, Werte per Rose hierzu aus der DB (und nicht aus $form)
Möglichst viel dem Benutzer auf die Flossen hauen, wenn die Buchungsmaske unlogisch benutzt wird