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.

installation_check: shell_quote mit vorangestelltem Modulnamen aufrufen, …

… sonst wird die subroutine nicht gefunden, wenn mit require eingebunden wird.

Kam im commit 1cff7d8034b00f4fd365a716596b54b798f035d7
"InstallationCheck: String::Shellcode nicht zur compilezeit laden"
rein.

Auftrags-Controller: Null-Werte in Eingabezeile von leer unterscheiden.

Die Idee war, bei einem leeren Wert in der Eingabezeile ein default zu
nehmen (Menge => 1, Preis => "bester" Preis, Rabatt => "bester" Rabatt).

Bisher wurde aber nicht zwischen leer und 0 bzw. 0,00 unterschieden, so dass
dann auch die default-Werte genommen wurden.
Das wird jetzt unterschieden.

Auftrags-Controller: Bei Angeboten das richtige Nummern-Feld nehmen

Fehler waren hier: keine Angebotsnummer in Name des Anhangs, kein Speichern
im Webdav oder Datei-Storage.

Auftrags-Controller: Email: Anhang-Policy anders prüfen

Wenn das Dateimanagement ausgeschaltet ist, gibt es keine attachement_policy im
Dialog, also nicht auf 'normal' testen.

Sonst wurden keine Anhänge bei ausgeschaltetem Dateinmanagement verschickt.

Auftrags-Controller: print-options aus E-Mail-Dialog für Form::send_email

Sonst wurde z.B. der letzte Ausdruck nicht nicht als Anhang verschickt,
wenn dies ausgewählt wurde, da z.B. formname nicht bekannt war.

Verloren gegangene Uebersetzung fuer 'Payment / Delivery Options' wieder eingefuegt

Warnhinweis in der Suchmaske des Buchungsjournals bezueglich geaenderter Datumsbezeichnungen wieder entfernen

siehe commit 18848eb015510889f521eefa747dee2d1dcd0bec vom 30.5.2017

Changed to gender-free email salutation and replacing "versand" with accurate spelling "versandt"

Added greeting to "my @vc_fields" in flatten_to_form to be able to use the greeting variable in periodic invoices_

vergessene locales nicht nur vom letzten Commit

Liefertermin Erinnerung für Auftrags-Controller

Falls in Mandanten-Konfig aktiviert, wird ein leerer Eintrag in
Liefertermin in Aufträgen beim Speichern oder
beim Workflow 'Speichern und Lieferschein' angemahnt.

Lieferschein löschen, mehr Rückmeldungen an die Oberfläche im Fehlerfall

DATEV-CSV Export Belegfeld2 wieder mit Fälligkeitsdatum YYMMDD belegen

Buchungsgruppen-Auswahl in Waren alphabetisch sortieren

bank_transactions.t Testfälle angepasst

Zwei Testfälle (Vorauswahl der Vorschlagsliste) passen aktuell nicht.
Die sind von Odyn 032b03ab96f8ba6d89, dies ist in kivitendo so nicht implementiert.

behebt #356 Bei Zuweisung von zwei Kreditorengutschrift per Kontoauszug verbuchen fehlerhaft

Programmkorrektur für Testfall #b75c6cbb82023b0d6

BankTransactions.pm  proposals an Testfall übergeben

BankTransaction.pm POD verbessert, Feedback von Sven verarbeitet

Kontoauszug verbuchen: Nur unabgeglichene Buchungen anzeigen

implementiert teilweise Issue #163

MT940 import: transaction_code statt transactionCode

aqbanking-cli benutzt im Standardprofil transactionCode, und das wurde
auch hier beim umwandeln im Header generiert. Das interne Feld wurde
aber mittlerweile umbenannt zu transaction_code, also wurde
transaction_code nicht mitimportiert. Das hatte dann zur Folge, dass
SEPA Sammelüberweisungen nicht abgeglichen werden konnten.

Dialogbuchen, Betrag aus Kontoauszug verbuchen schreibschützen (Maske)

Als Konsequenz aus dem vorherigen Commit, sollte der Benutzer
erstmal nicht fröhlich Freitext-Werte in das Feld füllen.

Eine Bankbewegung muss atomar auf n Belege, bzw. eine Dialogbuchung gesetzt werden

Fehler basierte auf dem falsch verstandenem Konzept von BankTransactions
Entsprechend beim Dialogbuchungen hart abfangen

Bullshit von meinem commit 81ce5300bddff980 rausgeworfen

Nein, Jan. Eben nicht so implementieren, sondern klarer
und hoffentlich wartungsärmer.

BankTransaction weniger Code ist mehr Wert

Aufgrund des klarer formulierten PODs kann eine Routine und
eine weitere zu "schwache" Bedingung entfernt werden.
Fast alle kivi-Testfälle inkl. adaptierter odyn-Testfälle laufen sauber durch.

save_single_bank_transaction dem caller weniger erlauben

Als Konsequenz zum beschriebenem Verhalten im  POD

POD Ergänzungen

BankTransaction::save_single_bank_transaction kann nur
1 noch niemals vorher verbuchte Bankbewegung mit n Belegen verbuchen.
Sollte etwas klarer im POD und später in der Methode deutlich gemacht werden.

Dialogbuchen transaktionssicher

In Ergänzung zum Commit 81ce5300bddf, dass Todo transaktionssicher gelöst.

Kontoauszug verbuchen -> Dialogbuchungsentwürfe verbessert

Nette Idee aus odyn (Start des Gedankens #f09c2b407faa7 Ende des Gedankens #765a3d421e7).
Zwei Sollbruchstellen in odyn, deshalb in kivi neu formuliert:

Sollbruchstellen:
a) Ein Aufruf von BankTransaction::action_list kann Zustände im Datenmodell verändern
b) Der Benutzer kann beliebige Zahlenwerte oder neue Konten in der Dialogbuchungsmaske eingeben

Konsequenz:
-> Zustände des Datenmodells in gl.pl post_transactions ändern, Werte per Rose hierzu aus der DB (und nicht aus $form)
   Möglichst viel dem Benutzer auf die Flossen hauen, wenn die Buchungsmaske unlogisch benutzt wird

Bericht BankTransaction auch Verknüpfungen mit Dialogbuchungen anzeigen

Zahlungsverkehr -> Berichte -> Bankbewegung -> verknüpfte Rechnungen
zeigt die record_links zum Typ ar|ap, erweitert für den Typ gl.

bank_transactions.t Odyn Testfall für kivi angepasst

Bankimport: Fehler beim Verbuchen von Teilzahlungen: Rollback bei Fehler

Falls ein Fehler auftritt wird kein Rollback von der bereits gemachten Zahlung und dem neuen Recordlink gemacht,
lediglich die Banktransaktion wird nicht verändert

Erweiterung durch ein Test test_bt_error

 -> liefert erstmal kein rollback fehler, test dennoch von odyn übernommen (jb)

Conflicts:
t/bank/bank_transactions.t

goodperl: Doppelte Variablennamen raus

bank_transactions.t: Anzahl Testfälle korrigiert

Bankimport: Rundungsproblem beim Vergleich Rechnungsbetrag - Kontobetrag

Durch explizites Runden konnte die perl Floatingpoint Arithmetik nicht überzeugt werden,
deshalb werden nun die Formatierten Strings der Beträge noch zusätzlich verglichen.

Hiermit wird der "exact_match" beim Vergleich von z.B. 3456,28 und 3456,29 nicht mehr gefunden

behebt teilweise Issue #201