Artikelgruppen erfassen

Community German Community
1

Ich erfasse gerade Artikelgruppen von Hand.

Es handelt sich um einen Kategorienbaum, der einem Katalog nachempfunden ist. Dort erscheint er als mehrstufige Hierarchie im Inhaltsverzeichnis, wovon ich diejenigen Kategorien, die Artikel enthalten (nicht z.B. "Informationen, Bestellhinweise o.ä.), übernehme für die Lagerverwaltung.

Nun stelle ich fest, dass ich verschiedenen Artikelgruppen Namen nicht zweimal zuweisen kann. Manche Namen kommen nämlich als Untergruppe verschiedener Parents aka “Übergeordnete Artikelgruppe” vor, was im Katalogkontext bzw. im fachlichen Kontext (Breadcrumbs, die zu jeweils verschiedenen Artikeln führen) absolut sinnvoll ist.

Es handelt sich im Prinzip ja um reine Bezeichner für den Mensch, da die Baumelemente über “technische IDs” verwaltet werden (zumindest verwaltet werden könnten). Kann irgendwo konfiguriert werden, dass Namen doppelt vorkommen dürfen?

Weiterhin stelle ich fest, dass die Untergruppen jeweils alfabetisch sortiert werden. Im Katalog aber, dem der Baum nachempfunden sein soll (und natürlich in den Köpfen aller Mitarbeiter), ist eine andere Reihenfolge vorhanden. Gibt es eine Möglichkeit, die abzubilden, also die alfabetische Sortierung nicht automatisch (und ungefragt) anzuwenden? Anscheinend kann eine Gruppe auch nicht innerhalb ihrer siblings (Untergruppen derselben übergeordneten Artikelgruppe) verschoben werden. Gibt es für sowas eine Einstellung, und eine Verschiebemöglichkeit (Greiferfläche zum Verschieben, ähnlich wie bei der Workspace-Anpassung)?

Außerdem ist die Eingabe nur über die Tastatur etwas langwierig. Ständig muss die Hand zwischen Tastatur und Maus wechseln, sodass man nicht einfach die Liste runtertippen kann. Was fehlt bzw. was ich nicht gefunden habe: Tastaturkürzel für “Unterpunkt hinzufügen”, und auch weitere zum Navigieren (Beispiel: im Windows Explorer z.B. kann man alles von der Tastatur her machen, ohne Maus), oder eins für “weiteren Unterpunkt hinzufügen” (gleicher übergeordneter Artikelgruppe hinzufügen).

  1. Will ich zu viel,
  2. weiß ich die schon existierenden Antworten bloß noch nicht, oder
  3. gibt es diese Produktivitäts- und Anpassungenhilfen (noch) nicht?
2

Hi,
es gibt tatsächlich gewisse Einschränkungen, da der name der Item Group (item_group_name) im Standard auch der Schlüssel der Datenbanktabelle ist und daher unique sein muss.
Wir haben auch einen externen Baum eingelesen und das umgangen, in dem wir eine eindeutige ID der Warengruppe angehängt haben. Sieht dann etwa so aus:

image
image410×744 36.8 KB

Ist jetzt nur eine Idee, sicher kann man das auch durch Änderungen am Doctype lösen. Wenn du diese ID aber vorweg platzieren würdest, könntest du ggf. auch deine Sortierung steuern.

Wir haben den Baum übrigens über ein Python Script importiert.

Bzgl. Keyboard Shortcuts: Im “Hilfe” Menü gibts einen Link zu den aktiven Shortcurts:

image

image
image589×557 33.5 KB

3

In der DB gibt es ja gewisse Felder, und zwar insbesondere:

name
item_group_name
parent_item_group

Wenn jetzt davon die für die Baumreferenz genutzen mit beliebigem Kram (z.B. GUID) gefüllt werden, aber das Angezeigte als mein User-Readable-String gesetzt werden kann, lässt sich das Problem lösen. Nicht jedoch, wenn der User-Readable-String wiederum als Referenz für den internen Baumaufbau genutzt wird.
Keine Ahnung, was davon jetzt Sache ist. Muss ich wohl entweder ausprobieren oder an die Quelle gehen.
UI ist dann noch das nächste Thema. Über API könnte ich alles einstellen, aber wäre ja schöner™, wenn die mitgebrachte UI sowas auch für Ottonormaluser ermöglichte (für spätere Änderungen).

MariaDB [_6047ff7eb4c5b1e2]> describe `tabItem Group`;
+-------------------+--------------+------+-----+---------+-------+
| Field             | Type         | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+---------+-------+
| name              | varchar(140) | NO   | PRI | NULL    |       |
| creation          | datetime(6)  | YES  |     | NULL    |       |
| modified          | datetime(6)  | YES  | MUL | NULL    |       |
| modified_by       | varchar(140) | YES  |     | NULL    |       |
| owner             | varchar(140) | YES  |     | NULL    |       |
| docstatus         | int(1)       | NO   |     | 0       |       |
| idx               | int(8)       | NO   |     | 0       |       |
| item_group_name   | varchar(140) | YES  | UNI | NULL    |       |
| parent_item_group | varchar(140) | YES  |     | NULL    |       |
| is_group          | int(1)       | NO   |     | 0       |       |
| image             | text         | YES  |     | NULL    |       |
| lft               | int(11)      | NO   | MUL | 0       |       |
| old_parent        | varchar(140) | YES  |     | NULL    |       |
| rgt               | int(11)      | NO   | MUL | 0       |       |
| _user_tags        | text         | YES  |     | NULL    |       |
| _comments         | text         | YES  |     | NULL    |       |
| _assign           | text         | YES  |     | NULL    |       |
| _liked_by         | text         | YES  |     | NULL    |       |
+-------------------+--------------+------+-----+---------+-------+
18 rows in set (0,001 sec)
4

Im Export wird der Baum so angeboten:

Item Group		
ID	Name der Artikelgruppe	Übergeordnete Artikelgruppe
name	item_group_name	parent_item_group
Yes	Yes	No
Data	Data	Link
		Valid Item Group
		
"All Item Groups"	All Item Groups	
"Artikel"	Artikel	All Item Groups
"Fachbedarf"	Fachbedarf	Artikel
"Ausrüstung"	Ausrüstung	Fachbedarf
"Behausungen"	Behausungen	Fachbedarf
"Ernte"	Ernte	Fachbedarf
"Füttern"	Füttern	Fachbedarf
5

Wenn ich es richtig sehe, ist die Einschränkung aufgrund der Umleitung des angezeigten Titel auf das Feld item_group_name durch die Benennungsregel:

field:item_group_name

entstanden.
Nun ist aber name der Primärschlüssel, also definitionsgemäß “UNI”, und item_group_name ist ZUSÄTZLICH als UNI festgelegt.

Also handelt es sich um eine überflüssige zweifache Einschränkung, die auf zwei verschiedenen Feldern vorgenommen wird, obwohl eine einfache Einschränkungen, nämlich die des Primärfelds reichen würde.

Sicherlich ist das historisch gewachsen, als der Typ “lineare Tabelle” als Zusatzfunktion “Baumstruktur” rangeklatscht bekam, und dabei nicht gleichzeitig komplett eine rein interne Baumverlinkung mittels willkürlicher (zufälliger oder UUID) IDs eingeführt wurde.

Das ließe sich wohl ändern und mit einem Migrations-Patch für alle lösen.

Für so einen PR bin ich allerdings nicht eingearbeitet, und für einen so tiefen Eingriff in die Baum-Extension sind sicher einige Augenpaare und Ingenieure als Kontrolle nötig.

Ein idx Feld ist ja auch schon vorhanden, keine Ahnung, ob das für den Baum genutzt werden kann, um die Zwangsalfabetisierung loszuwerden, oder ob der schon für andere Anwendungsfälle gebraucht und nicht für eine Baumstruktur zweitgenutzt werden kann.

6

Hier sind ein paar Einblicke (ohne Anspruch auf Vollständigkeit) in die Entstehung bzw. Nutzung dieser Struktur:

Create Tree View and a Tree Browser for any DocType - Frappe Framework / App Development - Frappe Forum

7

Ich vermute, wir haben es hier sowieso mit zwei software-archäologisch nachweislichen Veränderungen zu tun:
Index => Namensfeldumleitung
Tabelle => Baum.

Ein Problem für Änderungen ist, dass diese Veränderungen auch vom Nutzer dadurch nachvollzogen werden können, dass man “Is Tree” an- und abschalten kann, und gleichzeitig kann man die Namensumleitung auf ein beliebiges Feld nachträglich wählen bzw. abwählen.

Die nachträglichen Änderungen des DocFields haben alte Benennungstechniken weitergenutzt, die man in einem Baum eben anders nutzen möchte, insbesondere: vor dem Nutzer verbergen möchte.

Somit zeigt sich vielleicht eine einfache Lösung für das Baumbenennungsproblem:
=> Als Titel einfach ein neues Feld nehmen, das man der Struktur hinzufügt.
Dann können die Baumverlinkungsfelder relativ beliebig gewählt werden (z.B. zufällige Hash-Stücke, oder “alte” Namen, o.ä., was halt gerade zur Hand ist und praktisch ist).

Muss ich wohl mal testen. WIP

8

Gute Idee, danke!

Ein Editieren dürfte damit aber noch umständlich bleiben, wenn die UI nicht eng umschlungen mit der Baumstruktur mitläuft.

Wofür ist eigentlich das Feld old_parent? (Ist bei mir überall = parent_item_group.)

9

Ich habe ein paar weitere Sachen herausgefunden:

=> “Die Reihenfolge der Kinder eines Knotens bleibt erhalten.”

Also ist das Problem der zwangsalphabetisierten Reihenfolge kein Grundsätzliches der verwendeten algorithmischen Struktur.

Auf der WP-Seite ist auch die Logik für “Nested Sets” beschrieben, mit denen die Hierarchie von Bäumen in frappe gebaut ist.

Wenn ich es richtig verstanden (meine Kenntnis des Framework-Codes ist lückenhaft) habe, wird die Reihenfolge der Children der Doctype-Ergänzung für Bäume an dieser Stelle durch das Framework zwangsalphabetisiert:

Im Prinzip müsste es möglich sein, durch eine allein auf die DB zugreifende Logik, die nur die Felder lft und rgt bearbeitet, die Reihenfolge nach Wunsch zu gestalten.

Ob bzw. durch welche UI-Bedienklicks das dann wieder erneut alphabetisiert würde, ist mir momentan nicht klar. Das ließe sich aber abstellen, z. B. durch: Overloading der Methode oder direkte Verbesserung des Frameworks? So oder so, möglich dürfte das sein, und vermutlich ohne allzu großen Aufwand.

Mit anderen Worten, UX-mäßig könnte man sich kleine Greiferflächen o.ä. vorstellen, mit denen die Einträge nach oben oder unten verschoben werden.

Ggf. könnte man durch ein weiteres Setting im Doctype eine Zwangsalphabetisierung von Baum-Children wieder erzwingen, d. h. als Kompatibilitäts-Einstellung für legacy-Anwendungen.