Shoconnector Syntaxfehler behoben

SHOPOrders Status setzten bei Rechnungen korrigiert

ShopApi: statussetzen bei Rechnung schreiben Syntaxfehler behoben

ShopConnector: set OrderStatus in Shop

WebshopApi: template und js überarbeitet

WebshopApi: Controller/ShopOrder.pm überarbeitet

WebshopApi: ShopConnector überarbeitet

CSV-Import CustomerVendor: Warnungen wegen nicht initialisierter Variable vermeiden

CSV-Importe: Warnungen wegen nicht initialisierter Variable vermeiden

CsvImport - Tests für Kundenimport

Im Moment werden alle Tests nur für Kunden, nicht für Lieferanten durchgeführt.

CsvImport: Mulitplex: handle_cvars-Routine verlassen, wenn Objekt keine CVars kann

CsvImport: Bei Imports ohne CVars deren Standard setzen, wenn vorhanden.

Upgrade-Skript um Doubletten bei benutzerderfinierten Variablen zu entfernen.

Im großen commit 52518527bc507767386d21e1870cc2888269ba70
"CSV-Import Artikel: Einige Erweiterungen ..."
kam ein Bug rein, der für Part-CVars doppelte Einträge anlegen konnte.

Dieses Upgrade-Skript löscht die Doubletten - der neuste Eintrag wird behalten.

CsvImport: Parts: CVars von handle_cvars behandeln lassen.

Dabei aber beachten, dass das bei einen Import, wo nur die Preise aktualisiert
werden sollen, nicht geschieht.

CSV-Import: CustomerVender benutzerdefinierte Variable aktualisieren

handle_cvars erst aufrufen, wenn das zu speichernde Objekt bekannt ist. Das
betrifft den Fall, wenn vorhandene Objekte aktualisiert werden sollen.

behebt #237 (redmine)

CsvImport: handle_cvars: CVars für das zu speichernde Objekt setzen.

Revert "CSV-Import: CustomerVender benutzerdefinierte Variable aktualisieren"

This reverts commit a8628c6af6ab8303fe67d874adbee0211bd86c1e.

Hier wird das eigentliche Problem nur umgangen.
Zudem, wie im commit schon erwähnt, sollte handle_cvars nur einmal aufgerufen
werden.

Es folgen commits, um den Bug zu beheben.

CsvImport: CustomerVendor: Nummer vom Helper des Objekts vergeben lassen.

Vorher wurde hier SL::TransNumber verwendet - das ist kein Problem, aber die
es den Helper gibt, ist das hier einfacher.

Zudem wurde vorher auch eine neue Nummer für die zu aktualisierenden Objekte
geholt - aber das Objekt selber wurde nicht gespeichert, sondern object_to_save.
Da war dann die Report-Anzeige nach dem Speichern falsch, das Objekt aber
richtig. Aber der Nummernkreis wurde falscheweise hochgesetzt.

behebt #287 (redmine)

CsvImport: Im Report die Werte des gespeicherten Objekts speichern.

Bei den Workern, die Objekte aktualisieren können, kann statt dem object
das object_to_save gespeichert werden. Die Werte dieses Objekts sollten im
Report angezeigt werden, auch wenn die eigentlich gleich sein müssten.
Aber so können einem evtl. Fehler auffallen.

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.