GX4.5 und neuer: Entfall von EAN und Grundpreisen in Attributen

Thema wurde von Wilken (Gambio), 8. November 2021 erstellt.

  1. Anonymous

    Anonymous Mitglied

    Registriert seit:
    6. Dezember 2016
    Beiträge:
    5
    Danke erhalten:
    0
    Sorry, aber hier sind auch Laien wie ich, der einfach einen Shop betreiben will, ohne das Programmierkenntnisse erforderlich werden. Es ging hier simpel und einfach um die Preisaddition von Attributpreisen (zum Grundpreis des Artikels hinzugerechnet), nicht mehr und nicht weniger. Von einer Begriffserklärung zum Thema Grundpreis war hier von mir nie die Rede, ich wollte einfach wissen, ob der Preis des Artikels durch die Angabe der Attributpreise weiterhin addiert wird oder nicht. Punkt.

    Und die Frage ist nun beantwortet, nach dem 3 Versuch !!! Weitere Kommentare sind daher überflüssig.

    Und einen Gruß an alle Programmierer. Denkt ab und zu mal daran, das eure Software in aller Regel NICHT von Fachleuten, sondern von Normalusern angewendet wird. Dann würden viele Fragen erst gar nicht geklärt werden müssen. Kostet unser aller Zeit.

    Danke für die Antworten !
     
  2. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.276
    Danke erhalten:
    700
    Danke vergeben:
    245
    Der Grundpreis ist ein kaufmännischer Begriff und hat mit der schlichten Addition von Aufpreisen auf einen Basispreis überhaupt nichts zu tun. Du hast das Thema verfehlt und hast es trotz mehrfacher Erklärung von verschiedenen Seiten nicht kapiert. Hier geht es um völlig andere Sachen.
     
  3. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Wir helfen uns hier doch alle, aber ein Grundpreis hat nichts der Preiskalkulation zu tun, das haben einige hier versucht zu verdeutlichen und auch Lektüre-Tipps gegeben. Ob Laie, Neueinsteiger oder Nicht-Programmierer - alles kein Problem, sind alle willkommen, dürfen auch alle Fragen stellen - aber sie müssten sich auch mit den jeweiligen Antworten auseinandersetzen.
     
  4. franz_morzinger

    franz_morzinger Neues Mitglied

    Registriert seit:
    14. November 2019
    Beiträge:
    3
    Danke erhalten:
    0
    Liebe Leute,
    Ein Webshop ist weder Lagerverwaltung noch Artikelverwaltung!
    Um eine saubere Lagerverwaltung zu haben, bedarf es einer ordentlichen WaWi !.


    Egal wie es gedreht und gewendet wird, der korrekte Weg ist z.B. pro Produkt, Größe. Farbe, etc. eine eigenen Strickcode zu vergeben. Die Attribute sind Fakten für die Filterung. Somit entfällt der EAN-Code in den Attributen. Das war damit gemeint. Und ist auch so in einem der namhaftesten Softwarelösungen für Textilhändler.
    LG
    Franz
     
  5. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.276
    Danke erhalten:
    700
    Danke vergeben:
    245
    Da sind wir uns einig. Der Shop ist bei mir nur Bestellsystem, nichts weiter. Lagerverwaltung, Fakturierung, Finanzbuchhaltung ink. OP-Verwaltung sind Aufgabe der WaWi.

    Du gehst dabei aber von deiner Branche aus. Bei mir unterscheiden sich Reinigungswerkzeuge z.B. nur in der Farbe, von denen es 14 verschiedene gibt. In der Wawi lege ich dafür 14 Artikel an, das ist OK, aber im Shop habe ich dafür einen Artikel mit einem Attribut und 14 Farben. Jede der 14 Farben hat eine EAN, bzw Artikelnummer. Das funktioniert mit der Lagerverwaltung und der Kunde bekommt im Shop statt 14.000 nur 1.000 Artikel angezeigt. Verschlankt die Auswahl ungemein und ist wesentlich übersichtlicher.
     
  6. Wilken (Gambio)

    Wilken (Gambio) Administrator
    Mitarbeiter

    Registriert seit:
    7. November 2012
    Beiträge:
    17.849
    Danke erhalten:
    6.795
    Danke vergeben:
    2.060
    Das würden wir übrigens weniger schwarz/weiss sehen. Früher war das mal so, heute hat das klassische ERP Modell hie und da etwas Staub angesetzt.
     
  7. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    3. März 2018
    Beiträge:
    246
    Danke erhalten:
    12
    Danke vergeben:
    165
    Ich benutze auch seit Jahren php und sql um den Bestand von meiner Warenwirtschaft mit Gambio zu synchronisieren. Dabei vergleiche ich die EANs in der products_properties_combis. Meine Artikel haben nur die Eigenschaft Farbe.

    Das sollen wir also Updatesicher mit der REST-API machen. Der Umstieg wird nicht einfach. Ich habe damit noch nie gearbeitet. Die Doku hier wirkt kompliziert (Link nur für registrierte Nutzer sichtbar.)

    Gibt es im Forum keine Beispielcodes, wie es diese bei SQL gibt?
    Wenigstens die ersten schritte auf deutsch wären gut. Wie man eine Verbindung aufbaut. Das weitere kann man ja lernen.
    Und der Link zur Githubseite ist tot. Page not Found
     
  8. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Hi kidcars, es gibt ja scon wieder eine neue API :-D Die alte wird auch nur noch gewartet, aber neue Funktionen wird es nur für die neue geben.

    Ich weiß nicht, ob es Eigenschaften-Unterstützung für die v2 API gibt. War für GX 4.5 mal angekündigt, aber ist vielleicht noch nicht in der Doku. Wenn es das gibt, müsste das irgendwo hier sein:
    (Link nur für registrierte Nutzer sichtbar.)

    Ganz unten findest du einen Beispiel-API Call mit PHP und SQL:

    Code:
    <?php
    
    
    
     
    $curl = curl_init();
    
    
     
    
    
    
     
    curl_setopt_array($curl, array(
    
    
     
      CURLOPT_URL => "https://gambio-shop.de/shop1/api.php/v2/products/{product_id}",
    
     
      CURLOPT_RETURNTRANSFER => true,
    
     
      CURLOPT_ENCODING => "",
    
     
      CURLOPT_MAXREDIRS => 10,
    
     
      CURLOPT_TIMEOUT => 30,
    
     
      CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    
     
      CURLOPT_CUSTOMREQUEST => "PUT",
    
     
      CURLOPT_POSTFIELDS => "{\"id\":0,\"isActive\":false,\"sortOrder\":0,\"dateAdded\":\"\",\"dateAvailable\":\"\",\"lastModified\":\"\",\"orderedCount\":0,\"productModel\":\"\",\"ean\":\"\",\"price\":0,\"discountAllowed\":0,\"taxClassId\":0,\"quantity\":0,\"weight\":0,\"shippingCosts\":0,\"shippingTimeId\":0,\"productTypeId\":0,\"manufacturerId\":0,\"isFsk18\":false,\"isVpeActive\":false,\"vpeId\":0,\"vpeValue\":0,\"name\":{\"en\":\"\",\"de\":\"\"},\"description\":{\"en\":\"\",\"de\":\"\"},\"shortDescription\":{\"en\":\"\",\"de\":\"\"},\"keywords\":{\"en\":\"\",\"de\":\"\"},\"metaTitle\":{\"en\":\"\",\"de\":\"\"},\"metaDescription\":{\"en\":\"\",\"de\":\"\"},\"metaKeywords\":{\"en\":\"\",\"de\":\"\"},\"url\":{\"en\":\"\",\"de\":\"\"},\"infoUrl\":{\"en\":\"\",\"de\":\"\"},\"urlKeywords\":{\"en\":\"\",\"de\":\"\"},\"checkoutInformation\":{\"en\":\"\",\"de\":\"\"},\"viewedCount\":{\"en\":0,\"de\":0},\"images\":[{\"filename\":\"\",\"isPrimary\":false,\"isVisible\":false,\"imageAltText\":{\"en\":\"\",\"de\":\"\"}}],\"addonValues\":{\"productsImageWidth\":\"\",\"productsImageHeight\":\"\",\"codeIsbn\":\"\",\"codeUpc\":\"\",\"codeMpn\":\"\",\"codeJan\":\"\",\"googleExportCondition\":\"\",\"googleExportAvailabilityId\":\"\",\"brandName\":\"\",\"identifierExists\":\"\",\"gender\":\"\",\"ageGroup\":\"\",\"expirationDate\":\"\"},\"settings\":{\"detailsTemplate\":\"\",\"optionsDetailsTemplate\":\"\",\"optionsListingTemplate\":\"\",\"showOnStartpage\":false,\"showQuantityInfo\":false,\"showWeight\":false,\"showPriceOffer\":false,\"showAddedDateTime\":false,\"priceStatus\":0,\"minOrder\":0,\"graduatedQuantity\":0,\"onSitemap\":false,\"sitemapPriority\":\"\",\"sitemapChangeFrequency\":\"\",\"propertiesDropdownMode\":\"\",\"startpageSortOrder\":0,\"showPropertiesPrice\":false,\"propertiesCombisQuantityCheckMode\":0,\"usePropertiesCombisShippingTime\":false,\"usePropertiesCombisWeight\":false,\"groupPermissions\":[{\"id\":0,\"isPermitted\":false}]},\"quantityUnitId\":0,\"specialOfferId\":0,\"additionalFields\":[0]}",
    
     
      CURLOPT_HTTPHEADER => array(
    
     
    
    
    
     
    "authorization: Basic REPLACE_BASIC_AUTH",
    "content-type: application/json"
    
     
    
    
     
    
    
    
     
    ),
    
    
     
    ));
    
     
    
    
    
     
    $response = curl_exec($curl);
    
    
     
    $err = curl_error($curl);
    
     
    
    
    
     
    curl_close($curl);
    
    
     
    
    
    
     
    if ($err) {
    
    
     
      echo "cURL Error #:" . $err;
    
     
    } else {
    
     
      echo $response;
    
     
    }
    
    Hier gehts zur neuen v3 API:
    (Link nur für registrierte Nutzer sichtbar.)

    Ich weiß aber jetzt auch nicht, ob die Eigenschaften bald Optionen oder Varianten heißen, und wie denn die jetzigen Optionen heißen werden. Jedenfalls gibt’s für Varianten und Optionen was in der v3 API:
    (Link nur für registrierte Nutzer sichtbar.)
    Das kannst du aber vermutlich erst benutzen, wenn du auf Gambio GX 4.5.x bist, weil zu dem Zeitpunkt ja erst die Eigenschaften und Attribute abgeschafft oder umgebaut werden.


    Psst! Nicht laut drüber sprechen: Wenn du etwas weitgehend Konstantes suchst, dann bleib dabei, direkt auf die Datenbank zu gehen. Habe ich auch vor für die eine oder andere Funktion. Da ändert sich seltener was als an den APIs, und du hast anders als bei APIs vollen Zugriff, volle Kontrolle und volle Flexiblität auch für Spezialanforderungen.
     
  9. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    3. März 2018
    Beiträge:
    246
    Danke erhalten:
    12
    Danke vergeben:
    165
    Hahaha:)
     
  10. Wilken (Gambio)

    Wilken (Gambio) Administrator
    Mitarbeiter

    Registriert seit:
    7. November 2012
    Beiträge:
    17.849
    Danke erhalten:
    6.795
    Danke vergeben:
    2.060
    Sachlich schwierige Feststellung. Ja, es gibt neue API-Knoten die in der URL zu ihnen eine andere Versionsnummer tragen. Es ist aber egal ob man nun V2 oder V3 sagt, die Dinge dahinter haben im Interface zum Apinutzer dieselben Paradigmen und es wurde nichts vorheriges entfernt. Gibt es also ein Problem?

    Nein, gibts nicht, war auch nicht angekündigt. Angekündigt war API Unterstützung für Eigenschaften und die ist nun da.
     
  11. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Oh! Also für eine Migration zu V3 muss man nichts anpassen außer der URL die man anspricht? Das wäre ja gut...
     
  12. Wilken (Gambio)

    Wilken (Gambio) Administrator
    Mitarbeiter

    Registriert seit:
    7. November 2012
    Beiträge:
    17.849
    Danke erhalten:
    6.795
    Danke vergeben:
    2.060
    Nein, das hast du nicht richtig. Richtiger ist: In 90% der Fälle ist über ein längeren Zeitraum keine Migration nötig, das ist die Aussage. Die Aussage ist auch man kann V2 und V3 API Aufrufe wild miteinander mischen, das ist völlig egal und über einen längeren Zeitraum hier auch die richtige Herangehensweise.

    Eine Migration kann nötig werden, wenn ein oder mehrere Knoten einer alten API-Version durch neuere, in neueren API -Versionen ersetzt werden und der Support für die alten Knoten ausläuft. Das hat dann normal ein dickeres Zeitpolster.

    Eine Migration kann auch nötig werden, wenn der Shop eine Funktionalität erlangt die man anbinden will, die über ältere Versionen eines API-Knotens die man bislang nutzt dann aber nicht angeboten werden. Eventuell nötige, neue Felder könnten dann nur in den aktuellsten Varianten der jeweiligen Knoten hinzugefügt werden.
     
  13. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Warum denn in 90 % der Fälle über einen längeren Zeitraum? Du hast doch hier geschrieben:

    (Link nur für registrierte Nutzer sichtbar.)

    Diese Aussage ist doch im aktuellen Anwendungsfall 100% zutreffend, eindeutig und unmissverständlich, oder?
    Also auch wenn die API v2 unverändert bestehen bleibt (oder auch nicht, siehe dein obiger Beitrag, Wilken), dann braucht kidkars für Optionen, Eigenschaften, Attribute, Variationen und Kindartikel mit der v2 gar nichts mehr anfangen, oder? Weil wenn sich das alles ändert, wird die v2 da nichts mehr von können? Ist doch dann richtig, dass v2 für seine Zwecke veraltet ist und er die neue API nehmen muss, weil die neuen Attribute, Eigenschaften, Optionen etc. eine neue Funktion sind, die nicht mehr mit v2 kompatibel gemacht wird? Das habe ich jetzt auch aus diesem Beitrag so zwischen den Zeilen herausgelesen?

    Und die Tatsache, dass man dann, wenn man zukunftstauglich sein möchte und auch künftig neue Funktionen über eine API ansprechen will und jetzt erst beginnt mit APIfizierung, irgendwie lieber die Finger von der v2 lässt, ist auch richtig, oder? So hatte ich es Kidkars geschrieben? Oder was war daran eine "schwierige Feststellung"?

    Eine Herausforderung wird ja vermutlich auch, herauszufinden, welche API-Version welche Funktionen unterstützt. Ich kann auf jeden Fall nachvollziehen, wenn man in Sachen Shop-Anbindung erstmal konservativ bleibt.
     
  14. Wilken (Gambio)

    Wilken (Gambio) Administrator
    Mitarbeiter

    Registriert seit:
    7. November 2012
    Beiträge:
    17.849
    Danke erhalten:
    6.795
    Danke vergeben:
    2.060
    Ich konstruier mal was wildes:

    Stell dir vor etwas neues wird zur Pflicht, zum Beispiel die Einverständnis eines Kunden zur Beilegung von Gummibärchen in Versandkartons. Stell dir dann vor, dass der Shop diese dann neue Information eventuell nur über einen neueren Knoten zur Verfügung stellt und die alten nicht entfernt aber auch nicht mehr verändert werden, dann hast du einen Migrationszwang.

    Falsch. Es gibt auch viele Informationen, die nur über V2 Knoten bereitstehen, also gehts wahrscheinlich nicht ohne V2. Kundendaten beispielsweise bekommt man Stand heute ziemlich ausschliesslich über V2.

    Nein, viel zu pauschal, falsches Entscheidungskriterium.

    Die Frage lautet: Wenn ich Daten erlangen oder ändern möchte, sollte ich dann immer den neuesten dafür zur Verfügung stehenden Knoten nehmen? Die Antwort ist: Ja.

    Dafür gibts die Doku.

    Es gibt keinen plausiblen Grund.
     
  15. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Außer dass man in mehreren Dokus parallel herumwühlt und sich mit 2 APIs auskennen muss. Ist das keine Zumutung für externe Entwickler? Für mich selbst ist es auch frustrierend: Du hast so viel für die API geworben, und ich habe erste Schritte gemacht und kleine Sachen geschrieben. Wenn ich jetzt sehe, dass ich für die dauerhafte und vollumfängliche Nutzung mich noch in eine zweite API einarbeiten muss, ist das etwas frustrierend und verleitet dazu, einfach per PHP so wie früher einen SQL-Befehl in die Datenbank zu werfen, und fertig.

    Also ich verstehe euer Anliegen mit der API, finde das aber für meinen Gebrauch ineffizient, weil die Einarbeitungszeit dann offenbar immer groß bleiben wird und die Halbwertzeit der erworbenen Kenntnisse gering ist. Sieht für mich aus wie: "Werd Profi und mach das im großen Stil für ein paar Hundert Shops, oder lass es ganz sein." Das erste kann ich nicht, das zweite will ich nicht. Für mich ist das ein wichtiger Vorteil von Gambio zu anderen Shopsystemen, dass man doch noch immer eine ganze Menge selbst basteln konnte und damit unterm Strich kostengünstig unterwegs war.
     
  16. Wilken (Gambio)

    Wilken (Gambio) Administrator
    Mitarbeiter

    Registriert seit:
    7. November 2012
    Beiträge:
    17.849
    Danke erhalten:
    6.795
    Danke vergeben:
    2.060
    Das kann man relativ bequem auch als eine sehen. Nochmal, die Paradigmen sind gleich. Die Verdrahtung im Shop ist anders. Wir hätten die V3 Knoten auch V2 nennen können, hätte keinen Unterschied gemacht, so wars aber für uns intern schöner.

    Wenn jemand das behaupten will kann er. Praktisch spielts keine Geige.

    Nein, das ist folgefalsch. Du hast das bisher nicht verstanden. Es ist doch nichts weg.

    Nein, ein einmal gelerntes Verhalten hat normal über Jahre Bestand.

    Wir sind mit Sicherheit aus den Zeiten raus, in dem ein Shopsystem 300 Zeilen relativ unkomplexer Code war, wo man "alles" als Heimwerker zwischenfummeln konnte, das geht nicht mehr. Alle Shopsysteme sind inzwischen ein grosser Berg von komplexen Abhängigkeiten, das schneidet die simpelsten Anläufe ab. Mit einem System was soviel kann wie irgendwas in 2005 wär aber auch niemand mehr zufrieden, die Wünsche aller sind ja auch gestiegen, das ist zusammenhängend.

    Wir erklären die API, weil es der einfachste und verlässlichste Anlaufpunkt unter den gültigen, vertretbaren Möglichkeiten ist.

    Die Existenz von Serviceklassen in PHP als Alternative zur API und zur internen Beschaffung von Daten im Shopsystem und angeflanschtem Code muss auch verstanden werden, geht aber dauernd unter.
     
  17. Anonymous

    Anonymous Administrator
    Mitarbeiter

    Registriert seit:
    26. April 2011
    Beiträge:
    1.055
    Danke erhalten:
    810
    Danke vergeben:
    208
    @L & B Du brauchst aktuell v2 und v3 als API um alle Endpunkt die der Shop zur Verfügung stellt nutzen zu können.
    Welche Endpunkte welche API zur Verfügung stellt, steht nicht nur in der Doku, sondern du kannst dafür auch die API selbst nutzen, indem du den Endpunkt /api.php/v2 ohne Parameter ansprichst, dann bekommst du eine Liste aller Endpunkte.
    Das gleiche gilt für v3. Damit kannst du deine Schnittstelle so bauen, dass dort nachgeschaut wird, ob der Endpunkt vom Shop zur Verfügung gestellt wird.

    Keine der Endpunkte die in der v2 sind, sind in der v3, daher kann man sagen, willst du die neuen Optionen haben musst du die Endpunkte der v3 ansprechen und wenn du z.B. Kundendaten (customers) verarbeiten, willst musst du v2 ansprechen.

    Ruf mal über den Browser api.php/v2 und api.php/v3 auf, dann wirst du sehen was welche API kann.
     
  18. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Ok, aber der Sinn erschließt sich mir immer noch nicht ganz, das dann zu trennen, wenn es doch eigentlich eine API ist. Vielleicht ist dann die Namensgebung auch etwas irreführend und sollte besser API Basisfunktionen und API Erweiterungen heißen, weil man sonst denken könnte, dass das v in v2 und v3 für Version steht und dann v2 veraltet ist oder so. Ebenso die Darstellung hier:
    (Link nur für registrierte Nutzer sichtbar.)
    Da muss man dann raten, welche API (oder welche Kombination der APIs) für die gewünschten Zwecke verwendet werden muss.

    Aber das was Wilken anspricht, die Services, die habe ich tatsächlich nicht auf dem Schirm gerade. Ist vermutlich der bessere Weg, wenn es zum Beispiel um Lieferstatus-Aktualisierungen auf Basis der Bestände etc. geht. Versteckt sich das unter dem Punkt PHP Docs? Gibt’s dazu auch Beispiel-Code? Und die Namensgebung der Services scheint sich dann aber doch auch wieder nach den Namen der Datenbank-Tabellen zu richten? Dann ist es ja nicht so zweckmäßig, dass ihr nicht verraten wollt, in welchen Tabellen sich künftig die neuen attribute, optionen, Eigenschaften, Varianten, Variationen verbergen? Oder benennt ihr die Services noch so um, dass sie den Bezeichnungen im Backend oder Frontend entsprechen, um eine sauberere Trennung zwischen dem was man anstoßen möchte und dem was im System passiert zu erreichen?
     
  19. Christian Mueller

    Christian Mueller Beta-Held

    Registriert seit:
    4. Juli 2011
    Beiträge:
    3.276
    Danke erhalten:
    700
    Danke vergeben:
    245
    Wenn das dauernd untergeht, dann sollte man das vielleicht prominenter darstellen und erklären.
     
  20. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.604
    Danke erhalten:
    1.011
    Danke vergeben:
    882
    Macht doch dazu mal ein Webinar! Gambio Service für Einsteiger. Mit 2-3 Beispiel-Anwendungen.