hmm...
der fehler liegt im ajax checkout prozess ... habe den checkout auf "false" gesetzt und man kann nun zahlen ... aber halt nicht mehr in der 1page checkout 
Hab den Fehler gefunden!
Wer das Fixpack für die 2.0.6 eingespielt hat, bitte noch diese Änderung durchführen:
Öffne /includes/xajax/xajax_core/xajax.inc.php und suche:
'defaultMethod' => 'POST', // W3C: Method is case sensitiveändere das in
'defaultMethod' => 'GET', // W3C: Method is case sensitiveDas ist alles. Nun sollte der Checkout mit der neuen xajax Version reibungslos laufen.
Klappt bei uns nun sauber. Lag nur an der Art der Datenübertragung, hat mit einem Zahlungsmodul nix zu tun. Fixpack drüber, geht.
Hi Zusammen,
ist euch auch aufgefallen, dass auf der Checkout Seite die Versandkosten ohne MwSt. angezeigt werden, so ist die Gesamtsumme auch nicht korrekt, in der Emailbestätigung aber alles richtig.
Kann den Fehler jemand nachvollziehen?
Gruß
Im Versandkostenmodul die Versandkosten ohne MwSt angeben und passenden Steuersatz auswählen. Dann passts.
natürlich sind die Versandkosten im Versandmodul ohne MwSt. angegeben, trotzdem wird beim Checkout ohne angezeigt, ausserdem habe ich noch eine Kleinigkeit festgestellt.
Auch im Checkout wird die Rechnungsadresse unter der Lieferadresse angezeigt und wenn der Kunde keine Lieferadresse angegeben hat, bleibt die Rechnungsadresse leer.
Gruß
hast du auch den Steuersatz angegeben?
Wenn ja, versuche die Reihenfolge der Module->Zusammenfassung über das Feld Anzeigereihenfolge anzupassen
bei mir folgendermaßen:
Zwischensumme (ot_subtotal)
Versandkosten (ot_shipping)
Nachnamegebühr (ot_cod_fee)
Summe Netto (ot_subtotal_no_tax)
Gesammtsumme (ot_total)
MwSt (ot_tax)
Summe Netto (ot_total_netto)
Das mit den Adressen ist mir auch aufgefallen, da hab mir meinen eigenen checkout programmiert.
Gleiche Probleme beim Bestellvorgang Version 2.06
Hab 3 Zahlungsweisen angelegt, keine funktioniert, immer kommt die Fehlermeldung "Bitte wählen Sie eine Zahlungsmethode aus"
Dann kann der Shop das "ß" nicht lesen, z. B. gibt der Kunde in seiner Adresse Lindenstraße 10 an, wird in der Versandadresse nur
Lindenstra übernommen, "ß" und alles was nach diesem Buchstaben kommt, wird einfach vom Shop gelöscht. Adresse kann so nicht mehr gelesen werden.
ja, Steuersatz ist eingegeben, ich hab geschrieben, in der Mailbestätigung ist auch alles richtig, mir geht es auch nicht um die Anzeige der Versandkosten unter dem Frachtführer, sondern ganz unten, wo die Zusammenrechnung kommt, egal wie ich die Reihenfolge lege, ist der Versand immer ohne MwSt., in der Mail, so wie direkt unter dem Frachtführer ist alles ok.
Gruß
hat schon jemand einen Lösung?
Muss dringend den checkout zum laufen bringen.
Danke
na es funktiniert doch, nur die Versandkosten werden im Checkout ohne MwSt angezeigt, in der Email steht aber alles richtig.
Gruß
leider nein!
Parse error: syntax error, unexpected T_IF in /shop2/includes/xajax/xajax_core/plugin_layer/xajaxEventPlugin.inc.php on line 1
Vorab gelöst durch austausch der Datei mit alter Version xajax 0.5
hier laden http://xajax-project.org/media//xajax/0….5_standard.zip
und dann die Datei austauschen.
Leider geht aber auch die Auswahl der Versand bzw. Zahlungsmodule nicht mehr.
Sobald man den Bestellprozess abschliessen möchten kommt
- Bitte wählen Sie eine Versandart aus
- Bitte wählen Sie eine Zahlungsart aus
hat jemand bereits das Problem gelöst?
Wie sollte das gehen? Der Shop legt immer erst einmal in beide Addressen die Anschrift des Kunden. Wenn eine leer wird wurde die Manuell herausgelöscht. Oder redet Ihr von der Mail? Was mit dem Checkout ja überhaupt nichts zu tun hätte.
Hi,
na es ging eher um ein optischen Fehler, bei mir wurde im Checkout die Lieferadresse links aufgeklappt angezeigt und die Rechnungsadresse rechts zugeklappt, daher dachte ich dass es ein Fehler ist, nach dem Ausklappen der Rechnungsadresse ist alles ok, obwohl schöner fände ich, wenn die Rechnungsadresse links angezeigt werde.
Das mit den Versandkosten ohne MwSt (im Checkout) ist immer noch so, bis jetzt ist es den Kunden nicht aufgefallen.
Gruß
lastscout
Dann musste das im Admin auch so einstellen!
@all
Ich konnte das Porblem lösen.
Nachdem ich einen Server mit so vermurksten Einstellungen gefunden habe, bei dem ich dieses Phänomen nachstellen konnte, habe ich eine Funktion im Ajax erweitert.
Zum Problem:
Das Ajax erwartet einen $_GET ODER $_POST String.
Das sieht bei Bestätigung der Zahlart als $_POST so aus:
Array( [invoice_num] => 1 [pmodule] => 1 [payment] => moneyorder [moneyorder_num] => 2)als $_GET so:
invoice_num=1&pmodule=1&payment=moneyorder&moneyorder_num=2Bei euren "Servern" kommt das aber so an:
{\"invoice_num\":\"1\",\"pmodule\":\"1\",\"payment\":\"moneyorder\",\"moneyorder_num\":\"2\"}Die Zusatzfunktion wandelt das wieder in ein Array zurück. Somit geht das auch bei euch.
Ich packe gerade das Fixpack 7. Für die ganz eiligen hier die Lösung:
öffne die /includes/classes/checkout.php und suche:
function convertToVars($query_string) { $vars = array(); if (!is_array($query_string)) { $arr_vars = explode('&',$query_string); foreach ($arr_vars as $value) { $arr_vars2 = explode('=',$value); $vars[$arr_vars2[0]] = utf8_decode(urldecode($arr_vars2[1])); } } else { reset($query_string); while (list($key, $value) = each ($query_string)) { $vars[$key] = utf8_decode($value); } } return $vars; }ersetze das mit:
function convertToVars($query_string) {
$vars = array();
if(strpos($query_string, '&') === false) {
$string = str_replace('\\', '', $query_string);
$string = str_replace('"', '', $string);
$string = str_replace('{', '', $string);
$string = str_replace('}', '', $string);
$exploded = explode(',', $string);
for($i=0; sizeof($exploded) > $i; $i++) {
$trennen = explode(':', $exploded[$i]);
if($trennen[0] != '' && $trennen[1] !='')
$vars[$trennen[0]] = $trennen[1];
}
} else {
if (!is_array($query_string)) {
$arr_vars = explode('&',$query_string);
foreach ($arr_vars as $value) {
$arr_vars2 = explode('=',$value);
$vars[$arr_vars2[0]] = utf8_decode(urldecode($arr_vars2[1]));
}
} else {
reset($query_string);
while (list($key, $value) = each ($query_string))
$vars[$key] = utf8_decode($value);
}
}
return $vars;
}Ist wieder mal gern geschehen...
Problem besteht auch bei einer Standard Einstellung Domianfactory.
Wie sieht denn die Empfehlung der Einstellung für den cseoV2 Shop aus?