Zeiterfassung: Artikel beim Erfassen wählen können und mit auflisten

Zeiterfassung: SimpleSettings für Artikel

Zeiterfassung: Sortierung und Ordnung für Artikel

Zeiterfassung: Auswählbare Artikel: DB-Upgrade und Rose

Zeiterfassung: Keine Zeiterfassungstypen mehr

Revert "Zeiterfassung: SimpleSystemSettings für Typen"

This reverts commit d01aad90ec0e0f0800037e9753acbacccf819a0c.

 Conflicts:
menus/user/10-time-recording.yaml

Zeiterfassung: form: tr-Tags vergessen

Zeiterfassung: Mitarbeiter ändern können bei entspr. Recht

Zeiterfassung: Filtereinstellungen f. callbacks merken

Zeiterfassung: Recht f. Bearbeitung aller Einträge berücksichtigen

Zeiterfassung: Beim Bearbeiten fremder Einträge, Mitarbeiter behalten

Zeiterfassung: Recht berücksichtigen, Einträge von anderen (nicht) zu sehen

Zeiterfassung: neue Rechte: anzeigen bzw. bearbeiten der Einträge aller

Zeiterfassung: einfaches Recht andere Position

Zeiterfassung: Recht hierzu der Gruppe Vollzugriff gewähren

time-recording: Boolean für abgerechnete und an die LohnBu gemeldete Zeiten

Zeiterfassung: Defaultfilter: aktueller Benutzer, letzte 2 Wochen

Zeiterfassung: Nur nicht-gelöschte Mitarbeiter angezeigen

Zeiterfassung: T8-Filter heißt $T8

Zeiterfassung: Übersetzungen

Zeiterfassung: Ein Recht dafür

Zeiterfassung: Controller

Zeiterfassung: SimpleSystemSettings für Typen

Zeiterfassung: Sortierung und Ordnung für Typen

Zeiterfassung: Tabellen und Rose

zu 85693, auch in show_print_options prüfen!

POD für ClientJs aktualisiert

Order: Warnung/Fehler bei Liefertermin auch bei kombinierten Export-Aktionen

locales: en, de

Changelog: Neue Action in Order, BDVs Waren im Stammtab und per_page im Lager

Lagerbestandsbericht per_page als Filter-Parameter an der Oberfläche

Order-Controller: Neue Action preview_pdf (Druckvorschau für PDFs)

Artikel-BDVs unter Basisdaten anzeigen, falls konfiguriert

Die benutzerdefinierten Variablen für Artikel können konfigurierbar im Tab Basisdaten
angezeigt werden

Einkaufsrechnung Historie, Fehler beim Refactoren für ActionBar behoben

Der Parameter muss glid ansatt id sein. Ansonsten kommen nie
Ergebnisse beim Aufruf in der Belegmaske

locales-Lauf en

locales Lauf "de" überwiegend Shopübersetzungen

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

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

Bugfix: taxinclusive mit aus dem Auftrag übernehmen wenn aus Lieferschein eine Rechnung erstellt wird

Bankimport im Dialog verbuchen, Fließkommazahlen/Rundungsfehler erlauben

CVars für Lagerbestand auch in hiddens für den Export

Changelog CVar für Lagerbestand, Option für Lagerbuchung

Im Lagerbuchungsbericht standardmäßig das Dokument der Lagerbewegung zeigen

Lagerbestandsbericht um Anzeige von IC Cvars erweitert

Changelog für Projekte um Dateianhänge erweitert

Dateianhänge aus Projekten auch in E-Mail anzeigen

In Anlehnung an odyn fa2f21bb7d9247782f5e
Im E-Mail-Dialog werden hochgeladene Dateianhänge aus einem
globalen Projekt angeboten und sind vorausgewählt.

Projekte: Dateianhänge auch für Projekte

Cherry-pick aus odyn (Upgrade Skript entsprechend geändert)
implemntiert EGW #6889

fix cherry-pick get_feature_experimental -> get_feature_experimental_order

ar_transactions um Parameter want_binary_pdf erweitert

OE -> report_generator um want_binary_pdf Option ergänzt

ReportGenerator: Get PDF as binary (no print, no http-redirect)

Neuerfassen von  Artikeln, darf keinen Division by Zero Fehler werfen

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