Wechselkurs pro Angebot/Auftrag: DB-Upgrade-Skript + Rose

exchangerate direkt in Tabelle oe ablegen.

Die Implementierung, um bei Angeboten/Aufträgen den Wechselkurs pro Beleg
zu speichern folgt in weiteren commits und wird erstmal nur für den neuen
Auftrags-Controller umgesetzt.

Bezieht sich auch auf #135
Refs #135

Auftrags-Controller: Wechselkurs: Kosmetik / POD update

Auftrags-Controller: Währung in make_order setzen

Auftrags-Controller: Wechselkursfeld leer lassen, wenn Kurs nicht bekannt

Auftrags-Controller: Währung bei Kunden-/Lieferantenwechsel setzen

Auftrags-Controller: Feld für Wechselkurs CSS-Klasse numeric/reformat_number

Damit kann in dem Feld auch "gerechnet" werden.

S:D:Order: kein has_customervendor in kivitendo

Anpassung nach cherry-picks aus odyn

Warnung Währungs-/Kurswechsel: Text u. Übersetzung angepasst

Auftrags-Controller: js: Debug-Meldungen raus

Anpassung nach cherry-pick aus odyn

Auftragsschnellerfassung: Korrekturen für Währung/Wechselkurs

- Feld auf disabled setzen wenn nicht gebraucht
- _as_null_number damit undef nicht zu 0 wird
- Übersetzte Fehlermeldungen

ticket #9491

(cherry picked from commit c581e4685a217bdd5b73380b1f808037a473dd9f)
(cherry pick von odyn)

Auftragsschnellerfassung: Warnung wenn neuer Wechselkurs eingegeben

(cherry picked from commit 3825bc25c386674446879946bd73a16a2c3e3314)
(cherry pick von odyn)

Warnung Währungs-/Kurswechsel: englischen Text an Übersetzung angepasst

(cherry picked from commit a51ce740e43f2c70f8584a29ca1c3c3b2ecc7acf)
(cherry pick von odyn)

exchangerate bei Order erst nach transdate und currency_id setzen

(cherry picked from commit 7d76676faf4c3a4d71fc5df449365374a9997995)
(cherry pick von odyn)

Auftrags-Controller: DOM-Id des Datumsfeld richtig angeben

Es heißt _as_date in kivitendo.
Anpassung nach cherry-pick aus odyn

locales-Lauf en

Auftragsschnellerfassung: Währung und Wechselkurs definierbar

impl. #9491

(cherry picked from commit 6cdc5a4a33df4530ce4e141151e83138320e27a2)
(cherry pick von odyn)

Rose-Attr-Helfer: _as_null_number

von odyn abgeguckt, aber nicht mit SL::Helper::Number implementiert
(gibt es in kivitendo nicht)
siehe auch odyn: commit b4177a76db52e94795314b527774f515fd8ee42f

Debitorenbuchung: Wechselkurs bei Zahlung formatieren

Debitorenbuchung: unbekannten Wechselkurs (0) nicht anzeigen

Wechselkurs in VK-Rechnung nicht aus Zahlung setzen

Revert "BUG-Fix: Kreditorenbuchungen: Währung wird nicht übernommen."

This reverts commit dc89fd52864f1778e4aded439e0765b1422879ce.

Der commit tut nicht, was in der commit-Message steht (dafür gab es
schon einen anderen) und sorgt dafür, dass der Wechselkurs doppelt
formatiert wird und dadurch kaputt geht.

Wechselkurs mit 5 Nachkommastellen anzeigen

sieh auch
"Debitorenbuchungen - Wechselkurs mit 5 Nachkommastellen anzeigen"
(commit 4291cf9efdf89ef6ad98aa877c1a31bee63fffad)

Lagerbestand: Paginieren An- und Ausschalten

wh report: Kosmetik

Release 3.5.6

Doku-Update: Versionnummer 3.5.6

Datenbank-Upgrade-Skripte für Release 3.5.6-Abhängigkeiten

vim-Auslagerungsdatei entfernt

Typo in Upgrade-Doku

doc: Sicherheitshinweise in Bezug auf SQL-Injections und XSS

changelog: Bugfixes nachgetragen

changelog zu: Einfüge-Position eines neuen Artikels angeben können

Kosmetik: Einrückung im changelog

DATEV-Export: Test repariert, da nun kein Leistungsdatum bei Zahlungen

zu commit eab277a4114a1115310e05fa5bbe867877900d84
(DATEV-Export: Leistungsdatum nicht bei Zahlungen exportieren)

Kosmetik: keine Tabs

Zeile 'drop table temp_taxkey_conversions;' vor 'END IF;'

Doku: openSuSE angepasst

ISO3166 deutsche Überseztung ergänzt (Belgien)

UN 20 Recs: Quartal als gültige Einheit hinzugefügt

doc: Buildlauf

Diverse Typos in Doku

DATEV-Export: Leistungsdatum nicht bei Zahlungen exportieren

Bankbewegungen haben prinzipiell kein Leistungsdatum,
allerdings baut der Export die über die Gegenbuchung zusammen,
sodass dann ein deliverydate des Belegs an die Bankbewegungen
drangehangen wird. Das irritiert dann zu Recht beim DATEV-Import.

Merge pull request #28 from DerDakon/quote

quoten von Argumentlist in shellscript

quoten von Argumentlist in shellscript

Ansonsten werden Pfade mit Leerzeichen zu einzelnen Argumenten.

Dokumentationsanpassung und .htaccess um rewrite Regel ergänzt

.htaccess Beispiele für apache 2.2 entfernt | UTF-8 als default

Dokumentation: selber bauen von HTML::Restrict entfernt

Dokumentationslauf

Dokumentation: Neue Perl-Module für 3.5.6. Features (Postgres 12 + MwSt) ergänzt

Dokumentation: Empfehlung Debian >= 10 ab kivi 3.5.6

Zu bcc996e65643 Rechnungsadresse aus dem Stammdaten auch für alte oe

Bugfix #435 Einkaufsrechnung mit Leistungsdatum zieht falsche Steuer

Steuer für die acc_trans sollte anhand von deliverdate berechnet werden.
An der Oberfläche wird die Steuer richtig angezeigt, die DATEV-Prüfung
beschwert sich aber glücklicherweise

UPGRADE-Hinweise aktualisiert

Doku: ZUGFeRD Feature Vorbedingung und Erläuterung

bank_transactions.t - Test Jahr 2019 in 2020 benutzen

shop_order.t - typo: shop statt shor

SL::DB::ShopOrder - in convert_to_sales_order transdate übergeben

Um ein bestimmtes Datum zu forcieren, nützlich für Tests.

Außerdem Umstellung auf hartkodiertes Testjahr 2019 in 2020.

price_tax_calculator.t - in 2020 das Jahr 2019 nehmen

payment.t - in 2020 das Jahr 2019 nehmen

und außerdem bei payments Datum immer als DateTime-Objekt übergeben.

convert_invoice.t - in 2020 das Jahr 2019 nehmen

SL::DB::Invoice new_from - param transdate übergeben

Insbesondere bei Tests nützlich, um das Defaultverhalten zu
überschreiben.

year_end.t - Testjahr: in 2020 das Jahr 2019 nehmen

wegen Steuerumstellung

artransactions.t - Umstellung Konjunkturpaket

Tests, bei denen Salden abgefragt werden, auf 2019 umgestellt.

Payment Helper - Logikfehler bei Parameter transdate

Es war eine Klammer falsch gesetzt, daher wurden nie DateTime-Objekte
erkannt und man mußte das Datum immer als formatierten String übergeben.
Jetzt sollte es auch wieder mit DateTime-Objekten funktionieren.

Algorithm::CheckDigits: Fix für belgische UStID-Nummern

Das Schema in Belgien wurde irgendwann von sieben auf acht
Ziffern (zzgl. zwei Prüfziffern) umgestellt. Das originale Modul von
Algorithm::CheckDigits prüft fest auf sieben und ist damit für
aktuelle Nummern fehlerhaft.

Das Modul in overrides akzeptiert nun sieben- und achtstellige Ziffern
bei der Prüfung und erzeugt immer achtstellige
Nummern (bzw. zehnstelige mit Prüfziffern).

Testfälle: bank_transactions.t um Datum erweitert

Merge remote-tracking branch 'origin/f-leistungsdatum'

Auftrags-Controller: Sprache f. Überstzung im E-Mail-Dialog verwenden

CVars: render_cvar_input: Variablen vom Typ bool mit for_sumbit rendern

Damit tauchen dann auch nicht angehakte Variablen in der Form auf.
Das war z.B. im Auftrags-Controller ein Problem, da dieser sonst ein
"Häkchen entfernen" nicht gespeichert hat.

EK-Rechnungen: Web-Template: vergessenes <tr> eingefügt

Kam rein mit
commit 517ed14d9733e94411274bd2b9fb59cef9e632ff
("Lieferdatum in Einkaufsrechnung erfassen können").

SKR04: Steuer mit Schlüssel 15 und 17 (16%) bei SKR04 entfernen …

…, wenn unbenutzt.

Wenn nicht angepasst, dann sind diese Steuern mit reservierten Steuerkonten
verknüpft, die jetzt für die neue Steuer verwendet/umbenannt wurden.
Zudem gibt es keine Konten, die diese Steuerschlüssel für die Steuerautomatik
verwenden.

Nicht bebuchte Steuern vor Neuanlegen entfernen

SKR04 unbebuchten 16% Steuern und doppelte 19% Steuern entfernen

ZUGFeRD: Gesamtsteuer nach PTC-Strukturänderung richtig ermitteln

Chart cache_taxkeys - startdate korrekt abfragen

Ansonsten werden Buchungen am 1.7.2020 (= startdate) nicht richtig
zugeordnet.

DBUpgrade-Mechanismus: umgekehrte Abhängigkeiten mit »required_by« angeben können

Existierender Mechanismus mit »depends« sagt: die Scripte in »depends«
müssen ausgeführt werden, bevor ich selber ausgeführt werde.

Mit »required_by« kann man das Umgekehrte angeben: ich selber muss
ausgeführt werden, bevor die Scripte in »required_by« ausgeführt
werden können.

Damit kann man z.B. kundenspezifische SQL-Upgrades schreiben, die
erzwungen vor offiziellen SQL-Upgrades ausgeführt werden, ohne die
offiziellen Upgrade-Dateien dafür verändern zu müssen.

AR/IR/OE - Steuerbeschreibung an Oberfläche / Druck aus tax_id holen

siehe Kommentare in SL/IS.pm

Wenn ein Steuerautomatikkonto mehrmals bei den Steuern auftaucht kann
man die Steuerbeschreibung nicht mehr eindeutig anhand der Kontonummer
(hier als taxnumber verwendet) bestimmen, von daher wird jetzt immer
auch die tax_id mit ausgelesen.

Hier gibt es noch ganz viel Refactoringpotential...

Konjunkturpaket - SKR04 überarbeitet

* Debug OLD entfernt
* Gewährte und Erhaltene Skonti 16% Konten umbenannt
* Anlegen von Konto 8735 (c&p aus SKR03) rausgenommen
* Kommentare raus

Konjunkturpaket - SKR03 - kein 5 und 7 mehr anlegen

Im Gegensatz zu der Standardinstallation von SKR04 gibt es bei SKR03
keine konfigurierten Steuerschlüssel 5 und 7 (für die alten 16%-Fälle),
stattdessen gibt es noch Einträge für 16% die über die Steuerschlüssel 3
und 9 abgebildet werden und sogar noch auf die korrekten Konten zeigen.

Da das Anlegen von 5 und 7 derzeit noch zu Komplikationen führt, und
diese durch das Lieferdatum/Leistungsdatum nicht zwingend notwendig
sind, wird daher vorerst darauf verzichtet.

Außerdem werden noch ein paar fehlende Konten und taxkeys angelegt.

Konjunkturprogramm - t/tax/tax.t mit Skontozahlung testen

Konjunkturpaket - SKR03 neues Konto Skonti 5%

year_end.t - Testjahr hartkodiert

da ansonsten in 2020 durch die Umsatzsteuerumstellung die Kontensalden
des Tests nicht stimmen.

kivi nur mit corona-schutz rumlaufen lassen

Steuerschlüssel in Dropdowns anzeigen

bei Dialog-, Debitoren- und Kreditorenbuchungen.

Damit man z.B. durch die Mehrwertsteuerumstellung des Konjunkturpakets
die Vorsteuer 16% des alten Steuerschlüssels 7 von dem des aktuellen
Steuerschlüssels 9 unterscheiden kann.

Konten bearbeiten - Steuerschlüssel nach Datum sortieren

Es gab keine Sortierreihenfolge.

Konjunkturpaket 2020 Anpassung der Mehrwertsteuersätze und Test

Ab dem 01.07.2020 sollen 16% und 5% gelten.
Ab dem 01.01.2021 sollen wieder 19% und 7% gelten.

CSV-Import Debitorenbuchungen: Lieferdatum bei Steuerermittlung berücksichtigen

CSV-Import Debitorenbuchungen: Feld für Kontonummer heißt accno, nicht chart

S:D:Order: deliverydate Methode für PTC

PTC: Steuer nach Lieferdatum oder Rechnungsdatum

sollte nur für Rechnungen/Gutschriften gelten, nicht für Aufträge.

S:DATEV:CSV: Lieferdatum als Leistungsdatum exportieren

Tests: DATEV-CSV-Export: Lieferdatum/Leistungsdatum

Lieferdatum in Dialogbuchung - Steuer anhand von Datum

Lieferdatum in Dialogbuchung: Speichern und Laden in Belegmaske

Lieferdatum in Dialogbuchung: DB-Upgrade + Rose

Lieferdatum in Debitoren-und Kreditorenbuchung

Lieferdatum in Einkaufsrechnung erfassen können

Das DB-Feld gab es schon, wurde aber nicht befüllt.

PTC: Rückgabehash taxes in taxes_by_chart_id umbenannt

Damit ist klarer, was zu erwarten ist

ZUGFeRD: Steuerwerte pro Steuer, nicht pro Steuerkonto ausweisen

Auftrags-Controller: Steuerwerte pro Steuer, nicht pro Steuerkonto ausweisen