S:C:Order: Angebotseingang schließen, wenn Lieferantenauftrag daraus erstellt.
Anpassung nach RecordController/Rebase
Kosmetik: S:C:Order: Leerzeichen am Ende weg
Model::Record: Workflow zu Angebots- und Auftrags-Eingänge eingefügt
Controller::Order: Nutze type_data Text fürs Speichern
Model::Record: Überprüfe ob Positionen vorhanden sind
Order: FIX: überprüfen von Werten in der Form bei Workflows
Model::Record: Order: Anpassen nach Rebase
Records: js-save Aufrufe angepasst und vereinheitlicht
Records: Workflow-Methoden angepasst und vereinheitlicht
Model::Record: Funktionsaufruf angepasst für new_from_worklow ...
und new_from_workflow_multi
Model::Record: FIX: Methodenaufruf in Workflow
Model::Record: Anpassen nach Kunden/Lieferanten-Änderung
Order: nutze TypeData
Model::Record: Entferne TypedataProxy
Auf Typedata kann jetzt immer über den Belege zugegriffen werden.
Angebotsflag/Intakeflag aus Datenbankzugriffen entfernt
Order: nutze Record-Type
Order-Controller: Reklamation -> Auftrag: Positions-Verknüpfungen gefixt
Order-Controller: Typo-Fix
Order-Controller: Workflow zu Angebot/Auftrag mit S:M:R->new_from_workflow
Und converted_from_... gefixt.
Model::Record: übergebe Typ für new_from_workflow und ..._multi
Order-Controller: Typo in Kommentar
Order-Controller: Kosmetik: Ausrichtung
Revert "Order-Controller: snumbers für History in eigener Routine zusammenbauen"
This reverts commit 9dab1c5cb1f8b9ed946cde7b3c783801671680ed.
TypeData: nutzte Konstanten anstatt String für Typen
Order-Controller: S:M:R->save bestimmt selbst, ob Preise/Steuern berechnet werden
Model::Record: _get_snumber in DeliveryOrder, Order und Reclamation eingebunden
TypeData: Proxy in Controller/Order eingebunden
Order-Controller: Parsen von Telefonnotizen in sub ausgelagert
Order-Controller: Behandlung von Telefonnotizen beim Speichern in sub ausgelagert
Order-Controller: Leere Liste für objects_to_close abfangen
Model::Record: umbenennen von update_... zu clone_for_save_as_new
Model::Record: update_after_new implementiert
OrderController: Preise beim Speichern auch berechnen
über Model::Record
OrderController: Angebote schliessen, wenn Auftrag daraus erstellt
Order-Controller: Pflichtenheft: Verknüpfungen und Projekt setzen
DB::Order: no_linked_records Flag zu new_from hinzugefügt
Model::Record: update_for_save_as_new implementiert
Order-Controller: Model::Record->save verwenden
Order-Controller: snumbers für History in eigener Routine zusammenbauen
RecordLink: in controller vor dem Speichern und ausserhalb der TX behandeln
RecordLink: conversions nicht mehr manuell in Controllern machen
stattdessen per Helper setzen lassen
Order-Controller: doppeltes "use" für SL::Model::Record raus
OrderController delete auf SL/Model/Record->delete gemapt
Order-Controller: Unterversion hochzählen über Model:Record umgesetzt
Todo: SL::Model::Record->save verwenden, sobald implementiert
Model::Record: new_from_workflow_multi implementiert
Model::Record: new_from_workflow implementiert
IMAPClient: um Funktionen fürs Synchronisieren und Aufräumen erweitert
"Beleg ohne Positionen speichern erlauben" in Mandantenkonfig einstellbar
Auftrags-Controller: Beleg ohne Positionen speichern nicht zulassen.
Angebots-Eingang: Schliessen, wenn Lieferantenauftrag hieraus erstellt wurde
Angebots-Eingang: Controller
Auftrags-Eingang: AE schließen, wenn AB erstellt
Wenn eine AB gespeichert wird und im vorhergehenden Workflow einAE vorhanden ist, so wird der AE geschlossen.
Auftrags-Eingang: Controller
Aufruf zum IMAP-Client korrigiert
Order: Hole Emails aus zugehörigen Ordnern
Order: Erstelle Emailordner für neue VK-Angebote und VK-Aufträge
Auftrags-Controller: Gültigkeitstoken WF Artikel->Lieferantenauftrag
Behebt #565 (redmine)
Lieferantenauftrag→Einkaufslieferschein: Lieferantenartikelnummer anzeigen
Lieferantenauftrag→Einkaufslieferschein: optional nur mit ausgewählten Positionen
typo saving
FIX: _tax_row für Auftrag und Reklamation
Falsche If-Abfragen und fehlende Übergaben
Gültigkeitstoken in Transaction abfragen und löschen ("neue" Controller)
Lieferbedingungen ungültig markieren können
Auftrags-/LS-/Reklamation: neue Controller: BCC nicht vorbelegen mit globaler BCC
Die glovbale BCC-Adresse wird beim Versenden autoamtisch angehängt. Alsonicht in der Maske vorbelegen, sonst bekommt der Empfänger die Mailsdoppelt.
Gültigkeitstoken Auftragscontroller
S:D:Reclamation per use im Auftragscontroller einbinden.
S:D:Reclamation kommt an mehreren stellen vor und einmal wurde das "require" vergessen. Zudem merkt man compile time-Fehler dann direkt.
behebt #547 (redmine)
reclamation: Workflow Auftrag -> Reklamation: Parameter richtig an js übergeben
Nachdem benannte Parameter für save eingeführt wurden
Reclamation: don't save order after converting
Revert "Reclamation: Order Workflow actionraus"
This reverts commit 3061e8a20f1185e01f8d828b1692663df4a8cd2b.
Reclamation: Order Workflow actionraus
Workflow: order ↔ reclamation
design40: quotation flag in _tax.html
Auftrags-Controller: neue Unterversion erst in Transaktion speichern
WF Kunden-Angebot/-Auftrag -> Preisanfrage: Direktlieferung
Nachfrage, ob Lieferadresse als indiv. Lieferadresse in Einkaufsseiteübernommen werden soll.
Auftrags-Controller: WF Kunden-Angebot/-Auftrag -> Preisanfrage
Auftrags-Controller: WF Preisanfrage -> Kunden-Auftrag
Auftrags-Controller: WF Preisanfrage -> Kunden-Angebot
Auftrags-Controller: Workflows zum Controller selber vereinheitlicht
Es gibt nun eine Methode für die Worklows und das Workflow-Zielwird übergeben.
Auftrags-Controller: Workflows: Fehlermeldung beim Speichern richtig anzeigen
Workflows von und zum Auftrags-Controller wurden mit einem submit aufgerufen(bis auf die Workflows zu Angeboten - hier wurde ein ajax-Call verwendet,der dann aber wiederum ein submit gemacht hat)....
Auftrags-Controller: Neuberechnen und unveränderliche Daten immer vor Speichern
recalc() und get_unalterable_data() nicht mehr als run_before-Hook aufrufen,sondern immer vor dem Speichern in der sub save().Es gibt zuviele Actions, bei denen das gemacht werden muss und zu viele,...
ToDo-Liste: Angebote schließen können
Unterversionen: Code zum Ermitteln, ob finale/gesperrte Version, als Methode
Unterversionen: E-Mails finaler/gesperrter Versionen neu verschicken können
Auftrags-Controller: "Versendet" (Mail) nicht selber in History speichern.
Das wird schon in SL::Form::send_email() gemacht.
Auftrags-Controller: Meldung, dass Mail versendet wurde auch bei Fehlern, …
… anzeigen, die nach dem Senden auftreten.
Auftrags-Controller: Beleg neu laden nach "Speichern und E-Mail" auch bei Fehler
Wenn nach dem Speichern ein Fehler auftritt, Beleg neu laden mit redirect.Gleiche Problematik/Begründung wie in commit1268bf670c06f5a66ad78a75e41ad6c15061d9bc
Zudem wird dann auch der E-Mail-Dialog geschlossen und die Fehlermeldung...
Angebot/Auftrag Status: Status setzen können
Auftrags-Controller: js: benannte Parameter für save und show_print_options
Unterversionen: Aktion zum Erzeugen nur anzeigen, wenn Feature eingeschaltet
Unterversionen: Version sperren: update_attributes ruft save implizit auf
Unterversionen: Prüfung auf DMS-File angepasst: …
Nur prüfen, wenn Versionierung an, DMS an und Beleg mit verschickt wird.
Unterversionen: Controller: Variable umbenannt und Kosmetik
Unterversionen: auch im Einkauf
Unterversionen: Controller: Code zum Erzeugen der neuen Belegnummer vereinfacht
- number-Accessor nehmen, dann kann die Fallunterscheidung weg- der Controller stellt schon sicher, dass es nur valide Belegtypengibt- try/catch kann weg, da das save selber eine Ausnahme werden kann
Unterversionsnummer auch für ABs erhöhen
und postfix stabiler
Telefonnotizen in HTML: anzeigen/laden/speichern
Unterversionierung über Mandantenkonfiguration aktivierbar
locales für Funktion Unterversionen
Unterversionen für Angebote/Aufträge
Versionen werden finalisiert sobald sie per E-Mail rausgeschickt wurdenDanach ist die Bearbeitung gesperrt, aber es ist möglich eine neueUnterversion des Belegs zu erstellen.Unterversionen bekommen den Postfix -x, wobei x:= 2 .. n...