Fieses Problem! Variationen nichtmehr übernommen

[Andy Krüger]

AW: Fieses Problem! Variationen nichtmehr übernommen

@ Janusch,
da liegt es bei mir nicht dran. Die Variationsnamen sind bei mir deutlich kürzer.
Eventuell wäre es mal sinnvoll sich mit rbaier zu unterhalten. Er kann das Problem glaube ich sehr gut beschreiben.

@hometronix
Doppelpunkte und runde Klammern stören den Prozess. Umlaute glaube ich nicht! Bei mir jedenfalls nicht.

 

[rbaier]

AW: Fieses Problem! Variationen nichtmehr übernommen

Umlaute sind kein Problem - der von mir angebotene Connector ist UTF-8-fähig und prüft auch den vom Shop sowie der Datenbank verwendeten Zeichensatz.
Das eigentliche Problem ist die katastrophale Speicherung der Attribute von Virtuemart - alle Angaben zusammengefaßt als String in einem Tabellenfeld.
Da diese von Virtuemart natürlich auch verarbeitet werden müssen - und auch vom Connector (von daher meine drastische Formulierung, da diese Problematik mich schon ungezählte Stunden an Arbeit gekostet hat) - verwendet Virtuemart Trennzeichen.
So sind eckige und runde Klammern sowie Semikola 'verboten', da dadurch der Attribute-String nicht mehr verarbeitbar wird.
Dies läßt sich auch einfach im Backend von Virtuemart (also unabhängig von JTL-Wawi und Connector) verifizieren.

In Virtuemart kann der Attribute-String (fast) beliebig lang sein, da dieser in einem Feld vom Typ TEXT gespeichert wird.
Der Connector extrahiert aus diesem String die einzelnen Variationen, jeweils mit Werten und - falls vorhanden - Preismodifikationen.
Die Übergabe an JTL-Wawi erfolgt mithilfe der in den Mappingtabellen gespeicherten Informationen - einfach ausgedrückt: allen Virtuemart-Angaben sind IDs zugeordnet, die auf Keys von JTL-Wawi gemappt werden (bzw. umgekehrt / je nachdem, ob empfangen oder gesendet wird).

--
mfg
rbaier

 

[Andy Krüger]

AW: Fieses Problem! Variationen nichtmehr übernommen

Ist für dieses Problem denn nun noch Support von JTL zu erwarten?

 

[masterbrain]

AW: Fieses Problem! Variationen nichtmehr übernommen

bei einigen Shopsystemen sind die Variationnamen auf 32 Zeichen begrenzt (Datenbanktabelle order_product_attribute).
Sollte die Variation in Wawi länger sein, muss diese gekürzt werden, sonnst taucht diese nicht in der Bestellung auf, da der Connector diese über Namen zuweist.

nein dies hilft nicht, trotzdem danke. so langsam wirds echt anstregend mit diesem bug

 

[Janusch]

AW: Fieses Problem! Variationen nichtmehr übernommen

Das mit 32 Zeichen in order_product_attribute ist v.a. in xtc Forks zu finden.

Der Connector muss die richtigen Schlüssel der Variationen an die Wawi übergeben, sobald dies nicht 100% funktioniert, werden die Variationen nicht korrekt übernommen.

Die Handhabung der Bestellungen in Wawi ob Conntector oder JTL- Shop ist identlisch.
Alle werden in tinetBestellung usw. in der DB der Wawi gespeichert.

 

[masterbrain]

AW: Fieses Problem! Variationen nichtmehr übernommen

Hallo Janusch,

vielen danke das ihr das Thema noch nicht vergessen habt.

Die Handhabung der Bestellungen in Wawi ob Conntector oder JTL- Shop ist identlisch.
Alle werden in tinetBestellung usw. in der DB der Wawi gespeichert.

mir stellt sich die Fragen warum jedoch nachträglich Variation innerhalb der Wawi verschwinden wenn diese Bereits in der DB gespeichert waren ?

Bsp:
Bestellung 1 - Artikel X Variation A
1. Synro gestartet - Bestellung OK
-----------------------------------------
Bestellung 2 - Artikel X Variation A
2. Synro gestartet - Bestellung OK
------------------------------------------

-> Nach der 2.Syncro ist die Bestellung 2 korrekt angezeigt , jedoch die Variation der Bestellung 1 ist aus der Wawi wieder verschwunden, obwohl diese bereits zuvor korrekt angezeigt wurde bzw. in der DB gespeichert war/ist.

Wenn ihr möchtet kann ich euch den Vorgang gern per TeamViewer vorführen. Es ist tatsächlich sehr kompliziert zu verstehen, was da genau passiert.

Danke und Gruß aus Dresden

 

[Janusch]

AW: Fieses Problem! Variationen nichtmehr übernommen

Hallo,

können wir gerne machen. Bitte e-Mail direkt an mich.
Bitte Management Studio installieren, falls nicht vorhanden.

 

[Thomas Lisson]

AW: Fieses Problem! Variationen nichtmehr übernommen

Hallo zusammen,

das Problem liegt daran, dass der VM keine eigenen PKs hat für Bestellpositioneigenschaften - dadurch kommen diese Probleme.

Unser Connector muss in der Datei GetPosEigenschaft.php Zeile 31-51 wie folgt ausschauen:

		if (strlen($orderpos->product_attribute)>2)
		{
			$varTeile = explode(";",$orderpos->product_attribute);
			$i = 0;
			foreach ($varTeile as $varTeil)
			{				
				$kBestellPosEigenschaft = 10000 + intval($_POST['KeyBestellPos'])*20 + $i;
				$tmp = explode(":",trim($varTeil));
				$aufpreis=getAufpreis(trim($tmp[0]),trim($tmp[1]),$orderpos->product_id,$shopper->shopper_group_id)*(1+$steuer->tax_rate);
				$attribute_id=getEigenschaftsId(trim($tmp[0]),$orderpos->product_id);
				$kEigenschaftsWert=getEsEigenschaftswertNachName(trim($tmp[1]),$orderpos->product_id,$attribute_id);
				
				echo(CSVkonform($kBestellPosEigenschaft).';');
				echo(CSVkonform(intval($_POST['KeyBestellPos'])).';');
				echo(';');
				echo(CSVkonform($kEigenschaftsWert).';');
				echo(CSVkonform($aufpreis).';');
				echo("\n");
				$i++;
			}
		}

Der aktuelle Connectordownload wurde aktualisiert.

 

[masterbrain]

AW: Fieses Problem! Variationen nichtmehr übernommen

Hallo JTL Team ,

vielen Herzlichen Dank für eure hilfreiche Unterstützung ,,,

Nach ersten Test scheint das Problem gelöst zu sein , weiteres Feedback folgt.

Gruß Hübler

 

[Tentaurus]

AW: Fieses Problem! Variationen nichtmehr übernommen

Nach ersten Test scheint das Problem gelöst zu sein , weiteres Feedback folgt.
Gruß Hübler

Und, gibt's mittlerweile Erfahrungswerte?

@rbaier: wie sieht's mit ihrem Connector aus?

Gruss

 

[masterbrain]

AW: Fieses Problem! Variationen nichtmehr übernommen

Und, gibt's mittlerweile Erfahrungswerte?

ja, der fehler ist behoben - keine probleme.

viel erfolg.

 

[rbaier]

AW: Fieses Problem! Variationen nichtmehr übernommen

@Tentaurus,

masterbrain war schneller - er hatte sich auch bereit erklärt, meine Tests durch eigene zu ergänzen. Auch dafür an dieser Stelle Danke @masterbrain.

M.a.W. - ich habe den Connector entsprechend modifiziert.
Da auch viele Anwender des Connectors ohne Variationen arbeiten, bitte ich für den Moment die Anwender des von mir entwickelten Connectors:
Eine kurze formlose eMail mit Rechnungs- bzw. Kunden-Nr. an rbaier@web-signs.de 'bitte aktuellen Connector zusenden' (oder so ähnlich).

--
mfg
rbaier

 

[SchnapperMichel]

AW: Fieses Problem! Variationen nichtmehr übernommen

Hallo

Habe zwar heute morgen beriets ein eigenes Thema eröffnet, allerdings habe ich festgestellt, dass ich genau das gleiche Problem habe.

Ich habe den aktuellen Connector von Herrn Baier erhalten.
Muss ich noch etwas ändern?

Freundliche Grüße

Michel

 

[hometronix]

AW: Fieses Problem! Variationen nichtmehr übernommen

Ich habe das gleiche Problem immer noch und nutze den aktuellen Connector von rbaier.

Die Variationen werden nach einem WebShop Abgleich nicht mit in die WAWI übernommen

Grüße
hometronix

 

[SchnapperMichel]

AW: Fieses Problem! Variationen nichtmehr übernommen

Gibt es denn jemanden, bei dem es funktioniert?
Wenn nicht, brauch ich nicht weiter nach einer Lösung suchen und deinstalliere alles wieder.
Das verbuche ich dann unter "Griff ins Klo" und kann mich wieder meiner eigentlichen Arbeit widmen.

Ich dachte der Connector kann es.

 

[rbaier]

AW: Fieses Problem! Variationen nichtmehr übernommen

Das in diesem Thread ursprünglich angesprochene Problem wurde - wie oben zu lesen ist - bereits am 27.04.2010 behoben.

Was bedeutet 'Die Variationen werden nach einem WebShop Abgleich nicht mit in die WAWI übernommen' genau?
Wird JTL-Wawi verwendet, dann funktioniert eine Synchronisation nur dann fehlerfrei, wenn nach erfolgter Erstsynchronisation alle Änderungen ausschließlich in JTL-Wawi erfolgen.

Auf die Frage 'Gibt es denn jemanden, bei dem es funktioniert?' erlaube ich mir zu antworten: Bei allen anderen Anwendern des von mir angebotenen Connectors scheint dies zu funktionieren. Ansonsten hätte ich auch nach dem 27.04.2010 entsprechende Anfragen erhalten.

Nun will ich nicht ausschließen, dass - aus welchen Gründen auch immer - im Einzelfall Probleme auftreten können. Diese waren bislang auch immer lösbar. Nur dazu bitte ich um eine konkrete Supportanfrage via eMail. Zuemeist helfen dann die Logdateien weiter, um die Fehlerursache herauszufinden.

--
mfg
rbaier

 

[hometronix]

AW: Fieses Problem! Variationen nichtmehr übernommen

Ich hatte bisher keine Zeit mehr um mich um das Problem zu kümmern, da andere Dinge wichtiger waren.

Wir müssen daher immer noch die Variationen bei einem Auftrag von Hand in der WAWI auswählen, da diese beim Abgleich verloren gehen. In der Bestellmail sind die Variationen drin, doch holt man sich den Auftrag in die WAWI sind sie weg.

Könnte natürlich an bestimmten Zeichen liegen, die bei den Variationen verwendet werden. Hierzu gibt es leider keine genaue Information welche Zeichen man nicht verwenden darf. Bei uns werden z.B. oft ":" und "-" verwendet.

Vielen Dank!

Grüße
hometronix

 

[rbaier]

AW: Fieses Problem! Variationen nichtmehr übernommen

Wenn für die Bezeichnung von Variationen und/oder deren Werten ein Doppelpunkt verwendet wird, dann dürfte spätestens bei der Verwendung von Preismodifikatoren aufgefallen sein, dass dann Virtuemart die Preise nicht mehr korrekt berechnet.
Bei der Übernahme von Bestellungen mit in dieser Form bezeichneten Variationen (bzw. Variationswerten) muß es zu Fehlern kommen, da Virtuemart zum Speichern der Variationen den Doppelpunkt als Trennzeichen zur Trennung von Variations-Name und Variations-Wert verwendet.

Bsp.: Wird in Virtuemart eine Variation mit 'Attribute 1' und ein dazugehörender Wert mit 'Property 1' bezeichnet und ist für diesen ein Preisaufschlag von 10,00 € (Nettowert als Modifikator) festgelegt, dann findet sich bei Bestellung dieses so konfigurierten Produktes im Feld product_attribute der Tabelle #__{vm}_order_item der Eintrag 'Attribute 1: Property 1 (+ 11,90 € )'.
Diese Angabe kann auch korrekt vom Connector verarbeitet werden.
Wird nun eine Variation mit 'Attribute 1:1' und ein dazugehörender Wert mit 'Property 1:1' bezeichnet und ist für diesen ebenfalls ein Preisaufschlag von 10,00 € (Nettowert als Modifikator) festgelegt, dann findet sich bei Bestellung dieses so konfigurierten Produktes im Feld product_attribute der Tabelle #__{vm}_order_item der Eintrag 'Attribute 1: 1: Property: 1-1'.
Diese Angabe kann vom Connector nicht verarbeitet werden. Zumal - wie oben bereits geschrieben - Virtuemart die Preismodifikation bereits 'verschluckt' und auch nicht bei der Berechnung des Preises berücksichtigt hat.

Zu einer weiteren Ursache, warum Variationsangaben bei Bestellübernahmen von JTL-Wawi nicht zugeordnet werden (können):
Wird der Connector im sog. 'Spezial'-Modus verwendet, weil JTL-Wawi als reine Verwaltungslösung dienen soll, dann funktioniert dies nur zuverlässig, solange keine Variationen verwendet werden. Dieser Modus funktioniert auch mit Variationen, wenn nach erfolgter Erstsynchronisation keine Änderungen mehr in Virtuemart vorgenommen werden. Nur: dies ist üblicherweise eben nicht der Fall, da dieser 'Spezial'-Modus in sehr wenigen Anwendungsfällen gerade deshalb genutzt werden soll, weil die Produkte weiterhin in Virtuemart gepflegt werden sollen.
Für die Synchronisation der Daten zwischen Virtuemart und JTL-Wawi werden Mappingtabellen verwendet. Solange die darin enthaltenen Informationen synchron mit den Angaben in der MS-SQL-Datenbank von JTL-Wawi sind, wird es auch keine Probleme geben.
Werden Bestellungen mit Variationen in Virtuemart aufgegeben und nach JTL-Wawi geholt, die JTL-Wawi nicht kennt - da diese später (nach erfolgter Erstsynchronisation) in Virtuemart angelegt wurden - dann kann JTL-Wawi diese natürlich nicht zuordnen.
Ich werde deshalb voraussichtlich den Spezial-Modus in der Konfiguration des Connectors deaktivieren, da dieser ohnehin nur auf speziellen Kundenwunsch integriert wurde.

--
mfg
rbaier

 

[hometronix]

AW: Fieses Problem! Variationen nichtmehr übernommen

Das ist doch mal eine super Antwort mit der man etwas anfangen kann. Vielen Dank! Wir verwenden den "Normal Modus" und pflegen unseren Shop hauptsächlich mit der WAWI. Hier besteht wohl keine Fehlerquelle.

Allerdings haben wir wie schon beschrieben ":" in unseren Variationswerten enthalten. Wir mussten irgendwie eine Verknüfung von Farben und Größen schaffen, damit nicht ausversehen die falsche Kombination bestellt werden kann.

Daher sehen unsere Variationen z.B. so aus:

Variation - "Auswahl"
Werte - "Farbe: black - Größe: L"
Werte - "Farbe: black - Größe: M"
Werte - "Farbe: gray - Größe: L"
Werte - "Farbe: gray - Größe: M"

Da haben wir natürlich die Fehlerquelle mit den ":" drin und müssen uns überlegen wie wir die Bezeichnungen verändern ohne Fehler beim synchronisieren zu verursachen. Jemand eine Idee wie man dies lösen könnte? Wir brauchen die Verknüpfung zwischen Farbe und Größe, da wir den Warenbestand nach Variationen pflegen.

Vielen Dank!

Grüße
hometronix

 

[rbaier]

AW: Fieses Problem! Variationen nichtmehr übernommen

@hometronix,

wesentlich ist sicher, dass der potentielle Kunde in einem Webshop nicht überlegen muß - auch nicht, wenn es um Variationen geht.

Ich könnte mir folgende Variante vorstellen:
Screenshot 1 zeigt das VM-Backend:
http://dev.web-signs.de/tmp/snap_variation_1.png

Screenshot 2 das VM-Frontend:
http://dev.web-signs.de/tmp/snap_variation_2.png

Als Anregung ... auf die Schnelle
PS: Damit funktionieren übrigens auch Preismodifikatoren - falls diese vorgesehen sein sollten.

--
mfg
rbaier