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.
Bernd Bleßmann [Wed, 24 Jun 2020 14:45:55 +0000 (16:45 +0200)]
PTC: Steuern auch nach Steuer-Id zurückgeben
Bisher kann der PTC die berechntete Steuer pro Steuerkonto zurückgeben.
Allerdings kann kivi so konfiguriert sein, dass verschiedene Steuern
auf ein Konto gebucht werden. Diese lassen sich dann durch die Rückgabe
des PTC nicht unterscheiden.
Jetzt werden die Steuern zusätzlich auch pro Steuereintrag (also per tax.id)
zurückgegeben.
Jan Büren [Sat, 13 Jun 2020 07:08:28 +0000 (09:08 +0200)]
Bugfix #430 Steuer speichen wirft SQL-Fehler
Das Refactoring 543d78225ec609 hat die Bind-Variablen außer Acht gelassen.
Bernd hat den Teil beim Speichern mit b30eacc6bbc6f gefixt.
Jetzt auch bei Neuerfassung. Ferner Rückmeldung an den Nutzer per Flash
projects / kivitendo-erp.git / log