Constraints für tax und taxkeys

Dieser Commit fügt für die Tabellen tax und taxkeys folgende
Constraints hinzu:

Tabelle tax:

1.chart_id hat jetzt einen Fremdschlüssel auf chart.id.
2.rate darf nicht mehr NULL sein und hat DEFAULT-Wert 0.
3.taxkey darf nicht mehr NULL sein.
4.taxdescription darf nicht mehr NULL sein.

Tabelle taxkeys:

1.chart_id darf nicht mehr NULL sein, hat jetzt einen Fremdschlüssel
  auf chart.id.
2.tax_id darf nicht mehr NULL sein.
3.taxkey_id darf nicht mehr NULL sein.
4.startdate darf nicht mehr NULL sein.
5.chart_id und startdate müssen eindeutig sein.

SEPA-Überweisung: Rechnungen mit NICHT gesetztem "Lastschrifteinzug" vorauswählen

Die Logik ist im Einkauf genau umgekehrt zum
Verkauf. "Lastschrifteinzug" bedeutet im Verkauf, dass wir einziehen,
also dass wir die Rechnung via SEPA anweisen müssen.

Im Einkauf bedeutet es, dass der Lieferant direkt von uns einzieht und
wir deshalb nichts manuell machen müssen.

Übersetzung Titel in Kreditorenbuchungsmaske gefixt

Fehlende Übersetzung

Loginbildschirm: Unter Versionsnummer auch aktuelle Git-Revisionsnummer anzeigen

Conflicts:
locale/de/all

dokumentation von
  c_vendor_id
  v_customer_id

L: hidden_tag(): Parameterübergabe gefixt

kivitendo-CSS: Farbe inaktiver Tabwidgetschrift: schwarz, nicht grün

Nur direkte Tabwidget-DIV initial verstecken, nicht alle Kindeskinder-DIVs

ActsAsList: mit remove_from_list() entfernte Items auf position = -1 setzen

position ist in allen Tabellen NOT NULL deklariert. Nur in der einen,
die ich zum Testen genutzt hatte, nicht. Das habe ich nun
nachgeholt. Jetzt wird -1 als magischer "not in list"-Wert benutzt.

ActsAsList: neu: remove_from_list(), add_to_list(), Unit-Tests

ActsAsList: Möglichkeit, Positionsgruppen nach anderen Spalten anzugeben

Selftest Prüfung für Bilanzkonten in GuV-Gruppe

Ein Konto sollte nicht gleichzeitig in beiden Berichten auftauchen.

SEPA-Überweisung: Rechnungen mit gesetztem "Lastschrifteinzug" vorauswählen

Debitorenbuchungen: "Lastschrifteinzug" auch nach Buchen aus Stammdaten vorbelegen

Kreditorenbuchungen: Checkbox für "Lastschrifteinzug"; Vorbelegung aus Stammdaten

Einkaufsrechnungen: Checkbox für "Lastschrifteinzug"; Vorbelegung aus Stammdaten

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

Vergessene Lieferscheindruckvariablen (bom Stückliste) in TEMPLATE_ARRAYS ausgelagert

Hinterngrund: commit 02475b7f88ed372dd8d17cc2ed22c1dac251340b.
              (Lieferscheindruckvariablen in den speziellen "TEMPLATE_ARRAYS" namespache ausgelagert)

Stücklisten-Druck von Erzeugnissen wird entsprechend selten angehakt und wurde deshalb bei
der Erweiterung für TEMPLATE_ARRAYS übersehen.
Ferner hab ich den Ausdruck der Stückliste auch genauso wie bei der Rechnung formatiert, da es sich
hier um "denselben" Code handelt.
Optimalerweise sollte man den Stücklisten-Code auch noch für alle Druckvorlagen in ein- und.
diesselbe Funktion auslagen (DRY), dann wird das beim nächsten Mal nicht vergessen und die.
Formatierung ist in allen Verkaufsvorlagen einheitlich.

RB Druckvorlagen: Proformarechnung eingeführt

Kopie von Auftrag mit Proformarechnung statt Auftragsbestätigung
und invdate statt orddate

$::request: Funktionen "is_ajax()" und "type()"

Refactoring: DHTML-Tab-Dialog durch Variante aus jQuery-UI ersetzt

charset in Upgrade-Script

In diesem SQL-Update hat noch die Angabe charset gefehlt.

tax_id ist nicht zwingend 0

Bei Dialogbuchungen war bisher die tax_id für keine Steuern hartcodiert
0. Das muss allerdings nicht so sein und führt zu Problemen, wenn
der Steuerschlüssel 0 unter einer anderen id gespeichert wurde.

Bessere Formatierung

Verbessert die Formatierung von Commit 5c5e92bc37819dd9df952068b9e58b47dd0b0de2
(Großschreibung von SQL-Befehlen, Zeilenumbrüche bei langen Sub-Queries)

HTML Enteties entfernen

Durch Commit 9c39cd67ed6cfb811df8bb20e93a68e0b56a881c sind einige
HTML Enteties reingekommen, die durch diesen Commit entfernt werden.

Sonderbehandlung im template

Dieser Commit ist eine Verbesserung zu Commit
9eb59a91db1758fd98d0eff8b081e442ddae5cb3

Im template gab es noch für das Startdatum eines Steuerschlüssels
eine Sonderbehandlung, die prüft, ob ein Konto bereits existiert
oder nicht.

tax_id in acc_trans

Dieser Commit enthält das Update-Script um eine neue Spalte Namens
'tax_id' in die Tabelle 'acc_trans' einzufügen. Diese Spalte hat
Constrait NOT NULL und einen Fremdschlüssel auf die id von tax.

Das Pflichtfeld wird jetzt immer geschrieben bei:

-VK-Rechnungen (auch automatisch erzeugten)
-EK-Rechnungen
-Kreditorenbuchungen
-Debitorenbuchungen
-Dialogbuchungen

Durch das Feld 'tax_id' können in der Tabelle tax der
Steuerschlüssel und der Steuersatz ausgelesen werden.

In diesem Commit wird allerdings der Wert in tax_id nur geschrieben,
im Moment wird er noch nirgendwo ausgelesen.

Update-Script für fehlende Steuerschlüssel

Bisher gab es noch sehr viele Konten, für die kein Eintrag in der
Tabelle taxkeys und damit kein Steuerschlüssel vorhanden war.
Dieses Update erstellt für jedes Konto ohne Steuerschlüssel einen
in der taxkeys, s.d. solche Konten den Steuerschlüssel 0 haben.

Hierfür ist unbedingt erforderlich, dass der Steuerschlüssel 0
existiert (also in tax vorhanden ist) und dieser Eintrag den
Steuersatz 0% hat. Existiert der Steuerschlüssel 0 nicht, so
wird er angelegt. Existiert ein Steuerschlüssel 0 mit mehr als 0%
Steuern, so wird das Update mit Fehlermeldung abgebrochen.

Siehe hierzu auch die Tickets #2028, #2029.

Fehlende Steuerschlüssel

Bisher wurde beim Anlegen eines neuen Kontos nicht unbedingt auch
ein Steuerschlüssel gespeichert. Jetzt kommt eine Fehlermeldung,
wenn man keinen Steuerschlüssel angibt, bzw. versucht alle Steuer-
schlüssel aus einem bestehenden Konto zu löschen.

Siehe auch Bug #2128, #2129 und #2115.

Speichern von Waren nach Fremdschlüsseleinführung gefixt

Refactoring: list_objects() aus Controllern in ReportGenerator-Helfer verschieben

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

Refactoring render-Parameter: Reste zu 7647d46

Sortindicator für SellPriceInformation

transdate Sortierung bei OrderItem war nicht eindeutig

warnings

warnings

warnings

warnings

Typo korrigiert, Install prüft jetzt korrekt auf Test::Output

Locales.pl: bei Templatefiles auch nach .json und .js suchen

Testcase für SL::Controller::Base::render() gefixt

Kundenstammdatenmaske: Checkbox "Steuer im Preis inbegriffen vorauswählen" verschoben

Refactoring: Parameterredesign SL::Controller::Base::render und SL::Presenter::render

Conflicts:
SL/Controller/FinancialControllingReport.pm
SL/Controller/ProjectType.pm

Test::Exception und Test::Output für Testsuite voraussetzen

Conflicts:
doc/kivitendo-Dokumentation.pdf

DebugMenu entfernt, weil es momentan nicht mehr funktioniert

Invoice-Model: Verknüpfung zu Stornorechnungen "storno_invoices"

Rechnungen, die $self storniert haben -- sprich User war in $self und
hat dort auf "Storno" gedrückt.

Record-Presenter: robustere Typenprüfung

Presenter: Dokumentationsbeispiel berichtigt

Projektstammdaten: Liste verknüpfter Dokumente anzeigen

Conflicts:
SL/Controller/Project.pm

Presenter-Module für Listen von Verkaufs-/Einkaufsobjekte

SL::Presenter -- die neue Präsentationsschicht

Dokumentation: Variablennamen für periodisch erzeugte Rechnungen dokumentiert

Conflicts:
doc/kivitendo-Dokumentation.pdf

scripts/dbupgrade2_tool.pl: UTF-8-encodierte Upgradescripte richtig behandeln

locales.pl: mehrere t8() in einer Zeile richtig behandeln

Funktion get_first_conflicting() im Model-Basisklasse

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

Stringifizierbare Klassen laden, bevor YAML::Load() aufgerufen wird

Hintergrund. Normalerweise dumpt YAML Klassen sinnvoll, sprich mit
Typus, Paketnamen und Innereien. Für eine Instanz von
SL::Locale::String könnte das z.B. so aussehen:

--- !!perl/hash:SL::Locale::String
untranslated: Invoice

Lädt mal das wieder, so entsteht daraus auch ein Objekt. Allerdings
ist es zwingend erforderlich, dass Perl die Klassendefinition zum
Zeitpunkt von YAML::Load() bereits gesehen hat. Ansonsten geht die
Stringifizierung verloren, weil sie zum Zeitpunkt des "bless()"ens
nicht bekannt war.

Das passierte mit normalen CGI, weil der Controller selber erst nach
dem Auslesen der Session via "require..." geladen wird, der Controller
lädt Rose-DB-Model, das lädt SL::Locale::String.

JavaScript-Syntax-Fehler bei Kreditlimit-Warnung

ActsAsList: Neue Funktion "reorder_list"

Conflicts:
SL/Controller/ProjectType.pm

Wenn Proxies übergeben werden, müssen die vor dem Downgrade stringifiziert werden.

Debitoren-/Kreditoren-/Dialogbuchungen: Fremdschlüsselspalte "department_id" nicht mit "0" schreiben

Conflicts:
SL/AP.pm

Sorted-Controller-Helfer: Standardsortierrichtung nutzen, wenn nicht anders übergeben

Projektverwaltung auf Rose- und Controller-Code umgestellt

Projekt: neue Spalten (Kunde, Typ, gültig)

DateTime-Helfer: 'goto' heißt das Keyword, nicht 'gofrom'

mosu vs "search & replace" -- 0:1

DateTime-Helfer: Funktionsnamen in (to|from)_kivitendo umbenannt

Mit Legacy-Aliasen.

DateTime-Formatierung: Jahreszahlen immer vierstellig ausgeben

Machen die anderen Datumsformatfunktionen von kivitendo ebenso.

Rose: Fremdschlüsselbenennung fixen

Die von Rose erzeugten Fremdschlüsselaccessoren heißen wie die
Spaltennamen, also z.B. in Perl 'trans' zu Spalte 'trans_id'. Das ist
unintuitiv und muss an vielen Stellen (z.B. bei den manager_args,
with_objects etc.) auch als 'trans' angegeben werden.

Also im Generatorscript gewisse Namen auf sinnvollere Namen mappen.

Schreibfehler im englischen String

Rose-Order-Manager: Sortier-Spezifikation und Paginating

Umwandlung Angebot/Auftrag -> Lieferschein/Rechnung: nur nicht gelieferte/berechnete Mengen vorgeben

Funktion 'is_sales' in SL::DB::{Invoice,PurchaseInvoice}

Gleiche Funktionen für ähnliche Objekttypen

Boolesche Funktionen ("is_...") auch boolesche Werte zurückgeben lassen

Ansonsten sind Vergleiche nervig:

$a->is_ales == $b->is_sales

LinkedRecords-Helfer: Parameter 'via' bei 'linked_records' für beliebige Pfade von -> zu

z.B. um zu einem Angebot alle Rechnungen zu erhalten, egal, ob
zwischendurch Aufträge und Lieferscheine stehen

LinkedRecords-Helfer: Dokumentationsupdate

LinkedRecords-Helfer: Funktionsname privat gemacht

Rose: 'with_args' nach Foreign-Key-Einführung gefixt

Die Beziehung heißt nun 'parts' und nicht mehr 'part'. 'part' ist nur
ein Alias.

Doppelter foreign key auf oe wieder entfernt

Rose-Beziehungstypen in Order gefixt

Siehe #2139.

Rose-Beziehungstypen gefixt

Behebt #2139.

Fremdschlüssel für Tabellen oe, delivery_orders, parts, translation

Kundentypnummernkreis nur berücksichtigen, falls dafür Nummernkreis gesetzt ist

Gilt analog für Lieferanten.

Siehe #2138.

CSV-Import Lieferadressen: Funktion gefixt

Shipto hat keine custom variables. Die Base-Klasse hat sich aber
darauf verlassen, indem es 'all_cvar_configs' aufruft. Der Test mit
'$self->can("all_cvar_configs")' ist hier sinnfrei, weil
Rose::Object::MethodMaker nun mal genau diese Methoden anlegt.

CSV-Import-Script: Dokumentation zum Doublettencheck erweitert

CSV-Import-Script: Mit Leerzeichen im Dateinamen klarkommen

Vor Fremdschlüsselzuweisung trans_id verwaiste Einträge in orderitems löschen

Nach Löschen in customer/vendor via DB-Trigger in contacts, shipto aufräumen

Nach Löschen in ar/ap/gl via DB-Trigger in acc_trans aufräumen

SL::DB::Buchungsgruppen: Verknüpfungen und Hilfsmethoden

Diverse Fremdschlüssel für Tabellen ar und ap

POD-Dokumentation

InvoiceItem, OrderItem, DeliveryOrderItem: diverse Fremdschlüssel eingeführt

Option in [debug], keine 'nologin' zu schreiben

CSV-Import Ansprechpersonen: Feld "Funktion/Position" (cp_position)

SL::DB::Order: falsche one-to-many zu PeriodicInvoice entfernt

Experimentelles Hilfe-Overlay wieder deaktiviert

Spalte 'cp_function' in 'cp_position' umbenennen zwecks Kompatibilität mit CRM

Ansprechpersonen: Feld "Funktion/Position"