Ergebnis von SL::DB::Manager::Employee->current cachen

Order-Controller: Workflow -> *-Auftrag vorher Speichern

Ansonsten werden die cvars nicht übernommen.
Außerdem ist es konsistenter, da bei allen anderen
Workflow-Aktionen auch immer gespeichert wird (Rechnung oder LS).

Zu 47da14db generische LS-Mail: locales und Anhak-Option in Suche

generische E-Mail-Adresse für Lieferscheine

Ähnlich wie bei Verkaufsrechnungen gibt es generische
Empfänger für Lieferscheine beim E-Mail-Versand.
Die jetzige Konfiguration (nicht änderbar) entspricht
dem Wert Stammdaten und Ansprechpartner in CC.
Ist eine Stammdaten-Mail und ein Ansprechpartner definiert,
bzw. ausgewählt wird der Ansprechpartner in CC gesetzt und
die vorbelegte Anrede ist 'generisch'

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

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

DMS-Dateianhänge beim E-Mail-Versand Vorauswahl konfigurierbar

Rechnungsversand E-Mail-Body

Falls die generische E-Mail-Adresse verwendet wird, sollte auch
die generische Anrede hinterlegt sein, selbst wenn ein Ansprechpartner
noch in CC gesetzt wird.

manueller Rechnungsversand per E-Mail. Vorbelegung mandantenweit konfigurierbar

Changelog und Doku aktualisiert

Verkauf->Rechnungsbericht Filter nach nicht per E-Mail verschickten Belegen

SL::RP: unbenutzte Subroutine entfernt.

DisplayableNamePrefs: Überstzungen

DisplayableNamePrefs: changelog-Eintrag

DisplayableNamePrefs: Benutzereinstellungen

DisplayableNamePrefs: Mandantenkonfiguration

DisplayableNamePrefs: DB-Upgrade-Skript um defaults zu setzen

DisplayableNamePrefs: SL::DB:xxx verwenden DB-Helper

erstmal nur Customer/Vendor/Part

DisplayableNamePrefs: DB-Helper als Mixin

DisplayableNamePrefs: UserPreferences-Helper f. DisplayableName

Ansprechpartner um boolean Hauptansprechpartner erweitert

Entsprechend mit einigen Attributen für den Export von Kundenstammdaten
hinzugefügt.
Hintergrund: Ansprechpartner-Export gibt nur die Liste aller Ansprechpartner.
Das Feld Kontakt (in der Tabelle Kunde) war wahrscheinlich der Vorgänger
für die Ansprechpartner-Logik. Das ist etwas wenig, wenn man noch
E-Mail, Telefon usw. personenbezogen unterbringen will. Deshalb die
Ergänzung für diesen Bericht.

Kontoauszugsimport 2 Konten bei einer Bank. Bankgebührenbuchung wird als schon importiert makiert
Fix für #367

Zahlungsverkehr->Zahlungs-(ein/aus)gang. Bezahlen/Abgleichen mehrerer Rechnungen
Fix für #366

Stammdaten-Kunden: Neues Feld Amtsgericht. Weitere Export-Möglichkeiten

Ust-ID, Kreditlimit, Amtsgericht (benötigt bspw. für Factoring)

Aktualisierte Installationsanleitung Debian/Ubuntu

Drei Pakete sind komplett untergegangen

Aufruf von with_objects in RequirementSpecPart korrigiert

bei SL::DB::Object ist der Parameter "with", nicht "with_objects" (wie
bei SL::DB::Manager::Object)

Das hatte allerdings keine kritischen Auswirkungen, der Parameter wurde
ignoriert und die Daten wurden dann erst später geladen.

Typo in Übersetzung

BackgroundJob SelfTest: unbenutzte Variable entfernt

Typos und spellcheck: unkown -> unknown

Changelog zu den Commits von heute

Ergänzung zu a3b8cfa7b7546 (Mahnungen konfigurierbar machen)

- bessere Fehlerbehandlung -> send_mail läuft schon in einer Transaktion
  Von daher mit die hart aussteigen
- Die Signatur des E-Mail-Versenders sollte dann auch zur E-Mail-Adresse
  passen, entsprechend backup vars erstellt vor dem Aufruf von Form::create_signature

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

Zahlungserinnerung an Rechnungsadresse schicken - Weiche für Absender

Mail-Absender aus defaults.dunning_creator ableiten.
Falls die Rechnungsadresse E-Mail gesetzt ist, diese als Empfänger nehmen ansonsten die
globale E-Mail des Kunden (abwärtskompatibel).

Erweiterung um Fehlerbehandlung mit Hinweis an der Oberfläche, falls keine Sender oder
 Empfänger-Adresse gefunden wird

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