SelfTest Transaction zum commit von gerade: weniger false positives

Bei Buchungen, bei denen nicht ein RecordLink existiert (GL),
gelöscht, ist es nicht mehr möglich sauber auf verwaiste Einträge zu
testen. Entsprechend min(itime) from bank_transaction_acc_trans als
Schwellenwert für Startpunkt der Prüfung von bank_transactions.transdate
genommen

BankTransaction: want a whole lotta test

neuer Test full_workflow in bank_transactions
1.
Verbucht drei Verkaufsrechnungen nacheinander, davon
eine mit Zahlungsbedingung Skonto nach ZB. Zusätzlich
zu den Nebenbücher werden acc_trans Einträge kontrolliert,
sowie der gesetzte RecordLink.
2.
Da die Bankbewegung komplett aufgeht, wird diese abgeglichen
und die Zustände danach kontrolliert.
3.
Leider war die Verbuchung komplett Murks, weswegen die
Ursprungszustand vor 1. wiederhergestellt (neues Funktion
Kontoauszug-Verbuchung rückgängig machen)

Bonus-Level:
Damit andere Anwendungen / Schnittstellen, DB-Admins nicht
auf die Idee kommen an der Hilfstabelle bank_transaction_acc_trans
zu schrauben, entsprechend einen weiteren SelfTest geschrieben

Reconciliation: Veto, kein invoice_amount nachträglich setzen.

Im Fehlerfall die Summe der Bank gegenüber der Buchungen
an Benutzer (testfall) übergeben.

unlink_bank_transaction optionaler parameter für testfall

BankTransaction Die richtigen (erwarteten) Parameter von amount an pay_invoice

Stellt den vorherigen Zustand im Controller wieder her, der über
Fallunterschiede vom Invoice-Typ Vorzeichen verschoben hat.
Tests laufen damit erstmal durch. Ferner kann und muss es mehr
als 2 acc_trans_ids als Rückgabe von pay_invoice geben

Payment pay_invoice alle acc_trans_ids sammeln

Hintergrund. new_acc_trans wird mehrfach für verschiedene
Fälle verwendet, entsprechend nach jeder Änderung einsammeln

BankTransactionAccTrans für ALL.pm

Manuelle Zahlungen verbieten, falls mit Kontoauszug verknüpft.

Falls die Änderbarkeit von Zahlungen nicht auf niemals steht,
entsprechend Überbuchen / manuelles Ändern verbieten.
Der Fehlertext weißt zusätzlich auf die Funktion im Bankbewegungs-Bericht hin

locales und changelog für BankTransaction-Änderungen

BankTransaction: Neue Funktion um Bankverbuchungen wieder rückgängig zu machen

action_unlink_bank_transaction inkl. POD
Der Bericht Bankbewegungen erhält im Presenter Anhakboxen (ähnlich wie bei SEPA)

Vergessener template-Schnipsel zu 41a1b801 (Lieferschein-E-Mail)

BankTransaction: weniger im Controller rechnen -> ausgelagert in Objekt

s.a. Commit davor. Redundanzen hier direkt vorbeugen.

Dialogbuchungen aus Bankbewegungen teilweise Verbuchungen erlauben

Da vorher nur komplette Bankbewegungen verbucht werden konnten,
war es nicht sinnvoll Teilbeträge im Dialog zu buchen.
Das Verfahren ist jetzt geändert und übergeben wird der aktuelle
Rest-Betrag der Bankbewegung

BankTransaction new method not_assigned_amount

returns the current open amount of this bank transaction.
Added to POD

BankTransaction: save_single_bank_transaction API-Änderung

S.a. POD und devel-Liste
Testfälle angepasst

save_single_bank_transaction: acc_trans_ids von pay_invoice speichern

Payment-Helper pay_invoice um Rückgabewert der acc_trans_ids erweitert

Kosmetik/Perl-Detail Optionen als Hash anstatt array

GL mit Bankbewegungen verbuchen. Helfertabelle und striktere Aktionen

Neue acc_trans_id können wir bei diesem Typ von gl-Einträgen nicht
gebrauchen. Alle Anwendermöglichkeiten von der Oberflächen verbieten

Neue Helper-Tabelle SL/DB/BankTransactionAccTrans.pm

Hintergrund: Verbuchte Bankbewegungen sind nur über
einen löschbaren RecordLink aktuell zuordenbar.
Das macht ein verlässliche Aussage über die Verbuchungen
der Bankbewegung schwierig. Besser wäre es eine
Tabelle reconciliation_links direkt bei der Verbuchung zu füllen
und die gesetzten Constraints so zu lassen (ER-Fehler mit
aussagekräftigerer Fehlerwarnung an den Nutzer) ....
Da die Bankverbuchungen seit 66d468b09 (2016) in einer
Transaktion laufen, wird über record_link und itime eine
Rekonstruktion der Zusammenhänge für die alten Einträge versucht herzustellen.

Wichtig: Dieser Commit ist Vorbedingung für das Neuverbuchen
von importierten Bankbewegungen. Zusätzlich beißt sich das mit
der Anforderung das Zahlungen manuell vom Anwender geändert werden
können (s.a. hierzu c923fff436).

Falls Kontoauszüge importiert und gebucht werden, sollte (!) manuelles Ändern deaktiviert sein

Vorbereitend zum Feature, auch verknüpfte Kontoauszüge wieder
rückgängig zu machen.

SL::DB::Invoice(closed) POD korrigiert s.a. #368

Ggf. die Routine ganz entfernen oder zumindestens für
Gutschriften wie in 368 beschrieben patchen

Trigger zum Löschen von RecordLinks auch für verknüpfte Briefe und Dialogbuchugen

SL::DB::BankTransactions(linked_invoices): Returns an array of record objects

Anstatt nur die Namen der Belege werden jetzt die Beleg-Objekte
zurückgegeben. Einziger Aufruf der Methode beim ReportGenerator in
Controller::BankTransactions. Die Stelle entsprechend angepasst

PTC: Sortierung von items beachten bei Rechnungen die nachträglich geändert wurden

(cherry picked from commit eacfe1d260a6f9d4c12aa508b2c4d4cc018508c8)

Order: Auftrag mit Items und Ware laden

Die werden überall gebraucht, also gleich mitladen

(cherry picked from commit cb546c6e64e4b3315dcd8b826261939a89baa543)

Order: second row javascript direkt indizieren …

… auch für Positionen, die noch nicht in der DB gespeichert sind.

Order: second row javascript direkt indizieren.

Beschleunigt das Nachladen der zweiten Zeile bei großen Aufträgen (100+
Zeilen), weil der client weit weniger DOM selectors auswerten muss.

(cherry picked from commit 87ca139b2162813d71dec8e4e8ecef21588c818d)

Preisregeln: Präzedenzbug bei Mengenregel behoben

Durch eine fehlende Klammerung konnten Mengenregeln zufällig nicht
greifen.

(cherry picked from commit f1cf2062a7df1877e931f5655afe899e0dacb649)

CreatePDF-Helper: UNLINK für temporäre Dateien (wieder) richtig setzen

Berechtigung, Einkaufsrechnungen persönlich zugeordneter Projekte einzusehen

Betrifft sowohl Einkaufsrechnungen als auch Kreditorenbuchungen.

Berechtigung, Verkaufsrechnungen persönlich zugeordneter Projekte einzusehen

Man kann nun Mitarbeiter*innen zu Projekten zuordnen, indem man sie in
den Projektstammdaten hinzufügt.

Ist eine Mitarbeiter*in zu einem Projekt zugeordnet, so darf sie alle
Rechnungen ansehen, die über die Projektnummer der Rechnung (nicht der
Positionen) dem Projekt zugeordnet sind, auch dann, wenn sie nicht das
allgemeine Recht zum Erstellen und Ansehen von Rechnungen hat.

Verändern oder Ausdrucken der Rechnungen ist nicht gestattet.

Die Verwaltung dieser Projektberechtigungen ist über ein neues
Gruppenrecht eingeschränkt.

Betrifft Verkaufsrechnungen, Verkaufsgutschriften und Debitorenbuchungen.

Autovervollständigung Kunden/Lieferanten auch ohne Stammdatenrechte

Ergebnis von SL::DB::Manager::Employee->current cachen

Order-Controller: Workflow -> *-Auftrag vorher Speichern

Ansonsten werden die cvars nicht übernommen.
Außerdem ist es konsistenter, da bei allen anderen
Workflow-Aktionen auch immer gespeichert wird (Rechnung oder LS).

Zu 47da14db generische LS-Mail: locales und Anhak-Option in Suche

generische E-Mail-Adresse für Lieferscheine

Ähnlich wie bei Verkaufsrechnungen gibt es generische
Empfänger für Lieferscheine beim E-Mail-Versand.
Die jetzige Konfiguration (nicht änderbar) entspricht
dem Wert Stammdaten und Ansprechpartner in CC.
Ist eine Stammdaten-Mail und ein Ansprechpartner definiert,
bzw. ausgewählt wird der Ansprechpartner in CC gesetzt und
die vorbelegte Anrede ist 'generisch'

poso mehr werte löschen (wandlung kundenauftrag -> lieferantenauftrag)

Währung und Steuerzone wird ansonsten vom vorherigen Beleg
übernommen. Betrifft nur die alte Maske

DMS-Dateianhänge beim E-Mail-Versand Vorauswahl konfigurierbar

Rechnungsversand E-Mail-Body

Falls die generische E-Mail-Adresse verwendet wird, sollte auch
die generische Anrede hinterlegt sein, selbst wenn ein Ansprechpartner
noch in CC gesetzt wird.

manueller Rechnungsversand per E-Mail. Vorbelegung mandantenweit konfigurierbar

Changelog und Doku aktualisiert

Verkauf->Rechnungsbericht Filter nach nicht per E-Mail verschickten Belegen

SL::RP: unbenutzte Subroutine entfernt.

DisplayableNamePrefs: Überstzungen

DisplayableNamePrefs: changelog-Eintrag

DisplayableNamePrefs: Benutzereinstellungen

DisplayableNamePrefs: Mandantenkonfiguration

DisplayableNamePrefs: DB-Upgrade-Skript um defaults zu setzen

DisplayableNamePrefs: SL::DB:xxx verwenden DB-Helper

erstmal nur Customer/Vendor/Part

DisplayableNamePrefs: DB-Helper als Mixin

DisplayableNamePrefs: UserPreferences-Helper f. DisplayableName

Ansprechpartner um boolean Hauptansprechpartner erweitert

Entsprechend mit einigen Attributen für den Export von Kundenstammdaten
hinzugefügt.
Hintergrund: Ansprechpartner-Export gibt nur die Liste aller Ansprechpartner.
Das Feld Kontakt (in der Tabelle Kunde) war wahrscheinlich der Vorgänger
für die Ansprechpartner-Logik. Das ist etwas wenig, wenn man noch
E-Mail, Telefon usw. personenbezogen unterbringen will. Deshalb die
Ergänzung für diesen Bericht.

Kontoauszugsimport 2 Konten bei einer Bank. Bankgebührenbuchung wird als schon importiert makiert
Fix für #367

Zahlungsverkehr->Zahlungs-(ein/aus)gang. Bezahlen/Abgleichen mehrerer Rechnungen
Fix für #366

Stammdaten-Kunden: Neues Feld Amtsgericht. Weitere Export-Möglichkeiten

Ust-ID, Kreditlimit, Amtsgericht (benötigt bspw. für Factoring)

Aktualisierte Installationsanleitung Debian/Ubuntu

Drei Pakete sind komplett untergegangen

Aufruf von with_objects in RequirementSpecPart korrigiert

bei SL::DB::Object ist der Parameter "with", nicht "with_objects" (wie
bei SL::DB::Manager::Object)

Das hatte allerdings keine kritischen Auswirkungen, der Parameter wurde
ignoriert und die Daten wurden dann erst später geladen.

Typo in Übersetzung

BackgroundJob SelfTest: unbenutzte Variable entfernt

Typos und spellcheck: unkown -> unknown

Changelog zu den Commits von heute

Ergänzung zu a3b8cfa7b7546 (Mahnungen konfigurierbar machen)

- bessere Fehlerbehandlung -> send_mail läuft schon in einer Transaktion
  Von daher mit die hart aussteigen
- Die Signatur des E-Mail-Versenders sollte dann auch zur E-Mail-Adresse
  passen, entsprechend backup vars erstellt vor dem Aufruf von Form::create_signature

Verkaufsaufträge: konfigurierbares Intervall für Lieferdatum-Berechnung

Zahlungserinnerung an Rechnungsadresse schicken - Weiche für Absender

Mail-Absender aus defaults.dunning_creator ableiten.
Falls die Rechnungsadresse E-Mail gesetzt ist, diese als Empfänger nehmen ansonsten die
globale E-Mail des Kunden (abwärtskompatibel).

Erweiterung um Fehlerbehandlung mit Hinweis an der Oberfläche, falls keine Sender oder
 Empfänger-Adresse gefunden wird

fixt: #345 Mahnungsersteller im Ausdruck konfigurierbar machen

Im Menüpunkt Mahnungen konfigurieren, kann man nun wählen, ob
der aktuelle Mitarbeiter für die Mahnung/Zahlungserinnerung gesetzt ist
oder der ursprüngliche Mitarbeiter/Ersteller der Rechnung

Rechnungsversand per E-Mail

Falls bei dem Kunden eine E-Mail-Adresse für den
Rechnungsversand hinterlegt ist, so hat diese Priorität
vor der allgemeinem Rechnungsadresse.
Als visuelle Hilfe, wird aus dem Titel 'Empfänger' der
Titel 'Rechnung an:'.

Logik normale Rechnung:
1.) Die Adresse des Ansprechpartners hat Priorität vor allen anderen Adressen (bleibt)
2.) Falls kein Ansprechpartner -> Prüfen auf Rechnungsadresse (neu)
3.) Falls immer noch keine E-Mail -> Prüfen auf generische Mail des Kunden (bleibt)

Logik wiederkehrende Rechnung:

Falls eine Rechnungsadresse gesetzt ist, wird diese schreibgeschützt angezeigt.
Weitere Adressen können wie bisher auch über die Auswahl des Ansprechpartners oder
per freier Eingabe zusätzlich definiert werden

Rechnungsadresse aus den Stammdaten (template file vergessen)

Rechnungsadresse aus den Stammdaten bei periodischen Rechnungen verwenden (Anzeige beim Editieren)

Stammdaten -> Kunden um Textfelder Rechnungsmail und Herkunft personenbezogener Daten erweitert

i)
Die Rechnungsmail ist die generische E-Mail des Kunden, welche die
Rechnung in der Regel bearbeitet (buchhaltung@, einkauf@).
ii)
Aufgrund der DSGVO ist es im Zweifel sinnvoll den Erstkontakt
des Kunden zu dokumentieren (Messe xyz, Telefon-Aktion beta, ...)
Die beiden Felder sind als Suchfeld anhakbar.

SelfTests: check_ap_paid berücksichtigt Auswahl von fromdate und todate

Release 3.5.3

dokumentation.xml Versionsnummer hochgesetzt

LaTeX-Druckvorlagen RB Logo getauscht und Skalierung angepasst

Datenbank-Abhängigkeits-Skripte für release 3.5.3

Abhängigkeit für release 3_5_2 zu 3_5_1 nachgezogen

doc aktualisiert

- changelog um Bugfixes erweitert
- Installationsanleitung um Hinweise für Postgresql je nach Distribution ergänzt

DATEV: Tests: danach wieder aufräumen

PTC: Fehlerhafte ungerundete Berechnung von grossamount

Bei Rechnungen mit sehr vielen sehr kleinen Positionen wurde die
Rundungsfehlerakkumulation _nur_ in den finalen netamounts
berücksichtigt, nicht aber in den daraus berechneten grossamounts was zu
Cent-Abweichungen geführt hat.

(cherry picked from commit 061180a3a9cd5ddffc5d9b40fc1751653fc8ef09)

t/db_helper/convert_invoice.t: Zahlen nach Rundungs-Patch f. PTC angepasst.

Neue Zahlen mit (zahlengleichen) Beispielen an der Oberfläche ermittelt.

Korrektur PriceTaxCalculator: Falsches Objekt zum Prüfen genommen

mit Sven durchdiskutiert

(cherry picked from commit d4102550a27e2bee22d4faed2626fc1434d9e721)

PTC-Tests: ein weiterer Test mit großen Mengen und kleinen Preisen

PTC-Tests angepasst nach PTC-Rundungs-Patch …

"PTC rundet nicht mehr Rabatt vor Mengenmultiplikation"

PTC: item->discount auf 0, wenn nicht definiert, um Warnungen zu vermeiden

PTC: Rückgabe sellprice für items: Steuer und Rabatt berücksichtigen.

So war das vor dem PTC-Rundungs-Patch …
"PTC rundet nicht mehr Rabatt vor Mengenmultiplikation"

PTC: Kosmetik/Kommentare

PTC rundet nicht mehr Rabatt vor Mengenmultiplikation

siehe Ticket #82

Neuer Test für 100000 Artikel zu 0,10€ bei 3% Rabatt
Einen weiteren Test angepasst an die neuen Zahlen.

PTC: nicht einfach die Rundungsgenauigkeiten erhöhen …

… das verschiebt das Problem auf jeden Fall nur.
Siehe auch Ticket #82.

Diser commit macht den Teil
"Ferner Rundungsgenauigkeiten für wiederkehrende Rechnungen erhöht." aus
commit 075f64d61e999506517a304022525d83c29e6e3e rückgängig.

Es folgen weitere Commits zu diesem Problem.

Fixt #350 Fehler p.income_accno_id does not exist

Die mehrmals in RP.pm vorkommenden Zeilen
'JOIN chart c on (p.income_accno_id = c.id)'
und
'JOIN chart c on (p.expense_accno_id = c.id)'
erzeugten einen Fehler, da es in der Tabelle parts
keine solchen Spalten gibt, sondern in taxzone_charts
Deshalb jeweils die Zeile
'JOIN taxzone_charts t ON (p.buchungsgruppen_id = t.id)'
vorher eingefügt und jeweils p.income bzw. p.expense durch
t.income bzw. t.expense ersetzt.
Der Fehler trat auf bei 'Berichte -> Projektbuchungen'
sowie bei der GUV und BWA mit ausgewähltem Projekt.

Aktualisierung Doku

Testfälle für DATEV angepasst

Der Standardwert ist: "Ersetze mit ähnlichen Zeichen".
Die Testfälle basieren aber noch auf: "Werfe Fehler wenn Zeichen nicht in cp1252".

Fixt #352 Beim Drucken mehrerer Rechnung aus dem Bericht heraus wird der Rabatt falsch berechnet

Hotfix für die zweifache Berechnung vom Rabatt (Marge bei Berichten falsch) erstellt.
Hintergrund: Der alte Code erwartet keine vorformatierten Werte, wird aber bei
periodischen Jobs noch zwingend aufgerufen (sellprice mit fxsellprice in MassPrintCreatePDF überlagert)
Ferner Rundungsgenauigkeiten für wiederkehrende Rechnungen erhöht.

changelog für DatevExport kommt mit bestimmten Zeichen im Buchungstext nicht klar

Fixt #348 DatevExport kommt mit bestimmten Zeichen im Buchungstext nicht klar

In der Mandantenkonfiguration befindet sich jetzt eine Einstellung,
welche die Kodierung des DATEV-Exports steuert. DATEV erwartet CP1252.
kivitendo kann diese Kodierung so vom kivitendo Nutzer einfordern, alternativ nicht
vorhandenen Zeichen versuchen zu ersetzen oder die DATEV-Erwartung ignorieren
und UTF-8 liefern. Voreingestellt ist CP1252 mit Ersetzungen

toten Code entfernt

Lagerberichte: html: verrutschtes <tr> und <p> um <table>s weg.

Doku: Modullisten allgemein und Paketlisten für openSUSE, Fedora aktualisiert

LC_CTYPE-Locale auf eine UTF-8-Locale setzen

Beim Starten des Perl-Interpreters wird die Locale anhand von
Umgebungsvariablen wie `LC_CTYPE`, `LC_ALL` und `LANG`
gesetzt. Unter (F)CGI sind diese normalerweise leer, wodurch als
Locale die POSIX-Locale (`C`) gewählt wird — und die hat nur ASCII als
Zeichensatz.

Die iconv-Funktion scheint nun nicht transliterieren zu können, wenn
ASCII als Zeichensatz ausgewählt ist. Sie macht dann z.B. aus `ć` ein
`?` anstelle von `c`.

Beim Start der Programme wird nun `LC_CTYPE` auf eine sinnvoller
Locale gesetzt. Dies ist `de_DE.UTF-8` oder `en_US.UTF-8`, falls
erstere nicht verfügbar ist. Die Sprache ist hierbei irrelevant, da
nur `LC_CTYPE` gesetzt wird und und nicht z.B. auch `LC_MESSAGES` oder
`LC_TIME`.

Dies ist Voraussetzung dafür, das #348 gefixt werden kann.

Weitere Fallback-Module entfernt und Doku angepasst (s.a. #344)

Part-Controller: Normalisieren nach Parsen der Form und nicht als run_before

Das Problem enstand durch commit 2e97532c88dacf9523576df4028b6f7df5967ea8
"Fixt #349 (Normalisierung Artikel) - normalize_text_blocks nach Part-Controller
migriert"

normalize_text_blocks greift auf $self->part zu, welches beim Neuanlegen
noch nicht existiert, wenn normalize_text_blocks als aller erstes durch
run_before aufgerufen wird. Danach wurde init_part aufgerufen, welches
aber bei einem neue Artikel den part_type braucht, um part zu erzeugen.
Das ist aber nicht nötig, da das part in den action_add_xxx-Methoden
später erzeugt wird.
Ausserdem muss normalize_text_blocks z.B. auch nicht bei den Picker-Actions
aufgerufen werden.

Also normalize_text_blocks nur nach dem Parsen der Form aufrufen.

Fixt #361