Moritz Bunkus [Thu, 19 Mar 2020 12:15:59 +0000 (13:15 +0100)]
Skontovorschläge: ungültige Steuer-Zeilen aus acc_trans ignorieren
Buchungen in acc_trans, die das Steuer-Konto ansprechen (also eines,
bei dem chart_link AR_tax oder AP_tax enthält), haben oftmals eine
ungültige Kombination aus taxkey & tax_id (ungültig im Sinne von:
diese Kombination gibt's in der Tabelle tax nicht).
Für Skontoberechnung sind solche Zeilen aber irrelevant. Also sie
einfach überspringen und nicht sterben.
Moritz Bunkus [Mon, 3 Aug 2020 11:56:02 +0000 (13:56 +0200)]
ZUGFeRD: auch bei massengedruckten Rechnungen ZUGFeRD-Infos erzeugen
Funktioniert aber nur, wenn nur eine einzige Mail ausgewählt
ist. Andernfalls existieren halt mehrere Anhänge mit demselben Namen,
was nicht funktionieren kann.
Moritz Bunkus [Mon, 3 Aug 2020 11:34:03 +0000 (13:34 +0200)]
ZUGFeRD: Namen der eingebetteten Datei richtig setzen
'ucfilespec' wird erst ab PDF 1.7 unterstützt, was wir nicht
erzeugen. Daher wurde bisher der Name der temporären Datei auch im PDF
als Dateiname verwendet.
Jetzt wird korrekt »ZUGFeRD-invoice.xml« als Name des Anhangs im PDF
angezeigt.
G. Richardson [Thu, 23 Jul 2020 13:42:10 +0000 (15:42 +0200)]
Deb-/Kred-/Dialogbuchungen - get_active_taxes_for_chart mit tax_id
Durch die Konfiguration bei den Steuern, für welche Konten welche
Steuerfälle in den Dropdowns bei Debitoren-, Kreditoren- und
Dialogbuchungen auftauchen, kann es passieren, daß für bereits gebuchte
Belege beim erneuten Öffnen die Steuer nicht mehr zur Verfügung steht
und dadurch falsch angezeigt wird. Indem man die aktuelle tax_id an
get_active_taxes_for_chart mit übergibt kann man sicherstellen, daß die
ausgewählte Steuer immer im Dropdown auftaucht.
Da der Code für die Erstellung der jeweiligen Dropdowns so umständlich
ist, und mehrmals wiederholt wird, war es einfacher, dies als neuen
Parameter in get_active_taxes_for_chart zu implementieren.
G. Richardson [Thu, 23 Jul 2020 13:36:10 +0000 (15:36 +0200)]
GL get_active_taxes_for_chart - tax_id param
Damit kann man bei bereits gebuchten acc_trans-Einträgen den aktuellen
tax_id Wert übergeben, so daß der Eintrag bei Dropdowns immer erscheint,
also auch dann, wenn er durch Umkonfiguration ansonsten aus dem Dropdown
herausgefiltert werden würde (z.B. wenn sich chart_categories in tax
ändert).
G. Richardson [Mon, 27 Jul 2020 16:39:54 +0000 (18:39 +0200)]
DATEV Export Lieferdatum - für Dialogbuchungzahlungen wieder erlauben
In Commit eab277a411 wurde das Lieferdatum für Buchungen auf
"Zahlungs"konten deaktiviert. Für Einkaufs- und Verkaufsrechnungen ist
das auch korrekt, hier soll nur die Hauptbuchung im DATEV-Export mit
Lieferdatum exportiert werden, die Zahlungen sind vom Lieferdatum
unabhängig. (Zumindest solange nicht automatisch Steuer bei
Skontobuchungen berücksichtigt wird).
Bei Dialogbuchungen soll hingegen schon das Lieferdatum erscheinen, auch
wenn eins der Buchungskonten z.B. Bank ist. Ob das Lieferdatum bei der
entsprechenden Dialogbuchung sinnvoll ist muß natürlich der Bucher
entscheiden.
Hierfür wurde auch einer der DATEV-Tests überarbeitet.
Bernd Bleßmann [Wed, 17 Jun 2020 09:40:03 +0000 (11:40 +0200)]
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.
Bernd Bleßmann [Fri, 5 Jun 2020 12:26:35 +0000 (14:26 +0200)]
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
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.
Jan Büren [Thu, 9 Jul 2020 11:30:56 +0000 (13:30 +0200)]
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.
Jan Büren [Wed, 8 Jul 2020 11:48:37 +0000 (13:48 +0200)]
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
G. Richardson [Tue, 7 Jul 2020 15:45:16 +0000 (17:45 +0200)]
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.
Moritz Bunkus [Tue, 7 Jul 2020 10:59:34 +0000 (12:59 +0200)]
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).
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.
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.
Moritz Bunkus [Tue, 30 Jun 2020 11:52:59 +0000 (13:52 +0200)]
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.
G. Richardson [Tue, 30 Jun 2020 09:35:38 +0000 (11:35 +0200)]
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...
G. Richardson [Tue, 30 Jun 2020 07:04:23 +0000 (09:04 +0200)]
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.
G. Richardson [Fri, 26 Jun 2020 08:37:23 +0000 (10:37 +0200)]
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.