Hallo, gibt es einen Endpunkt, über den ich die Varianten eines Produktes abfragen kann? Ich bekomme bei /v2/products/ ja nur die Basisdaten der Produkte zurück. bei einer Bestellung mit einer gekauften Variante erhalte ich immerhin die ausgewählten Werte und die produkt id und einen identifier wie 144x16242 (144 ist die Produkt Id). 16242 scheint also irgendwie die Identifizierung de Variante zu sein, oder? Anschließende Frage: Kann ich beim Produkt erstellen auch direkt Varianten anlegen? Viele Grüße, Jan
Hallo Jan, Varianten eines Artikels, also Attribute oder Eigenschaften, können derzeit leider noch nicht über die REST-API abgefragt oder angelegt werden. Das ist noch auf unserer Todo-Liste. Die Zahl hinter dem x ist die combi_id, die ID einer konkreten Eigenschaftenkombination.
Hallo Jan, wir haben zu fehlenden Punkten in der GX3 API einen Thread aufgemacht wo wir von Faktura-XP versuchen die noch fehlenden API-Funktionen zu dokumentieren und Alternativlösungen zu den betroffenen Punkten gemeinsam mit anderen zusammen zutragen. Was uns / euch hilft, hilft auch dem Moritz und den anderen Jungs die API zu verbessern. Ich poste dir mal hier den Link zum Thema, wenn dir noch andere Funktionen auffallen die Fehlen schreibs doch am besten da auch rein auch Lösungen, wenn du selbst eine Alternative zu einer fehlenden Funktion dir erarbeitet hast ist darin gerne gesehen Hier der Link: (Link nur für registrierte Nutzer sichtbar.)
Das Problem gibt es auch bei Amicron Faktura 12. Weil die Rest-API keine Varianten-Artikelnummern übermittelt, können im Amicron beim Bestellimport auch keine Varianten übertragen werden. Damit ist die komplette Bestandsverwaltung unmöglich.
Uns ist bewusst, dass wir an der Stelle noch eine Funktionslücke haben. Man kann an der API Dokumentation sehen, dass die API ab Version 2.3 mit ersten Funktionen da war, und wir danach Stück für Stück immer erweitert haben, neue weitere Daten zugreifbar gemacht haben. Auch für dieses Jahr sind einige Steps in der Roadmap um den Funktionsumfang aufzustocken und zu verbessern, wir sind noch nicht am Ende dessen was wir wollen. Bei Variantenartikeln ist das Thema aber etwas komplexer, weil da generell noch Altleichen im Weg liegen, das heisst vor der zweiten Jahreshälfte werden wir Variantenartikel vorraussichtlich nicht über die API abbilden können.
Ich bin auch der Meinung, dass Amicron zu früh auf die REST-API gewechselt hat, ohne genau zu prüfen, ob das überhaupt Sinn macht. Ich habe mir bereits einen eigenen Bestellimport gebastelt, ohne REST-API. Damit werden die Varianten wieder übertragen.
Es gibt so einige Formen von Anbindungen, die man über die API inzwischen schon ganz gut machen kann. Wawis sind da soetwas wie die Königsdisziplin, die wollen normal immer an alle Daten irgendwie heran. Wie auch immer: Das ist ein vorübergehendes Bauchweh im Technologiewechsel, dass sich im Laufe des Jahres geschätzt von selbst legen wird, wenn jeder seine Hausaufgaben macht, und da bin ich guter Dinge.
Wir wollen jetzt auch einen Bestellimport über eine Gambio API in Auftrag geben. Frage 1: XML API oder REST API? XML ist nicht mehr zeitgemäß und wird nicht mehr prioritär weiterentwickelt, richtig? Und REST ist noch nicht fertig? Frage 2: Wenn REST, reicht die CreateOrder, um eine Bestellung als Gastkonto-Bestellung anzulegen ( (Link nur für registrierte Nutzer sichtbar.) ) oder müssen die CreateOrderTotal und die UpdateOrderStatus parallel angesprochen werden, um Datenbank-Inkonsistenzen zu verhindern? Frage 3: Wir wollen auch Varkombi-Artikel (Gambio Eigenschaften, also products_properties_combis) importieren, die auf dem Marktplatz als Einzelartikel geführt werden. Kann ich die über die REST-API mittels products_properties_combis.combi_ean oder über die combi_model anlegen oder werden die Eigenschaften auch für den Bestellimport noch gar nicht unterstützt?
1: Ja. 2: CreateOrder reicht. 3. Puh, bin ich gerade auch überfragt. Muss ich morgen mal in Erfahrung bringen.
Also Eigenschaften können bei Artikeln einer Bestellung mit angegeben werden. Wie in der Doku beschrieben muss dann im attributes-Array die combisId angegeben werden, damit der Datensatz in die orders_products_properties-Tabelle geschrieben wird. Sollte es im Shop keine Eigenschaftenkombination geben, kann auch einfach 0 als combisId angebeben werden.
Wie Moritz schreibt, über die REST-API selber kommst da schon an die Daten dran, man kann nur nicht aus den Bestelldaten ganze Artikel anlegen da fehlen dann doch zu viele Informationen, für die Bestellung selbst reichts aber wenn die API 2.3 nutzt, alles davor ist quasi noch "leere Hülle", mussten wir für unseren Connector auch selbst nachbauen.
Was ich mich noch frage zu (Link nur für registrierte Nutzer sichtbar.) : Warum wird bei Vaterartikel mit der products_model gearbeitet, bei Kindartikeln aber mit der products_properties_combis_id? Die internen Nummern werden doch vermutlich ohnehin quasi nie exportiert zu Marktplätzen etc, sondern da sind EAN oder Artikelnummern entscheidend. Wäre für mich sachlogisch, bei den Kindartikeln analog zu den Vaterartikeln mit der products_properties_combis.combi_model zu arbeiten? Jetzt muss man immer schauen: Gibt's die Artikelnummer in products.products_model? Wenn nicht: Gibt's die Artikelnummer in products_properties_combis.combi_model? Wenn ja, suche dazu die products_properities_combis.products_properties_combis_id und die products_properties_combis.products_id Macht das Sinn? Wäre es nicht einfach einfach beide Tabellen (oder von mir aus alle drei - Attribute auch noch - ) nach der Artikelnummer zu durchsuchen und dann per API die entsprechenden IDs in der Bestellung zu hinterlegen?
Für den Shop ist die Combi ID das bestimmende Merkmal, nicht die EAN etc, damit ist das über die API so schon folgerichtig. Dass es bei den Eigenschaften in der API noch Löcher gibt ist dabei anerkannt.
Aber für den Shop ist doch auch die products_id das bestimmende Merkmal und nicht die products_model, zumal die ja nicht einmal zwangsläufig in jedem Shop unique ist. Dann also vielleicht das auch umstellen?
Eine Eigenschaftenkombination ändert einen Basisartikel. Der Basisartikel ist durch die pid bestimmt, die im Basisartikel zusätzlich ausgewählte Eigenschaftenkombination durch die Combi ID. Eine Eigenschaftenkombination ist selbst kein Artikel.
Ok... und was soll bei (Link nur für registrierte Nutzer sichtbar.) als customers_id bzw. cid bzw. number übergeben werden? Amazon kennt ja die nächste zu vergebende Kundennummer nicht. Soll das einfach immer eine 0 bleiben, damit der Kunde als Gast angelegt wird?
Hallo nochmal. Sind das Bugs oder haben wir die API-Doku missverstanden? Bestellzeitpunkt soll laut API so übergeben werden: Y-m-d H:i:s . Statt dem Bestellzeitpunkt wird aber die aktuelle Zeit verwendet? Der Bestellstatus der Bestellung wird ignoriert und stattdessen der Standardstatus verwendet. Dafür taucht der Bestellstatus dann aber in der orders_status_history als Status auf. Könnt ihr das bestätigen?
Willst du Zugang zu unserem Testshop? Ich kann dir auch einen Beispiel-Request-Body geben. Und die Links aus der Api-Doku sind veraltet. Neuer Link: (Link nur für registrierte Nutzer sichtbar.)