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.

Auftrags-Controller: Sprache aus Kunden-/Lieferantenstammdaten vorbelegen.

Auftrags-Controller: totalen Ertrag unten anzeigen

Auftrags-Controller: Verkäufer aus Benutzer vorbelegen, wenn nicht beim Kunden

Beim Anlegen eines Angebots/Auftrags wird der Verkäufer mit dem Verkäufer aus
den Kundenstamdaten gefüllt. Ist hier keiner gestezt, so wird der Verkäufer mit
dem aktuellen Benutzer vorbelegt.

copy & paste Fehler bei SQL-Upgrade Skript für die Beschreibung behoben

Auftrags-Controller: "Speichern und Lieferschein/Rechnung" unter Workflow

Auch, wenn hier gespeichert wird, ist es doch ein Workflow.

Kundenstatistik: Links bei Orders waren noch falsch

Bericht Lieferscheine (do.pl) check_all bzw. hier multi_all gefixt

Kundenstatistik: Fehler beim Link zu Rechnungen behoben

Kundenstatistik: Rechte abgefragt

Kundenstatistik: Typo und Formatierung

Kundenstatistik: POD Syntaxfehler behoben

Kundenstatistik: Link bei den Rechnungen, Übersetzungen

Kontoauszug verbuchen: Skonto-Option auch über Rechnung suchen anbieten

Historisch bedingt kann das automatische Skonto bei Zahlungen nur
benutzt werden, wenn die Bankbewegung in der Spalte Vorschläge
per ajax Klick hin- oder herbewegt wird. Alle Rechnungen die auch
oder zusätzlich oder gar besser passen, aber über die Funktion
Rechnung suchen gewählt werden, wurden bisher nicht berücksichtigt.
Dieser simpler Aufruf in TT bereinigt die Inkosistenz (s.a. POD
zum Commit vorher).

Payment-Helper: get_payment_select_options_for_bank_transaction verbessern

Falls es kein Skonto-Datum gibt, d.h. der Beleg hat überhaupt keine
Skonto-Option, dann auch dem Benutzer erst gar nicht die Auswahl
anbieten.
Prinzipiell die Auswahl anzeigen ist sinnvoll, damit das Verhalten
durchgängig ist und dem Anwender visuell klarer ist, was gebucht werden wird.

SEPA-Export: Überweisungen via SEPA - Feature Überweisungsdatum vorbelegen

Muss aktiv in der Mandantenkonfiguration (Feature -> SEPA) aktiviert werden.
Entweder wird ein vorhandenes Skontoziel als Ausführungsdatum an
die Bank/Export übergeben oder die Netto-Fälligkeit.
Skonto geht vor Netto. Bei beiden Verfahren wird ein Puffer
in Tagen (Standard 0) abgezogen.

changelog Leerzeichen anstatt tabs

changelog zu Kundenstatistik

Kundenstatistik: javascript uas Templates in eigene js ausgelagert

Kundenstatistik: Rechte

1 Recht um den Tab Belege bei Kunden anzeigen zu lassen
1 Recht um den Tab Belege bei Lieferanten anzeigen zulassen

locales

Kundenstatistik: Typo im Template

Kundenstatistik: POD

Kundenstatistik: Typo im Template

Kundenstatistik: Briefe

Kundenstatistik: Emails

Kundenstatistik: offene Rechnungen, offene Aufträge, Angebote, Aufträge,

Kunden und Lieferanten
Kunden Angebote, Aufträge, Rechnungen
Lieferanten Preisanfragen, Lieferantenaufträge, Rechnungen

Kundenstatistik: dbh auf SL::DB->client->dbh umgestellt

Kundenstatistik: Weiteres Template

Kundenstatistik: Templates

Kundenstatistik: erster commit ohne Webtemplates

SEPA verknüpfte Kreditorenbelege nicht stornieren/löschen

Wie in #b231d037 für Einkaufsrechnungen, gelten dieselben
Regeln bei Kreditorenbelegen. Changelog aktualisiert.

Ergänzend zu #359 DB->load anstatt croak

croak|die liefert keine Meldung an den ajax-Aufrufer zurück.
SL::DB::..->load hingegen schon. Entsprechend geändert.

Changelog für #359

fix #359 get_payment_select_options_for_bank_transaction vereinfachen

OrderController Einrückung/Formatierung

OrderController Typo

get_storage_enabled war falsch in MassInvoiceCreatePrint

auch in MassDeliveryOrderPrint eingefügt

Kreditorenbuchungen: Warnung bei vorhandener Rechnungsnummer für diesen Kreditor

Vorbedingung:
AP.js erweitert, sodass der Prüfcode entsprechende Inputs von IR oder AP prüft.

Erweiterungen:
Einkaufsrechnung (IR) mit derselben Prüfung wie Kreditorenbeleg beim Speichern versehen
Prüffunktion auf schon vorhandene Belegnummer zu diesem Kreditor bei
Einkaufs- oder Kreditorenbeleg implementiert.
Generischen Controller für JS-Prüfung (SalesPurchase.pm) mit einer
Funktion hinzugefügt, sowie entsprechend Changelog und locales.

Fixt #336 Can't locate object method "doc_storage_enabled" via Package SL::Controller::MassInvoiceCreatePrin

Auftrags-Controller: OpenDocument-Druck

CustomerVendor-Picker: 'type' nicht als html-Attribut setzen

Die Parameter des Picker-Aufrufs werden an das Input-Tag weitergeben und so
wurde das type-Attribut mit dem Typ (customer/vendor) des Pickers
überschrieben.

CustomerVendor-Controller: test_page Presenter (P) einbinden (statt L)

Dateimanagement: nicht implementierte Speichertypen nicht anbieten/entfernen

Aus Maske und Datenbank (defaults)

Update Übersetzungen nach Umstellung Links zu Auftrags-Controller

Nach commit "Auftrags-Controller: nur neue Maske/Links hierhin,
wenn experimentelle Features an"
(f825d995db2667be33e98ced722ddf012b484642)

DATEV-CSV-Export Belegfeld 2: trim statt regex verwenden

DATEV-CSV-Export Belegfeld 2 6- oder 5-stellig formatieren

Ansonsten gibt es bei führenden 0en immer eine Warnung beim
DATEV-Import.

Auftrags-Controller: gelieferte Menge in Auftragsposition anzeigen.

ShippedQty: Typo in POD

io.pl: unbenutzte Variable entfernt

Workflow VK-Rechnung->Auftrag auf neuen Controller bei experimentellen Features

Auftrags-Controller: weitere Links hierhin bei experimentellen Features