Die API 2.1 hat die gleichen Methoden in allen Bereichen (products, metadaten, business) wie die API 2.0.

Es gibt jedoch einige Unterschiede im den Feldern innerhalb von Datenformaten oder im Verhalten der API selbst.

Hier eine Übersicht der Änderungen

products/ Methode

Die Datenformate developerupdate, standardupdate haben sich in der API 2.1 nicht geändert. Die Datenformate developer und standard wurden um einige Felder ergänzt.

Im Abschnitt product (developer, standard)sind folgende Felder neu:

  • eClassV7: eClass Version 7.0
  • customsTariffNumber, wurde nur in der Position innerhalb des Dokuments verschoben
  • UNSPSC: UNSPSC Classification Code
  • productName: wurde umbenannt, war früher productNameWithManufacturer. Hat in der API 2.1 den exakten Inhalt wie in der API 2.0, kann jedoch über den Export konfiguriert werden. 
  • colorFamilyId: Id der Farbfamilie (normalisierte Farbe)
  • colorFamily : Farbfamilie (normalisierte Farbe) z.B. grau statt space-grau oder maus-grau
  • combinedLengthAndGirth: Gurtmaß 
  • netWeight: Nettogewicht
  • netDimX: Nettomaß X
  • netDimY: Nettomaß Y
  • netDimZ: Nettomaß Z
  • valueAddedTaxGermany: Deutscher Umsatzsteuersatz
  • energyEfficiencyClass: Energieeffizienzklasse
  • keySellingPoints: Key Selling Points
  • packageContents: Lieferumfang
  • productFeatures: Produktfeatures
  • htmlMainSpecs: Technische Eigenschaften des Produktes in Kurzform, getrennt mit br-Tags
  • contractTypeId: Der Vertragstyp bei Lizenz- und Serviceprodukten
  • contractTypeName: Der Name des Vertragstyp bei Lizenz- und Serviceprodukten

Im Abschnitt supplierItem (developer, standard) sind folgende Felder neu:

  • contractTypeId: Der Vertragstyp bei Lizenz- und Serviceprodukten
  • contractTypeName: Der Name des Vertragstyp bei Lizenz- und Serviceprodukten

Im Abschnitt attribute (nur im standard) folgende Felder neu:

  • value: Der Basiswert (siehe auch Basiseinheit) der Eigenschaft, bei Text als Textbaustein, bei Zahlen als kleinste Angabe

business/deals/send Methode

Hardware Artikel benötigen dieses zusätzlichen Infos nicht. Nur Artikel mit Lizenzvertragstyp Id  > 0 (Physical). 

Über die Bestell API 2.1 ist es erst möglich ESD Bestellungen für bestimmte Distributoren (siehe Übersicht) entgegen zu nehmen.

ESD Bestellungen werden anhand von Regeln vor dem Versand an den Distributor geprüft und bei Verstoß gegen diese Regeln wird die Bestellung von der API abgelehnt, und der Grund auch als Repsonse zurückgegeben. 

Folgende Regeln gelten bei der Übermittlung einer ESD Bestellung:

  • Werden Bestelldokumente mit ESD Informationen, Opentrans Remarks itscontractype oder itsesdemail,  an die API 2.0 gesendet, werden diese zusätzlichen OpenTrans Remarks Elemente in der API 2.0 aus dem Dokument entfernt
  • Regeln für Remarks type="itscontracttype":
    • darf nur einmal pro ORDER_ITEM angegeben werden
    • Der Remarks type="itscontracttype" muss immer in Kleinbuchstaben übermittelt werden.
    • gültiger Lizenzvertragstyp Name muss in korrekter Schreibweise übermittel werden. Aktuell wird nur ESD unterstützt. Weitere Vertragstypen folgen später
  •  Regeln für Remarks type="itsesdemail":
    • darf nur einmal pro ORDER_ITEM angegeben werden
    • Der Remarks type="itsesdemail" muss immer in Kleinbuchstaben übermittelt werden.
    • Muss immer in Verbindung mit Remarks Typ itscontracttype ESD gesetzt werden
    • Der Inhalt des Remarks Elements darf nicht leer sein
    • Der Inhalt des Remarks Elements muss eine gültige Emailadresse (Email Format) erhalten
    • Es sind keine unterschiedlichen Esd-Emails innerhalb einer Bestellung erlaubt
  •  Regeln für Party Customer:
    • Es muss bei ESD Bestellungen immer nur eine Customer Party im ORDER_HEADER angeben sein
  • Regeln für CUSTOMER_ORDER_REFERENCE: 
    • darf nur einmal pro ORDER_ITEM angegeben werden
    • CUSTOMER_IDREF darf nur auf eine Customer Party zeigen
    • CUSTOMER_IDREF darf nicht auf eine ungültige Customer Party zeigen
  • Die ESD Position innerhalb der Bestellung wird immer gegen den Lizenz Vertragstyp der Bezugsquelle auf ITscope.com geprüft
    • Bestellposition ESD und Bezugsquelle ESD: OK
    • Bestellposition ESD und Bezugsquelle unbekannt: OK
    • Bestellposition ESD und Bezugsquelle nicht ESD: Fehler
    • Bestellposition nicht ESD und Bezugsquelle nicht ESD, aber Produkt ESD: OK
    • Bestellposition nicht ESD und Bezugsquelle ESD: Fehler
  • gemischte Bestellungen sind erlaubt, d.h. ESD und Physical Positionen innerhalb der Bestellung, es gelten die Regel wie oben beschrieben
  • reine ESD Bestellungen sind erlaubt, d.h. nur ESD Positionen innerhalb der Bestellung, es gelten die Regel wie oben beschrieben,
    • bei reinen ESD Bestellungen ist Dropshipment nicht erlaubt, d.h. UDX.DROPSHIPMENT muss in diesem Fall auf false gesetzt sein

 

 

 

 

Haben Sie Fragen? Anfrage einreichen