Hi habe eine Frage. Warum werden die Varianten von den Artikel beim Preisimport immer zerschossen? CSV Tabelle: ordernumer | baseprice | price Nach Import werden alle betroffenen Artikel einzel angelegt. z.B.: Ring aus Gold hat 8 Varianten als Größe, nach Import werden die alle einzeln auf der Seite angezeigt. Lg.
keine ahnung?
Eine harte Lösung, um diesen Bug zu umgehen ist, in der engine/connectors/api/import/shopware.php die Zeilen if(isset($article['kind'])) $upset[] = "kind=".$article['kind']; (ca. Zeile 448) auskommentieren.
Hallo, seit ihr denn nach dem korrekten Preisimport vorgegangen? Es gibt ja gewisse Felder, die Pflicht sind und damit das System erkennt, welche Import-Art genutzt wird. Siehe hier: http://wiki.shopware.de/Import-Export-E … _Export.29 Das oben genannte Beispiel ist also auf jeden Fall nicht korrekt. Ich habe unter „Export Sonstiges“ gerade noch einmal einen Export der „Artikelpreise“ gemacht und ein paar Varianten-Artikel im Preis verändert. Das hat problemlos funktioniert. Bitte auf die spezielle Exporte/Importe achten. Bei dem Beispiel oben würde z.B. auf jeden Fall die Spalte mit der Zuordnung zum Vaterartikel fehlen. Da Shopware den einzeln nicht findet, kann kein UPDATE durchgeführt werden und der Artikel wird automatisch neu angelegt.
$price= array("ordernumber"=\>$ordernumber, "price"=\>$netto); $stock= array("ordernumber"=\>$ordernumber, "instock"=\>$bestand, "active"=\>$active); $weight = array("ordernumber" =\>$ordernumber, "weight"=\>$gewicht); $import-\>sArticlePrice($price); $import-\>sArticleStock($stock); $import-\>sArticle($weight); aus 2. Thread zum selben Thema. Wieso muss ich die Zuordnung zum Vaterartikel übergeben? Wenn ich mit der ordernummer arbeite ist die Zuordnung doch bereits 100% eindeutig möglich? Im konkreten Fall ist in der Fakturierung die Zuordnung Vater/Varianten auch gar nicht vorhanden, so dass die Zuordnung gar nicht möglich wäre, ohne die ID vor dem Import aus Shopware abzufragen.
Hi, wie das in dem anderen Beitrag bzw. in der API selber aussieht, kann ich aktuell noch nicht nachsehen. Wenn man allerdings das Standardmodul im Backend nutzt, so sollte man die Doku beachten, auf die speziell hingewiesen wird. Eine Importmöglchkeit wie oben ist da nicht vorgesehen. Daher gibt es speziell einen Preisimport, der Varianten und Konfigurator unterstützt sowie Staffeln und Kundengruppen. (Ist sogar eine extra Funktion in der Import-Datei der API) Das Beispiel oben wird als regulärer Artikelimport angesehen da keine Varianteninfos vorhanden sind und daher werden Artikel angelegt. Es wird nicht als reines Update angesehen. Ein abgewandelter Import im Backend kann immer zu Seiteneffekten führen und sollte ausführlich getestet werden…
Dann sollten wir die Diskussion nach programmierung-f13/api-import-zerschieszt-varianten-t6797.html verlegen, denn hier geht es nicht um den Import über das Backend, sondern über den Import mittels API Funktionen und hier tritt der Fehler auch auf. Sie haben allerdings Recht: Die Dokumentation fordert für $article einen Bezug zum Stammartikel: [quote] $article Notwendige Felder: varchar [“name”] Artikel-Bezeichnung varchar [“ordernumber”] Artikel-Bestellnummer varchar [“supplier”] Herstellername oder int [“supplierID”] ID des Herstellers (s_articles_supplier.id) oder int [“articleID”] ID des Artikels (beim Update) Verknüpfung von Varianten: Wenn Sie einen der folgenden Werte übergeben, wird der Artikel mit einem bestehenden Artikel verknüpft, also als Variante zugeordnet. (Eindimensional) optional char [“mainID”] > ID des Hauptartikels (s_articles.id) optional char [“maindetailsID”] > DetailsID des Hauptartikels (s_articles_details.id) optional char [“mainnumber”] > Artikelnummer des Hauptartikels (s_articles_details.ordernumber) [/quote] Beim Update über die Funktionen sArticleStock und sArticlePrice genügt die ordernumber. Es ist trotzdem merkwürdig, dass es diese Einschränkung für sArticle gibt, denn die ordernummer als Referenz ist immer eindeutig. Kein Shop hat dieselbe Ordernummer doppelt. Die ordernummer schließt immer Hauptartikel und Varianten ein. Beim Feld Gewicht könnte ich mit der Einschränkung auch leben, denn hier wird die Synchronisation nur 1x benötigt. Bei aktiv/inaktiv ist es schon unangenehmer, denn natürlich muss man häufiger Artikel wegen schlechter Verfügbarkeit oder aus anderen Gründen temporär sperren und da wäre es ebenso sinnvoll, wie bei Preisen und Beständen, diesen Wert ohne großen Aufwand synchronisieren zu können. Und ganz offensichtlich ist es keine große Sache, das zu ermöglichen, wenn ich mit vier / das Problem aus der Welt schaffen kann.
Danke euch… …aber jetzt ist es sowieso zu spät, da wir den shopsystem ändern. Wir sind seit August 2011 bei Shopware, ist ein schöner Shop und auch prof. System aber irgendwie gibt es immer wieder Probleme. Deswegen haben wir uns für ein anderes Shopsystem entschieden und nicht mehr die kostenlosen Shops.