Release 3.5.6.1

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

Doku-Update: Versionnummer 3.5.6.1

changelog-Update

S:USTVA: benötigte Module einbinden

Order->new from poso/sopo keine quonumber übernehmen

Im Lieferantenauftrag macht es keinen Sinn, dass die
Verkaufs-Angebotsnummer als Anfragenummer übernommen wird.

LaTeX-Druckvorlagen f-tex entfernt, doku und installation_check

installation_check -l prüft jetzt auf pdfx und die Version
Entsprechenden Hinweis in der Doku.
f-tex entfernt, die letzten Änderungen wurden von Geoff und Jan
in 2014 gemacht, der ursprüngliche Maintainer scheint seitdem inaktiv zu sein.

S:C:CustomerVendorTurnover: Beträge rechtsbündig

S:C:CustomerVendorTurnover: Sortierung der Belege absteigend nach Datum

S:C:CustomerVendorTurnover: unnütze Zeile weg

DBUtils: Query loggen: Dateinamen des Aufrufers richtig ermitteln

Kosmetik / Ausrichtung

E-Mail Betreff auch mit Kundenbestellnummer vorbelegen.

Auftrags-Controller: Beleg neu Laden nach Mail

Damit sind auch die verknüpften Belege, in denen die Mail verlinkt ist,
aktualisiert.

Auftrags-Controller: Beleg-Id für Mailer setzen, damit verknüpft wird

Das sit nur nötig, wenn vor dem Mailen nicht gespeichert wurde. Das
wurde zwar gerade erzwungen, aber falls es wieder rausgenommen wird,
funktioniert die Verknüpfung auch.

locales-Lauf

Order-Controller E-Mail nur nach Speichern möglich

Hotfix um einen wirklich gesicherte $::form zu haben

Konjunkturpaket - Upgradereihenfolge korrigieren

Auftrags-Controller: Speichern und E-Mail-Dialog über vorhandene Funktion

Die js-Funktion email() tut praktisch das gleiche wie save(). Dann kann
auch diese benutzt werden.
Damit auch klar ist, dass vor dem Aufruf des E-Mail-Dialogs gespeichert
wird, ist die action im Controller umbenannt worden.

Auftrags-Controller: Vor dem Aufruf des E-Mail-Dialogs speichern

Das geschieht zwar auch beim Verschicken der Mail wenn man den Dialog bestätigt,
aber beim Speichern wird die Belegnummer generiert, die sonst bei
ungespeicherten Belegen im Dialog selbst (für den Betreff) nicht zur Verfügung
steht.

Typo in Nachfrage-Text

locales-Lauf

USTVA: Toter Code: auch totes Template entfernen

zu commit f59c9111f911e0c4d418d9b126483970cef4df5a
("USTVA: Toter Code (ca. 2012 abwärts)")

USTVA: Fall IST-Versteuerung aggregat an der richtigen Stellen

und nicht im Subselect für die Abfrage bezahlter Beleg oder nicht.

Bemerkungen/Wiedervorlage bei Kunden/Lieferanten: richtiges Attribut für "für"

die Rose-Beziehung für das DB-Feld "created_for_user" heißt
"created_for_employee".
Vorher wurde der Name bei "Wiedervorlage für" in der Liste der Notizen nicht
angezeigt.

USTVA: kivi special fields auch für 7%

S:D:OrderItem: nicht benutzte Module nicht inkludieren

Merge branch 'master' of github.com:kivitendo/kivitendo-erp

cusordnumber in email auch für neuen controller

DB-Upgrade-Skript: in vorhandenen Ek-Rechnung Zahlungsbedingungen aus Lieferant

Aktuell können die Zahlungsbedingungen in EK-Rechnungen angegeben werden.
Früher war das nicht so. Aber bei SEPA-Überweisungen wurden die
Zahlungsbedingunen des Lieferanten für den Skontovorschlag verwendet.
Damit bei alten EK-Rechnungen der Skontovorschlag weiterhin angezeigt wird,
werden die Zahlungsbedingunen des Belegs auf die des Lieferanten gesetzt.

SEPA-Überweisungen: Zahlungsbedingungen f. Skonto aus EK-Rechnungen übernehmen …

… und nicht aus den Lieferanten-Stammdaten.

Hier könnte es im VK und EK noch eine Art fallback auf die Zahlungsbedingungen
aus den Kunden-/Lieferanten-Stammdaten geben - so dass diese zusätzlich als
Auswahl angeboten werden, sofern sie nicht in der Rechnung angegeben sind.
Refs #444 (redmine)

sepa: Kosmetik: Kommentar neu formatiert.

Zahlungsbedingungen auch in Ek-Rechnung angeben können

Diese werden im Bericht EK-Rechnungen schon aus den DB-Daten der Rechnung
angezeigt und nicht aus den Lieferanten-Stammdaten. Die Zahlungsbedingungen
können ja durchaus mal von denen abweichen, die in den Lieferanten-Stammdaten
hinterlegt sind.

Zudem ist es dann gleich dem Verhalten im Verkauf.

Behebt #35 (redmine)
Refs #36 (redmine)

typo spellcheck comment

USTVA nur noch für SKR03/SKR04 Hotfix für 19% Buchungen im 16% Zeitraum

Falls kivi doch 19% Buchungen erzeugt ist die Logik
über taxkeys zum Zeitpunkt ungünstig, da die USTVA
die Wahrheit in der acc_trans so nicht erfassen kann

USTVA temp MwSt Konten anzeigen

USTVA kivi Infofelder für temporäre Mehrwertsteuer

USTVA: Toter Code (ca. 2012 abwärts)

- Typo
- Kommentare
S.a. doc/CHANGELOG:
Die Druckvorlagen für USTVA vor 2012 wurden entfernt und das Ausdrucken von
  USTVA als PDF ist deprecated. Da die Eingabe von Erklärungen als PDF nicht
  mehr gestattet ist, sollten Archivkopien der USTVA direkt bei Elster bezogen
  werden, oder auf anderem Wege erstellt werden. Der Prozess dazu wird sich in
  einer kommenden Version ändern

USTVA: Konjunkturpaket erwarte Pos. 35 und Pos. 36 für Voranmeldung

Ferner unlogische Automatiken in SKR03 bereinigt (Steuerkonten haben
keine Automatikfunktion auf sich selber).

USTVA Weiteren toten Code identifizieren - Werte mit Key undef ignorieren

Die summen Abfrage erzeugt auch Werte ohne pos_ustva (category)
Diese brauchen nicht weiter verarbeitet zu werden.

toter code

20.10.2009 sschoeling: this sub seems to be orphaned.
-> yes.

Auftrags-Controller: Workflow VK->EK: Lieferadresse für direkte Lieferung

Falls beim Workflow Kundenauftrag->Lieferantenauftrag eine Lieferadresse
ausgewählt oder eine indiv. Lieferadresse eingetragen ist, wir gefragt,
ob diese Lieferadresse als (indiv.) Lieferadresse in den Lieferantenauftrag
übernommen werden soll.

Auftrags-Controller: Lieferadresse: Auswahlliste richtig zusammenbauen

Das behebt einen Fehler, wenn der Kunde nur eine Lieferadresse hat und der
Auftrag geladen wird. Dann wurde keine Lieferadresse angeboten.

Ist nur eine Lieferadresse vorhanden, so wird diese nicht als (erstes)
Array-Element geliefert wird, sondern als Hash.
Anders, wenn mehrere Lieferadressen vorhanden sind - dann wird ein Array
geliefert.
Die import-Methode hätte also einmal als 'shiptos.import([shipto])' und
einmal als 'shiptos.import(shipto)' aufgerufen werden müssen.
Um das zu vermeiden, werden die Adressen jetzt in einer Schleife mit 'push'
hinzugefügt.

Der Fehler kam mit commit "Auftrags-Controller: individuelle Lieferadresse"
(199bd497fa158b819070767fa737b2e23d164b96) rein.

Auftrags-Controller: "Speichern und ..." nicht ausgrauen, wenn nicht gespeichert…

…, da vorher ohnehin gespeichert wird.

locales-Lauf 'de' und vergessene Übersetzung f. Fehler beim Projektanlegen

locales-Lauf 'en'

Kunden-/Lieferantenstamm: Anzeige WebDAV-Reiter

Kunden-/Lieferantenstamm: Kosmetik/Einrückung im Web-Template

Kunden-/Lieferantenstamm: Reiter Dateianhänge ohne Einschränkung anzeigen …

… Hier wurde auf das Recht geprüft, ob man Ek-/Vk-Belege aller Mitarbeiter
einsehen darf.

Hier wurde offenbar aus Versehen in die vorhandene IF-Anweisung reinkopiert.

Changelog Auslagern mit Seriennummer

Feature: Auslagern über Rechnung inkl. Seriennummer Lagermenge berücksichtigen

Dateispeicher "webdav" fehler bei vorhergehe ...

nden commit behoben vendornumber anstatt vendor

Dateispeicher "Webdav" auch für Kunden und Lieferanten

Feature: Auslagern über Rechnung inkl. Seriennummer == Chargennummer

Prüft, ob die kommaseparierte Liste in serialnumber mit
der Stückzahl in der Position übereinstimmt
Prüft, ob die Seriennummer als Chargennummer vorhanden sind.
Bei Erfolg werden diese Chargen dann ausgelagert.

Auslagern über VK-Rechnung, Erweiterung um Abgleich Seriennummer == Charge

Option in Mandantenkonfiguration->Lager

aqbanking 6.x benötigt weitere Unterordner

Durch die verkettung der Systemaufrufe kann der
MT940 Import aktuell erst beim zweiten Aufruf ausgeführt werden (ubuntu 20.04)
Das Anlegen der Unterordner umgeht diese Eigenschaft

S/GL: Typo im POD (t/011pod.t)

S/GL: Typo im POD (t/006spellcheck.t)

Auftrags-Controller: individuelle Lieferadresse

Behebt #365 (redmine)

S/D/Order: before_save-hooks f. indiv. Lieferadressen, um …

- keine leeren zu speichern
- das Modul immer auf 'OE' zu setzen

S/D/Shipto: Methode is_empty, um auf leere Lieferadresse zu prüfen

Form::prepare_for_printing: Lieferadresse nicht mehr hier laden. …

Das passiert jetzt in FlattenToForm

FlattenToForm: individuelle Lieferadresse und CVars berücksichtigen.

CVars: Einträge beim Löschen dazugehöriger Lieferadressen automatisch löschen

Lieferscheine: Benutzerdef. Variablen in Lieferadressen gefixt

Individuelle Lieferadresse hinzufügen: falsche Reihenfolge der Werte korrigiert

kam mit "Individuelle Lieferadresse hinzufügen: cp_gender nicht vergessen"
(commit bca91008eddc6a1734a75fcd555f10d1c8ac65f6),
bzw. "Individuelle Lieferadresse hinzufügen: cp_gender nicht auf leer prüfen …"
(commit b8fa93b5d2cfff453fd8a82206d1a288407a8be6) rein.

Bezieht sich auch auf #410 (redmine)
Refs #410
Behebt #438 (redmine).

div_tag aus L in Presenter verschoben

Kosmetik/Typo

Mandanteneinstellung: Projekt zum Auftrag erzeugen auch für Order-Controller

Vorgangsbezeichnung erzwingen auch im Order-Controller

Kosmetik Zeilenumbruch

Version auf unstable gesetzt

Liefermengenberechnung: Default auf verlinkte Position (seit 2016 möglich)

SL::Mailer: Aufrufer kann optional beliebige Header mitgeben

pod ergänzung GL.pm

Kreditoren- Debitorenbuchung: Lieferdatum für die Steuer berücksichtigen

Logik-Kosmetik: Die Variablen werden lokal für der Schleife benötigt

Aufruf von weiteren Funktionen nach der initialiserung erschwert
die Lesbarkeit

Form: Backend-Funktion get_taxcharts entfernt

Toter Code, die ALL_TAXCHARTS werden nicht mehr verwendet
Aufruf auch in ar.pl entfernt

ap.pl ALL_TAXCHARTS toten Code entfernt

Wird seit 6e594d280b nicht mehr verwendet

htaccess: Regel auf Verzeichnisse mit Namen .git oder config beschränken

Die bisherige Regel verbietet schlicht den Zugriff auf beliebige
Dateien und Verzeichnisse, die ».git« oder »config« irgendwo im Namen
haben — z.B. »js/edit_periodic_invoices_configs.js« oder die
»config.js« vom CKEditor. Damit gehen dann Dinge wie das Bearbeiten
der Konfiguration wiederkehrender Rechnungen nicht mehr.

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.

E-Mail-Versand: vorbelegter Text für Rechnungen mit aktiviertem Bankeinzug

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.

ZUGFeRD: auch wiederkehrende Rechnungen mit ZUGFeRD-Infos erzeugen

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.

Kosmetik: Einrückung

File: Kein deep clone von Strukturen machen die SL::DB::* Objekte enthalten

Das führt zu Duplizierungen von Singletons, in diesem Fall der
Datenbankverbindung die dann beim abbauen kaputtgehen.

(cherry picked from commit 9a86234c1a5624573a3f2738cf25b526527796c8)

Behebt #358 (redmine).

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.

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).

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.

changelog: Währung/Wechselkurs im Auftrags-Controller

Auftrags-Controller: Wechselkurs in Preisquellen-Dialog berücksichtigen

Bezieht sich auch auf #139
Refs #139

Wechselkurs pro Angebot/Auftrag: In Angebots-/Auftragsbericht berücksichtigen

Auftrags-Controller: Wechselkurs: Preis beim Hinzufügen eines Artikels umrechnen

Auftrags-Controller: Wechselkurs pro Beleg …

- Wechselkurs wird pro Beleg gespeichert
- Wechselkurs ist immer änderbar
- vorausgefüllt aus "alter" Tages-Wechselkurstabelle

Bezieht sich auch auf #135
Refs #135

Wechselkurs pro Angebot/Auftrag: legacy-Methode exchangerate umbenannt

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