typo in ustva

PgUpgrade: nicht während eines Upgrades commiten

Merge branch 'cvar_partsgroup_filter'

changelog-Eintrag zu neuen Features bei benutzerdefinierten Variablen.

Warengruppen-Filter f. CVars bei Waren

cherry-pick aus Kundenprojekt und Anpassungen an unstable (hauptsächlich
Umstellung auf Controller)

Conflicts:

SL/CVar.pm
SL/DB/CustomVariableConfig.pm
bin/mozilla/amcvar.pl
bin/mozilla/io.pl
templates/webpages/amcvar/display_cvar_config_form.html
templates/webpages/amcvar/render_inputs_block.html

PartPicker: Tab Event atomar, visuelles Feedback

Nach dem Löschen von einer CVar wieder die Liste des entspr. Moduls anzeigen.

Steuerzone - neue Customer/Vendor-Objekte brauchen Steuerzone

Durch den not-NULL Constraint bei Kunden und Lieferanten muß
beim Anlegen eines neuen Objekts nun zwingend die Steuerzone mit
übergeben werden, ähnlich wie bei der Währung.
Dies wurde bei einigen automatischen Tests nachgeholt.

test.pl: --fast switch, skippt 001compile und 003safesys

Rechtschreibfehler in RB Druckvorlagen behoben

CsvImport: Bei Imports ohne cvars nicht die cvars klobbern.

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

PartPicker: Im Popup dem letzten Suchstring übernehmen

Spaltenzahl f. benutzerdef. Variablen in Belegen in Benutzereinstellungen ...

.. angeben können. Default ist 3.

Benutzerdef. Variablen in Belegen als Tabelle rendern ...

... im Moment mit fester Spaltenzahl.

Benutzerdef. Variablen f. Waren per Voreinstellung für Belege aktivieren/deaktivieren.

Steuerzone - korrekter Name von Warenbestand in Template

convert_taxzone - Fall keine Buchungsgruppen berücksichtigen

Für den Fall, daß in dem Mandanten gar keine Buchungsgruppen
konfiguriert sind (z.B. bei einem frischen Schweizer Kontenrahmen), wird
die Umwandlung der Buchungsgruppen übersprungen.

Steuerzone - Sortierreihenfolge bei Customer/Vendor

Sortierreihenfolge im Dropdown bei den Stammdaten einhalten.
Dadurch ist die Steuerzone mit der höchsten Sortierpriorität immer als
Defaults bei neuen Kunden/Lieferanten eingestellt (standardmäßig
Inland).

Steuerzone: in Upgrade-Datei customer/vendor angepasst

Macht man eigentlich nachträglich nicht, aber da das Update noch so
frisch ist...

Beim Umstellen von taxzone wurde vergessen, auch die Einträge der
Standardsteuerzone bei den Kunden und Lieferanten anzupassen. Im Zuge
der Umstellung, wo bei taxzone keine 0 mehr erlaubt ist, und diese auf 4
umgemapped wurde, müssen auch die hinterlegten Daten bei Kunden und
Lieferanten konvertiert werden.
In diesem Schritt wurden dann auch gleich Fremdschlüssel für die
Steuerzone bei Kunden und Lieferanten angelegt.

Ist das Update schon durchgelaufen und muß man manuell nachbessern wären
dies die Schritte (unter der Voraussetzung, daß id 0 auch zu id 4
geworden ist):

UPDATE customer SET taxzone_id=4 WHERE taxzone_id=0;
UPDATE vendor SET taxzone_id=4 WHERE taxzone_id=0;
ALTER TABLE customer ALTER COLUMN taxzone_id DROP default;
ALTER TABLE vendor ALTER COLUMN taxzone_id DROP default;
ALTER TABLE customer ADD FOREIGN KEY (taxzone_id) REFERENCES tax_zones (id);
ALTER TABLE vendor ADD FOREIGN KEY (taxzone_id) REFERENCES tax_zones (id);

Nachtrag Steuerzone - Tests angepasst

Typo-Fix und kleine Verbesserungen in deutscher Übersetzung.

L.radio_button_tag: id erhalten wenn sie schon vorher gesetzt ist.

Installcheck: Version von Archive::Zip korrigiert.

CsvImport - Part : Anpassung für neue Steuerzonen

statt income/expense_accno_id_0 werden jetzt bei importierten
Waren/Dienstleistungen die Konten-IDs der Standardsteuerzone verwendet.
(Wobei die genau ID ja egal ist, wichtig ist, ob etwas gesetzt ist).

Buchungsgruppe anlegen/bearbeiten/anzeigen - Logik umgestellt

3 Fälle in Maske berücksichtigen:

* neue BG: Konten-Dropdown mit Standardkonten vorausgewählt
* existierende BG nicht in Benutzung: Konten-Dropdown mit gespeicherten
  Konten vorausgewählt
* existierende BG in Benutzung: gespeicherte Konten als Text anzeigen

Steuerzone in price_tax_calculator.t angepasst

Neue Methode orphaned für Buchungsgruppe

Zum Prüfen, ob eine Buchungsgruppe gelöscht oder bearbeitet werden kann.

Fehlende MetaSetup Dateien für Steuerzonenupdate

Console Shortcut für chart (analog zu part)

DB Code für Buchungsgruppe und TaxzoneChart aufgeräumt

In SL::DB::Manager::Buchungsgruppe die Methoden inventory_accno und
inventory_accno_description entfernt, da hier einfach
inventory_account->accno und inventory_account->description benutzt
werden können.

Beim Erfassen von Steuerzonen Standardkonten verwenden

Vorauswahl von Erlös- und Aufwandskonten laut Mandantenkonfiguration.
Im Gegensatz zum Anlegen von Buchungsgruppen kann bei der Steuerzone
kein Bestandskonto konfiguriert werden, da dies nur von der
Buchungsgruppe abhängt.

Buchungsgruppen - löschen und beim Erstellen Standardkonten benutzen

Wenn eine Buchungsgruppe noch nicht einer Waren zugeordnet ist kann
diese noch bearbeitet (Kontenzuordnung) oder gelöscht werden.

Beim neu Erstellen von Buchungsgruppen werden die Standardkonten aus der
Mandantenkonfiguration (Erlös/Aufwand/Bestand) vorausgewählt.

Steuerzone - Default eingeführt (statt id 0)

Als Defaultsteuerzone gilt nun die Steuerzone mit dem höchsten Sortcode, der
nicht obsolet ist (in der Regel also id 1).

Bernd hatte noch ein paar Stellen gefunden, wo als Default 0 gesetzt wird.
Außerdem Doku angepasst, taxzone_id ist nun nicht mehr im Bereich 0-3.

Nachtrag zu Steuerzonen: benutzte Klassen mit require einbinden.

Steuerzonenfeature - tags auf Version 3.1.0 anpassen

Changelog Eintrag für konfigurierbare Steuerzonen

Steuerzonen ungültig machen

jede Steuerzone kann man unter "System->Steuerzonen->auf Steuerzone klicken"
individuell auf ungültig (obsolete) setzen.

ungültig heißt:

* Steuerzone erscheint nicht in der großen Buchungsgruppenübersicht
* Steuerzone erscheint nicht im Drop-Down Menü für Steuerzonen bei neuen
  Belegen (Angebot-Rechnung)

Bei alten Belegen, die erneut geöffnet werden, ist leider das Verhalten unterschiedlich:

* bei schon gebuchten EK/VK-Rechnungen (id) ist das Drop-Down ausgegraut und
  disabled und es wird nur die ausgewählte Steuerzone angezeigt -> funktioniert

* bei schon gebuchten Angeboten/Aufträgen müssen immer alle Steuerzonen
  angezeigt werden, da man die Steuerzone auch im Nachhinein ändern kann, aber
  auch alle alten Belege mit mittlerweile ungültigen Steuerzonen korrekt
  angezeigt werden müssen. Man kann also nicht einfach nach id fragen und
  entsprechend nach ungültig filtern.

Bucht man also einen Auftrag mit einer bestimmten Steuerzone, setzt die
Steuerzone auf ungültig, und generiert dann aus dem Auftrag z.B. eine Rechnung,
würde die Steuerzone aus dem Auftrag nicht übernommen werden, sondern die erste
Steuerzone aus der Liste standardmäßig ausgewählt sein.

Änderung von Upgrade-Script change_taxzone_id_0

Die Tabellen ar und ap werden jetzt auch an den ID-Wechsel angepasst.

Weiterhin werden 2 Fremdschlüssel gesetzt, die durch den Wechsel
aufgefallen sind.

Sortieren von Steuerzonen in Belegen

Die Sortierreihenfolge von Steuerzonen in Belegen wurde bisher noch
nicht in den Belegen berücksichtigt.

id ungleich Null setzen in tax_zones

In der Tabelle tax_zones gibt es sehr häufig noch Einträge mit id=0.
Dadurch kommt es bei der Anzeige, und auch beim Bearbeiten dieses
Eintrags zu fehlern. Dieser Commit vergibt verändert den Wert der
id, s.d. die id einen von 0 verschiedenen Wert hat.

Steuerzonen und Buchungsgruppen bearbeiten

Nachdem man Steuerzonen und Buchungsgruppen auf Datenbankebene
bearbeiten kann, ist jetzt auch eine Bearbeitung an der Ober-
fläche möglich.

Alter Code, der für die Anzeige/Bearbeitung/Erstellung von
Buchungsgruppen entwickelt wurde hat nicht mehr funktioniert
und wurde vollständig ersetzt.

Auf Datenbankebene Steuerzonen konfigurierbar gemacht

Damit können jetzt mehr als die 4 Standardsteuerzonen eingerichtet
werden. Die bisherigen Steuerzonen wurden aus der Tabelle
buchungsgruppen in die neue Tabelle taxzone_charts ausgelagert.

Konzeption siehe Ticket #2295

Es wurden noch keinerlei Veränderungen an der Kivitendo
Benutzeroberfläche durchgeführt, durch dieses Upgrade können die
Buchungsgruppen also nicht mehr konfiguriert werden, dies muß auf
Datenbankebene passieren.

Rose schon angepasst.

Conflicts:

SL/DB/MetaSetup/Buchungsgruppe.pm

Installationcheck: --silent switch um es in shell scripte einzubinden

Typo-Fix: Trennzeichen für CVar-Flags ist ':' nicht ';'.

round_amount: Fix für falsches Runden bestimmter Werte

Gewisse Werte wie z.B. 33,675 wurden bei 2 Stellen falsch gerundet,
nämlich auf 33,67 anstelle von 33,68. Bei anderen Werten hingegen
funktionierte es (beispielsweise 149,175 @ 2 → 149,18).

Grund war, dass durch das Addieren von 0.5 wieder Fließkommaberechnung
und damit die Ungenauigkeit der Präsentation der IEEE-Fließkommazahlen
ins Spiel kommt. Das anschließende int() schneidet dann die
Fließkommazahl falsch ab, ungefähr so:

- Initial: 33,675
- Linksshift um 2 Dezimalstellen, also * 100: 3367,5
- Dann + 0.5 und truncate, hier passierts: +0.5 =
  3367,499999999999999999999958 (auch wenn Perl das in der Ausgabe als
  3368 darstellen würde) oder so, davon int() ergibt nun mal 3367 vor
  anschließendem Rechtsshift um 2 Dezimalstellen

Lösung ist, bis auf das Links-/Rechtsshiften um die Dezimalstellen gar
keine Fließkommaberechnung zu verwenden. Eine Variante ist, eine Stelle
mehr zu shiften als man an Genauigkeit will, dann 5 zu addieren und
anschließend auf das nächst kleinere Vielfache von 10 zu
reduzieren (durch simples Abziehen vom Modulo 10).

Um die Logik leicht einfacher zu halten, wird das Vorzeichen anfangs
ermittelt und ab dann nur noch mit dem Absolutwert der Zahl
gerechnet. Das ursprüngliche Vorzeichen wird erst nach dem erneuten
Rechtsshift, also ganz am Schluss der Berechnung, wieder hergestellt.

GetModels: Funktion zum Setzen zusätzlicher URL-Parameter

L: Eindeutige ids für radio_tag wiederhergestellt.

Die waren in da2fecb453416b3731a896ab6d35e9992be3d9eb kaputtgegangen.

VERSION auf unstable gesetzt

Revert "POD-Dokumentation aktualisiert"
die methoden werden jetzt generisch generiert.
Doku ist korrekt und aktuell.  My bad.
This reverts commit b04128a335772d4cb9a30b0fde52413796981de0.

HTML-Tag richtig schliessen und Kosmetik

Standardmässiges Ein- und Auslagern von Dienstleistungen per Mandantenkonfiguration eingestellt

Mandantenkonfiguration erweitert:Dienstleistungen NICHT automatisch Auslagern
Standardmässig werden Dienstleistungen wie Waren und Erzeungnisse behandelt und
so auch beim Standard-Auslager-Verfahren. Entsprechend die Mandantenkonfiguration (defaults)
angepasst.

POD-Dokumentation aktualisiert
get_ Methoden werden nicht mehr einzeln für die Tabelle defaults gesetzt

HTML::Util: Tests, und Bugfixes für ein paar Randbedingungen

HTML::Util: Short circuit ohne $value. Behebt gleichzeitig eine Warnung.

Tests: neue Background Job Klasse auch erwarten

SL::Locale::String: @_ in neue Ref kopieren anstatt \@_

ansonsten verschwinden aus irgend einem Grund alle Elemente außer dem
ersten.

Hintergrundjob zum Löschen abgelaufener Sessions

CreatePDF-Helfer: Anpassung an API-Änderung SL::Template.*new

PreisTaxCalculator: Caching-Abfrage für »keine Positionen« gefixt

Kunden-/Lieferantenstammdaten: CVar-Input-Felder mit richtigem Namen versehen

Ging leider im Commit »CustomVariables: Verwendung mit RDBO als Writer
implementiert« kaputt, weil außerhalb dieses Templates »var_name«
bereits gesetzt war und somit alle CVar-Input-Felder denselben Namen
bekommen haben.

Handle zur LXDebug-Logdatei auch UTF-8 encoden

Wenn GREEK CAPITAL LETTER DELTA im Text, dann auch utf8 flaggen.

Wiederkehrende Rechnungen: Variablen für lange Monatsnamen gefixt

Ging im Commit »Wiederkehrende Rechnungen: Formatierung von
Datumsdruckvariablen über freie Formatstrings« kaputt. Danach waren die
Variablen <%current_month_long%> schlicht leer.

task_server: pro Job mit Sprache vom konfiguriert initialisieren

…und die Systemsprache nur als Fallback nutzen.

Hat in der Praxis vermutlich keinerlei Auswirkung, ist aber die
Implementation, wie sie sein sollte.

LXDebug::log_time: Differenz zum letzten Aufruf in ms mit ausgeben

Druckvorbereitung: Lieferschein-Model mit richtigem Primärattribut laden

Das ging im Commit »Einkauf/Verkauf: Lieferadressenfelder nie aus
Stammdaten vorbelegen« kaputt.

SL::DB::(Delivery)Order,(Purchase)Invoice: Aliase »add_items«

Die Relationships für die Positionen heißen in allen Klassen
unterschiedlich. Daher gibt es schon seit Längerem den Alias »items« in
allen Klassen.

Das Hinzufügen von Positionen hingegen erforderte bisher, dass man den
Namen der Relationship kennt, z.B. für Invoice:
$obj->add_invoiceitems. Um das zu Vereinfachen: neuer Alias »add_items«
in allen vier Klassen.

Aufträge bei Anzeige der Lieferungen in Kundenstammdaten richtig zuordnen.

Und richtigen Beleg (VK/EK) öffnen.

Behebt #2467.

Hinweis von Sven format_amount hat nichts in Template Verzweigung zu suchen.
Keine Ahnung warum mein Test am Freitag, dass nicht korrekt evaluiert hat.
Wahrscheinlich ist qty undef. Es reicht hier aber auch aus, einfach zu prüfen, ob
es sich um einen oder mehrere Einträge in STOCK_INFO handelt.

Hinweis von Sven format_amount hat nichts in Template Verzweigung zu suchen.
Keine Ahnung warum mein Test am Freitag, dass nicht korrekt evaluiert hat.
Wahrscheinlich ist qty undef. Es reicht hier auch aus, einfach zu prüfen, ob
es sich um einen oder mehrere Einträge in STOCK_INFO handelt

DB-Trigger, um sicher zu stellen, dass ein Lagerplatz auch zum Lager gehört.

Betrifft #2485.

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

Einkaufslieferschein, Einlagern mit mehreren Lagern verbessert
Mehrfaches Aufrufen vom Fragezeichen Einlagern-Knopf, bzw. Erneuern der Posititonseinlagermaske
hat die Zuordnung zu Lager -> Lagerplatz fehlerhaft gesetzt, falls ein Standardlagerplatz in
den Stammdaten gesetzt war.
Details s.a. Ticket: 2485

UStVA: Position 47 in Summe 53 mit aufnehmen

2 Warnungen in den Tests beseitigen

Lieferadresse eingeben: Möglichkeit zum Kopieren aus Stammdaten

Im Dialog für die Eingabe einer individuellen Lieferanschrift gibt es
nun die Möglichkeit, die Felder aus den Stammdaten des
Kunden/Lieferanten vorzubelegen. Dabei werden sowohl die
Rechnungsadresse als auch alle Lieferadressen angeboten.

Ist beim Abschicken in mindestens einem Feld etwas eingetragen, so wird
eine eventuell vorher ausgewählte shipto_id abgewählt, ansonsten
beibehalten.

Was momentan noch nicht angeboten wird, ist die Firmenadresse aus den
Mandantendaten, weil hier das Adressfeld leider nicht nach Straße,
Postleitzahl, Ort aufgeteilt ist. Ansonsten wäre das für Einkaufsbelege
sinnvoll.

Verkauf: leeren Eintrag in Lieferadressendropdown klarer benennen

Angezeigt wird nun »Keine/individuelle Lieferadresse«, um es den
Benutzern klarer zu machen, dass die über den Button »Lieferadresse«
eingetragene Lieferadresse greift.

Einkauf/Verkauf: Lieferadressenfelder nie aus Stammdaten vorbelegen

Das neue Verhalten ist wie folgt:

- Weder die shipto_id (die Drop-Down-Box in den Belegmasken) noch die
  individuellen shipto*-Felder werden weder beim Neuanlegen eines
  Beleges noch bei Wechsel des Kunden aus den Datenbanken belegt.

- Beim Ausdruck werden die shipto*-Felder nicht mehr aus der
  Mandantenkonfiguration vorbelegt, wenn keine Lieferadresse gesetzt
  ist.

- Beim Ausdruck werden die shipto*-Felder mit den Daten aus den
  Kundenstammdaten belegt, wenn die shipto_id (die Drop-Down-Box in den
  Belegmasken) gesetzt ist.

Die ursprüngliche Intention war, möglichst viele Fälle abzudecken. Ganz
ursprünglich war es nämlich in den Druckvorlagen gar nicht möglich,
Kontrollstrukturen zu benutzen und damit die Ausgabe konditional zu
steuern. Es konnte also rein in den Druckvorlagen nicht unterschieden
werden zwischen »der Benutzer hat keine Lieferadresse eingegeben« und
»der Benutzer hat eine eingegeben oder ausgewählt«.

Daher wurde die ganze Logik immer im Perl-Code abgehandelt.

Das macht aber erhebliche Probleme für den Benutzer, für den es absolut
intransparent ist, wann welche Lieferadresse wie vorbelegt wird. Hinzu
kommt, dass in den Belegmasken nicht ersichtlich ist, dass eine
individuelle Lieferadresse eingetragen wurde.

Hinzu kommt, dass die Druckvorlagen inzwischen verschiedene Mechanismen
zur Verfügung haben, um Fallunterscheidungen zu treffen (z.B. die
kivitendo-Mechanismen $(if shipto…)$ oder die LaTeX-eigenen
\IfThenElse{\equal{$(shipto…)$}{…}}}…). Leider war es mit dem vorherigen
Code für die Druckvorlagen nicht mehr möglich festzustellen, ob der
Benutzer nun eine Lieferadresse eingegeben hat oder nicht.

Die neue Situation ist recht einfach:

Steht in »shiptoname« oder »shiptostreet« ein nicht leerer Wert, so ist
eine Lieferadresse vorhanden, ansonsten nicht.

Für die »nicht«-Fall kann dann jede Vorlage selber entscheiden, was zu
tun ist. Für Vorlagen im Verkaufsbereich sinnvollerweise gar keine
Lieferadresse ausgeben (oder einfach die Lieferadresse aus den
Kundenrechnungsdaten), für Vorlagen im Einkaufsbereich ebenfalls keine
Lieferadresse oder die Adresse aus der Mandantenkonfiguration.

Behebt #2345, #2400.

DateTime: (add|subtract)_businessdays Funktionen

Rundungsfehler bei periodischen Rechnungen mit Einzelpreisen ...

... mit einer Nachkommastelle und Rabatt behoben.

siehe auch commit a22b8118e0bd68acac8a2d7b02a2d4f9fd0eaff1

Zudem einen Test dazu angelegt. Allerdings weicht die Art, wie der
PriceTaxCalculator und die Beleg-Masken rechnen, von einander ab.
Da müsste nochmal geprüft werden, was die richtige Art ist
(erst Rabatt abziehen und dann runden,
oder gerundeten Rabatt abziehen und wieder runden).
Auch beim Errechnen des Amounts gibt es unterschiede
(netamount * (1+Steuersatz),
oder aufsummieren).

FollowUp(Access)-Rose-Models: sinnvollere Namen für Relationships

rose_auto_create_model.pl: Relationship-Namen anhand der Spaltennamen mappen

Bisher wurde das Umbenennen der generierten Relationships anhand des von
Rose vergebenen Namens der Relationship vorgenommen. Das ist
problematisch, weil diese wiederum von der Reihenfolge abhängen, in der
die Fremdschlüsseldefinitionen von der Datenbank zurückgeliefert werden.

Konkretes Beispiel: Tabelle »follow_up_access« mit den Spalten »who« und
»what«, die beide Fremdschlüssel auf employee sind.

Rose benennt die erzeugten Relationships nach dem Klassennamen
derjenigen Tabelle, auf die die Schlüssel verweisen. Tabelle »employee«
→ Klasse »SL::DB::Employee« → Default-Relationshipname »employee«.

Die erste von der Datenbank gemeldete Fremdschlüsseldefinition bekommt
nun den Namen »employee«. Die zweite sollte diesen ebenfalls bekommen,
aber da der schon vergeben ist, bekommt sie das Suffix »_obj«, ergo
»employee_obj«. Soweit, so gut. Ändert sich nun aber die Reihenfolge, so
werden die Namen genau umgekehrt herum vergeben.

Die Umbenennung anhand des Tripels <Domäne, Tabelle, Spaltennamen>
hingegen ist immer eindeutig.

Kunden-/Lieferantenstammdaten: Maps-Link mit Firmenadresse als Routing-Ausgang

Spaltentyp Text anstelle von varchar() in diversen Tabellen Teil 3

Kunden-/Lieferantenstammdaten: Beschränkungen für Feldlängen entfernt

…da die Datenbankspalten inzwischen alle vom Typ TEXT und nicht mehr
VARCHAR sind.

Spaltentyp Text anstelle von varchar() in diversen Tabellen Teil 2

Tabelle »shipto«

Lieferantenauftrag → Kundenauftrag: Verkaufspreis als Einkaufspreis übernehmen

Der Preis, den ich beim Lieferanten zahlen musste (alte Maske:
sellprice_N) ist dann im weiteren Verkaufsprozess der
Einkaufspreis (neue Maske: lastcost_N).

Generische Unterstützung für CTI: Click-to-dial

ReportGenerator: class für Links angeben können

SL::MoreCommon: benutztes Encode auch usen

USTVA: Analog zu b0f569c auch Position 46 umdrehen.

Neuer Bericht »Liquiditätsvorschau«

Verkaufsbelege: optional nur Projekte des Kunden anbieten

Auch dieses Feature kann über die Mandantenkonfiguration eingeschaltet
werden.

Instance-Conf am Anfang jedes Requests laden

Angebote: neue Felder Auftragswahrscheinlichkeit, Voraus. Abrechnungsdatum

Einkaufs-/Verkaufsprozesse: optionale Einschränkungen für gewisse Aktionen

Über die Mandantenkonfiguration kann verboten werden, dass gewisse
Aktionen in den Einkaufs- und Verkaufsprozesse durchgeführt
werden. Diese sind:

- Direkte umwandlung von Verkaufsangeboten und -aufträgen in
  Verkaufsrechnungen (nur über den Weg der Lieferscheine)
- Direktes Anlegen neuer Einkaufslieferscheine und -rechnungen (nur
  durch Umwandlung bestehender Belege)

Offene Transaktionen vor DB-Upgrades comitten

Hintergrund ist, dass Locks potenziell vorhanden sein können. Einfaches
Beispiel: $::instance_conf wird geladen (dadurch implizites
ACCESS-SHARE-Lock auf »defaults«), Upgrade will Schema von »defaults«
verändern, was dann hängt, weil dafür ACCESS-EXCLUSIVE benötigt wird –
das mit ACCESS-SHARE kollidiert.

CSV-Helfer-Test: In-Memory-Streams mit richtigem Encoding initlisieren