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

Fix: #354 Zahlungsbedingung falsch bei Workflow Lieferschein -> Rechnung

Bisher wurde nur nach dem ersten Treffen der richtigen Auftragsnummer gesucht.
Dabei konnten Zahlungsbedingungen vom Einkaufs-Auftrag nach Verkaufs-Rechnung übernommen werden.
Entsprechend zusätzlichen Filter nach vc_id eingebaut.

Auftrags-Controller: Kunde/Lieferant vorbelegen, wenn deren id übergeben wird

Für die Workflow-Links aus den Kunden-/Lieferantenstammdaten heraus werden
die customer_id oder vendor_id berücksichtigt und die Kunden-/Lieferanten-
abhängigen Attribute im Order-Objekt entprechend gesetzt.

Workflow aus Kundenstammdaten zum neuen Auftrags-Controller, …

… wenn experimentelle Features eingeschaltet sind

calculate_qty (Formel): auf Dialog umgestellt

Auftrags-Controller: Formelberechnung

Sollte evtl. auf Dialog umgestellt werden.

calculate_qty (Formel): Input- und Formel-Feld auch als Dom-Id übergeben können

calculate_qty (Formel): alu (?) und andere unbenutzte Parameter entfernt

Auftrags-Controller: Kunden-/Lieferantendetails ("D")

Hier sollte die alte Makse auch umgestellt werden, erstens auf Dialog und
zweitens damit via Rose zugegriffen wird.

SuSa - vergessene Hidden für department_id

t/ar/ar.t aufgeräumt und Refactoring

Typo in Beschreibung von chart_pos_er.sql

Refactoring payment.t

reset_state in init_state umbenannt und params entfernt. Die Daten werden nur
einmal aufbereitet.

Überall title an Anfang der Funktion verschoben, bzw. neu angelegt.

ALWAYS_RESET entfernt. Es werden nun während des Tests nie Rechnungen gelöscht.
Immer alle Daten der Einzeltests zu löschen und alles neu zu initialisieren
würde den Test auch recht langsam, und war eh nicht sauber implementiert.

t/db_helper/payment.t - Testcode verschoben

die eigentlichen Tests stehen jetzt vor den Testfunktionen und
Helperfunktionen, nicht ganz am Ende.

Payment Helper - Parameter in POD korrigiert

Payment Helper - besser Fehlermeldung in pay_invoice

Dev create_sales_invoice - type ist invoice

CVars: in Artikelstammdaten sind alle CVars gültig

Der Code zum Rendern der CVars zeigt nur »Element deaktiviert«, wenn
die CVar als ungültig geflaggt ist. Das kann auch in den Stammdaten
passieren, nämlich dann, wenn man eine CVar in der Konfiguration als
»Deaktiviert als Voreinstellung« ausgewählt hat.

Der Effekt ist, dass man die CVar in den Stammdaten nicht mehr
bearbeiten kann.

EK-Rechnung Stornos verbieten solange Zahlungen nicht ausgeglichen sind

S.a. #325 (https://redmine.kivitendo-premium.de/issues/325)

Stornos bei EK-Rechnungen verbieten, solange SEPA-Exports verknüpft sind

Order-Controller: Angebotsgültigkeitsintervall beachten

Wie beim alten Angeboten auch, soll die Gültigkeit des Angebots
aus der Mandatenkonfiguration gesetzt werden, falls hier ein Wert vorhanden ist.

doc: Liste der Debian-Pakete ergänzt

Somit gibt es wieder zwei einfach zu pastende Installationslisten.
Einmal Datenbank, Webserver und Perl und des weiteren die Druckvorlagenpakete.
Die Pakete poppler-utils, aqbanking-cli und postgresql-contrib sind somit hinzugefügt.

Auch Verwendungszweck beim Import per CSV zusammenfügen

Beim MT940 Import wird purposeX und remote_name_X in einer
Zeichenkette zusammengefügt. Beim CSV-Import ist dies nicht
möglich, da an der Oberfläche das entsprechende Drop-Down-Element
diese Zuordnung (Spalte -> Import-Objekt) nicht zulässt.

SQL release Upgrade Skripte für 3.5.2