projekt kivitendo

Lieferantenauftragsbestätigung: Nummernbezeichnung im Bericht geändert

Lieferantenauftragsbestätigung: Bericht: Bestätigungsnummer des Lieferanten …

… filtern und anzeigen können

Lieferantenauftragsbestätigung: WF -> Rechnung

Kosmetik: Ausrichtung

Lieferantenauftragsbestätigung: Bericht

ckeditor5: update der javascripte in bin/mozilla/ controllern

Da die meist im footer sind, kann P.textarea_tag das javascript noch
nicht registrieren

Revert "ckeditor5: add_javascript in bin/mozilla controllern entfernt"

This reverts commit 6c0032c716231d72f4d070f0d337b6e8db916fa7.

ckeditor5: add_javascript in bin/mozilla controllern entfernt

Die werden jetzt alle über den P.textarea eingebunden

Angebots-/Auftragsbericht: Lieferadresse anzeigen und filtern

Angebots-Eingang: Bericht

Auftrags-Eingang: Bericht

Wf EK-Auftrag->EK->LS: sortierte orderitems holen => weniger Zufall

Lieferantenauftrag→Einkaufslieferschein: optional nur mit ausgewählten Positionen

Lieferbedingungen ungültig markieren können

save_exchangerate entfernt (wurde benötigt für backorder_exchangerate)

Gültigkeitstoken Einkaufsrechnung

Gültigkeitstoken Lieferscheine (alter Controller)

Verkaufsbelege: Modul bei Lieferadressenauswahl und Detail-Anzeige beachten

Da Ids für Belege und Kunden gleich sein können, muss bei der Listung der
Lieferadresse zum Kunden darauf geachtet werden, dass das Modul auch 'CT'
ist.

design40: DeliveryTerms in alles alten controllern im form_header sichtbar machen

ToDo-Liste: Angebote schließen können

ToDo-Liste: Anfragen und Angebote anzeigen, wenn Anseh-Recht vorhanden …

… Und Rechte getrennt nach Ein- und Verkauf berücksichtigen.

Belegberichte (Angebote/Aufträge) mit Positionsdetails

Kosmetik: gaaaanz lange Zeilen umgebrochen

Angebot/Auftrag Status: Im Bericht anzeigen und danach filtern können.

Fix Formulargültigkeit bei Angbebot/Auftrag → Rechnung

Volltext-Suche im Auftragsbericht

Telefonnotizen: in Berichten Angebot/Auftrag filtern können.

Durchsucht werden Betreff und Text.

Langtext-Dialog: Größe prozentual zum Hauptfenster einstellbar pro Benutzer

Ist hier in der Benutzereinstellung ein Wert != 0 gewählt, so wird der Dialog
entsprechend dargestellt. Auch die Größe des Editor-Bereichs wird in diesem
Fall angpepasst.
Ist 0 oder kein Wert gewählt, so ist das Verhalten wie zuvor.

Recht: Ansehen von Belegen bei Angebot und Auftrag berücksichtigen

Ansehen nur im neuen Auftrags-Controller

Anzahlungs-Rg.: Workflow vom Auftrag: alle Anzahlugns-Rg. und Schluss-Rg.

Wird der Workflow vom Auftrag aus begonnen, so werden alle Anzahlungs- und
die Schlussrechnung vom Auftrag aus gemacht.
Der Einstieg über eine Anzahlungs-Rg. und dann der Workflow
"weitere Anzahlungs-Rg." (...) und hieraus Schluss-Rg. bleibt bestehen.

Anzahlungs-Rg.: Workflow Auftrag -> Anzahlungs-Rg.

Zusätzliche Rechnungsadressen: in Verkaufsbelegmasken auswählbar

Auch aus Angebot/Auftrag->Rechnung tax_included übernehmen ...

wird sonst eventuell von den Kundeneinstellungen überschrieben
und dann unterscheiden sich Angebot/Auftrag und Rechnung

fix cherry-pick get_feature_experimental -> get_feature_experimental_order

OE -> report_generator um want_binary_pdf Option ergänzt

Mandantenkonfig: Lieferdatum bei VK-Auftrag und Gültigsdatum bei VK-Angebot

Anstatt diese beiden Werte zu berechnen, gibt es die Möglichkeit
diese konfigurativ gar nicht zu setzen. Hoffentlich letzmalig auch
für die OE.pm implementiert.

Bericht Angebote/Aufträge: internen Bemerkungen filtern und anzeigen können

Order-Controller: Umwandlung: Berechnung bereits gelieferter/abgerechneter Mengen gefixt

In $::form steht der Wert für die gelieferte Menge in
`ship_$row`. Dieser Wert wird überall im Programm als unformatiert
angenommen, nur bisher in der Methode nicht, die berechnet, wie viel...

Order-Controller: Umwandlung: gemeinsamen Code in eigene Funktion ausgelagert

Wiederkehrende Rechnungen: Anrede in E-Mail-Body-Vorbelegung verwenden

Einkauf/Verkauf: Sprach-Drop-Down aus Print-Optionen in Hauptbeleg verschoben

Noch nicht erledigt ist der neue Angebots-/Auftragscontroller.

Angebote/Aufträge: Abteilungen sortiert anzeigen

Zu bcc996e65643 Rechnungsadresse aus dem Stammdaten auch für alte oe

AR/IR/OE - Steuerbeschreibung an Oberfläche / Druck aus tax_id holen

siehe Kommentare in SL/IS.pm

Wenn ein Steuerautomatikkonto mehrmals bei den Steuern auftaucht kann
man die Steuerbeschreibung nicht mehr eindeutig anhand der Kontonummer
(hier als taxnumber verwendet) bestimmen, von daher wird jetzt immer...

Wiederkehrende Rechnungen: vorbelegte E-Mail-Texte setzen falls leer

Vorher wurde nur geprüft, ob die Konfiguration schon gesetzt wurde.
Sollte ein Kunde im Nachhinein auf E-Mail-Versand umstelle ist
das Verhalten jetzt komfortabler

Angebot / Auftrag (alte Masken) / Lieferschein: nur Mailen, wenn gespeichert

Behebt #418 (redmine).

Bericht Angebote/Aufträge: Abteilungen anzeigen können

Einkauf/Verkauf: Bemerkungsfelder gleich groß anzeigen

Einkauf/Verkauf: keine Validierung bei Update-Button

Andernfalls wird z.B. erzwungen, dass die Vorgangsbezeichnung
eingegeben ist, bevor der Update-Button betätigt wird. Das betrifft
auch den Kundenwechsel, der ein automatisches Update triggert, was
wiederum die Validierung triggert....

Module: gebundletes YAML durch dünnen Wrapper über YAML::XS & YAML ersetzt

poso mehr werte löschen (wandlung kundenauftrag -> lieferantenauftrag)

Währung und Steuerzone wird ansonsten vom vorherigen Beleg
übernommen. Betrifft nur die alte Maske

Verkaufsaufträge: konfigurierbares Intervall für Lieferdatum-Berechnung

Auftrags-Controller: Aufträge auch mit neuem Controller zusammenfassen können

Mandantenkonfiguration: experimentelle Features einzeln an-/abschaltbar machen

es gibt nun "feature_experimental_order" und "feature_experimental_assortment"

angepasster cherry pick von odyn: bc94c40f2f64e7b40fbd90c49dbf41f86688c32d

Angebote/Aufträge: Benutzerdef. Variablen in Lieferadressen gefixt

Auftrags-Controller: nur neue Maske/Links hierhin, wenn experimentelle Features an

- in Menüs Verkauf/Einkauf: Links zu Angebot u. Auftrag)
- in Berichten Angebot/Auftrag und Lieferscheine: Links zu Angeboten und Auträgen
- im Presenter (und damit in der Liste der verknüpfte Belege)...

Auftrags-Controller: auch für Angebote/Anfragen

Aufträge speichern: Warnung bzgl. existierender wiederkehrender Rechnungen gefixt

Behebt #341.

Wiederkehrende Rechnungen: Templatevariablen in Hash oder Objekt übergeben

Damit lässt sich das Template auch mit einem PeriodicInvoiceConfig-Objekt
aufrufen und kann so von anderen Controllern verwendet werden.

Auftrags-Controller: Workflow Lieferschein: gelieferte Positionen filtern

Dieser commit enthält einen Hack, der nochmal diskutiert und geändert werden
sollte.

Auftrags-Controller: Workflow -> Rechnung (Speichern und Rechnung erfassen)

kivi.Validator: In OE Suche und Normaler Maske als check registriert

kivi.Validator: Validaotr in restlichen Belegcontrollern eingebunden

Vorbelegte E-Mail-Texte um Vorbelegung periodic invoices ergänzt

CustomerVendor Picker: autocomplete_customer.js includes umgestellt

oe: implizite global %TMPL_VAR in den request cache verschoben.

Bug-Fix

Klick auf Drucken in der ActionBar löste nur speichern aus, wenn es sich um einen neuen Auftrag handelte.

Einkaufs- & Verkaufsbelege: Bearbeiter*in & Verkäufer*in mit aktueller Benutzer*in vorbelegen

Dies ist nur ein Fallback, wenn bis zur Ausgabe des Form-Headers noch
nichts für die beiden Felder festgelegt wurde. Damit wird also
weiterhin eine Verkäufer*in aus den Kunden-/Lieferantenstammdaten...

ActionBar: oe.pl: Actions für Wechsel Einkauf ↔ Verkauf gefixt

ActionBar: Korrekte actions für purchase_order und request_for_quotation

Auftrags-Controller: als experimentelles Feature abschaltbar.

Bei Aufträgen die mit "Save as new" erzeugt werden muss die gelieferte Menge auf 0 gesetzt werden

Beim neu Laden des Auftrags wird ship_{pos} zwar überprüft, jedoch erst beim erneuten Speichern zu 0
oder richtigen Wert gesetzt.

ActionBar: »Anhänge aller Artikel herunterladen« bei Angeboten/Aufträgen wieder implementiert

ActionBar: ReportGenerator nutzt per Default nun die ActionBar

ActionBar: Auslassen von Actions über Parameter »only_if«/»not_if« steuern können

Gedacht für Buttons, die z.B. aufgrund der Mandantenkonfiguration nie
angezeigt werden können. Nicht gedacht für Buttons, die nur aufgrund des
Belegzustands nicht benutzt werden können (z.B. »Löschen« bei einem noch...

ActionBar: Verwendung bei Angebots-/Auftragssuche

ActionBar: existierende Inputs namens »action« vor Submit entfernen

Wenn man zuerst druckt und dabei »action« auf z.B. »print« gesetzt wird,
so wird anschließend das PDF heruntergeladen. Allerdings verbleibt die
»action=print« in der Form.

Wenn dann anschließend einer der Menüpunkte angeklickt wird,...

ActionBar: alte Funktionen zum E-Mail-Versand entfernt

ActionBar: Angebote/Aufträge: E-Mail-Versand über Dialog implementiert

ActionBar: Angebote/Aufträge: Lieferadresse via Popup bearbeiten

ActionBar: Verwendung in Berichtsfunktion in oe.pl

ActionBar: API-Umstellung fürs Hinzufügen

Designziele:

• möglichst wenig Funktionsaufrufe auf eine ActionBar-Instanz
• Hash-artige Struktur der Daten zwecks bekanntem Aussehen und leichter
Verständlichkeit
• Leichter um neue Typen erweiterbar
• Rekursiv parsend (für Comboboxen)

ActionBar: Prüfung auf Transportkostenartikel in JavaScript implementiert

ActionBar: bei Click auf Combo ohne oberste Action Menü aufklappen

Manche Comboboxes wie z.B. »Workflow« oder »mehr« haben auf dem obersten
Button keine Action konfiguriert (weder »submit« noch »call«). Um die
Benutzer nicht zu sehr zu verwirren, werden diese nun nicht mehr als...

ActionBar: Setup in oe.pl in eigene Funktion ausgelagert

ActionBar: Tooltips für deaktivierte Aktionen in oe.pl

accesseky enter

oe: confirm bei delete

oe: lieferadresse in body verschoben

oe: buttons im footer entfernt

oe: neue syntax für scriptbuttons und separators

oe: actiobar nochmal umgestellt

oe: auf prototyp auf einzelnes add umgeschrieben

oe: auch die korrekten checks registrieren

oe: neue actionbar version prototyp

ActionBar: oe Prototyp

PartPicker von autocomplete_part.js nach kivi.Part.js verschoben

Dateimanagement: Integration in Masken und Controller

Einbau in alte Masken (bin/mozilla/* und templates/webpages/??/)
sowie in neue Controller für Kunden/Lieferanten/Artikel ,
in neuen Auftragscontroller

arap.pl entfernt

Sie enthielt nur noch drei Funktionen:

• select_project — wurde nirgends mehr verwendet
• project_selected — war nur eine Helferfunktion für select_project
• continue — diese wurde nach common.pl verschoben

Angebote/Aufträge: Währungsauswahl via L.select_tag