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

Bankimport: Prüfung des reinen Ziffernanteils der Rechnung

Falls Rechnungen in der Rechnungsnummer ein Prefix vor der Nummer haben
und dies nicht exakt im Verwendungszweck der Kontobewegung aufgeführt ist,
wurde dies nicht als Bewertungskriterium herangezogen.

Nun wird dies mit etwas wenig Punkte bewertet.

In diesem einfachen Verfahren wird bei einer Rechnungsnummer 'RE12345' auch ein 'Blabala 12 nix 34 ddd 5' erkannt,
was aber recht unwahrscheinlich ist.

behebt auch Issue #201

Bankimport: Tests erweitert

fix Issue #201

Conflicts:
t/bank/bank_transactions.t

SL::Mailer: content_type statt contenttype, so wie im POD beschrieben

RecordLinks: Support für Kreditore/Debitorenbuchungen

Conflicts:
SL/Controller/RecordLinks.pm

ergänzung cherry-pick: form->format_sellprice existiert nicht

BankTransaction/list: vorhandene sepa_export_items an get_agreement übergeben

Conflicts:
SL/Controller/BankTransaction.pm

Ergänzung zum cherry-pick von gerade format_sellprice ist nicht in Form.pm

Ferner doppelt gepickte Bibliothek entfernt.

BankTransaction/list: sepa_export_items mit partition_by splitten

Spart eine Doppelschleife

Conflicts:
SL/Controller/BankTransaction.pm

BankTransaction::get_agreement_with_invoice - sepa_export_items optional übergeben

CSV-Import Aufträge: Bei History-Eintrag zwischen Ver- und Einkauf unterscheiden

Auftrags-Controller: Lieferantendetails ("D"): keine Preisgruppe bei Lieferanten

Überflüssige Zeile entfernt

Verbindlichkeits-/Forderungskonto bei Kred-/debitoren mit Standardkonto
aus Mandantenkonfiguration vorbelegen wenn vorhanden

CsvImport Aufträge: interne Bemerkungen aus Kunden-/Lieferantenbemerkunen setzen

falls keine intnotes in der CSV-Datei angegeben sind.

LaTeX-Escaping: gewisse Formen von »no line to end here« vermeiden

Passiert, wenn im HTML so ein Konstrukt existert:

…Text</p><p>&nbsp;<br>

Das wird zu einem Paragraphen, einem Leerzeichen und einem forcierten
Zeilenumbruch:

----schipp----
Text

 \newline
----schipp----

Durch die Leerzeile fängt für LaTeX dann dort ein neuer Absatz an. Der
ist soweit leer. Das Leerzeichen am Anfang der Zeile ist kein
Inhalt. Also gibt es aus Sicht von LaTeX dann keinen Zeileninhalt,
sobald es das `\newline` trifft.

Finanzübersicht: »einmalige« Periodizität bei wiederkehrenden Rechnung gefixt

Die Finanzübersicht nutzt die Funktion
`SL::DB::PeriodicInvoicesConfig::calculate_invoice_dates`, um jedes
Ausführungsdatum innerhalb eines Zeitraumes zu berechnen. Dort wurde
»einmalig« fälschlicherweise wie »jeden Monat wiederholen«
behandelt. Dadurch tauchten die solche wiederkehrenden Rechnungen in
der Finanzübersicht in jedem Monat auf, sofern die Konfiguration noch
aktiv ist.

Beim eigentlichen Erzeugen der wiederkehrenden Rechnungen hingegen war
das deshalb kein Problem, weil so eine Konfiguration direkt nach dem
ersten Erzeugen der Rechnung auf inaktiv gesetzt wird.

bank_transactions Testfälle erweitert

für #356 und #355.

part-template typo with_empty

Kontoauszug verbuchen: Fehlermeldungen visuell (flash) besser hervorheben

Beim Analysieren von #355 aufgefallen. Falls Probleme beim
Verbuchen der Kontoauszüge auftreten, sollte auch die Flash-Anzeige
nicht grün sein.

SelfTest false positive vermeiden

Der #b4cc349b ist leider auch Schrott.
Im Array hab ich nur failed mit 0 oder 1 als zuverlässige Status-Meldung

Kreditorenbuchungen: Flag »cleared« beim Zahlungsbuchen beibehalten

Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.

Das Flag einer Zahlung wird nun beibehalten, sofern:

• die Zahlung bereits vorher existiert hat (Präsenz der
  `acc_trans_id`)
• Wert und Konto gleich geblieben sind

Debitorenbuchungen: Flag »cleared« beim Zahlungsbuchen beibehalten

Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.

Das Flag einer Zahlung wird nun beibehalten, sofern:

• die Zahlung bereits vorher existiert hat (Präsenz der
  `acc_trans_id`)
• Wert und Konto gleich geblieben sind

Einkaufsrechnungen: Flag »cleared« beim Zahlungsbuchen beibehalten

Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.

Das Flag einer Zahlung wird nun beibehalten, sofern:

• die Zahlung bereits vorher existiert hat (Präsenz der
  `acc_trans_id`)
• Wert und Konto gleich geblieben sind

Verkaufsrechnungen: Flag »cleared« beim Zahlungsbuchen beibehalten

Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.

Das Flag einer Zahlung wird nun beibehalten, sofern:

• die Zahlung bereits vorher existiert hat (Präsenz der
  `acc_trans_id`)
• Wert und Konto gleich geblieben sind

SelfTest false positive vermeiden

$self->all_passed enthält nicht mehr den Zustand, ob alle
Tests erfolgreich waren. Als Workaround auf zwei negativ
Status-Meldungen prüfen, die bei Problemen gesetzt sind.

Payment::pay_invoice with skonto -> Steuersatz ist eindeutig

tax_id in acc_trans definiert sicherer den Steuersatz als der
taxkey (Steuerschlüssel von DATEV), s.a. FK-Constraint:
"acc_trans_tax_id_fkey" FOREIGN KEY (tax_id) REFERENCES tax(id)

DATEV::CSV Typo in Datenstruktur

SelfTests: False Positive bei Buchungen auf ic_cogs als Sammelkonto vermeiden

CSV-Helfer: Leere Zeilen ignorieren.

Als leere Zeilen hier gelten auch Zeilen, die nur das Trennzeichen enthalten.

Mit leeren Zeilen gab es immer wieder Probleme, teils mit schwer zu
interpretierenden Fehlermeldungen, teils mit nicht gewünschtem Verhalten, z.B.
beim Warenimport das Anlegen neuer Artikel für jede leere Zeile.

Auftrags-Controller: Workflow Auftrag VK <-> EK

SL::DB::Order->new_from: Prüfung auf Quell- und Ziel-Typ refactored

Typo in Fehlermeldung

Auftrags-Controller: fake id für Items nach Workflow setzen.

Für items, die hinzugefügt werden, also noch nicht in der DB gespeichert sind,
muss eine fake id gesetzt werden, damit diese bei den actions, die einzelne
items betreffen, auch richtig gefunden/zugeordnet werden können.

Das behebt z.B. einen Fehler mit falschen Preisquellen nach dem Workflow
Angebot -> Auftrag, wo immer die Preisquellen der ersten Postion im Dialog
verwendet wurde.

Lieferplan um Filter nach Abteilungen ergänzt