Projekt

Allgemein

Profil

« Zurück | Weiter » 

Revision f49e9deb

Von Sven Schöling vor etwa 1 Jahr hinzugefügt

  • ID f49e9deb77039f7cac10d23ab93ebb9cd66b8870
  • Vorgänger b0c61725

PoC: Invoice Controller

Das hier ist der Versuch mit dem aktuellen TypeData und Model::Record
Unterbau einen Invoice Controller zu bauen, vor allem zu
Dokumentationszwecken.

Dieser Branch ist NICHT zum mergen gedacht.

Erkenntnisse, was alles anders ist oder angefasst werde muss:

Im Controller:
- $self->order > $self>invoice
- Mit Tamino und Bernd besprochen, sollte eher generisch $self->record
sein
- ValidityToken::SCOPE_ORDER_SAVE > SCOPE_SALES_INVOICE_POST
- Da gab es wohl schon einmal Diskussionen ob die überhaupt scopes
haben müssen. Ansonsten, nach TypeData verschieben.
- init_type Fehlermeldung: "not a valid type foe order"
- type_data Proxy muss mit der richtigen Klasse SL::DB::Invoice erstellt
werden.
- Items müssen SL::DB::InvoiceItem statt SL::DB::OrderItem sein
- $::form
>{order} > $::form>{invoice}
- auch hier - vereinheitlichen auf $::form->{record}?
- $::form->{orderitems} > $::form>{invoiceitems}
- dito.
- setup_custom_shipto module OE -> AR
- javascripte müssen umgebogen werden und evtl frontend checks neu
gebaut werden:
- kivi.Order.check_cv
- kivi.Order.check_duplicate_parts
- kivi.Order.check_valid_reqdate
- kivi.Order.check_transport_cost_article_presence
- kivi.Order.check_cusordnumber_presence
- kivi.Order.check_has_final_invoice - unnötig
- kivi.Order.check_invoice_advance_payment - unnötig

Features:
- close_quotations - gibt es in Invoice nicht
- periodic_invoices - gibt es in Invoice nicht
- basket_from_from - (sic!) gibt es in Invoice nicht
- shipped_qty - Invoice macht im Moment nichts mit Lager im Frontend
- transport_cost_reminder - gibt es in Invoice nicht
- phone_notes - gibt es in Invoice nicht
- subversion / final_version - gibt es in Invoice nicht als Zieltypen
im workflow
- not_order_locked - Waren nicht nicht mehr eingekauft werden dürfen
- ja/nein?

In SL::DB::Invoice und TypeDate
- Invoice kennt bereits ein type, was aber nicht das gleiche ist wie
das record_type. Das muss in der Datenbank gefixt werden.
- duedate/reqdate default belegung fuktioniert so nicht, ist von
payment_terms abhängig
- gldate belegung funktioniert so nicht
- parts_classification

Dazu ware in is.pl sehr viele Flags in Form, die da eigentlich nicht
hingehören:
- locked
- readonly
- storno
- storno_id
- postal_invoice
- is_gldate_ready (gldate today)
- payment_balanced (oldpaidtotal paidtotal)

- type_data->rights kann im Moment keine object rights wie über Projekte
- und die parts_classification_query sind da noch kaputt

Unterschiede anzeigen:

SL/DB/Invoice.pm
use SL::DB::Helper::RecordLink qw(RECORD_ID RECORD_TYPE_REF RECORD_ITEM_ID RECORD_ITEM_TYPE_REF);
use SL::DB::Helper::SalesPurchaseInvoice;
use SL::DB::Helper::TransNumberGenerator;
use SL::DB::Helper::TypeDataProxy;
use SL::DB::Helper::ZUGFeRD qw(:CREATE);
use SL::Locale::String qw(t8);
......
__PACKAGE__->before_save('_before_save_set_invnumber');
__PACKAGE__->after_save('_after_save_link_records');
use Rose::Object::MakeMethods::Generic (
'scalar --get_set_init' => [ qw(record_type) ],
);
# hooks
sub _before_save_set_invnumber {
......
sub items { goto &invoiceitems; }
sub add_items { goto &add_invoiceitems; }
sub record_number { goto &invnumber; };
sub record_type { goto &invoice_type; };
#sub record_type { goto &invoice_type; };
sub is_sales {
# For compatibility with Order, DeliveryOrder
......
}
}
sub init_record_type {
goto &invoice_type;
}
sub invoice_type {
my ($self) = @_;
......
goto &customer;
}
sub is_type {
return shift->record_type eq shift;
}
sub number {
my $self = shift;
my $nr_key = $self->type_data->properties('nr_key');
return $self->$nr_key(@_);
}
sub link {
my ($self) = @_;
......
return $self->netamount; # already matches base currency
}
sub type_data {
SL::DB::Helper::TypeDataProxy->new(ref $_[0], $_[0]->record_type);
}
1;
__END__

Auch abrufbar als: Unified diff