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

Merge pull request #22 from robert-scheck/wollen-moechten

s/Wollen/Möchten/g - less strong and likely a bit more polite

Merge pull request #20 from robert-scheck/fa-leonberg

Reflect changed data of tax office Leonberg (since 2018)

Font-Familie nur im <body>-Tag setzen, und auf Browser-Standard-Schrift belassen

sans-serif ist ein Meta-Name, der im Browser von den Anwendern selber
eingestellt werden kann.

Merge pull request #19 from robert-scheck/capital-sharp-s

Support German capital sharp s

Merge pull request #21 from robert-scheck/typo

Corrected typos, added missing tags and updated Fedora information

Merge pull request #18 from robert-scheck/vatno

Use consistently shortening "USt-IdNr." according to German BZSt

Merge pull request #17 from robert-scheck/apache24

Update .htaccess for Apache 2.4 to avoid mod_access_compat dependency

Auftrags-Controller: bei als neu speichern auch ein neues Objekt erzeugen

Behebt #351 (redmine).

Order: new_from: auch gleiche Quell- und Ziel-Typen berücksichtigen

s/Wollen/Möchten/g - less strong and likely a bit more polite

Corrected typos, added missing tags and updated Fedora information

Reflect changed data of tax office Leonberg (since 2018)

See also:
 - http://www.fa-leonberg.de/pb/,Lde/Startseite
 - http://www.fa-leonberg.de/pb/,Lde/Startseite/Ihr+Finanzamt/Bankverbindungen

Support German capital sharp s

See also:
 - https://de.wikipedia.org/wiki/Gro%C3%9Fes_%C3%9F
 - https://en.wikipedia.org/wiki/Capital_%E1%BA%9E

Use consistently shortening "USt-IdNr." according to German BZSt

http://www.bzst.de/DE/Steuern_International/USt_Identifikationsnummer/FAQ/FAQ_Vergabe_USt_IdNr/Vergabe_FAQ_node.html

Update .htaccess for Apache 2.4 to avoid mod_access_compat dependency

See also: https://httpd.apache.org/docs/2.4/upgrading.html

vergessener Presenter::EmailJournal

Der Betreff der E-Mail soll anklickbar sein und direkt zum
Detaileintrag des Mail-Journals führen.
Überwiegend übernommen von Presenter::Letter

Changelog: Neue Verknüpfung E-Mail-Journal <-> Beleg

Verknüpfte Belege um die Verknüpfung 'E-Mail Journal' erweitert.

Falls das E-Mail-Journal aktiviert ist wird zusätzlich zu der
archivierten E-Mail auch die Verknüpfung vom Beleg zu der E-Mail mitgespeichert
und ist im Beleg zusätzlich direkt anwählbar.
Etwas mehr Details im POD vom Mailer.pm, die Implementierung orientiert
sich überwiegend an der Erweiterung der Verknüpfung von Letter.pm, bzw. dem ShopConnector.

DATEV/CSV check_encoding, sollte wirklich das encoding checken

Entsprechend vier Testfälle für die Routine gesetzt und
 Hintergründe in #348 dokumentiert.

Auftrags-Controller: Anzeige mit Infos über den Kunden-/Lieferantentyp

Auftrags-Controller: Belegnummer in Titlezeile anzeigen

SL::DB::Order: keinen Fehler werfen, wenn Typ noch nicht zu ermitteln.

Das ist der Fall, wenn noch kein Lieferant oder Kunde gesetzt ist.

Inventur: Journal nach Artikel filtern können: Doppeltes "tr" korrigiert

Inventur: Journal nach Artikel filtern können

SelfTests/Transactions.pm erweitert

Da beim Löschen von Zahlungen mittlerweile auch kaskadieren die
reconciliation_links gelöscht werden, können verwaiste abgeglichen
Bankbewegungen entstehen.
Entsprechend Testfall ergänzt.

Validator: time - striktere Prüfung und tests

Typo in Übersetzungen

Auftrags-Controller: Workflow Angebot->Auftrag nur, wenn gespeichert

Typos in POD

Validator: time