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

Auftrags-Controller: nur neue Maske/Links hierhin, wenn experimentelle Features an

- in Menüs Verkauf/Einkauf: Links zu Angebot u. Auftrag)
- in Berichten Angebot/Auftrag und Lieferscheine: Links zu Angeboten und Auträgen
- im Presenter (und damit in der Liste der verknüpfte Belege)
- Todo-Liste

SL::Menu: Negierung (!) beim access_string erlauben

und Tests hierzu

Tests für access-String-Auswertung des Menüs.

SL::Auth: evaluate_rights_ary: Negierung (!) ermöglichen

Zu #ed9b1bfb7 chart_link _paid (Zahlungsein- /ausgang). statt nur AR_paid

Auftrags-Controller: multi items dialog: JavaScript aus html-Template raus

Auftrags-Controller: S:D:PartsGroup mit use einbinden, nicht mit require

Auftrags-Controller: kein run_before für create_pdf.

Es gibt schon länger keine action_create_pdf mehr.
Auch den Namen des session-keys umbenannt.

Auftrags-Controller: kein Unterstrich vor privaten Funktionen

In einem Controller wird den von aussen zugänglichen Funktionen "action_"
vorangestellt, deshalb ist zur Unterscheidung das Voranstellen eines
Unterstrichs unnötig und verschlechtert die Lesbarkeit.

Auftrags-Controller: kivi.Order.js: Variable row nicht redeklarieren.

Auftrags-Controller: kivi.Order.js: Kosmetik

- alignement
- whitespaces
- weniger data.push

Auftrags-Controller: Kosmetik, alignement

Auftrags-Controller: Auftrag aus DB mit new(id => ...)->load laden …

und nicht mit find_by, damit ein Fehler bei nicht vorhandener id
geworfen wird.

Auftrags-Controller: kein all_projects mehr nötig, da Projekt-Picker

Part: Nach einfügen von Zeile den Customer-Vendor-Picker clearen

sonst gibt es bei "Enter" zwei neue Einträge bei Kunden- und
Lieferantenartikel-Nummern bzw. -Preise

Artikelstammdaten: Einfügen eines Kunden führt zur Fehlermeldung

Im Zusammenhang mit "Kunden-Spezifische Artikeleigenschaften"
commit 62f2141002f5b8c11fa9d881473fd3bc469b4eef
wurde die falsche ID zur Prüfung verwendet.

Jetzt wird nichts zum Server gesendet, falls keine customer_id gesetzt ist

(cherry picked from commit 000ac96383146c8e942badc4c73ccf2f0899392f)

FlattenToForm - Verkäufer-Daten und gelöschte Benutzer berücksichtigen.

Analog zur Behandlung der Benutzer-Daten, die nur in auth vorhanden sind,
auch die Verkäufer-Daten berücksichtigen.

Zudem Daten gelöschter Benutzer/Verkäufer, die der Beleg referenziert, zur
Verfügung stellen.

Das ganze in eine eigene Routine ausgelagert.