Import von "Eigene Felder" quälend umständlich

[jendris]

Hallo,

wir möchten unsere Artikeldatensätze per Ameise importieren.
Der csv. Datensatz enthält alle notwendigen Artikeldaten.
Diese werden über die Funktion "Artikeldaten" in der Ameise importiert.
Ein weiterer Import dieses Datensatzes wäre notwendig, um die eigenen Felder zu importieren.

Dies ist so aber nicht möglich, da man für die eigenen Felder eine andere Importstruktur benötigt.
Der Aufbau ist mir auch klar und logisch, nur muß ich nun schauen, wie ich meinen ursprünglichen Datensatz auseinander gefriemelt bekomme.
Alles 10 "eigenen Felder" stehen in einem Datensatz.
Ich muß nun für jeden Artikel 10 Datensätze haben, um die Import Funktion nutzen zu können.
Hat jemand eine Idee, wie man das zügig hinbekommt? Excel oder Access?

Eine weitere Variante wäre sicher, jedes eigene Feld einzeln zu importieren, das würde aber bei 10 Feldern auch 10 Import nach sich ziehen.

Am einfachsten wäre es gewesen, der Import würde von der Struktur her identisch mit dem Artikeldatenimport sein.

 

[Thomas Lisson]

AW: Import von "Eigene Felder" quälend umständlich

hi,

Eine weitere Variante wäre sicher, jedes eigene Feld einzeln zu importieren, das würde aber bei 10 Feldern auch 10 Import nach sich ziehen.

Wo ist denn das Problem das zu tun? Das geht doch fix und es ist einmaliger Aufwand. Nach einem Import 1 Feld anders mappen und erneut importieren - kann man doch super nebenbei machen.

 

[jendris]

AW: Import von "Eigene Felder" quälend umständlich

Ich habe mir das mit der Batch Datei und dem Aufgabenplaner gerade mal in der Wiki durchgelesen.
Damit ist mein Problem gelöst. Ich danke Dir.

 

[jendris]

AW: Import von "Eigene Felder" quälend umständlich

Eine weitere Variante wäre sicher, jedes eigene Feld einzeln zu importieren, das würde aber bei 10 Feldern auch 10 Import nach sich ziehen.

So wie ich das nun sehe, ist auch das nicht möglich, jedenfalls nicht mit dem Artikeldatensatz den ich importieren möchte.
Der Grund ist, daß der Freifeldname in dem Artikeldatensatz fehlt.

Es handelt sich um eine Lieferantendatei, und mir geht es darum, diese möglichst unkompliziert importieren zu können.
Durch die unterschiedlichen Importstrukturen ist es aber wohl doch notwendig, diese nachzubearbeiten, und das so oft, wie man "eigene Felder" als Anzahl hat.

Vielleicht übersehe ich auch einfach nur etwas ???

 

[jendris]

AW: Import von "Eigene Felder" quälend umständlich

Hier mein Verbesserungsvorschlag für den Import der "eigenen Felder":
Bitte die Möglichkeit einbauen, "Standardwerte" anzugeben.

 

[neimles]

AW: Import von "Eigene Felder" quälend umständlich

hi,

Wo ist denn das Problem das zu tun? Das geht doch fix und es ist einmaliger Aufwand. Nach einem Import 1 Feld anders mappen und erneut importieren - kann man doch super nebenbei machen.

Hallo Thomas!

Das ist ein riesiges Problem, wenn man laufend Artikel neu importieren muss und für Amazon in 5 Sprachen die Bullet Points, Keywords & Browse Nodes importieren muss (das sind 12 Felder x 5 Sprachen = 60 Importe).

Ich kann nicht für jeden Artikel den ich neu importiere 60 Importe machen bzw. die Daten manuell in der Wawi pflegen.

Es wäre wirklich toll, wenn die Importstruktur gleich wäre wie bei den anderen Daten, also "Feldwertname" als Überschrift und "Feldwert" als Werte. Kann ja auch im Feldwertname einen Präfix haben, damit die Amesie erkennt das es ein eigenes Feld ist.

 

[jendris]

Ich hole mal einen alten Thread hoch, weil wir die eigenen Felder nun doch häufiger nutzen müssen, da alle anderen "Mißbrauchsfelder" inzwischen ausgeschöpft sind.
Daher die Frage: Habt ihr noch vor, den Import benutzerfreundlich anzupassen?

 

[Enrico W.]

Ich muss gestehen - ich verstehe nicht wirklich, wo hier das Problem liegt. Welcher Import ist denn da benutzerunfreundlich? Oder wie stellst Du Dir den Import von eigenen Feldern sonst vor?

 

[css-umsetzung]

Ich hole mal einen alten Thread hoch, weil wir die eigenen Felder nun doch häufiger nutzen müssen, da alle anderen "Mißbrauchsfelder" inzwischen ausgeschöpft sind.
Daher die Frage: Habt ihr noch vor, den Import benutzerfreundlich anzupassen?

Oha, jedes einzelne der Missbrauchsfelder wird dir irgendwann ein Messer in den Rücken stechen, du solltest die Felder wirklich nur für das verwenden für das sie gedacht sind.

Ich wüsste jetzt auch nicht was man an diesem Import optimieren kann.

 

[jendris]

Das Problem mit dem Import wurde schon kurz nach Veröffentlichung der EF diskutiert.
Es ist so, das man Teile seiner Lieferantendaten, nicht in den EF Import bekommt, ohne die CSV vor dem Import anzupassen.
Es ist notwendig den Feldnamen für das EF in die CSV mit einzubauen, was zur Folge hat, dass man ein Script bauen oder bauen lassen muß.
Und bei häufigeren Änderungen oder Anpassungen, bleibt das keine Einmaligkeit.

Ich hatte damals schon vorgeschlagen, die Feldnamen als Standardwert zur Verfügung zu stellen.
Das hätte zwar zur Folge, dass man für jedes EF jeweils einen Import starten muß, aber dafür seine Lieferantendateien nicht mehr anpassen braucht.
Ich verstehe eh nicht, warum die EF nicht im Artikelimport vorhanden sind, das wäre für den User am einfachsten. Aber das hat sicher Datenbanktechnische Gründe, von denen ich nur sehr eingeschränkt etwas verstehe.

Nungut, meine Mißbrauchsfelder sind dicht, und nun weiß ich auch nicht, wie ich das lösen soll.

Oha, jedes einzelne der Missbrauchsfelder wird dir irgendwann ein Messer in den Rücken stechen, du solltest die Felder wirklich nur für das verwenden für das sie gedacht sind.

Ist das so? Ich hatte bisher keine Bedenken, ins "Herkunftsland" eine andere Information zu platzieren.

 

[Enrico W.]

Standardwerte greifen beim Import von Daten nur bei der Neuanlage von Datensätzen, nicht bei der Aktualisierung von Daten. Jeder Import muss sowohl so flexibel wie nur möglich als auch so intuitiv wie möglich gestaltet werden. Das ist immer eine Gratwanderung. Natürlich könnte man theoretisch sagen "das sind alles Artikeldaten" - aber würde man alles, was in die Artikel importiert werden kann, in einem Import unterbringen wollen, würde man da sehr schnell als Nutzer die Übersicht verlieren, von der technischen Unmöglichkeit einiger Kombinationen ganz abgesehen.

 

[jendris]

Standardwerte greifen beim Import von Daten nur bei der Neuanlage von Datensätzen, nicht bei der Aktualisierung von Daten..

Womit die Standardwerte dann zumindest für die Neuanlage eine erhebliche Erleichterung wären.
Ich sage das, weil wir diese Felder tatsächlich nie aktualisieren müssen.

 

[Enrico W.]

Und da wären wir dann wieder dabei: Wieviele Importe sollen dann in einem Import zusammengefasst werden? Hier sind es jetzt die eigenen Felder, der nächste hätte gern die Merkmale und so weiter und so fort.
Um die Importe noch übersichtlich zu halten ist eine solche Unterteilung leider notwendig.

 

[jendris]

Ja, ist ok. War auch nur ne Idee.