Hallo, wir haben ein Problem mit einer ganz speziellen Varkombi-Google-Shopping-Kombination: - Eigenschaften aktiv - Lagerbestand in Eigenschaften aktiv - Google Shopping Export von admin/csv.php -> Preisportal -> [Gambio] Google Shopping Scheinbar wird bei den einzelnen Eigenschaften für den Export nicht die Eigenschafts-Verfügbarkeit verwendet, denn alle Kinderartikel werden als "nicht auf lager" exportiert. Bug oder fehlerhafte Einstellungen? Danke und VG
Ok, ich bin dem Fehler auf der Spur: Es sieht mir so aus, als würde für die Menge die combi_quantity verwendet, aber für den Lieferstatus die Menge des Vaterartikels. Vielleicht nur ein Problem bei uns, da wir teilweise die Dropshipping-Bestände unserer Lieferanten direkt in die combi-quantity schreiben und dafür die aufsummierte Menge in den Vaterartikel nicht geschrieben wird. Damit ist das vermutlich ein Bug, der sich bei fast niemandem auswirkt, vermute ich.
Nee daran lags nicht - habe ich getestet. Wovon hängt denn die Google Shopping Verfügbarkeit bei Variationskombinationsartikeln ab?
Ok, habs gefunden glaube ich: Die Info kommt vermutlich aus products_item_codes (google_export_availability_id) und darin gibt es nur eine Spalte für die products_ids aber nicht für die combi_ids wenn es Variationskombinationen gibt. D.h. eine Lieferbarkeit im Google Feed lässt sich sauber nur für Artikel ohne Kombis festlegen. Das ist nicht so gut. Welche google_export_availability_id für welchen Wert im Google Feed steht, habe ich noch nicht herausgefunden, weil es dazu scheinbar keine Konfigurationsmöglichkeiten in der Datenbank gibt. Ich vermute, products_item_codes.google_export_availability_id = products.products_shippingtime ? Dann würde der Lieferstatus des Produkts auch mit in den Google Feed übernommen, vorausgesetzt dass es keine Kindartikel gibt. Stelle außerdem fest, dass es für viele unserer Artikel gar keinen Eintrag gibt (z.B. Marke etc.). Ich vermute, dass die JTL Wawi diese Tabelle einfach gar nicht beliefert. Da kommt @Wilken jetzt bestimmt wieder mit der Forderung, die API zu verwenden statt direkt in der Datenbank zu schreiben, weil bei Aufruf der Gambio-eigenen Funktionen die entsprechenden Daten und die Lieferbarkeit etc. direkt in der products_item_codes aktualisiert werden? So langsam verstehe ich den Sinn. Also was mache ich jetzt? In der JTL Wawi einen fiktiven Dropshipping-Lieferantenbestand für die Kinder eintragen und den dem eigenen Lagerbestand hinzufügen, damit dem Vaterartikel in der Gambio-Tabelle products überhaupt ein Bestand zugewiesen wird und man eine Chance hat, das Produkt bei ebay anbieten zu können und in den Google Shopping Feed hineinzubekommen. Der Bestand macht hier rein logisch überhaupt keinen Sinn, weil es gar keinen sinnvollen Vaterartikel-Bestand geben kann. Ein Script basteln, das mir per Cronjob in Abhängigkeit von diesem unsinnigen fiktiven Bestand in der products_item_codes die Lieferbarkeit setzt und die fehlenden Marken und die Artikelnummern hinzufügt. Auch das ist eigentlich unsauber, weil es wie gesagt eine Lieferbarkeit bei Verwendung von Eigenschaften nicht auf Grundlage des Vaterartikels, sondern nur auf Grundlage des Kindartikels geben kann (also combi_quantity). Das gilt genauso für die MPN und EAN und je nachdem wie man die Varkombis anlegt gegebenenfalls sogar für die Marke. Beispiel: Vaterartikel: Staubsaugerbeutel-Filtertüte für Gerät xy, Kinderartikel Marke Siemens, Marke Swirl. Wenn dann Swirl ausverkauft ist und Siemens auf Lager, welche Marke und welcher Lieferstatus soll für den Vaterartikel in die Google Exportdatei? Fazit: Mit diesem Quick & Dirty Workaround komme ich bestimmt erstmal klar. Ich weiß nicht genau, WIE die neuen geplanten Varkombis in GX 3.x umgesetzt werden, aber es scheint mir, als wäre eine Überarbeitung der Google Shopping Exportfunktion und der Tabelle products_item_codes in dem selben Atemzug unumgänglich. Denn selbst wenn man die Gambio API einsetzen würde, könte man rein von der Datenbank-Struktur in Gambio keine saubere Lösung hinbekommen, oder? Oder übersehe ich irgendwelche Konfigurationsmöglichkeiten, die das Problem umgehen? VG Burkhard
Da habe ich über 2 Monate dran gegrübelt und den Support gut beschäftigt. Nicht mal in Verbindung mit google. Mir ging es erstmal nur darum, die Eigenschaftenlagerbestände via CSV zu aktualisieren. Es gab viele Aussagen, aber funktioniert hat letztendlich nichts. Ich bin jetzt nicht sicher, aber vielleicht brauchts für den Google-Export noch die combi-model, damit die korrekte Vater-Kind-Kombi-Artikelnummer ausgegeben wird.
Ich aktualisiere die Variationskombi-Lagerbestände auch per CSV, die automatisch eingelesen und verarbeitet wird anhand der combi_ean. Das klappt soweit ganz gut. Aber mit dem Google Shopping Export ist Gambio noch nicht fertig, denke ich...
Hi Burkhard, ja, das ist so, der Lieferstatus und der Hersteller beziehen sich auf den Vater Artikel. Ich finde das mit dem Hersteller aber nicht ganz falsch, da die Eigenschaften ja Variationen eines Artikels sein sollen. Wir machen es bei den von uns betreuten Projekten mit JTL WaWi bei Varianten so, dass wir die Artikel in der JTL WaWi auf Artikelebene ganz normal mit Lagerbestand, Preis, Artikelbild... pflegen und direkt aus der JTL WaWi (0.9...) heraus die Eigenschaften in Gambio aktualisieren (Bild, Preis, EAN, VPE, Bestand....), dabei automatisch den Kind Artikel in Gambio zum "Kind" machen und die Bestellung dann wieder auf Artikel Ebene an JTL zurückgeben. So bleibt der Artikel in JTL ein Artikel der für ebay, Amazon... verwendet wird und ist in Gambio eine Eigenschaft Damit funktioniert die Lagerbestands Führung 100%. ED
Hallo Ed, hört sich interessant an, aber ich verstehe es noch nicht ganz: Die JTL Wawi < 1.0 unterstützt ja keine Eigenschaften, d.h. ihr legt die Produkte als Einzelprodukte in JTL an und führt die dann in Gambio zu einem Artikel mit Eigenschaften zusammen? Was für einen Connector verwendet ihr denn, der sowas kann bzw. wie macht ihr in Gambio aus Einzelartikeln einen? Und wie erkennt die Wawi dann beim Bestellimport, dass eine Eigenschaft eines Artikels wieder der jeweilige Einzelartikel ist? VG
Hi, Das ist nicht ganz richtig, im Standard unterstützt die WaWi natürlich mit XTC, Gambio... nur die Variationen/Attribute. mit einer etwas umfangreicheren, trotzdem überschaubaren Anpassung an verschiedenen Stellen (Datenbank, connector, Gambio... - trotzdem updatesicher) lässt sich das schon problemlos realisieren. Dann lassen sich auch mit der WaWi <1 die Eigenschaften aktualisieren. In der WaWi selbst brauchen dabei nicht einmal mehr die Variationen oder Variationskombinationen gepflegt werden, es reicht wenn ein Vaterartikel angelegt wird. ED
Hi Burkhard, ich den zweten Teil Deiner Frage übersehen. Das lösen wir eben über unsere JTL-WaWi/Gambio Anpassung, die für alle Gambio Versionen möglich ist. ED
Ach so, Einzelartikel, die ein bestimmtes Artikelnummern-Format haben, werden dann darüber vom Connector zusammengeführt? Interessant. Und diese Anpassungen verkauft ihr auch? Käme für uns fast in Frage, wenn es auch Variationskombis könnte...
Jein, ein einheitliches Format der Artikelnummer wäre die optimale Lösung, damit kann man alles voll automatisch realisieren. Klar wenn ich Artikelnummern in 4711-rot und Artikelnummern 4711-blau habe und sich die ganze Logik so durch alle Artikel durchzieht, kann ein hoher Automatisierungsgrad erreicht werden. In den wenigsten Fällen ist das aber sicher möglich. Ein spezielles Artikelnummern Format ist also nicht unbedingt notwendig, die Voraussetzung ist allerdings, dass jede Eigenschaft in JTL eine eindeutige Artikelnummer hat, also ein eigenständiger Artikel ist. Wir verkaufen keine fertigen Module... wir passen aber Shopsysteme individuell an. ED