(erledigt) Bug oder Feature? Categorie-Name und Ziffern mit führenden Nullen

[Druckfehler]

Hallo zusammen,

bevor ich das Team mit einem Fehler konfrontiere der Absicht ist, frage ich zuerst mal lieber hier nach.

Ich habe eine Roh-Datenbank umkonvertiert zu CSV für den Import über das Webfrontend, deren Kategorie-Namen (Warengruppen) 3-stellige Ziffern mit führenden Nullen beinhalten. Diese werden auch ordentlich eingetragen, Fehlermeldungen erscheinen nicht. Importiere ich nun die Artikeldaten mit den entsprechenden Warengruppenkennzeichnungen, ergibt das auch kein Problem, jedoch werden weitere Warengruppen mit dem selben Namen angelegt. Jeder Artikel hat dann offenbar seine eigene Warengruppe (Kategorie).

Ich halte das für einen Fehler, irgendwo im System selbst. Denn verändere ich die Kennzeichnung der Kategorie in der Umkonvertierung (Kategorie.csv und Artikel.csv) mit einem führenden Buchstaben, funktioniert der Import selbst als auch der Bezug zwischen Warengruppe <-> Artikel perfekt.

 

Also, ist das ein Bug oder ein gewolltes Feature?

Edited February 21, 2020 by Druckfehler (see edit history)

[Druckfehler]

Verflixt .. ich habe vergessen die Version zu erwähnen, Sorry.

1.7.6.3

[rictools]

Also ich komme da nicht mit, was heißt "beinhalten"? Was sind "Warengruppenkennzeichnungen"?

[Druckfehler]

Auszüge aus dem zu importierenden CSVs

cat.csv und artikel.csv die so nicht funktionieren (zum selbst testen)

851;0;851;;0;;;;;;
628;0;628;;0;;;;;;
016;0;011;;0;;;;;;
611;0;611;;0;;;;;;
820;0;820;;0;;;;;;

99979;0;DP KROMB.WEIZEN 60X5X0,5L +GLAS           ;011;000299,40;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99979;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99980;0;HACK.PSCH.KEL.1417BV  0,50                ;011;000000,89;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99980;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99981;0;HACK.PSCH.KELLERB. 1417 BV 20X0,50        ;011;000016,99;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99981;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99982;0;HACK.PSCH.KELLERB. 1417 BV 20X0,50        ;011;000016,99;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99982;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99983;0;DEKO/DOSE B/HORNKLEESAME                  ;851;000001,69;1;;0;;;;;;;;000843100;;;;;;;;;;100;1;10;;;;;;;;;;;;99983;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99984;0;Dekor-Dose Korianderblat                  ;851;000001,69;1;;0;;;;;;;;000843100;;;;;;;;;;100;1;10;;;;;;;;;;;;99984;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0

So funktioniert es

851;0;A851;;0;;;;;;
628;0;A628;;0;;;;;;
016;0;A011;;0;;;;;;
611;0;A611;;0;;;;;;
820;0;A820;;0;;;;;;

99979;0;DP KROMB.WEIZEN 60X5X0,5L +GLAS           ;A011;000299,40;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99979;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99980;0;HACK.PSCH.KEL.1417BV  0,50                ;A011;000000,89;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99980;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99981;0;HACK.PSCH.KELLERB. 1417 BV 20X0,50        ;A011;000016,99;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99981;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99982;0;HACK.PSCH.KELLERB. 1417 BV 20X0,50        ;A011;000016,99;1;;0;;;;;;;;000824200;;;;;;;;;;100;1;10;;;;;;;;;;;;99982;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99983;0;DEKO/DOSE B/HORNKLEESAME                  ;A851;000001,69;1;;0;;;;;;;;000843100;;;;;;;;;;100;1;10;;;;;;;;;;;;99983;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0
99984;0;Dekor-Dose Korianderblat                  ;A851;000001,69;1;;0;;;;;;;;000843100;;;;;;;;;;100;1;10;;;;;;;;;;;;99984;;;0;;;1;;;;;;;;;;;;;;;;0;;;;0

Ich hoffe so ists besser. ;o)

[rictools]

Ich sehe da keine, wie du schriebst "Kategorie-Namen (Warengruppen) 3-stellige Ziffern mit führenden Nullen beinhalten", sondern die einzeln stehende 011 wobei ich natürlich nicht weiß um welches Feld es sich da handelt. Daß eine ID nicht mit führender Null funktioniert kann ich mir vorstellen, die müßte sich aber in einer Tabellenkalkulation sehr einfach entfernen lassen.

[Druckfehler]

4 minutes ago, rictools said:

Daß eine ID nicht mit führender Null funktioniert kann ich mir vorstellen,

Nicht wenn es sich eigentlich um ein Textfeld handelt. Denn im Normalfall werden da ja "Worte" (Buchstaben) verwendet. Deswegen sollte eine führende NULL (011 besitzt eine), keine Probleme bereiten. Es sei denn die Programmierung lässt hier etwas zu wünschen übrig.

5 minutes ago, rictools said:

die müßte sich aber in einer Tabellenkalkulation sehr einfach entfernen lassen.

Eine Tabellenkalkulation ist, wie der Name schon sagt, eine Tabellenkalkulation. Und nein, ein entfernen der führenden NULL ist nicht möglich. Das hat technische als auch organisatorische Gründe, die eine Veränderung zum Datensatzursprung nicht zulassen.

Danke für die Hilfe.

[wmunich]

Ist sicherlich ein Bug, womöglich prüft PS nach category id vor category name und kommt mit den führenden Ziffern einfach nicht zurecht 😉

Wobei die führenden Ziffern etwas ungewönlich sind ... Teilenummern? Kreis?

Edited February 20, 2020 by wmunich (see edit history)

[Druckfehler]

9 hours ago, wmunich said:

Wobei die führenden Ziffern etwas ungewönlich sind ... Teilenummern? Kreis?

Ich würde eher historische Ursachen vermuten. Es scheint als ob die UR-Datenbank mal auf einer AS400 entwickelt worden ist und immer nur auf das jeweils neue System portiert wurde. Da ich das eigentliche System jedoch nicht anfassen möchte/darf, die Mitarbeiter aber die führende NULL gewöhnt sind und mein System "nur" eine Parallel-Datenbank ist, muss ich das halt so hinnehmen. Das heißt, einen Buchstaben davor setzen, das bekommen die hin den Buchstaben im Kopf zu entfernen. Etwas hinzufügen, zu einer 11 eine Null beispielsweise, so etwas gestaltet sich mehr als schwierig. Menschen sind halt so.

9 hours ago, wmunich said:

category id vor category name

Ja die Vermutung liegt nahe, dass die ID eine wesentliche Rolle spielt. Tut sie nur nicht, wenn ich mir das gesamte Konstrukt so betrachte.

An der Stelle behaupte ich dann einfach mal, das Problem ist weder Bug noch Feature, es ist einfach so. Mal sehen ob ich eine adäquate Lösung finde. ;o)

 

Danke noch mal.

[rictools]

Ich blicke das immer noch nicht, die Kategoriebezeichnung (um die es sich wenn ich dich richtig verstehe handelt) ist doch nicht für die Mitarbeiter da sondern für die Kunden und was können die mit einer Kategorie namens 011, 11 oder A011 anfangen?

[Druckfehler]

5 minutes ago, rictools said:

Ich blicke das immer noch nicht

Gut, dann ausführlich.

Es gibt eine sogenannte "Datensatzbeschreibung" die folgendermaßen aussieht:

000000000001167400839105090700000479SEITENB TROPIC MUESLI                      BT 43881109000500000000000000002772
000000100090931426013902361500000399EIS KNOEDEL SCHWARZW.KIR                   PG 43881109000600000000009093102422
+--------1----++---2-------++3-----++------------4---------5---------6-------++7-++------8+--++---9---------10+--+
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234

001-015 DBArtikelnummer
016-028 Referenznummer 
029-036 VK Preis 6 Vorkomma und 2 Nachkommastellen
037-068 Artikelbezeichnung
069-072 Gebindeart
073-080 Lieferantennummer
081-084 Gebindeinhalt
085-100 unbenutzt
101-104 Warengruppe

Der Warengruppe sind die einzelnen Artikelnummern bzw. die Artikelbezeichnung zugeordnet. Diese (internen) Warengruppen sind dann im Prestashop die entsprechend zugeordneten "Kategorien", die dann auch der Kunde angezeigt bekommt. ModRewrite ermöglicht ja das schnöde umbenennen, so dass die interne Warengruppe nach außen nicht mal zu sehen sein muss.

Sucht nun Mitarbeiter nur innerhalb der schon geläufigen Warengruppe, kann er das tun. Denn einen Buchstaben voran stellen, das können die. Dieser als Beispiel bezeichnete "011" nur ein "A" voran zu setzen ist also kein Problem. Überfordert sind die aber mit einer "11". Sie wissen schlicht nichts damit anzufangen, weil wie kann das sein, dass alle anderen 3-stellig sind und diese eine nur 2-stellig. Das verwirrt die. Bitte frage nicht nach der Ursache, es ist einfach so und ich muss das hinnehmen.

Ich konvertiere nun lediglich den Datensatz, der immerhin aus knapp 190.000 Zeilen besteht, in ein lesbares Format für Prestashop um.

Mit etwas Kenntnis von RegularExpressions sieht das dann zwar etwas "krypisch" aus,  aber mit Hilfe von PHP nehme ich den Ursprungsdatensatz dann so auseinander.

^([\w\W]{15})([\w\W]{13})([\w\W]{8})([\w\W]{42})([\w\W]{4})([\w\W]{9})([\w\W]{3})([\w\W]{17})([\w\W]{3})

Im Prinzip sind wir seit 2 Posts eigentlich schon Off-Topic. ;o)

[rictools]

Wie das dann zu einer brauchbaren Anzeige im Shop führt ist mir unklar, z. B. die stark abgekürzte Artikelbezeichnung (wie auf dem Kassenzettel im Supermarkt), auch die Warengruppen müssen ja nicht unbedingt einer sinnvollen Shopstruktur entsprechen (und wie du dann zu einer sinnvollen Bezeichnung im Shop kommst ...?).

[Druckfehler]

3 hours ago, rictools said:

Wie das dann zu einer brauchbaren Anzeige im Shop führt [ ... ]

Du hast noch nie Datenbanken konvertiert, oder?

1. Wenn Du einen Artikelstamm mit mehreren Zehntausend Artikeln hast, wirst Du den benutzen wollen, da ein Neuanlegen viel zu umständlich ist.
2. Eine "Artikelvorlage", der dann lediglich nur Ergänzungen/Änderungen hinzuzufügen sind, die man "später" freischalten kann, ist dann mit dem Import der bestehenden Daten vorhanden und man kann - man möge mir das Wort verzeihen - jeden Deppen dran setzen, der aus "Marga Kuhbut Gesalz" ein "Margarine, Kuhbutter, Gesalzen" daraus machen kann.
3. Eine "Sinnvolle Shopstruktur" ist immer Ansichtssache und leider viel zu oft von dem abhängig, was man in den meisten Fällen schon vorfindet.
4. Eine vorhandene Datenbank, zu der es eine weitere, parallele Datenbank mit Prestashop geben soll, aus der Daten mit der Original-Datenbank hin und her abgeglichen werden _müssen_, da sollte man sich schon an ein Regelwerk halten das da lautet: "Strukturen sind so weit es geht zu übernehmen und den Umständen und Möglichkeiten entsprechend anzupassen."
5. Ich kann die Masterdatenbank _NICHT_ verändern.
6. Mit dem Onlineshop bin ich schon recht frei in meiner Gestaltung. Also was Artikelbezeichnungen betrifft, Kategoriebeschreibungen, Artikelstammdaten, Lieferketten usw. Indizes zur - Masterdatenbank - sollten schon erhalten bleiben.
7. Es gibt Dinge, denen muss man sich einfach unterordnen und deswegen einfach akzeptieren.
8. Ergibt sich daraus eine Neustrukturierung weil man erkannt hat, die alte Datenbank ist viel zu umständlich - na hee  super - dann kann ich rufen: "Hier schaut mal, ich hätte da etwas fertiges".

Bitte, ich habe versucht etwas zu erklären, was hier jetzt absolut OffTopic ist. Nimm es bitte hin, es gibt Dinge die sind einfach so. Was für Dich nicht sinnvoll zu sein scheint, muss nichts mit der Realität und Praxis zu tun haben. Denn die Frage war schlicht eine andere. Bevor ich jetzt ungehalten in meinen üblichen Zynismus verfalle, beende ich diese Diskussion an der Stelle.