Dateimanagement: größere Vorschaubilder: Versionen berücksichtigen

Dokumentenablage für Rechnungen und Gutschriften unterscheiden.

Sonst werden Dokumente für Gutschriften nicht angezeigt.

Report-Generator: HTML-Template: Kein Paragprah (<p>) um Tabellen (<table>)

Behebt #478 Offene Forderungsliste per Mail verschicken

Preiskalkulation bei Erzeugnisbestandteile, etwas übersichtlicher gesetzt

zu 52f5223a1dcf, mehr als einen Filter im SQL-Statement erlauben

locales-Lauf en

VK-Rechnung: ActionButtons direkt ausgrauen, falls die Aktion nicht erlaubt ist

changelog zu Anpassungen bei Mahnungen

Mahnungsbericht: Anzeige f. Dokumente/Mails abschaltbar

Mahnungsbericht: E-Mails f. Mahnungen anzeigen

Mahnungen: DB-Trigger zum Löschen von Verknüpfungen beim Löschen einer Mahnung

Verknüpfung zum E-Mail-Journal für Mahnungen.

Mahnungen: Rechnungsnummer der Mahnrechung im PDF-Dateinamen statt dunning_id

Der Dateiname wird auch als Name des Anhangs bei Mailversand verwendet und dann
sieht es besser aus, wenn der Name auch mit der Rechnunsgnummer übereinstimmt.

Mahnungen: Status-Bericht nach Mahnlauf mit evtl. Fehlermeldungen.

Das Erzeugen der Mahnungen erfolgt je nach ausgewählten Rechnungen in mehreren
Schritten (Zusammenfassen je Kunde und Mahnlevel oder auch einzeln für jede
Rechnung).
Hierbei können in einem Schritt durchaus Mahnungen für einen Kunden oder einen
Mahnlevel erfolgreich erzeugt und per Mail verschickt werden. In einem
folgenden Schritt kann aber ein Fehler auftreten, der dann zum Abbruch und
einer Fehlermeldung führt.
Dabei gab es bisher keinen Hinweis, ob einzelne Schritte erfolgreich waren und
Mahnungen erzeugt wurden.
Dieser commit sammelt die Ergebnisse der einzelnen Schritte und zeigt am Ende
aller Schritte einen Status-Bericht an.

Mahnungen: PDF an Drucker schicken: Druckbefehl erst prüfen, dann verwenden

Mahnungsbericht: Webdav-Dateien f. Mahnlauf anzeigen

Einfachen Presenter f. Webdav-Objekte

SL::Presenter::FileObject: link_tag verwenden

S:P:Dunning: Link führt nicht mehr zum Drucken, sondern zum Mahnungsbericht, …

… gefiltert für diese Mahnung. Hier kann man die Details sehen und auch drucken.

S:P:Dunning: Link mit link_tag erzeugen

S:P:Dunning: unbenutzten Parameter "type" entfernt

Mahnbericht: Nach Mahnungsnummer filtern können und diese Anzeigen

Mahnungsbericht: Dokumente nur für ersten Eintrag eines Mahnlaufs anzeigen

Mahnungsbericht: zweite Sortierung (fast) immer nach Mahnungslauf …

… bzw. dunning_id. Damit bleib das Zusammenfassen mehrer Rechnungen eines
Laufes beim Sortieren erhalten, falls möglich.

Mahnungen: DMS/WebDAV: erzeugte Dokumente nach Mahnlauf ablegen.

Und zwar außerhalb der Transaktion und nur wenn diese erfolgreich war,
sonst können bei eine abgebrochenen Transaktion abgelegte Dokumente
vorhanden sein, ohne das eine Mahnung oder Mahnrechnung in der DB existiert.

Mahnungen: DMS/WebDAV: erzeugte Dokumente zum Mahnlauf ablegen …

und nicht zur gemahnten Rechnung.

Mahnungen/DMS Upgrade-Skript, dass die Dokumente zu den Mahnläufen verschiebt.

Vorher waren die Dokumente der gemahnten Rechnung zugordnet, nun werden sie
dem Mahnlauf zugeordnet.

Im Prinzip könnte nun dunning1-3, dunning_invoice und dunning_orig_invoice
als object_type im Filemanagement entfallen, aber es kann sein, dass Dokumente
nicht zugeordnet werden können, da z.B. die Mahnung gelöscht wurde.
Dabei werden Dokumente im Moment nicht mitgelöscht.

Dateimanagement: Mahnung: Mahnrechnung bekommt Typ dunning_invoice statt dunning

Hintergrund: Es soll umgestellt werden, dass bei einem Mahnlauf erzeugte
Dokumente zur Mahnenden Rechnung gespeichert werden. Sattdessen sollen diese
zum Mahnlauf gespeichert werden. Dazu wird dann der object_type "dunning"
verwendet, der bisher für die Mahnrechnung benutzt wurde. Die bisher
gespeicherten Mahnrechnungen bekommen nun den object_type "dunning_invoice".

Später könnten die object_typen "dunning1-3", "dunning_invoice",
"dunning_orig_invoice" dann raus, sofern es ein Migrationsskript gibt ;)

Rechnungen: Drucken und Buchen muss dieselbe Restriktion wie Buchen haben

Ansonsten kommt der Anwender auf die Idee eine Gutschrift aus einer
Storno-Rechnung zu erzeugen, doch noch Belege in abgeschlossenen Perioden zu ändern usw

locales-Lauf en

SL::Auth: Typo in Methodennamen korrigiert: create_unique_sesion_value …

-> create_unique_session_value

MT940: Zeichensatz der Datei bei Import auswählen können

MT940: Multi-Line-Varianten von Tag 86 unterstützen

Presenter: SL::Presenter::FileObject in ALL laden

Mahnungen: beim erneuten Drucken ggf. auch originale Rechnung mit drucken, …

… sofern diese beim Mahnlauf mit gedruckt wurde.

Mahnungen: merken, ob die originale Rechnung gedruckt wurde: DB+Rose

SL::DN: print_original_invoices in print_original_invoice umbenannt, …

… da nur eine Rechnung gedruckt wird.

SL::DN: überflüssigen Parameter dbh für print_original_invoices entfernt

Mahnungen: alle erzeugten Dokumente zu jeder gemahnten Rechnung ins WebDAV

Mahnungen: DMS: orig. Rechnung als eigenen Typ

Mahnungen: alle erzeugten Dokumente zu jeder gemahnten Rechnung im DMS ablegen

Dazu die Dateien nicht mehr in SL::Form::parse_template speichern lassen,
sondern in SL::DN selber für jede gemahnt Rechnung ablegen.

Mahnungsbericht: Erzeugte Dokumente anzeigen -> auch Rechnungen f. Mahngebühren

Mahnungen: PDF d. Rechnung über Mahngebühren im DMS speichern

Die Id der zugehörigen Rechnung ist in $invoice_id,
nicht in $form->{invoice_id}.

Mahnung per Mail: auch Rechnung über Mahngebühren anhängen

Der Mailer erwartet den Pfad für das Attachment mit dem key "path",
nicht "filename".
Zudem übersetzten Anhang-Namen verwenden.

Mailer: unbenutzen Code entfernt

Dateimanagement: Download-Aktion: Version richtig interpretieren

Dateimanagement: Fileystem-Backend: aussagekräftigere Fehlermeldung

File-Helper: unbenutzten Parameter file_number entfernt

Mahnungsbericht: Erzeugte Dokumente anzeigen

einfacher Presenter für SL::File::Object

Mahnungsbericht: letzte Sortierung immer nach Mahnungslauf …

… bzw. dunning_id. Damit bleib das Zusammenfassen mehrer Rechnungen eines
Laufes beim Sortieren erhalten, falls möglich.

Order: Vorbelegte E-Mail-Texte für Fall Ansprechpartner aktiviert

changelog: Dateimanagement - Drag&Drop

changelog: Dateimanagement - Vorschaubilder

Dateimanagement: größere Vorschaubilder beim Drüberfahren

S:C:H:ThumbnailCreator: Thumbnail-Größe übergeben können

Dateimanagement: Thumbnails erzeugen und anzeigen

Dateimanagement: Upload per Drag/Drop

Dateimanagement: Hochladen als andere Quelle f. EK-Belege

Also dort, wo bisher auch der Import vom Scanner möglich ist.

S:C:File: Import (scanner): Debug-Warnung, wenn Verzeichnis nicht geöffnet werden kann

Kosmetik: Auftrags-Controller: js: Einrückung und Position der Funktion

E-Mail-Dialog: Knopf E-Mail senden ausgrauen um mehrfaches Senden zu verhindern

 Author:    Jan Büren <jan@kivitendo.de>

Einkaufsrechnungen: Vorgangsbezeichnung speichern und danach suchen können

Artikelstamm: "Erneuert am" aus parts_price_history holen …

… und in "Preisänderung am" umbenennen.

Das ganze ist mit Rose gelöst und holt die Preise aus parts_price_history.
Das hat den Nachteil, dass im Artikelbericht nicht nach der Preisanpassung
sortiert werden kann und es wahrscheinlich nicht performant ist.

Der aktuelle Trigger für parts.priceupdate funktionierte nicht, und hätte
auch bei jeder Änderung eines Artikels das Datum angepasst. Dafür kann man auch
mtime nehmen.

Todo 1: Spalte priceupdate (und den Trigger) aus parts löschen (und alle
Vorkommen finden).
Todo 2: Query auf SQL umschreiben und soriteren wieder ermöglichen.

Refs #254 (redmine)

Lieferschein: direktes, erstmaliges Drucken gefixt

Behebt #469 (redmine)

Auftrags-Controller: 2. Zeile: Lagerbestand nicht doppelt formatieren

Entweder format_amount oder _as_number

Behebt #470 (redmine)

Auftrag-Controller: Vergleich des Beleg-Typs einheitlicher …

- Zum Typ-Vergleich die Typ-Funktionen verwenden.
War hier kein Problem, kann aber Typos verhindern - dafür sind die Funktionen
gedacht gewesen.

- Auf type nicht als Hash-Key, sondern als Methode zugreifen.
Dann ist das einheitlicher, da das auch überall sonst im Controller so gemacht
wird.

Kosmetik: Auftrags-Controller: Typo in Funktionsname

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.

Auftrags-Controller: auch bei E-Mail erzeugtes Dokument im WebDAV/DMS speichern

Brief: erzeugtes Dokument im DMS speichern

wiederkehrende Rechnungen: auch bei E-Mail erzeugtes Dokument im DMS speichern

Presenter::Tag: img_tag aus Plugin/L verschoben

Presenter::Tag: radio_button_tag aus Plugin/L verschoben

kivi.File.js: unbenutzte, leere init-Funktion raus

Filemanagement: Web-Templates list: table-End-Tag korrigiert. HTML-Plugin raus

Filemanagement: Web-Templates import: kleinere Fixes …

- nicht benutztes JavaScript-Plugin raus
- keine Tabellen-Tags ausserhalb einer Tabelle

Filemanagement: Web-Templates upload: nicht benutztes JavaScript-Plugin raus

Kosmetik: Filemanagement Web-Templates: Einrückung

Mailer: überflüssigen Nicht-Standard-Header entfernt

Einen Header namens »Type« gibt's nicht. Vermutlich war »ContentType«
gemeint, aber der wird definitiv anders gesetzt und nicht auf
multipart/mixed.

HTML zu LaTeX: gewisse kaputte Konstrukte vom CKEditor entfernen

Dazu gehören leere Listen <ul></ul> oder Paragraphen mit
Zeilenumbrüchen und non-breakable spaces <p><br><br>&nbsp;</p>

MT940: Zeile 61: Felder »Buchungsdatum« und »Währungsart« sind optional

MT940 parse Feld 25 nach östereichischen Vorgaben

Es scheint Konvention zu sein nach zwei // noch die Länderkennung
in Feld 25 zu schreiben und mit der optional gültigen Währung zu enden
Regex um exakt dieses Präfix vor BLZ/Kontoerkennung erweitert

Stammdaten->Berichte->Kunden Abt1 und Abt2 erweitert

Order-Controller: Knopf f. E-Mail-Aktion nach "Speichern und drucken" freigeben

S:C:H:ThumbnailCreator: POD: Modulname korrigiert und leere Abschnitte raus

SL/DB/Helper/ThumbnailCreator.pm wird nicht benutzt

siehe SL/DB/Controller/ThumbnailCreator.pm

File: POD-Korrektur: File-Typen sind singular

Mahnungen: Mit Rechnung verknüpfen

Erstellte Mahnungen werden mit den gemahnten Rechnungen verknüpft und
unter "Verknüpfte Belege" gelistet.
Außerdem werden Rechnungen über Mahnkosten wiederum zu den zugehörigen
Mahnungen verknüpft.

impl. #7440

DBUtils: Prüfung auf Trigram-Erweiterung aus S/D/ShopOrder in DBUtils verschoben

Order-Controller: Historienfunktion implementiert (aufzeichnen & anzeigen)

Order-Controller: Artikelklassifizierung berücksichtigen

GetModels Filtered: neuer Modifer »any« für logisches oder

Kann benutzt werden, um z.B. verschiedene Part-Klassifizierungs-IDs im
Filter zu nutzen:

<input type="hidden" name="filter.classification_id:any" value="0 1 3">

Order-Controller: TODO »credit limit« entfernt

In Besprechung letzte Woche festgehalten, dass wir die Funktion erst
mal nicht wieder implementieren.

Order-Controller: Workflow Lieferantenauftrag → Preisanfrage

Order-Controller: Workflow Verkaufsauftrag → Verkaufsangebot

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

S:C:Letter: toten Code entfernt

S:C:Letter: kivi.SalesPurchase.js laden