> Ich verstehe nicht warum Shopware hier keine Lösung von haus aus anbietet, dieses Problem tritt doch sicherlich bei vielen auf. Ja. Aber in fast so vielen Varianten wie Exemplaren. Soll heißen: Für kaum zwei Nutzer ist das Problem auf exakt die selbe Weise zu lösen. Das bedeutet wieder: ein Programm scheitert entweder in einer Vielzahl von Fällen oder ist so universell, dass es für viele unbedienbar wird. Möglichereise wird es auch sehr langsam, da es "Dinge" tut und Prüfungen vornimmt, die im konkreten Einzelfall nicht gebraucht aber abgearbeitet werden müssen. Da kann man also gleich Skripte für den Einzelfall schreiben. > Außerdem verstehe ich nicht welchen Sinn es macht in der Import Datei die ID der Kategorie zu erwarten, es würde doch nichts dagegen sprechen den Import auch dann zuzulassen, wenn statt der ID der Kategorie der Name der Kategorie in der Import Datei vorhanden ist. Hierzu sollte doch bestimmt eine "best practice" Lösung existieren. Die ID der Kategorie statt die Kategorie selbst in der Waren-Tabelle aufzuführen ist "best practice". Bekannt als "zweite Normalform". Das Problem ist nicht nur, dass es Warenwirtschaftssysteme in allen denkbaren Geschmacksrichtungen (und einer Unmenge von Exportformaten) gibt, sondern dass es mutmaßlich aberhunderte Firmen gibt, die auch nach dem Sprung vom Kleinunternehmen zum einem solchen mit 200 Mitarbeitern mangels a) einer Risikoabschätzung und b) des Mutes zu einer Umstellung allen Ernstes (und im Hinblick auf, das mangels Wahrnehmung nicht bekannte Risiko: "äußerst mutig") die Produktion (und also die Warenwirtschaft!) mit dem "*leistungsfähigem und universell einsetzbarem*" Excel betreiben. **Ich hätte das auch nicht geglaubt wenn ich es nicht zufällig mit eigenen Augen gesehen hätte.** Zum "Umrubeln" würde ich die Kategorien in ein kleines Skriptlein einlesen, so dass etwas wie ~~~js categories = [ { 'Hosen' : 101 }, { 'Jacken': 102 } ]; ~~~ entsteht und sodann die eigentliche Datentabelle hernehmen und die Kategorien entsprechend "umtauschen". Gibt es eine unbekannte Kategorie müsste man eine Entscheidung anbieten, die unbekannte Kategorie entweder in der Datenbank einzutragen (und sich die ID rausgeben zu lassen) oder aber zu einer bekannten Kategorie zu ändern. Die Daten werden ja oft von Menschen erfasst und die vertippen sich... Wahrscheinlich würde ich sogar gleich noch ein paar Tests oder Funktionen einbauen, nehmen wir z.B. das Umrubeln der Kodierung. Dann muss man sowas auch so gestalten, dass es "idiotensicher" ist. Bei (noch) nicht behebbaren Fehlern also mit den Fehlern die Rufnummer von demjenigen ausgeben, der entweder weiß was zu tun ist oder das rausfinden kann. Hin und wieder (wenn die Rufnummer mehr als 4 Stellen hat) ist dann ein Rahmenvertrag nötig.

> Ich verstehe nicht warum Shopware hier keine Lösung von haus aus anbietet, dieses Problem tritt doch sicherlich bei vielen auf. Ja. Aber in fast so vielen Varianten wie Exemplaren. Soll heißen: Für kaum zwei Nutzer ist das Problem auf exakt die selbe Weise zu lösen. Das bedeutet wieder: ein Programm scheitert entweder in einer Vielzahl von Fällen oder ist so universell, dass es für viele unbedienbar wird. Möglichereise wird es auch sehr langsam, da es "Dinge" tut und Prüfungen vornimmt, die nicht gebraucht werden. Da kann man also gleich Skripte für den Einzelfall schreiben. > Außerdem verstehe ich nicht welchen Sinn es macht in der Import Datei die ID der Kategorie zu erwarten, es würde doch nichts dagegen sprechen den Import auch dann zuzulassen, wenn statt der ID der Kategorie der Name der Kategorie in der Import Datei vorhanden ist. Hierzu sollte doch bestimmt eine "best practice" Lösung existieren. Die ID der Kategorie statt die Kategorie selbst in der Waren-Tabelle aufzuführen ist "best practice". Bekannt als "zweite Normalform". Das Problem ist nicht nur, dass es Warenwirtschaftssysteme in allen denkbaren Geschmacksrichtungen (und einer Unmenge von Exportformaten) gibt, sondern dass es mutmaßlich aberhunderte Firmen gibt, die auch nach dem Sprung vom Kleinunternehmen zum einem solchen mit 200 Mitarbeitern mangels a) einer Risikoabschätzung und b) des Mutes zu einer Umstellung allen Ernstes (und im Hinblick auf, das mangels Wahrnehmung nicht bekannte Risiko: "äußerst mutig") die Produktion (und also die Warenwirtschaft!) mit dem "*leistungsfähigem und universell einsetzbarem*" Excel betreiben. **Ich hätte das auch nicht geglaubt wenn ich es nicht zufällig mit eigenen Augen gesehen hätte.** Zum "Umrubeln" würde ich die Kategorien in ein kleines Skriptlein einlesen, so dass etwas wie ~~~js categories = [ { 'Hosen' : 101 }, { 'Jacken': 102 } ]; ~~~ entsteht und sodann die eigentliche Datentabelle hernehmen und die Kategorien entsprechend "umtauschen". Gibt es eine unbekannte Kategorie müsste man eine Entscheidung anbieten, die unbekannte Kategorie entweder in der Datenbank einzutragen (und sich die ID rausgeben zu lassen) oder aber zu einer bekannten Kategorie zu ändern. Die Daten werden ja oft von Menschen erfasst und die vertippen sich... Wahrscheinlich würde ich sogar gleich noch ein paar Tests oder Funktionen einbauen, nehmen wir z.B. das Umrubeln der Kodierung. Dann muss man sowas auch so gestalten, dass es "idiotensicher" ist. Bei (noch) nicht behebbaren Fehlern also mit den Fehlern die Rufnummer von demjenigen ausgeben, der entweder weiß was zu tun ist oder das rausfinden kann. Hin und wieder (wenn die Rufnummer mehr als 4 Stellen hat) ist dann ein Rahmenvertrag nötig.

> Ich verstehe nicht warum Shopware hier keine Lösung von haus aus anbietet, dieses Problem tritt doch sicherlich bei vielen auf. Ja. Aber in fast so vielen Varianten wie Exemplaren. Soll heißen: Für kaum zwei Nutzer ist das Problem auf exakt die selbe Weise zu lösen. Das bedeutet wieder: ein Programm scheitert entweder in einer Vielzahl von Fällen oder ist so universell, dass es für viele unbedienbar wird. Möglichereise wird es auch sehr langsam, da es "Dinge" tut und Prüfungen vornimmt, die nicht gebraucht werden. Da kann man also gleich Skripte für den Einzelfall schreiben. > Außerdem verstehe ich nicht welchen Sinn es macht in der Import Datei die ID der Kategorie zu erwarten, es würde doch nichts dagegen sprechen den Import auch dann zuzulassen, wenn statt der ID der Kategorie der Name der Kategorie in der Import Datei vorhanden ist. Hierzu sollte doch bestimmt eine "best practice" Lösung existieren. Die ID der Kategorie statt die Kategorie selbst in der Waren-Tabelle aufzuführen ist "best practice". Bekannt als "zweite Normalform". Das Problem ist nicht nur, dass es Warenwirtschaftssysteme in allen denkbaren Geschmacksrichtungen (und einer Unmenge von Exportformaten) gibt, sondern dass es mutmaßlich aberhunderte Firmen gibt, die auch nach dem Sprung vom Kleinunternehmen zum einem solchen mit 200 Mitarbeitern mangels a) einer Risikoabschätzung und b) des Mutes zu einer Umstellung allen Ernstes (und im Hinblick auf, das mangels Wahrnehmung nicht bekannte Risiko: "äußerst mutig") die Produktion (und also die Warenwirtschaft!) mit dem "*leistungsfähigem und universell einsetzbarem*" Excel betreiben. **Ich hätte das auch nicht geglaubt wenn ich es nicht zufällig mit eigenen Augen gesehen hätte.** Zum "Umrubeln" würde ich die Kategorien in ein kleines Skriptlein einlesen, so dass etwas wie ~~~js kategories = [ { 'Hosen' : 101 }, { 'Jacken': 102 } ]; ~~~ entsteht und sodann die eigentliche Datentabelle hernehmen und die Kategorien entsprechend "umtauschen". Gibt es eine unbekannte Kategorie müsste man eine Entscheidung anbieten, die unbekannte Kategorie entweder in der Datenbank einzutragen (und sich die ID rausgeben zu lassen) oder aber zu einer bekannten Kategorie zu ändern. Die Daten werden ja oft von Menschen erfasst und die vertippen sich... Wahrscheinlich würde ich sogar gleich noch ein paar Tests oder Funktionen einbauen, nehmen wir z.B. das Umrubeln der Kodierung. Dann muss man sowas auch so gestalten, dass es "idiotensicher" ist. Bei (noch) nicht behebbaren Fehlern also mit den Fehlern die Rufnummer von demjenigen ausgeben, der entweder weiß was zu tun ist oder das rausfinden kann. Hin und wieder (wenn die Rufnummer mehr als 4 Stellen hat) ist dann ein Rahmenvertrag nötig.

> Ich verstehe nicht warum Shopware hier keine Lösung von haus aus anbietet, dieses Problem tritt doch sicherlich bei vielen auf. Ja. Aber in fast so vielen Varianten wie Exemplaren. Soll heißen: Für kaum zwei Nutzer ist das Problem auf exakt die selbe Weise zu lösen. Das bedeutet wieder: ein Programm scheitert entweder in einer Vielzahl von Fällen oder ist so universell, dass es für viele unbedienbar wird. Möglichereise wird es auch sehr langsam, da es "Dinge" tut und Prüfungen vornimmt, die nicht gebraucht werden. Da kann man also gleich Skripte für den Einzelfall schreiben. > Außerdem verstehe ich nicht welchen Sinn es macht in der Import Datei die ID der Kategorie zu erwarten, es würde doch nichts dagegen sprechen den Import auch dann zuzulassen, wenn statt der ID der Kategorie der Name der Kategorie in der Import Datei vorhanden ist. Hierzu sollte doch bestimmt eine "best practice" Lösung existieren. Die ID der Kategorie statt die Kategorie selbst in der Waren-Tabelle aufzuführen ist "best practice". Bekannt als "zweite Normalform". Das Problem ist nicht nur, dass es Warenwirtschaftssysteme in allen denkbaren Geschmacksrichtungen (und einer Unmenge von Exportformaten) gibt, sondern dass es mutmaßlich aberhunderte Firmen gibt, die auch nach dem Sprung vom Kleinunternehmen zum einem solchen mit 200 Mitarbeitern mangels a) einer Risikoabschätzung und b) des Mutes zu einer Umstellung allen Ernstes (und im Hinblick auf, das mangels Wahrnehmung nicht bekannte Risiko: "äußerst mutig") die Produktion (und also die Warenwirtschaft!) mit dem "*leistungsfähigem und universell einsetzbarem*" Excel betreiben. **Ich hätte das auch nicht geglaubt wenn ich es nicht zufällig mit eigenen Augen gesehen hätte.** Zum "Umrubeln" würde ich die Kategorien in ein kleines Skriptlein einlesen, so dass etwas wie ~~~js kategories = [ { 'Hosen' : 101 }, { 'Jacken': 102 } ] ~~~ entsteht und sodann die eigentliche Datentabelle hernehmen und die Kategorien entsprechend "umtauschen". Gibt es eine unbekannte Kategorie müsste man eine Entscheidung anbieten, die unbekannte Kategorie entweder in der Datenbank einzutragen (und sich die ID rausgeben zu lassen) oder aber zu einer bekannten Kategorie zu ändern. Die Daten werden ja oft von Menschen erfasst und die vertippen sich... Wahrscheinlich würde ich sogar gleich noch ein paar Tests oder Funktionen einbauen, nehmen wir z.B. das Umrubeln der Kodierung. Dann muss man sowas auch so gestalten, dass es "idiotensicher" ist. Bei (noch) nicht behebbaren Fehlern also mit den Fehlern die Rufnummer von demjenigen ausgeben, der entweder weiß was zu tun ist oder das rausfinden kann. Hin und wieder (wenn die Rufnummer mehr als 4 Stellen hat) ist dann ein Rahmenvertrag nötig.