projekt kivitendo

Order: nutze TypeData

DB::Order: is_sales verwende record_type

DB::Order: Funktionen angepasst (kein Angebotsflag/Intakeflag)

Order: nutze Record-Type

LinkRecord: close_quotations nicht mehr im link record post save hook ausführen

Das war Teil der link_record behandlung, ist aber so unintuitiv, dass es
jetzt vom Controller an den Model::Record gegeben wird.

TypeData: nutzte Konstanten anstatt String für Typen

TypeData: proxy um $record->type_data benutzen zu können

DB::Order: no_linked_records Flag zu new_from hinzugefügt

RecordLink: converted_from_* Felder in allen convert_to und new_from korrekt setzen.

Das hier benutzt jetzt das neue Reclamation Format. Statt

converted_from_oe_id

wird jetzt

converted_from_record_id
  converted_from_record_type_ref = SL::DB::Order...

RecordLink: post save hook für alle Hauptbelege

S:D:Order und S:M:Record: POD für Unterversion hochzählen

Order-Controller: Unterversion hochzählen über Model:Record umgesetzt

Todo: SL::Model::Record->save verwenden, sobald implementiert

S:B:Order: Kosmetik: Ausrichtung

Angebots-Eingang: S:D:Order->new_from

Angebots-Eingang: Controller

Hotfix für reqdate in Auftragseingang

Auftrags-Eingang: Workflows

Auftrags-Eingang: Controller

Wiederkehrende Abrechnung Position: bei »als neu speicher« übernehmen

Reclamation: add billing_address_id to reclamation

Reclamation: Test for workflow (reclamation, order, delivery_order)

Workflow: order ↔ reclamation

S/D/Order new_from reqdate je nach Beleg-Typ und Konfig setzen

offen: Aktuell wird der Einkauf exakt wie der Verkauf behandelt
ggf, genauer differenzieren. Wobei der vorherige Standard
(next_working_day) wahrscheinlich auch nicht passt.

Neue Belegmethode netamount_base_currency

• für Angebote und Aufträge und Lieferscheine in der Fremdwährung
• für EK- und VK-Rechnungen in der Hauptwährung.

Um in bestimmten Berichten, die auf mehrere Belege zugreifen (z.B. Finanzübersicht),...

SL::DB::Order>new_from: mini-Refactoring

gleichen Code zusammen gefasst.

Auftrags-Controller: WF Kunden-Angebot/-Auftrag -> Preisanfrage

Auftrags-Controller: WF Preisanfrage -> Kunden-Auftrag

Auftrags-Controller: WF Preisanfrage -> Kunden-Angebot

Unterversionen: Methode zum Prüfen, ob finalisierte Version, leicht vereinfacht

Unterversionen für Angebote/Aufträge

Versionen werden finalisiert sobald sie per E-Mail rausgeschickt wurden
Danach ist die Bearbeitung gesperrt, aber es ist möglich eine neue
Unterversion des Belegs zu erstellen.
Unterversionen bekommen den Postfix -x, wobei x:= 2 .. n...

Telefonnotizen Angebot/Auftrag

In einem neuen Reiter können Notizen zum Beleg erfasst werden.

Zusätzliche Rechnungsadressen: in Verkaufsbelegmasken auswählbar

S:D:Order: convert_to_invoice params an Invoice::new_from übergeben

Analog zum Verhalten in SL::DB::DeliveryOrder. Siehe auch
commit "convert_to_invoice params an Invoice::new_from(%params)"
(386660077eb786611dc1649d0e1617a29ffc4091)

S:D:Order: convert_to_invoice: items verlinken

S/D/Order: new_from/new_from_multi: Bearbeiter ist immer der aktuelle Benutzer

Bei Workflows zu neuen Belegen ist der Bearbeiter des neuen Belegs immer der
aktuelle Benutzer, egal, was im vorherigen Beleg steht.

S/DB/Order convert_to_delivery_order delivered in Abhängigkeit von stock_out setzen

Testfall ergänzt

orderitems um Attribut optional erweitert

Optionale orderitems werden nicht in den Belegsumme aufaddiert
Anpassung für Order-Controller und Druckvorlagen-System
Weitere Anwender-Details s.a. Changelog

Order-Controller: Workflow Lieferantenauftrag → Preisanfrage

Order-Controller: Workflow Verkaufsauftrag → Verkaufsangebot

SL::DB::Order: überflüssigen Code entfernt

S/D/Order: new_from_multi: Leistungsdatum nur übernehmen, wenn überall gleich.

Für den Workflow, aus der Auftrags-Liste mehrere Aufträge zu einem
zusammenzufasssen.

Preisanfrage/Aufträge: dort, wo es ein Liefertermin gibt, diesen f. Steuer nehmen

Auftrags-Controller: Leistungsdatum bei Workflow berücksichtigen

Einkauf/Verkauf: Feld »Leistungsdatum« für Steuerberechnung

Order->new from poso/sopo keine quonumber übernehmen

Im Lieferantenauftrag macht es keinen Sinn, dass die
Verkaufs-Angebotsnummer als Anfragenummer übernommen wird.

S/D/Order: before_save-hooks f. indiv. Lieferadressen, um …

- keine leeren zu speichern
- das Modul immer auf 'OE' zu setzen

Mandanteneinstellung: Projekt zum Auftrag erzeugen auch für Order-Controller

Auftrags-Controller: Wechselkurs pro Beleg …

- Wechselkurs wird pro Beleg gespeichert
- Wechselkurs ist immer änderbar
- vorausgefüllt aus "alter" Tages-Wechselkurstabelle

Bezieht sich auch auf #135
Refs #135

Wechselkurs pro Angebot/Auftrag: legacy-Methode exchangerate umbenannt

S:D:Order: kein has_customervendor in kivitendo

Anpassung nach cherry-picks aus odyn

Auftragsschnellerfassung: Korrekturen für Währung/Wechselkurs

- Feld auf disabled setzen wenn nicht gebraucht
- _as_null_number damit undef nicht zu 0 wird
- Übersetzte Fehlermeldungen

ticket #9491

(cherry picked from commit c581e4685a217bdd5b73380b1f808037a473dd9f)...

Auftragsschnellerfassung: Währung und Wechselkurs definierbar

impl. #9491

(cherry picked from commit 6cdc5a4a33df4530ce4e141151e83138320e27a2)
(cherry pick von odyn)

S:D:Order: deliverydate Methode für PTC

SL::DB::Order: new_from_multi

Neue Aufträge aus mehreren Belegen (im Moment nur Aufträge) erzeugen.

SL::DB::Order: POD: Doku nicht vorhandener Subroutine entfernt.

Auftrags-Controller: bei "als neu speichern" Konfig wiederk. RGs übernehmen

Auftrags-Controller: Workflow Auftrag VK <-> EK

SL::DB::Order->new_from: Prüfung auf Quell- und Ziel-Typ refactored

Typo in Fehlermeldung

Order: new_from: auch gleiche Quell- und Ziel-Typen berücksichtigen

SL::DB::Order: keinen Fehler werfen, wenn Typ noch nicht zu ermitteln.

Das ist der Fall, wenn noch kein Lieferant oder Kunde gesetzt ist.

SL::DB::Order->new_from implementiert.

Im Moment nur von Angeboten zu Aufträgen (Ein- und Verkauf).

POD-Fehler fixen

Auftrag in Lieferschein wandeln: Rose-DB-Handle für Item-Verknüpfungen verwenden

Sonst wirkt die transaction nicht und es kann sein, dass record_links
angelegt werden, auch wenn die Transaktion abgebrochen wird.

DeliveryOrder->new_from: kein $custom_shipto-Objekt zurückgeben

Falls das Quellobjekt eine individuelle Lieferadresse besaß, wurden bei
new_from() zwei Objekte zurückgegeben: das neue Lieferscheinobjekt und
ein Clone der individuellen Lieferadresse. Diese waren nicht verknüpft....

TopQuickSearch: Auftrag, Angebot, Lieferauftrag, Preisanfrage

convert_to_delivery_order um record_links auf item-Ebene erweitert

Bisher wurden nur die Belege verknüpft und nicht die einzelnen
Items. Analoge Implementierung wie bei convert_to_invoice.
Sinnvoll wäre ein Auslagern, dieser "zu ähnlichen" Verfahren in beiden...

Einheitliche displayable_name Methode für ar/ap/oe/do Objekte

Bestehend aus Dokumentenname und Dokumentennummer, z.B.
Rechnung 12
Gutschrift 20
Verkaufslieferschein 15b

Einheitliche Methode record_number für ar/ap/oe/do Objekte

entspricht jeweils invnumber/ordnumber/donumber

Beleg-Rose-Objekte: items_sorted für nicht gespeicherte Items gefixt

Die bisherigen items_sorted-Routinen verlangen, dass die Positionsspalte
gesetzt ist. Das ist bei noch nicht gespeicherten Belegen oder bei
gerade hinzugefügten Positionen aber noch nicht der Fall....

Einkauf/Verkauf: Bemerkungsfeld mit HTML-Editor ausgestattet

Item-Positionen in DB: items_sorted sortiert nach postition …

in Order und DeliveryOrder

PriceRule: Erste Version

PriceSource: Mehr Informationen an Preise übergeben

record + record_item verfügbar gemacht
best_price für pricegroups
Price: spec/source entzerrt

SL::DB::(Delivery)Order,(Purchase)Invoice: Aliase »add_items«

Die Relationships für die Positionen heißen in allen Klassen
unterschiedlich. Daher gibt es schon seit Längerem den Alias »items« in
allen Klassen.

Das Hinzufügen von Positionen hingegen erforderte bisher, dass man den...

SL::DB::DeliveryOrder->new_from: Optionen zum Weglassen von Positionen mit Menge 0

Rose-Models Einkauf/Verkauf: Relationships für angepasste Lieferadressen

SL::DB::Order: bei Wandlung in Lieferschein delivered auf 1 setzen

SL::DB::Order: with_transaction anstelle von do_transaction nutzen

do_transaction startet immer eine Transaktion, auch wenn außen rum
schon eine läuft. Damit wird die äußere Transaktion de facto außer
Kraft gesetzt.

SL::DB::Order: verwendete Klassen explizit requiren

SL::DB::Order, DeliveryOrder: Funktionen zum Umwandeln von Order in DeliveryOrder

SL::DB::Order: quo/ordnumber in before_save-Hook erzeugen

kein use SL::DB::Object in SL::DB::Object

itmes_sorted liefert immer eine Array-Referenz ...

um unvorhersehbare Dinge durch wantarray zu vermeiden.

neue Methode items_sorted für Order, DeliveryOrder, Invoice, PurchaseInvoice

Verknüpfte Belege Einkauf/Verkauf/Projekte: Listen nach Datum sortieren

Rose: Fremdschlüsselbenennung fixen

Die von Rose erzeugten Fremdschlüsselaccessoren heißen wie die
Spaltennamen, also z.B. in Perl 'trans' zu Spalte 'trans_id'. Das ist
unintuitiv und muss an vielen Stellen (z.B. bei den manager_args,
with_objects etc.) auch als 'trans' angegeben werden....

Boolesche Funktionen ("is_...") auch boolesche Werte zurückgeben lassen

Ansonsten sind Vergleiche nervig:

$a->is_ales == $b->is_sales

Rose: 'with_args' nach Foreign-Key-Einführung gefixt

Die Beziehung heißt nun 'parts' und nicht mehr 'part'. 'part' ist nur
ein Alias.

Rose-Beziehungstypen in Order gefixt

Siehe #2139.

Rose-Beziehungstypen gefixt

Behebt #2139.

Fremdschlüssel für Tabellen oe, delivery_orders, parts, translation

SL::DB::Order: falsche one-to-many zu PeriodicInvoice entfernt

Spellchecks

Order->number dispacher methode, die je nach typ ordnumber oder quonumber aufruft.

Helfermethoden in Belegobjekten.

is_sales methode für Order

Podfixes.

Modelverknüpfungen

Mechanismus zur Konvertierung von RDBO-Objekten nach $form für $form->parse_template

Noch leicht unvollständig

Conflicts:

SL/DB/Order.pm