TRADElube 1.2.1.8 Release Notes
Release Datum: 30.08.2023
Feld "Lagerbestand Verwalten" unterschiedlich für Vater- und Kindartikel
Das Feld "Lagerbestand Verwalten" in der Aufgabe "WooCommerce Lagerbestände Hochladen" kann nun über neue Skriptvariablen "IsVariantProduct" und "IsParentProduct" konfiguriert werden. Das Problem bisher war, dass man dies nicht unterscheiden konnte und Vaterprodukte in der Regel aber keinen Lagerbestand haben. Deshalb wurde dann das ganze Produkt in WooCommerce als nicht verfügbar angezeigt. D. h. diese Zuweisung konnte bisher nur bei normalen (nicht Variantenartikeln) sinnvoll verwendet werden.
Feld "Lieferrückstand Erlaubt" korrigiert
Das Feld "Lieferrückstand Erlaubt" in der Aufgabe "WooCommerce Lagerbestände Hochladen" konnte bisher noch nicht korrekt konfiguriert bzw. verwendet werden. Nun wurde dies korrigiert und um weitere Möglichkeiten ergänzt.
Es kann nun die Auswahl aus den 3 Möglichkeiten als Fixwert ausgewählt werden (siehe Screenshot), oder es kann mit einem logischem Benutzerfeld verknüpft werden.
Benutzerfelder für weitere Lagerbestände
Benutzerfelder aus CAO-Faktura können nun für die Zuweisung weiterer Lagerbestände als Skriptfelder verwendet werden.
Preise für Feldzuweisung "Versandkostenfrei" verwenden
In der Aufgabe "Shopware Produkte Hochladen" können nun für die Feldzuweisung "Versandkostenfrei" die Preise als Variablen im Skript verwendet werden. So können nun die Versandkosten-freien Produkte automatisiert vom Preis abhängig festgelegt werden.
Die Abbildung zeigt das beschriebene Feld in Shopware:
Nachträgliche Zuweisung von Varianten bei neu angelegten Vaterartikel
In CAO-Faktura werden im Shoptransfer die Artikel (auch bei Neuanlage) nicht so sortiert, dass erst der Vaterartikel und dann die Kindartikel angelegt werden. Daher musste bisher die Übertragung aus CAO-Faktura oft doppelt erfolgen, damit beim zweiten mal dann die Vater-Artikel-Verknüpfung bei den Varianten zugewiesen wurde.
Nun gibt es eine neue Zuweisungsmöglichkeit im Transferplan von CAO-Faktura, damit nun auch umgekehrt beim Anlegen des Vaterartikels bereits existierende Produktvarianten nachträglich noch hinzugefügt werden. Dies Zuweisung sollte in der Regel nur für Neuanlage ausgewählt werden, da dies nur beim nachträglichen Anlegen des Vaterartikels relevant ist.
Aktuell werden bei dieser Zuweisung keine Produktvarianten vom Vaterartikel entfernt, sondern nur fehlende Produktvarianten hinzugefügt. Das Entfernen erfolgt bereits bei der Zuweisung "Vater Produkt" bei Produktvarianten selbst.
Vaterartikel wird bei Zuweisung zu einem Variantenartikel zurückgesetzt
Falls beim Übertragen von Produktvarianten aus CAO-Faktura entweder der Vaterartikel hinzugefügt oder entfernt wird, wird nun in TRADElube auch der Vaterartikel nochmal zurückgesetzt, damit dieser folglich nochmal in alle Systeme neu synchronisiert wird. Notwendig ist dies im Zusammenhang mit einer Neuerung bzgl. WooCommerce (siehe oben), wo das Feld "Lagerbestand Verwalten" nun für Vater-Artikel individuell festgelegt werden kann.
Lieferzeit nun individueller gestaltbar
Die Feldzuweisung "Lieferzeit" in der Aufgabe "Shopware Produkte Hochladen" kann nun individueller gestaltet werden. Z. B. in Abhängigkeit von Lagerbeständen, von einem Lieferdatum oder von beliebigen benutzerdefinierten Feldern.
Als Grundlage dient hier immer noch das Mapping der Lieferzeiten in Tagen im Kanal "Shopware" Bereich "Zuordnungen" Register "Lieferzeiten".
Über den Modus "Feldzuweisung" können nun auch benutzerdefinierte Eigenschaften vom Typ Ganzzahl ausgewählt werden (z. B. "Lieferzeit in Tagen"). Oder wie bisher ein Lieferdatum-Benutzerfeld, dass dann in Tage und damit in die entsprechende Lieferzeit umgerechnet wird. Für Letzteres ist aber zu beachten, dass dies nur richtig funktioniert, wenn man die Übertragung regelmäßig erneuert, was wir als Herangehensweise nicht vorrangig empfehlen würden. Aus Gründen der Abwärtskompatibilität wurde diese Möglichkeit nicht entfernt.
Über den Modus "Skript" hat man nun viele weitere Möglichkeiten. Zum einen können alle benutzerdefinierten Felder, alle Lagerbestände als Variablen verwendet werden. Und über die neue Funktion "GetDeliveryTimeIdForDays(Integer days)" kann dann ein beliebig berechnetes Ergebnis in Tagen in die entsprechende Lieferzeit Id umgewandelt bzw. gemappt werden.
Beachten Sie folgenden Breaking-Change:
Aus dem Skript wurden Variable entfernt, und zwar die bereits umgerechneten Lieferdatum-Benutzerfelder. Als Ersatz sollte nun die neue Funktion "GetDeliveryTimeIdForDays" kombiniert mit den entsprechenden Variablen zu den Benutzerfeldern verwendet werden.
Preiszuweisung für benutzerdefinierte Produkt-Metadaten
Preise können nun in der Aufgabe "WooCommerce Produkte Hochladen" für die Metadaten Zuweisung verwendet werden. (Gute) WooCommerce Plugins (beispielsweise für B2B Funktionalität) speichern ihre Daten mit diesem allgemeinen Konzept der Metadaten. So kann TRADElube mit den (meisten) WooCommerce-Plugins sehr individuell konfiguriert werden.
Zusätzlich gibt es für Skript-Zuweisung auch neue Funktionen "GetPrice_....(Integer position)" über diese dann auch Staffelpreise durch Angabe der Position ausgelesen werden können.
Beim Neuladen von externen Zuordnungen (Mappings) verblieben gelöschte Einträge
Wurden im externen System (z. B. Shopware, WooCommerce etc.) Einträge gelöscht (z. B. Zahlungsarten, Eigenschaften etc.) konnten diese Zuordnungen in TRADElube nicht mehr entfernt werden, zumindest nicht mehr aus der Auswahl, und die Einträge wurden beim "Neu Laden" auch immer wieder neu angelegt.
Es ist nach wie vor so, dass zum Entfernen eines Eintrages zuerst die Zeile (das Mapping) gelöscht werden muss. Dann aber bewirkt ab jetzt ein "Neu Laden" auch ein vollständiges Entfernen aus der Auswahl.
Erzwungene Aktualisierung von Produktvarianten mit Übertragungsfehlern
Diese Änderung betrifft die Aufgabe "WooCommerce Produkte Herunterladen". Diese Aufgabe benötigt man für eine Sonderkonfiguration, wenn man nur Lagerbestände nach WooCommerce synchronisieren möchte. In WooCommerce geht dies aufgrund der Produktvariationen nur, wenn man vorher eine Verbindung zwischen den Produkten (über die SKU bzw. Produktnummer) herstellt. Daher werden die Produkte hier im ersten Schritt erst von WooCommerce in Richtung TRADElube synchronisiert.
Das Problem hierbei war, dass Produktvariationen, wo es einen vorangegangenen Übertragungsfehler gegeben hat, danach nicht mehr sofort synchronisiert wurden. Im konkreten Fall wurden in WooCommerce eine Menge Produktvarianten in andere Hauptprodukte durch eine andere Schnittstelle verschoben, was erstmal in TRADElube korrekterweise zu Fehlern bzgl. doppelten Produktnummern führte. Nach dem Löschen dieser alten Produkten wurden jedoch die neuen aus dem genannten Grund nicht mehr neu synchronisiert. Nun gibt es für solche und ähnliche Fälle einen Bugfix, indem Produkte, deren Produktvarianten in TRADElube einen Übertragungsfehler aufweisen, immer synchronisiert werden, bis der Fehler wieder verschwindet (mit Einschränkung, da der Interval für fehlerhafte Einträge nach einer Zeit auch stark gedrosselt wird).
Performanceoptimierungen für Download von Produkten
In einem aktuellen Fall gibt es das Problem, dass sich die Responses zu den Produkten aus der WooCommerce API bei jedem Abruf inhaltlich unterscheiden, obwohl es keine Änderung gegeben hat. Schuld sind Listen (z. B. Kategorien) deren Sortierung sich immer ändert und so die Listeneinträge von Aufruf zu Aufruf quasi immer hin- und her-toggeln. Oder anders gesagt diese Responses von WooCommerce scheinen nicht determistisch (vorhersehbar) identisch zu sein.
Aufgrund dessen konnte TRADElube hier die Performance nicht mehr optimieren. Dies geschieht normalerweise so, dass sich TRADElube einen Hashwert zu den einzelnen gelieferten Responses bzw. Datensätzen merkt. So ist es dann möglich, sofort zu erkennen, ob es seit der letzten Übertragung Änderungen gibt, und ob eine Synchronisierung überhaupt erforderlich ist. TRADElube kann die Responses mit bekanntem Hashcode also einfach überspringen und in der Folge reduziert sich der gesamte Zeitaufwand für die Übertragung drastisch, und in der Regel können dadurch auch sehr große Mengen von Daten sehr schnell verarbeitet werden. Dieser Vorteil fällt aber natürlich weg, wenn aus dem Grund wie im ersten Absatz beschrieben, diese Hashcodes nicht mehr zuverlässig berechnet werden können.
Der Workaround funktioniert nun so, dass es statt einem Hashcode nun vier weitere also insgesamt fünf Hashcodes gibt. Es werden also solange mehrere (bis zu 5) Hashcodes gesammelt, solange keine Änderung bei der Synchronisierung festgestellt wird. Dadurch kann nun ab dem 4-5 Durchlauf trotzdem eine gute Performance erzielt werden.