Länder-Dropdown

[Niclas]

Um nicht 10 verschiedene Schreibweisen für ein und dasselbe Land zu bekommen, empfiehlt sich ein Dropdown-Feld. Neue Länder sollten dann unter System eingegeben/bearbeitet werden können. Die Daten würden dann einfach in einer neuen Tabelle gespeichert.

Das einzige kleine Problem wäre, die alten Ländernamen zu übernehmen. Nimmt man hier dann einfach alle bestehenden Länder aus der Datenbank oder gibt es eine schlauere Methode, die erkennen kann, dass z.B. das Land GER zu Deutschland gehört?

Gibt es andere Probleme, die ich übersehen habe? Sonst würde ich loslegen...

Unterschiedliche Kunden wollen dort unterschiedliche Informationen drin haben. Mal den vollen Namen (Deutschland), mal die KFZ-Abkürzung (D), mal die englische Variante (Germany), oder wie von dir erwähnt die englische Abkürzung (GER).

Nächstes Problem ist die Ausgabe. Wenn du den Landesnamen in einer Druckvorlage ausgibst, so ist es möglich, die Abkürzung vor der Postleitzahl zu haben (D-12345 Irgendwo) -- oder aber als eigene Zeile darunter.

Nächstes Problem ist potenziell, dass Druckvorlagen ungültig werden! Stell dir Druckvorlagen vor, in denen ein User darauf prüft, ob im Land etwas drin steht und davon abhängig andere Formate wählt. Beispiel:

\IfThenElse{\equal{<%country%>}{D}}{%
  % Anschrift in Deutschland, Format 1
}{%
  % Anschrift außerhalb Deutschlands, Format 2
}

Wenn du diesem User plötzlich das Format von country änderst, funktionieren die Vorlagen nicht mehr so ganz. Das muss mindestens richtig gut dokumentiert werden.

Muss man denn wirklich die Länder unter System eingeben??

Es reicht doch wenn alle vorhanden Länder der Kunden ins Drop-Down kommen.

Dann muss man jedes Land bzw. deren Kürzel nur einmal eingeben und danach kann es
im Drop-Down ausgewählt werden. (Wie im CRM mit der Anrede)

Die Länder alle einzeln im System-Menü angeben zu müssen, halte ich ebenfalls für eine schlechte Idee. Wenn, dann müsste diese Liste per default mit allen jetzt bekannten Ländern der Erde bestückt sein -- oder zumindest den europäischen plus ein paar anderweitig als "wichtig" betrachteten.

Eine Vorbelegung mit > 100 Ländern wird dann andererseits bei der Eingabe nervig.

Der Vorschlag von Ciatronical scheint mir da dann doch besser als eine ewig lange Liste von Ländern zu haben. Ein anderer Vorschlag wäre vielleicht so etwas wie eine Autovervollständigung, die unter allen schon eingegebenen Ländern sucht, was eingegeben wurde. Allerdings müsste dieser dann z.B. auch sowas können wie deitschlang oder ger auf Deutschland matchen. Weiß nicht, wie aufwendig sowas zu programmieren ist...

Um keine Arbeit doppelt zu machen schlage ich vor hier einen Blick hin zu werfen:

​http://alioth.debian.org/projects/pkg-isocodes/

Wie wäre es damit:
http://www.kivitendo.de/services/offene-projekte/partpicker.html
Der zeigt einfach alles, was da ist. Dem beizubringen, dass er auch neues nimmt, ist vermutlich keine soo große Sache. Und es würde einfach mit dem was drin ist schon funktionieren. Also nur Oberflächenänderungen, soweit ich das abschätzen kann.

Der ist für Waren und nicht für Länder gemacht.

Das Hauptproblem, um das es hierbei geht, ist daß durch Varianten oder
Rechtschreibfehler die Auswertung eines bestimmten Landes erschwert wird.

Ich würde so vergehen:

Für das Upgrade von bestehenden Mandanten würde man im ersten Schritt einfach
für alle vorhandenen eindeutigen Einträge einen Dropdown-Eintrag erstellen. Bei
Variationen müßte man dann in der Nachbearbeitung eine Variante als die
Korrekte wählen, alle Variationen auf diese umändern, und die Variationen dann
auf ungültig setzen oder löschen. Dann würden auch weiterhin die Druckvorlagen
funktionieren.

Jedes neu benötigte Land unter System erst hinzuzufügen ist zwar lästig, zumal
der Standardbearbeiter wahrscheinlich keine Rechte dafür hat, aber wie oft
kommt das denn vor?

Bei neuen Mandanten würde ich auch nicht alle möglichen Länder vorbelegen, eben
weil manche Firmen vielleicht lieber mit ISO-Codes arbeiten, und viele
Mandanten wahrscheinlich überhaupt nur eine handvoll von Ländern brauchen.
Ansonsten wäre vielleicht auch eine Sortierreihenfolge nützlich.

Würde man auch beim Upgrade von einem vollen Ländersatz ausgehen, müßte man
versuchen möglichst fuzzy die vorhandenen Ländernamen der "offiziellen" Liste
zuzuweisen. Das klappt ganz gut bei einem bestimmten Mandanten, wo man die Variationen
kennt, aber nicht für beliebige Mandanten.

#partpicker: Genau der wird nicht funktionieren. Klar. Allerdings ist die Grundtechnik da, sich elegant und schnell durch Bestand zu wühlen. Ich bin zuversichtlich, dass eine entsprechende Umsetzung mit einem überschaubaren Aufwand möglich wäre.

Was die Fehler betrifft: Das Dilemma beginnt nicht erst beim Land, das gilt grundsätzlich in allen Eingabefeldern der Stammdaten. Wenn es dafür keine Regeln gibt, ist ein falsch geschriebenes Land das geringste Problem. Diese Regeln muss jedoch der Eingebende einhalten, das lässt sich softwareseitig nicht einfangen (von einer Kontrolle gegen Adresswerke abgesehen, was jedoch andere Probleme aufwirft).

Eine simple und außerordentlich gut funktionierende Regel lautet: Adressen erfasst und korrigiert nur einer, bzw. ein Team aus Wenigen. Da wird dann ggf. konsequent falsch geschrieben, womit es egal ist, was die Suche und Gruppierung betrifft.

So, Niclas hat das Feature mittlerweile implementiert, ich habe es eben getestet und es funktioniert meiner Meinung nach sehr gut und ist für den Standard sinnvoll. Wenn es keine gravierenden Einwände gibt würde ich das gerne in den Standard integrieren, hier die Beschreibung:

Beim Update bestehender Mandanten werden alle vorhandenen Einträge übernommen und in die Liste der Dropdowneinträge integriert, die Initialsortierung ist alphabetisch.

Es wird nicht intelligent nach Schreibfehlern gesucht und gegebenenfalls automatisch zugeordnet.

Hat man nachher zwei Einträge in der Liste:

Deutschland
Detuschland

muß man manuell unter Stammdaten->Berichte->Kunden alle mit "Detuschland" anzeigen und einzeln ändern. (Oder per Datenbankbefehl).

Die Variable "country" steht den Druckvorlagen weiterhin zur Verfügung.

Hinzufügen neuer Länder geht nur unter System.
Man kann die Sortierreihenfolge der Länder dort ändern oder auch die Beschreibung ändern.

Unbenutzte Länder kann man löschen.

Der erste Eintrag im Dropdown ist leer, man muß also kein Land zuweisen.

Bei einem neuen Mandanten sind keine Länder vordefiniert, hier könnte man es sowieso nicht Allen recht machen.

Ich habe mir den Patch angeschaut. Ein paar Sachen müssen/sollten da noch gefixt werden.

1. SL::DB::Countries muss SL::DB::Country heissen. RDBO Objekte sind immer im singular benannt, die Tabelle im plural. Hätte in SL::DB::Helper::Mappings vor dem automatischen Anlegen eingetragen werden sollen. Wenn das nicht gemacht wird ist das unendlich verwirrend wie die Klasse heute wieder heisst.
2. Upgradescript laender_dropdown. Bitte benennt interne Sachen immer in englisch, sofern es nicht wirklich gute Gründe für einen deutschen Namen gibt (wie DATEV).
3. Benutzt bitte keine CHARACTER VARYING(75). Das ist ein mysqlismus, der heute keinen Sinn mehr macht. Verwendet bitte TEXT.
4. In SL::Controller::Countries: Es ist eine lose Konvention die action_ Methoden zu gruppieren und die Helperroutinen weiter unten hinzupacken. Keine harte Anforderung, wäre aber schön.
5. SL::Controller::CsvImport::Shipto - da ist auf einmal das Attribut "table" von "scalar" auf "scalar --get_set_init" auggewertet worden. Absicht? Geht das nicht kaputt ohne init_table?
6. Der SL::DB::Helper::ALL Eintrag für countries fehlt (wie auch von t/redbo_consistency angemeckert, benutzt die Tests!)
7. In der SL::DB::MetaSetup::Countries sind Relationen die Rose da ganz sicher nicht hingetan hat. Die werden beim nächsten Update überschrieben. Gehören nach SL::DB::<Model>
8. Soweit ich das interpretiere geht bei allen Suchmasken die Möglichkeit verloren nach Teilstrings von Längern zu suchen. Ist das so gewollt?
9. Countries/list: render gibt einen eigenen header aus, bitte keinen $::form->header Aufruf da.
10. countries/list.html: flash bitte unter dem Titel ausgeben.
11. function change_country: macht euch das Leben leichter, benutzt jquery. $('#country').val($('#country_id :selected').text())
12. Konzeptuell finde ich es ein wenig unschön, dass man erst ins System muss, wenn man einen Kunden eingeben will, der nun gerade aus einem Land kommt, das man noch nicht in der Datenbank hat.

Das ist erstmal alles was ich sehe.

Replying to s.schoeling@…:

8. Soweit ich das interpretiere geht bei allen Suchmasken die Möglichkeit verloren nach

Teilstrings von Längern zu suchen. Ist das so gewollt?

Stimmt, man kann jetzt nicht mehr mit Teilstrings filtern, wenn man filtert dann genau ein Land.
Find ich persönlich völlig OK so, oder gibt es da tolle Sini-Tricks die ich nicht kenne?

12. Konzeptuell finde ich es ein wenig unschön, dass man erst ins System muss, wenn man einen Kunden eingeben will, der nun gerade aus einem Land kommt, das man noch nicht in der Datenbank hat.

Stimmt auch, aber wie oft kommt das denn vor? Das bekommt mit etwas Planung und Voraussicht eigentlich gut in den Griff, und wer will kann sich auch einmal alle Länder anlegen, wenn das ein wiederkehrendes Problem sein sollte.

Ich habe den Patch nicht gesehen; mir fällt gerade nur anhand von Svens Kommentaren auf:

zu 4: Auch Controllernamen sind bitte singular zu halten (SL::Controller::Country). Weiterhin verschärfe ich die Regel: alle action_*-Subs gruppieren. Darunter erst die Helfer. Falls mit Rose::Object::MethodMaker gearbeitet wird und dort --get_set_init-Methoden vorkommen: auch alle init_*-Subs dazu gruppieren.

zu 7: SL::DB::MetaSetup::* darf nie manuell geändert werden. Die werden alle automatisch erzeugt und überschrieben.

zu 8: Das ist schlecht, egal ob es gewollt ist oder nicht. Bitte wieder auf Substringsuche umstellen.

zu 10: Der Name des Template-Verzeichnis muss ebenfalls im Singular gehalten werden (templates/webpages/country).

zu 12: finde ich deutlich mehr als unschön, weil es die Dateneingabe deutlich nerviger macht. Vor allem bei neuen Installationen, wenn noch gar keine Länder angelegt sind und jemand viel mit ausländischen Kunden/Lieferanten zu tun hat.

Replying to m.bunkus@…:

zu 8: Das ist schlecht, egal ob es gewollt ist oder nicht. Bitte wieder auf Substringsuche umstellen.

Die vorgeschlagene Erweiterung heißt "Dropdown", das ist für mich der zentrale Vorteil von der ganzen Aktion. Es gibt keine Vertipper mehr und man sieht beim Filter sofort, welche Optionen es überhaupt gibt. So wie ich z.B. beim Verkaufsbericht Dropdown-Filter für Warengruppe, Kundentyp, Projekt und Abteilung habe stelle ich mir das auch für den Länderfilter vor. In der Form ist es bei einem Kundenprojekt schon seit 5 Jahren implementiert, damals von Linet so programmiert, und das hat sich gut bewährt, weshalb ich das auch für den Standard gut fände und auch gerne in anderen Kundenprojekten von uns hätte.

Zumindest von unseren Kunden nutzt so weit ich weiß niemand die Substringsuche als Feature.
Mir fällt auch spontan kein gutes Szenario dafür ein. Wenn z.B. jemand seine Kunden in die "Länder" Deutschland Ost, Deutschland Süd, Deutschland Nord und Deutschland West aufteilen würde, dann würde das Dropdown die Möglichkeit nehmen, nach ganz Deutschland auf einmal zu filtern. In dem Fall würde man Land aber auch nicht (ohne weitere Druckvorlagentricks) für die Rechnungsanschrift nehmen können, und man könnte sich für solche Regionen z.B. auch mit benutzerdefinierten Variablen helfen.

Sorry, aber mir fehlt derzeit die Fantasie, wieso Punkt 8 ein No-Go ist.

zu 12: finde ich deutlich mehr als unschön, weil es die Dateneingabe deutlich nerviger macht. Vor allem bei neuen Installationen, wenn noch gar keine Länder angelegt sind und jemand viel mit ausländischen Kunden/Lieferanten zu tun hat.

Ich finde immer noch, daß das zumutbar ist, und die Vorteile insgesamt überwiegen, bei anderen Kategorien funktioniert das ja auch. Und in bestimmten Fällen ist das sogar ein Vorteil, daß nicht jeder Benutzer einfach selbst neue Elemente hinzufügt. Aber ich sehe ein, daß das so nicht wirklich elegant und fluffig ist. Wäre das denn rechtemäßig unbedenklich bzw. unkompliziert möglich, in den Stammdaten neben dem Länderfeld einen neuen Knopf "Land hinzufügen" einzubauen, wo eine Maske genau für nur dieses Feature aufgeht? Oder direkt ein Eingabefeld mit "Hinzufügen"-Knopf neben dem Länderdropdown? Oder käme man dann mit AM-Rechten in einen Konflikt? Projekte kann man ja auch in der Stammdatenkategorie hinzufügen.
Das gleiche Argument könnte man jedenfalls auch für Warengruppen beim Anlegen von Artikeln oder Kundentyp und Zahlungsbedingungen beim Anlegen von Kunden geltend machen.

Die vorgeschlagene Erweiterung heißt "Dropdown", das ist für mich der zentrale Vorteil von der ganzen Aktion.

Versteh mich nicht falsch. Bei der Eingabe der Daten halten ich eine eingeschränkte Wahlmöglichkeit der Länder für sinnvoll.

Beim Suchen hingegen ist Flexibilität besser! Oder zumindest optionale Flexiblität. Wenn jemand gerade bei einer aktualisierten Altinstallation nach allen Kunden aus Deutschland suchen will und in der Datenbank sowohl die von dir als Beispiel erwähnten "Deutschland", "Detuschland" und "DE" hat, so hätte er vorher nach "de" suchen können (und vermutlich auch noch andere gefunden, aber trotzdem zumindest auch alle aus Deutschland).

Du kannst auch locker eine Kombilösung implementieren (geht mir weiterhin nur um die Suchmasken): sowohl Drop-Down als auch Freitext. Oder Freitextfeld mit JavaScript-Autocomplete (hier sinnigerweise ohne AJAX; die Länderliste ist ja relativ klein und kann komplett beim Aufrufen der Seite in JS ausgeliefert werden; das jQuery-Autocomplete kann das auch problemlos ohne AJAX -- ​siehe Beispiel).

Ich finde immer noch, daß das zumutbar ist, und die Vorteile insgesamt überwiegen

Nein. Gerade eine Neuinstallation darf nicht davon geprägt sein, erst im Systemmenü zwanzig Kategorien durchzugehen und tausend Sachen anzulegen. Das ist unglaublich nervig und erhöht die Einstiegshürde unnötig.

Aus der K/L-Stammdatenmaske direkt Länder anlegen zu dürfen, halte ich nur für eine Krücke, weil das natürlich denjenigen, die keine Rechte auf das Systemmenü haben, immer noch nicht weiterhilft.

Was ich gut fände, wäre eine Komfort-Befüll-Funktion für die Ländertabelle:

1. Im Upgradescript wird die Ländertabelle automatisch mit einer vordefinierten Liste von Ländernamen (volle Länge, deutsch) befüllt, aber nur dann, wenn die Ländernamen nach Migration der K/L-Länder leer ist. Das ist genau der Zustand nach leerer DB, oder bei einem Upgrade wenn der User keine Länder benutzt hat.
2. Im System-Menü in der Länderverwaltung gibt es zusätzlich einen Punkt "Länderliste einspielen". Dieser offeriert, die aktuelle Länderliste komplett zu löschen und durch eines von drei (optional sechs) vordefinierten Sets zu überschreiben. Das darf natürlich nur gehen, sofern die Länder noch nirgends verwendet wurden, bzw. es dürfen nur die ungenutzten Länder gelöscht werden. Die Sets sind:
   • Alle Länder mit langen, deutschen Namen (z.B. "Deutschland")
   • Alle Länder mit langen, englischen Namen (z.B. "Germany")
   • Alle Länder als offizielle KFZ-Kennzeichen-Abkürzungen (z.B. "D")
   • Optional: die drei Varianten von oben beschränkt auf europäische Länder

Diese Länderlisten gibt es im Internet zur Genüge frei verfügbar (​z.B. hier für deutsche Namen + KFZ-Kennzeichen). Ein wenig Copy&Paste, Scripting, dann hat man daraus schnell diejenigen Listen er

Vorteil ist, dass man bei einer Neuinstallation im Idealfall nichts ändern muss und trotzdem weiterhin die Länder nutzen kann sowie dass man es denjenigen einfach macht, die eben nicht deutsche Ländernamen in voller Länge für den ganzen Globus brauchen oder wollen.

Anhand dieser Liste könnte man sogar beim Upgrade anbieten, diejenigen Einträge, die nicht matchen, auf einen bekannten Eintrag umzustellen. Dann bräuchte man später nicht einmal manuelle Datenbankbereinigung! Wenn du so eine interaktive Bereinigung anbietest, dann wäre mir auch das bei 8. diskutierte Freitextsuchfeld wieder egal.

---

Ich will dich auf keinen Fall schikanieren. Ich versuche, die Qualität von kivitendo zu erhöhen. Was bei euch gut genug für ein paar Kunden ist, ist gilt leider nicht auch sofort für die Allgemeinheit. Gerade Neuinstallationen sind jetzt schon schwer genug für jemanden, der nicht so viel mit kivitendo macht. Daher sollten alle neuen Features, alle Änderungen immer eine möglichst reibungslose Einrichtung im Hinterkopf haben. Und um bestehenden Kunden das Leben nicht unnötig schwer zu machen, darf eben auch nach einem Upgrade das System nicht nerviger zu bedienen sein als vorher. Daher reite ich so auf den Punkten herum.

Replying to m.bunkus@…:

Aus der K/L-Stammdatenmaske direkt Länder anlegen zu dürfen, halte ich nur für eine Krücke, weil das natürlich denjenigen, die keine Rechte auf das Systemmenü haben, immer noch nicht weiterhilft.

Meine Frage zielte auch darauf hin ab, ob man Leuten mit nur Stammdatenrechten trotzdem die Möglichkeit geben kann, auf diesen AM-Code zuzugreifen. Oder ob man diese Funktionalität in diesem Szenario aus AM rausnehmen müßte, ich hab jetzt nicht geschaut, wie das beim Anlegen von Projekten funktioniert.

Was ich gut fände, wäre eine Komfort-Befüll-Funktion für die Ländertabelle:

Ich fände das ehrlich gesagt eher nervig, wenn ich jedesmal, wenn ich ein Land auswählen möchte, erst durch eine lange Liste scrollen müßte, wovon die meisten Mandanten wahrscheinlich 90% nie brauchen. Man könnte sich die am häufigsten benötigten Einträge zwar per Sortierreihenfolge nach oben stellen, aber so das ist auch nicht so ganz schön.
Außerdem sieht man bei einer eigenen Liste auf einen Blick, welche Länder überhaupt in der Datenbank vorkommen.
Für die Leute, die gerne alle Länder in der Liste hätten, wäre eine Auswahl von vordefinierten Listen dann aber in der Tat praktisch.

Wenn du so eine interaktive Bereinigung anbietest, dann wäre mir auch das bei 8. diskutierte Freitextsuchfeld wieder egal.

Ich glaube das ist der Punkte warum wir das bisher anders gesehen haben.
Ich bin implizit davon ausgegangen, daß das Update als Anlass genommen wird endlich mal bei den mehrfachen Einträgen, falls die existieren oder zum ersten Mal auffallen, aufzuräumen, und sich dann jemand hinsetzt und die Länder manuell umstellt. Deshalb war für mich das Freitextsuchfeld auch egal.
Bei dem schon erwähnten Kundenprojekt waren die bestehenden Länder bekannt und es wurde beim Upgradeskript direkt umgestellt, unter Berücksichtigung der Schreibfehler. Für den Standard fand ich den Aufwand, das möglichst intelligent zu machen und alle Fälle abzudecken, ehrlich gesagt zu hoch, deshalb halte ich das manuelle Nachbearbeiten für vertretbar. Und bei sauber gepflegten Ländern wäre auch erst gar keine Nachbearbeitung nötig. Aber du hast ja auch schon Vorschläge für ein Mapping gemacht, bei anderen Umstellungen hat das ja auch gut geklappt.

Daß das keine Schikane ist ist mir klar. Ich finde das derzeitige System aber schlecht und fehleranfällig und das neue System insgesamt besser, selbst mit den angesprochenen Nachteilen.
Ich finde es derzeit insgesamt viel mehr Aufwand, und viel nerviger, wenn man im jetzigen System im Nachhinein Mehrfacheinträge korrigieren und aufräumen muß, als der nervige Extraaufwand unter System die Länderliste zu pflegen. Derzeit besteht bei jedem Anlegen eines neuen Kunden und Lieferanten ein Fehlerpotential bei der Ländereingabe, und das kann auch zu unbemerkten falschen Ergebnissen bei Auswertungen mit Länderfiltern führen, wenn bestimmte Kunden in der Auswertung wegen Tippfehlern vergessen werden. Mit diesem Hintergrund hielt ich den Mehraufwand der Pflege der Länderliste unter System auch für angemessen, Vorschläge wie man das trotzdem benutzerfreundlicher machen kann sind aber natürlich super.

Meine Frage zielte auch darauf hin ab, ob man Leuten mit nur Stammdatenrechten trotzdem die Möglichkeit geben kann, auf diesen AM-Code zuzugreifen.

Auf keinen Fall. Das erschwert die Administration, weil ein Admin dieses Faktum nicht wissen kann. Außerdem läuft das dem initialen Konzept zuwider, das ja gerade darauf ausgelegt ist, dem Benutzer eine eingeschränkte Wahlmöglichkeit zu lassen. Wenn du nun jedem Stammdateneditor das freie Hinzufügen erlaubst, bist du nicht viel besser dran (etwas schon, ja klar).

Mitgelieferte und bereits richtig geschriebene Vorbelegungen sind da viel sinnvoller.

Ich fände das ehrlich gesagt eher nervig, wenn ich jedesmal, wenn ich ein Land auswählen möchte, erst durch eine lange Liste scrollen müßte, wovon die meisten Mandanten wahrscheinlich 90% nie brauchen.

Granted. Daher die von mir aufgeführten optionalen Varianten mit nur den europäischen Kunden. Das sollte 95% all unserer User out of the box abdecken. Wer dann noch in den USA bestellt, fügt die kurz manuell hinzu.

Wir können auch sagen, die europäische Liste ist diejenige, die per Default bei leerer Ländertabelle eingespielt wird. Die EU besteht momentan aus 28 Ländern, was ich für absolut zumutbar und überschaubar halte.

Weiterhin: eine leere Länderliste bei Erstinstallation bekommt von mir ein Veto. Sorry.

Ich bin implizit davon ausgegangen, daß das Update als Anlass genommen wird endlich mal bei den mehrfachen Einträgen, falls die existieren oder zum ersten Mal auffallen, aufzuräumen

Ja dann bietet aber den Usern auch die Möglichkeit, dass sie ihren Mist aufräumen können! "Do it in the database" ist keine Option für 99% aller einfachen User, und selbst bei den Administratoren halte ich den Prozentsatz derjenigen, die mit SQL-Queries nicht umzugehen wissen, für sehr hoch. Abgesehen davon ist die manuelle Eingabe von SQL-Queries extrem nervig und fehleranfällig. Das Bearbeiten einer Spalte country_id z.B. mit phpPGAdmin nach dem Upgrade ist genau so nervig und fehleranfällig, weil derjenige die ganze Zeit zwischen den Tabellen hin- und herspringen muss. Alle Kunden in der Oberfläche anklicken, Sprache ändern, speichern macht die Sache nicht besser.

Vorschlag für Upgradescript für den Fall "es gibt schon Länder in customer/vendor":

• Wahlmöglichkeit zwischen "alle existierenden Länder übernehmen, keine vordefinierte Liste einspielen" (was nur aktuellen Zustand bewahrt, Kunde muss zusehen, wie er das fixt) und "vordefinierte Liste einspielen und zuweisen"
• Wenn "vordefinierte Liste", dann soll der User in dem Moment die einzuspielende Liste auswählen mit Vorbelegung "EU-Staaten, deutsche Ländernamen". Danach:
  • Anzeige aller alten Länder, die es in der vordefinierten Liste nicht gibt
  • Für jeden Eintrag Wahlmöglichkeit aus der vordefinierten Liste
  • Zusätzlich Wahlmöglichkeit für "leere" alte Ländereinträge mit Vorbelegung Deutschland in der jeweilen Variante der vordefinierten Liste ("Deutschland", "Germany" bzw. "D")

Also nicht Anzeige aller Kunden/Lieferanten, sondern nur diejenigen alten Ländereinträge, die sich nicht zuordnen lassen, und davon jedes nur einmal (denke SQL-UNIQUE).

Wie gesagt, wenn es ein solches Mapping beim Upgrade zumindest optional gibt, dann vergiss das Freitextfeld in 8., das ist mir dann nicht mehr wichtig.

Und bei sauber gepflegten Ländern wäre auch erst gar keine Nachbearbeitung nötig.

Sorry, die Realität ist nicht ideal. Ich habe genug Kundenmigrationen mitgemacht (sowohl kivitendo-Upgrades als auch Umstiege von anderen Systemen auf kivitendo) mit übernahme der Altdaten, bei denen so dermaßen viel bereinigt wurde, dass es nicht witzig war.

Der jetzige Stand des Patches mag "etwas besser" sein als der aktuelle Produktivstand, aber er wird unweigerlich dazu führen, dass Bugeinträge zu den von mir bemängelten Punkten kommen werden. Wir verschieben die Lösung damit nur!