fixt: #345 Mahnungsersteller im Ausdruck konfigurierbar machen

Im Menüpunkt Mahnungen konfigurieren, kann man nun wählen, ob
der aktuelle Mitarbeiter für die Mahnung/Zahlungserinnerung gesetzt ist
oder der ursprüngliche Mitarbeiter/Ersteller der Rechnung

Rechnungsversand per E-Mail

Falls bei dem Kunden eine E-Mail-Adresse für den
Rechnungsversand hinterlegt ist, so hat diese Priorität
vor der allgemeinem Rechnungsadresse.
Als visuelle Hilfe, wird aus dem Titel 'Empfänger' der
Titel 'Rechnung an:'.

Logik normale Rechnung:
1.) Die Adresse des Ansprechpartners hat Priorität vor allen anderen Adressen (bleibt)
2.) Falls kein Ansprechpartner -> Prüfen auf Rechnungsadresse (neu)
3.) Falls immer noch keine E-Mail -> Prüfen auf generische Mail des Kunden (bleibt)

Logik wiederkehrende Rechnung:

Falls eine Rechnungsadresse gesetzt ist, wird diese schreibgeschützt angezeigt.
Weitere Adressen können wie bisher auch über die Auswahl des Ansprechpartners oder
per freier Eingabe zusätzlich definiert werden

Rechnungsadresse aus den Stammdaten (template file vergessen)

Rechnungsadresse aus den Stammdaten bei periodischen Rechnungen verwenden (Anzeige beim Editieren)

Stammdaten -> Kunden um Textfelder Rechnungsmail und Herkunft personenbezogener Daten erweitert

i)
Die Rechnungsmail ist die generische E-Mail des Kunden, welche die
Rechnung in der Regel bearbeitet (buchhaltung@, einkauf@).
ii)
Aufgrund der DSGVO ist es im Zweifel sinnvoll den Erstkontakt
des Kunden zu dokumentieren (Messe xyz, Telefon-Aktion beta, ...)
Die beiden Felder sind als Suchfeld anhakbar.

SelfTests: check_ap_paid berücksichtigt Auswahl von fromdate und todate

Release 3.5.3

dokumentation.xml Versionsnummer hochgesetzt

LaTeX-Druckvorlagen RB Logo getauscht und Skalierung angepasst

Datenbank-Abhängigkeits-Skripte für release 3.5.3

Abhängigkeit für release 3_5_2 zu 3_5_1 nachgezogen

doc aktualisiert

- changelog um Bugfixes erweitert
- Installationsanleitung um Hinweise für Postgresql je nach Distribution ergänzt

DATEV: Tests: danach wieder aufräumen

PTC: Fehlerhafte ungerundete Berechnung von grossamount

Bei Rechnungen mit sehr vielen sehr kleinen Positionen wurde die
Rundungsfehlerakkumulation _nur_ in den finalen netamounts
berücksichtigt, nicht aber in den daraus berechneten grossamounts was zu
Cent-Abweichungen geführt hat.

(cherry picked from commit 061180a3a9cd5ddffc5d9b40fc1751653fc8ef09)

t/db_helper/convert_invoice.t: Zahlen nach Rundungs-Patch f. PTC angepasst.

Neue Zahlen mit (zahlengleichen) Beispielen an der Oberfläche ermittelt.

Korrektur PriceTaxCalculator: Falsches Objekt zum Prüfen genommen

mit Sven durchdiskutiert

(cherry picked from commit d4102550a27e2bee22d4faed2626fc1434d9e721)

PTC-Tests: ein weiterer Test mit großen Mengen und kleinen Preisen

PTC-Tests angepasst nach PTC-Rundungs-Patch …

"PTC rundet nicht mehr Rabatt vor Mengenmultiplikation"

PTC: item->discount auf 0, wenn nicht definiert, um Warnungen zu vermeiden

PTC: Rückgabe sellprice für items: Steuer und Rabatt berücksichtigen.

So war das vor dem PTC-Rundungs-Patch …
"PTC rundet nicht mehr Rabatt vor Mengenmultiplikation"

PTC: Kosmetik/Kommentare

PTC rundet nicht mehr Rabatt vor Mengenmultiplikation

siehe Ticket #82

Neuer Test für 100000 Artikel zu 0,10€ bei 3% Rabatt
Einen weiteren Test angepasst an die neuen Zahlen.

PTC: nicht einfach die Rundungsgenauigkeiten erhöhen …

… das verschiebt das Problem auf jeden Fall nur.
Siehe auch Ticket #82.

Diser commit macht den Teil
"Ferner Rundungsgenauigkeiten für wiederkehrende Rechnungen erhöht." aus
commit 075f64d61e999506517a304022525d83c29e6e3e rückgängig.

Es folgen weitere Commits zu diesem Problem.

Fixt #350 Fehler p.income_accno_id does not exist

Die mehrmals in RP.pm vorkommenden Zeilen
'JOIN chart c on (p.income_accno_id = c.id)'
und
'JOIN chart c on (p.expense_accno_id = c.id)'
erzeugten einen Fehler, da es in der Tabelle parts
keine solchen Spalten gibt, sondern in taxzone_charts
Deshalb jeweils die Zeile
'JOIN taxzone_charts t ON (p.buchungsgruppen_id = t.id)'
vorher eingefügt und jeweils p.income bzw. p.expense durch
t.income bzw. t.expense ersetzt.
Der Fehler trat auf bei 'Berichte -> Projektbuchungen'
sowie bei der GUV und BWA mit ausgewähltem Projekt.

Aktualisierung Doku

Testfälle für DATEV angepasst

Der Standardwert ist: "Ersetze mit ähnlichen Zeichen".
Die Testfälle basieren aber noch auf: "Werfe Fehler wenn Zeichen nicht in cp1252".

Fixt #352 Beim Drucken mehrerer Rechnung aus dem Bericht heraus wird der Rabatt falsch berechnet

Hotfix für die zweifache Berechnung vom Rabatt (Marge bei Berichten falsch) erstellt.
Hintergrund: Der alte Code erwartet keine vorformatierten Werte, wird aber bei
periodischen Jobs noch zwingend aufgerufen (sellprice mit fxsellprice in MassPrintCreatePDF überlagert)
Ferner Rundungsgenauigkeiten für wiederkehrende Rechnungen erhöht.

changelog für DatevExport kommt mit bestimmten Zeichen im Buchungstext nicht klar

Fixt #348 DatevExport kommt mit bestimmten Zeichen im Buchungstext nicht klar

In der Mandantenkonfiguration befindet sich jetzt eine Einstellung,
welche die Kodierung des DATEV-Exports steuert. DATEV erwartet CP1252.
kivitendo kann diese Kodierung so vom kivitendo Nutzer einfordern, alternativ nicht
vorhandenen Zeichen versuchen zu ersetzen oder die DATEV-Erwartung ignorieren
und UTF-8 liefern. Voreingestellt ist CP1252 mit Ersetzungen

toten Code entfernt

Lagerberichte: html: verrutschtes <tr> und <p> um <table>s weg.

Doku: Modullisten allgemein und Paketlisten für openSUSE, Fedora aktualisiert

LC_CTYPE-Locale auf eine UTF-8-Locale setzen

Beim Starten des Perl-Interpreters wird die Locale anhand von
Umgebungsvariablen wie `LC_CTYPE`, `LC_ALL` und `LANG`
gesetzt. Unter (F)CGI sind diese normalerweise leer, wodurch als
Locale die POSIX-Locale (`C`) gewählt wird — und die hat nur ASCII als
Zeichensatz.

Die iconv-Funktion scheint nun nicht transliterieren zu können, wenn
ASCII als Zeichensatz ausgewählt ist. Sie macht dann z.B. aus `ć` ein
`?` anstelle von `c`.

Beim Start der Programme wird nun `LC_CTYPE` auf eine sinnvoller
Locale gesetzt. Dies ist `de_DE.UTF-8` oder `en_US.UTF-8`, falls
erstere nicht verfügbar ist. Die Sprache ist hierbei irrelevant, da
nur `LC_CTYPE` gesetzt wird und und nicht z.B. auch `LC_MESSAGES` oder
`LC_TIME`.

Dies ist Voraussetzung dafür, das #348 gefixt werden kann.

Weitere Fallback-Module entfernt und Doku angepasst (s.a. #344)

Part-Controller: Normalisieren nach Parsen der Form und nicht als run_before

Das Problem enstand durch commit 2e97532c88dacf9523576df4028b6f7df5967ea8
"Fixt #349 (Normalisierung Artikel) - normalize_text_blocks nach Part-Controller
migriert"

normalize_text_blocks greift auf $self->part zu, welches beim Neuanlegen
noch nicht existiert, wenn normalize_text_blocks als aller erstes durch
run_before aufgerufen wird. Danach wurde init_part aufgerufen, welches
aber bei einem neue Artikel den part_type braucht, um part zu erzeugen.
Das ist aber nicht nötig, da das part in den action_add_xxx-Methoden
später erzeugt wird.
Ausserdem muss normalize_text_blocks z.B. auch nicht bei den Picker-Actions
aufgerufen werden.

Also normalize_text_blocks nur nach dem Parsen der Form aufrufen.

Fixt #361

2 testfälle bank_transactions.t auskommentiert

Die Testfälle sind von odyn portiert und sind erstmal so nicht
in kivitendo abgebildet.

Dokumentation/Modulabhängigkeiten ergänzt (s.a. #344)

Fehlermeldung bei 'als neu Speichern' bei Erzeugnissen ohne Erzeungisbestandteile werfen

Filemanagement: Mandantenkonfig "Erzeugte Dokumente löschbar" wird nicht berücksichtigt

Dieses Flag wurde bisher noch nirgend berücksichtigt.

fixed Issue #220

Fixt #349 (Normalisierung Artikel) - normalize_text_blocks nach Part-Controller migriert

Kosmetik (Einrückungen) zum Commit von gerade

disable_one_time_config: Transaktionssicher (Testcode entfernt!)

CreatePeriodicInvoices: Transaktionssicher

Aufträge verarbeiten, Rechnungen erzeugen, Drucken und E-Mail-Versand
in einer Transaktion

disable_one_time_config: Transaktionssicher

Merge pull request #24 from freiphone/patch-4

Neu angelegte Artikel in Shopware aktivieren.

Neu angelegte Artikel in Shopware aktivieren.

Scheint seit Shopware 5.2 notwendig zu sein, damit der Artikel im Frontend erscheint.
s. https://forum.shopware.com/discussion/39006/artikel-nach-import-ueber-rest-api-im-frontend-nicht-sichtbar

Artikelsuche: Lieferant und Lieferantenartikelnummer wieder als Berichts-Option anbieten

Ist mit der Umstellung auf den Part-Controller verloren gegangen.

Implementiert #357 Auftrag schliessen, falls einmalig wiederkehrende Rechnung inaktiv

Die Generierung einer periodische Rechnung mit der Periode einmalig
sollte auch den Quell-Auftrag schliessen.

Aktualisierung Dokumentation

DATEV::CSV undef ist kein gültiger Wert für den DATEV-Export

fixt den Fehler beim Testfall

DATEX-Export, kein Fälligkeitsdatum für Dialogbuchungen exportieren

t/datev doppelten aufruf entfernt

Lager->Einlagern: kein extra EAN-Feld mehr

das funktionierte ohnehin nicht und seit
commit 87b5c8e4245710eec1c6257ab4e291080bc900bd
"PartPicker kann auch nach EAN suchen"

kann der Partpicker auch nach der EAN suchen.

WH->transfer braucht die EAN auch nicht, da diese gar nicht in inventory
gespeichert wird.

behebt #315 "EAN-Feld beim Einlagern ohne Funktion"

Kontoeinstellungen: Folgekonto kann nicht das Konto selbst sein.

behebt #329
"Konto mit identischem Folgekonto führt zu Endlosschlaufe"

Part-Presenter: Typ u. Klassifizierung: Abfangen, wenn kein Argument übergeben

behebt #332
"Bug: Bericht Lagerbestand gibt Fehler beim einschliessen leerer Lagerplätze"

Lager->Berichte->Lagerentnahme: auch alle Lagerplätze eine Lagers wählen können

siehe #333
"Bericht Lagerentnahme: Lagerplatz lässt sich nicht auswählen"

Lager->Berichte->Lagerentnahme: richtige js-Funktionen einbinden

Hier wurde wohl bei der Übernahme aus einem anderen Projekt eine
neue js-Datei vergessen. Aber es gibt eine andere, die es noch tut.

behebt #333
"Bericht Lagerentnahme: Lagerplatz lässt sich nicht auswählen"

Lager/Einlagern: Grund der Einlagerung wird ignoriert

- Abfrage der eindeutigen ID des Transfertypes statt der Bezeichnung hinzugefügt
- Abfrage nach der eindeutigen ID des Transfertyps erweitert:
- ist diese vorhanden so wird sie direkt verwendet
- ist sie nicht vorhanden so wird das Transferobjekt über den alten Weg erzeugt und die ID des Transfertyps daraus genommen
    (letzteres tritt beim auslagern von Lieferscheinen auf)

implementiert TICKET #4482

(cherry picked from commit e98edcb3c81a18d52dd90b69c76bebeb45954bca)
(cherry-pick von odyn)

Artikel nicht löschen können, wenn in Preisregeln verwendet.

behebt #353
"Preisregeln Wenn Artikel gelöscht wird"

OrderItem-Manager: sortspec für sellprice und discount genau spezifiziert.

Sonst ist die Sortierung-Spalte evtl. nicht eindeutig, wenn z.B. das
Part-Objekt mit in der Abfrage ist.

behebt # #334
"Sortierung Artikelstammdaten/Preisinformationen/Verkaufspreisinformation:
Kundenauftrag"

Form::flatten_variables: Array Serialisierung gefixt

Durch einen 11 Jahren alten Bug wurden Top-Level Arrays nicht
serialisiert sondern jeweils nur das letzte Element zurückgegeben.

Die gefixte Version schafft alle relevanten Tests der t/helper/flatten
suite bis auf nested arrays, die sind von dieser Variante nicht
unterstützt.

(cherry picked from commit e7f489be84347d8e8571c2459e4afda8fb3d978a)

Auftrags-Controller: Kunde/Lieferant auch in englisch mit großem Anfang …

… dann geht auch die Übersetzung nach dem locales-Lauf wieder.

Auftrags-Controller: date_tags mit richtiger id ansprechen

Fehler kam rein mit:
commit 43e74053df32b26b2e2ec5059bebc60d47be753b
"Auftrags-Controller: date_tag mit _as_date füttern"

Inventur: Typo in Übersetzung

Inventur: Fehlermeldung an Benutzer, wenn kein Artikel ausgewählt wurde.

Inventur: Ton ausgeben, wenn Schwellwertwarnung angezeigt wird.

Inventur: Schwellwert in Mandantenkonfig. für Warnung bei Mengenabweichung

In der Mandantenkonfiguration kann ein Mengenschwellwert eingegeben werden.
Wenn die bei der Inventur gezählte/eingegebene Zielmenge mehr als dieser
Schwellwert von der Menge in der Datenbank abweicht, dann wird eine Warnung
angezeigt.

Hintergrund: Mitarbeiter lesen den Artikel mit einem Barcode-Scanner ein und
vergessen manchmal, die vorher eingegebene Menge zu speichern. Dann wird die
Artikelnummer oder EAN in das Mengenfeld geschrieben und ein "Enter" ausgelöst.
Dann ist die Zielmenge sehr groß und falsch. Das kann damit verhindert bzw.
abgeschwächt werden.

locales-Lauf

Kundensuche: html-tag-Fehler

Part-Controller: Als neu verwenden: neue Id für Kunden-/Lieferanten-Art-Nr.

bzw. nicht die alte Id (MakeModel / PartCustomerPrice) für die neuen Objekte
verwenden. Sonst gehen die Kunden-/Lieferanten-Art-Nr. beim Speichern im alten
Artikel verloren.

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

SL::DB::Order: Tests für new_from_multi

SL::DB::Order: new_from_multi

Neue Aufträge aus mehreren Belegen (im Moment nur Aufträge) erzeugen.

SL::DB::Order: POD: Doku nicht vorhandener Subroutine entfernt.

SL::Dev::Record: POD: new_part/_service statt create_part/_service

SL::Dev::Record: POD Formatierung

Auftrags-Controller: Variable besser benennen …

bin drüber gestolpert, weil ich gesucht habe, wo im Workflow -> Auftrag
die Verknüpfungen gespeichert werden. Wg. $quo nahm ich an, dass es hier
nur um Angebote geht.

Auftrags-Controller: date_tag mit _as_date füttern

Mandantenkonfiguration: experimentelle Features einzeln an-/abschaltbar machen

es gibt nun "feature_experimental_order" und "feature_experimental_assortment"

angepasster cherry pick von odyn: bc94c40f2f64e7b40fbd90c49dbf41f86688c32d

Umbennenen von Datei mit mehreren Versionen

Generell können generierte Dokumente nur alle den gleichen Namen haben.
Beim Umbennen wird ggf. auch die Version mitgeschickt. Diese muss aus de rID herausgefiltert werden

bei #102

BDVs für abweichende Lieferadresse auch in Verkaufsrechnungen anzeigen

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

DATEV-CSV-Export leere Feldwerte für Belegfeld2 erlauben

POD Syntax repariert

Auftrags-Controller: bei "als neu speichern" Konfig wiederk. RGs übernehmen

SelfTests: Transactions um Prüfung auf laxe Buchungskonfiguration erweitert

Kontoauszug verbuchen -> Rechnung zuweisen -> rückgängig machen

Ist mit commit 0b26e5752e295 verloren gegangen, jetzt wird
das x auch wieder angezeigt

Workflow quotation -> order. Quell-Beleg schließen.

Angebote|Preisanfrage werden immer geschlossen, falls
es ein Auftrag oder Lieferantenauftrag daraus generiert wird.
Die ursprüngliche Funktion in OE.pm kann als Quelle noch
mehrere Belege haben, dies ist im aktuellen Workflow nur eine
1:1 Beziehungen. TODO: Testfall.

Auftrags-Controller: Beleg vor drucken und E-mailen speichern.

Das nur bei "speichern" auch gespeichert wird, ist vielleicht konsequent, aber
im Alltag eher unpraktisch. Viele Anwender hatten damit ein Problem, dass die
verschickte oder gedruckte Version des Belegs anders ist, als die gespeicherte,
weil oft nicht daran gedacht wurde, nach der letzten Änderung und nach dem
Drucken/versenden nochmals zu speichern.

Deshalb wird jetzt beim Drucken und E-Mailen immer gespeichert.

Auftrags-Controller: Wiederkehrende Rechnungen. Konfig nicht mit neuer id …

… speichern, wenn diese schon vorhanden ist, sondern die vorhandene mit
den neuen Attributen versehen.

Wenn sich die id ändert, lässt sich nicht mehr feststellen, ob für diese Konfig
bzw. diesen Auftrag schon wiederkehrende Rechnungen erzeugt wurden und es werden
evtl. alle nochmal erzeugt.

Einkaufsrechnung: Sinnfreie Weiche für Gutschrift entfernt (toter Code)

Da es keine Einkaufsrechnungen-Gutschriften gibt, sind die
entsprechend Weichen eher irritierend als hilfreich => entfernt.

Workflow: Auftrag -> Angebot. Vorgangsbezeichnung auch löschen.

In Ergänzung zum Commit vom gerade, die Vorgangsbezeichnung des
Auftrags in einem neuen Angebot übernehmen, macht auch kaum Sinn

Kosmetik

Workflow Auftrag -> Angebot: Angebotsnummer entfernen

Betrifft nur die alte Form

SelfTest: Fehlermeldung beim E-Mail-Versand an den Task-Server hochreichen

Toten Code entfernt: customer_or_vendor_selection.js

Bevor es den Customer-Picker gab, bestand die Möglichkeit
über einen Klick auf ein Fragezeichen den Kunden/Lieferanten
rauszusuchen. Die Funktion war noch ein bisschen erweitert,
da der Ansprechpartner noch separat angezeigt wurde (toter Projektcode im
Standard ?), die zusätzlich Auswahl-Funktion hatte keine weitere
Auswirkung. Die aktuelle einzige Stelle, wo der Code noch geladen
wurde ist im Letter-Controller. Das Deaktivieren des js-Codes
zeigt, wie erwartet, keine Unterschiede im Verhalten =>
Alles mittlerweile komplett überflüssig, inkl. edit_part.js (?) in Letter.pm

changelog für TopQuickSearch Benutzereinstellung

TopQuickSearch: UserPreferences kleinere Syntaxverbesserungen

TopQuickSearch: Syntax Logik bei den Userpreferences. with_empty bei der
Auswahl

TopQuickSearch für den Benutzer konfigurierbar gemacht.

Über UserPreferences, allerdings wird die Mandantenkonfiguration (quick_search_modules) nicht
berücksichtigt. Der Benutzer hat alle Schnellsuchen zur Verfügung.
Das L.multiselect2side macht Probleme deswegen auskommeniert. Wenn aktiv wird das
Emailsignaturfeld m Tab "Persönliche Einstellungen" doppelt angezeigt,
beide Felder und Links (Signatur bearbeiten und volle Signatur prüfen) sind sichtbar.