Finanzbuchhaltung: abweichend gesetzte Steuer respektieren

Das Standardsteuerkonto wird inzwischen bereits vom Chart-Picker
belegt. Wenn also die Benutzer*in sowohl Buchungskonto als auch die
Steuer ändert, so sollte das Programm die Steuer nicht erneut setzen.

ActionBar: Rechnungsworkflow → Kundenauftrag: richtige Action angeben

Die entsprechende Sub in io.pl heißt »order« und nicht »sales_order«.
Behebt #245.

installation_check: bei check_pdfinfo Leerzeichen aus Version entfernen.

Das sorgt für eine ausgerichtete Ausgabe.

installation_check: doppelte sub "check_pdfinfo" entfernt

ActionBar: oe.pl: Actions für Wechsel Einkauf ↔ Verkauf gefixt

Rechnungsentwürfe beim Laden Tagesdatum setzen

Wie in vorherigen Entwürfen auch, wird das Datum beim Laden
des Entwurfs tagesaktuell gesetzt.

toten code auch entfernen

Fehlermeldungen beim automatischen Auslagern bei Verkaufsrechnungen anzeigen

Das eval/with_transaction Konstrukt in dieser Form liefert eine nicht
aussagekräftige Meldung, dass die Transaktion nicht geklappt hat, obwohl
einfach ein Fehler in IS->transfer_out von Anwender-Seite konfigurativ
verbessert werden kann. Etwas unschön ist jetzt, dass zwei Fehlerdialoge
erscheinen, ggf. kann das noch anders optimiert werden.

PDFs werden nicht mehr bei wiederkehrenden Rechnung per E-Mail erzeugt/angehangen

fix redmine #238

ActionBar: Korrekte actions für purchase_order und request_for_quotation

neue Version 3.5.0-alpha

Upgrade: Whitespace-Cleanup

Upgrade: neue Version

Revert "changelog und UPGRADE zu den GIN Indizes"

This reverts commit 5cd0c395b734c66c5c4c50dae6f3bcfa037a23df.

Bis das Problem mit Upgrades, die Admin-Rechte brauchen richtig gelöst ist,
werden die Commits für Trigram-Indizes erstmal reverted.

Conflicts:
doc/UPGRADE
doc/changelog

Revert "Experimentell: Trigram Indizes auf Spalten die mit ILIKE durchsucht werden."

This reverts commit f40363c5162d350c51c79d157fc16bdf5571399f.

Bis das Problem mit Upgrades, die Admin-Rechte brauchen richtig gelöst ist,
werden die Commits für Trigram-Indizes erstmal reverted.

Revert "trigram Indizes mit may_fail versehen und UPGRADE entsprechend angepasst"

This reverts commit be71a8600fc889060bed19fa5ef24938ab99b14b.

Durch das may_fail bricht das Upgrade bei nicht vorhandener trigram-Extension
zwar nicht mehr ab, aber das Upgrade wird dennoch als installiert geführt,
was zu unterschiedlichen (Grund-)Datenbasis bei ansonsten gleichen Versionsstand
führt.
Bis das Problem mit Upgrades, die Admin-Rechte brauchen richtig gelöst ist,
werden die Commits für Trigram-Indizes erstmal reverted.

mailmap update

SL::InstanceConfiguration - get_feature_experimental dokumentiert

Feature Sortiment als experimentell markiert

Pflichtenhefte: Kosmetik (Anordnung)

Pflichtenhefte: bei Kundenänderung auch Kunden in Versionen ändern

find-use.pl - Fehlergebnisse per Regex rausfiltern

find-use: Rose::DB::Object::Constants hartcodiert

InstallationCheck - HTML::Entities hinzugefügt

InstallationCheck - URI::Escape aufgenommen

Release 3.5.0-alpha - changelog angepasst

Release 3.5.0-alpha - Dokumentation angepasst

Auftrags-Controller: Hinweis auf Abschaltbarkeit im Changelog

Auftrags-Controller: als experimentelles Feature abschaltbar.

Mandantenkonfiguration: Schalter für experimentelle Features

- neue Spalte in defaults (Upgrade-Skript und Rose-Update)
- Schalter in der Mandantenkonfiguration
- Übersetzungen

Locales-Lauf

Doku: Belegvorlagenumstellung erwähnt

Neuer Kontenplan fuer die Schweiz, speziell für Vereine

CVAR DBHelper: Dokumentation zu Bugs

Vorlagensatz rev-odt um Vorlagen für Mahnungen ergänzt

ActionBar Doku: Ye Olde Butcherede Englishe

ActionBar Dokumentation

Konteneinstellungen wieder änderbar bei bebuchten Konten

Bei der Menüumstellung war dies für bebuchte Konten unmöglich gemacht
worden.

Changelog - Kontennachweis in BWA und GuV/EÜR

BWA Template nutzt Überschriften aus AM->get_bwa_categories

BWA mit Kontennachweis

Unterhalb der BWA gibt es einen Knopf "Kontenliste zeigen", wo eine nach
Kontennummer sortierte Liste aller Konten, mit dazugehörigem Betrag und
der Kategorie, aufgeklappt wird.

RP.pm income_statement: EÜR/GuV mit Kontennachweis

* Am Ende des Berichts kann man sich eine Liste aller Konten aus dem
Bericht anzeigen, mit Betrag und der Kategorie, in dem das Konto vorkommt.
Die Liste ist nach Kontonummer sortiert.

* Mit Klick auf eine Kategorie werden die dazugehörigen Konten
angezeigt, indem sie unterhalb der Überschrift mit einer etwas
kleineren Schrift innerhalb der Tabelle "aufgeklappt" werden.

* Am Kopf der Seite kann man mit dem Knopf "Konten zeigen" alle Konten
auf einmal aufklappen.

* Der Knopf "Knöpfe verstecken" dient dazu, die Knöpfe auszublenden,
damit man die Seite ausdrucken kann. Mit Klick auf die Überschrift
"Einnahmenüberschußrechnung" werden alle Knöpfe wieder eingeblendet.

* die Namen der Kategorien werden jetzt aus der Datenbank ausgelesen und
stehen nicht mehr hartkodiert im Template. Außerdem wurde das Template
vereinfacht, indem die Summen der Kategorien nicht mehr in einzelnen
Form-Variablen "eur1", "eur2", ... gespeichert werden, sondern alle
Summe in einem zentralen Hash stehen, und per FOREACH-Schleife im
Template ausgelesen werden können.

Kontendaten bearbeiten - Kategorien für EÜR/BWA aus DB

Die hartkodierten Kategorien für die Dropdowns entfernt und stattdessen
aus den Views eur_categories und bwa_categories auslesen.

RP.pm get_accounts_g zusätzlich nach Konto gruppieren

Dadurch erhält man die Salden der Einzelkonten in der Abfrage, und kann
diese in der EÜR und BWA als Kontenliste/Kontennachweis mit ausgeben.
Das Ergebnis aus der Abfrage für die Konten wird hierfür zusätzlich in
$form->{charts} gespeichert.

Für die Kontenliste wird an dieser Stelle auch die Kontenbeschreibung
mit abgefragt.

Kategorien für EÜR/GuV und BWA in Datenbank speichern

Vorbereitung für Kontennachweis in EÜR/BWA, wo die Kategorienamen im
Template nicht hartkodiert sein sollen.

Die Berichte sollen komplett überarbeitet werden, daher werden die
Kategorienamen temporär in einer View gespeichert, nicht in einer
Tabelle, dann braucht man auch keinen Rose-Code anlegen.

FiBu-Schnellsuche - Datumssortierung (neu zuerst)

Typos in changelog

CSV-Import: CustomerVender benutzerdefinierte Variable aktualisieren

Falls Import Einstellungen "existierende Einträge Übernehmen" eingestellt ist,
werden nun die CVARs übernommen.

Details:
die Methode handle_cvars wird nochmals aufgerufen, nachdem "object_to_save" gesetzt wurde
und anschließen die cvars aus dem "object" in "object_to_save" übernommen.

Hinweis:
Eine sauberere Lösung wäre die Methode handle_cvars nur einmal aufzurufen.
Das wäre aber ein Redesign.

fix redmine #237

Bei Aufträgen die mit "Save as new" erzeugt werden muss die gelieferte Menge auf 0 gesetzt werden

Beim neu Laden des Auftrags wird ship_{pos} zwar überprüft, jedoch erst beim erneuten Speichern zu 0
oder richtigen Wert gesetzt.

BankTransaction: "Kontoauszug verbuchen" überarbeitet für ap_transaction und credit_note

sowie Test erweitert

Anpassung Erfolgsrechnung

CsvImport: Warnungen: Uninitialisierte Variablen

DATEV: Warnungen: Uninitialisierte Variablen

Bankimport: Nicht alle Vorschläge beim ersten "Verbuchen" sichtbar

Beim Einbau der Berücksichtigung des SEPA Exports sind die gefundenen Regeln für jede Banktransaktion
vorher zurückzusetzen.

Lagerbuchungen: Fehler bei Sortieren nach Chargennummer

Can't use an undefined value as an ARRAY reference at SL/WH.pm line 445.

Es fehlte die Sortiervorschrift für "chargenumber"

Typo in Kommentar

SL::Dev::Record - Doku Beispiel für viele Aufträge

Doku zu DATEV.pm csv_export_for_tax_accountant

DATEV csv_export_for_tax_accountant nutzt generate_datev_data

DATEV.pm Einrückung

DATEV Daten Test

DATEV Export - nach Abteilung filtern

SL/GoBD.pm nutzt generate_datev_data statt _get_transactions

DATEV-Checks beim Buchen nutzen nun generate_datev_data

SL/DATEV.pm für KNE-Export überarbeitet / Zwischendaten eingeführt

_get_transactions war bisher eine interne Funktion von SL::DATEV, die vor dem
DATEV-Export aufgerufen wurde, und die Daten aus der Datenbank ausgelesen und
transformiert hat. In diesem Schritt wurde auch auf DATEV-Fehler geprüft, daher
war diese Funktion prinzipiell schon ausreichend für die DATEV-Checks beim
Buchen, und es muß nicht noch extra eine Datei-Export gestartet werden.

Im ersten Schritt wurde diese Funktion also umbenannt nach generate_datev_data.

Beim Erstellen des KNE-Formats aus den Daten wurde bisher direkt beim
Bearbeiten der Daten die KNE-Datei durch viele add_blocks aufgebaut. Jetzt
werden erst in einem Zwischenschritt alle Daten in einem "neutralen" Array von
Hashes gesammelt, so daß sie von dort in einem Rutsch nach KNE oder z.B. nach
CSV exportiert werden können.

Die so generierten Daten (generate_datev_lines) eignen sich auch gut für Tests.

In diversen Kundenerweiterungen werden auch gerne die zu exportierenden Daten
nochmal modifiziert, z.B. Ersetzen des Sammelkontos durch ein Personenkonto,
dies geschieht am Besten auch bei den neutralen Daten.

Weiterhin gab es beim KNE-Export noch Reste von Code, der die Buchungsdaten auf
mehrere Exportdateien "ED0001, ED0002, ..." verteilen konnte. Aktuell hat das
aber nicht funktioniert, und es wird immer alles nach ED0001 geschrieben, von
daher wurde hier auch Code entfernt. Das Postversendeformat (KNE) von DATEV
wird allerdings sowieso bald eingestellt werden (ab 2018).

DATEV Export - Vorbereitung für CSV Export

DATEV KNE Export Refactoring

Anstatt die Werte aus der DB direkt zu transformieren und per add_block
direkt die KNE-Datei zu bauen werden jetzt alle Daten in einem Array aus
Hashrefs gesammelt und unformatiert zwischengespeichert.
Aus diesem Zwischenstand wird dann erst in einem Rutsch die KNE-Datei
generiert. An dieser Stelle könnte man aber auch direkt die Daten als
CSV abgreifen.

CsvImport: Mehrdeutigkeit nur prüfen, wenn entsprechende Daten angegeben sind.

Fehler kam im commit
"CsvImport: bei nicht eindeutigen Kunden/Lieferanten Fehler melden."
rein.

CsvImport: customernumber/vendornumber statt number

Fehler kam im commit
"CsvImport: bei nicht eindeutigen Kunden/Lieferanten Fehler melden."
rein.

ActionBar: Verwendung bei »System« → »Vorlagen« → *

»System« → »Vorlagen« → »Stilvorlage« entfernt

Die Funktion funktioniert seit der Aufteilung der Stylesheets in
mehrere Unterdateien schlicht nicht mehr. Da sich bisher niemand
beschwert hat, wird die Funktion wohl auch nicht benötigt.

ActionBar: Verwendung bei »System« → »Historiensuchmaschine«

Kreditoren/Debitoren-Buchung zuletzt bebuchtes Konto laden

Wenn nur ein Konto ohne Wert vorhanden ist, gehen wir davon aus,
dass der Anwender einen anderen Kunden/Lieferanten buchen möchten und
hier das zuletzt bebuchte Konto als Default möchte

ActionBar: Verwendung bei »System« → »Benutzer«

ActionBar: Verwendung bei »System« → »Bücherkontrolle«

ActionBar: Verwendung bei »System« → »Korrekturen im Hauptbuch«

ActionBar: Verwendung bei »System« → »Lager«

CsvImport Mulitplex: Template: kein loop.count ausserhalb einer Schleife

CsvImport Aufträge: Rabatt richtig für Datenbank aufbereiten.

In der DB steht der Rabatt als Hundertstel.

CsvImport Aufträge: bei nicht eindeutigen Artikeln Fehler melden.

CsvImport Aufträge: Artikel auch nach EAN suchen

CsvImport: bei nicht eindeutigen Kunden/Lieferanten Fehler melden.

CsvImport: Kunden/Lieferanten auch nach GLN suchen können.

Für die Imports, die die Angabe eines Kunden oder Lieferanten brauchen und
check_vc verwenden (Aufträge, Ansprchpersonen, Lieferanschriften,
Debitorenbuchungen), kann neben Id, Nummer oder Name auch die GLN verwendet
werden.

Typo in Übersetzung behoben.

CsvImport Multiplex/Aufträge: CVars bei Fehlern nicht behandeln

Verbuchte Zahlungen auch in neuen Fällen von Bankbewegegungen berücksichtigen

Ergänzend zu af131a46:
Banktransaction: Kontoauszug verbuchen: Sonderfall für "credit_notes"

bank_transactions.t richtige Anzahl von Tests

Testfall test_ap_transaction auch ausführen

Seit Anbeginn des Testfalls vorhanden. Jetzt auch ausgeführt.

Testfall Verbuchen Kontoauszug zu Kreditorenbeleg ergänzt

Sehr viele Tests für ar, nur einen speziellen für ap.

Test: Lieferantengutschrift verbuchen, auch die Gegenseite Banktransaktion prüfen

Die Zahlung wurde korrekt gebucht, allerdings erwartet kivitendo jetzt auch
Änderungen in der bank_transactions invoice_amount, in anderen Testfällen
(test1) wird diese auch überprüft.

überflüssiges SQL-Upgrade-Script »parts_add_chart_foreign_keys.sql« entfernt

Im dem Script werden drei Fremdschlüssel für Spalten angelegt, die im
nachfolgenden Script »parts_remove_unneeded_fields.sql« gleich gedroppt
werden. Damit ist das Script überflüssig und sogar schädlich, falls
jemand noch Datenbankinhalt hat, bei dem die Spalten IDs enthalten, zu
denen es in den Zieltabellen keine Zeilen mehr gibt.

SL::X::DBError Serialisierung sollte auch die msg ausgeben

Ver-/Einkauf/Finanzbuchhaltung: automatisches Update nach Kunden-/Lieferantenwechsel

CsvImport Multiplex/Aufträge: Auch nicht angegebene CVars im Objekt speichern.

ActionBar: Verwendung bei »System« → »Benutzerdefinierte Variablen«

ActionBar: Verwendung bei »System« → »Lieferbedingungen«

ActionBar: Verwendung bei »System« → »Zahlungsbedingungen«

ActionBar: Verwendung bei »System« → »Sprachen und Übersetzungen« → »SEPA-Überweisungen«

ActionBar: Verwendung bei »System« → »Sprachen und Übersetzungen« → »Anreden«

ActionBar: Verwendung bei »System« → »Einheiten bearbeiten«