Hi Andrea,
ist wahrscheinlich das gleiche wie hier :
http://plussupport.commerce-seo.de/showthread.php…hlight=billsafe
Es scheint leider so, als hätte Webdesign Erfurt die Billsafe-Integration mit einem der letzten Updates "zerpatcht" , d.h. Billsafe läuft derzeit nicht, liegt nicht an dir.
Moin,
ich hatte mich zunächst gefreut als ich sah, dass wirecard checkout-page bereits integriert ist (v2.5.7) , leider ist das Modul aber nicht vollständig und auch nicht lauffähig - z.B: fehlt die /callback/wirecard/checkout_page_return.php die in der includes/modules/payment/wirecard_checkout_page.php definiert wird:
define('MODULE_PAYMENT_WIRECARD_CHECKOUT_PAGE_RETURN', 'callback/wirecard/checkout_page_return.php');
die checkout_page_confirm.php dagegen ist da, aber o.g. fehlt leider.
Hi Andrea, Ursache für diese Meldung ist immer ein SQL-Fehler, an welcher Stelle genau kommt denn diese Nachricht und bekommst du noch weitere Informationen mit dem Fehler?
Hallo,
der Part mit dem "Logo von Shop xy" kommt aus der Index.html deines verwendeten Templates, da google auf deiner Startseite keinen richtigen Text findet, wird was genommen was Google für wichtig hält (Der Warnhinweis in rot zb).
Ich hatte dasselbe Problem mit 2 Shops, mein Snippet sah genauso aus, also "Logo von xy" , Kontakt usw. Das einfachste wird sein, wenn du über den Contentmanager einen Text auf die Startseite packst, i.d.R. reicht das schon, dann nimmt google sich einen Auszug davon statt irgendwas aus Quelltext und Hinweisen zusammenzubauen.
Mit besten Grüßen
Mario
Unter Einstellungen -> PDF Wawieinstellungen und dann am besten ins Feld "Geschäftsinformationen"
Hi Tierland - soviel muss man beir der SQL Fehlermeldung nicht interpretieren, was den Fehler verursacht ist klar:
LIMIT -0, 0
Hier dürfte zum einen kein "-" drinstehen, dadurch kommt es zu besagtem Error, und zum anderen sollte die zweite Zahl nicht "0" lauten (da sonst immer ein leeres Ergebnis käme).
Der erste Wert müsste aus der Splitpageresults kommen da er dem Shop sagt ab welchem Eintrag die Produkte ausgelesen werden sollen, der zweite begrenzt die Ausgabe und darf ebenfalls nicht 0 lauten, dieser Wert kommt aus der DB, müsste DISPLAY_MAX_SEARCH_RESULTS oder so sein, also einer der Einträge aus Konfiguration->Maximum Werte.
Zumindest der Letzte Wert wird je Session nur einmal ausgelesen, kannst d.h. irgendwo steckt ein fehler der den ersten Wert ins negative dreht und den zweiten Wert auf 0 setzt.
Zur Sicherheit überprüf mal die Werte die bei dir unter konfiguration->Maximum Werte stehen, cih glaube aber nicht, dass dort 0 oder -0 drinsteht bei dir, aber sicher ist sicher.
ich denke im übrigen nicht,dass das irgendwas ist was du selbst produziert hast, es sei denn du hast am Multisort- Filter oder Pager herumgespielt?
Sowas "doofes" wie "die beiden Zahlarten sind für die Kundengruppen Gast und Neuer Kunde gesperrt" (nachzuprüfen in den Einstellungen der Kundengruppen) ist es aber nicht oder?
ist m.E. nicht übers Backend deaktivierbar, kannst du aber durch bearbeitung der login-Templates entfernen
Naja im Falle einer Rücklastschrift wegen Widerspruch wird Amazon den strittigen Betrag ganz sicher einbehalten, bei Rücklastschrift wegen Nichtdeckung wird Amazon das Geld vom Kunden eintreiben.
Aber wie gesagt, genaues und verbindliches wirst du nur von Amazon dazu erfahren können, die vorgenannten infos sind lediglich unsere pers. Erfahrung.
Das sollte dann nicht dein Problem sein, sondern dass von Amazon! Du bekommst nach dem sale 2 Emails - die erste direkt nach dem Kauf, da steht dann was drin wie "es wurde eine neue 'Bestellung angelegt" , die zweite kommt meist paar Minuten später, hier steht dann sowas:
"die Amazon-Bestellung xxx-xxxxxxx-xxxxxxxxxx(Shop Order-ID: xxxxxxx) wurde bezahlt und ist bereit zum Versand."
Das Amazon-Modul aktualisiert dir aber deine Bestellungen auch direkt im Shop wenn es korrekt eingestellt ist, d.h. du musst nicht auf die Emails achten, die sind nur nochmal zur Sicherheit, du hast die Bestellstatus auch direkt im Shop.
Ab dem Zeitpunkt bist du m.E. auf der sicheren Seite, allerdings ist das nur meine bisherige Erfahrung (bei einigen hundert Bestellungen darüber bisher noch nie eine Rückbelastung gehabt) , genau sagen können wir dir das nur Amazon... und dafür musst du die erstmal erreichen... 
Ist bei uns ganz ähnlich, wir haben es in einem eigenen Projekt am laufen und in 4 Kundenshops , der Anteil liegt jeweils bei ca 30% (der eine Shop bietet bedingungslosen Rechnungskauf an , dort sind es "nur" 25%).
"Vom Gefühl her", also nicht über hinreichend lange Zeiträume exakt ausgemessen, kommen durch Integration dieser Zahlart auch etwas mehr Bestellungen rein.
Größter Vorteil aus meiner Sicht : viele Kunden bezahlen ja einfach per Lastschrift bei Amazon oder haben Ihre Kreditkarte dort hinterlegt, dadurch erwischt man solche Kunden ohne diese Zahlarten direkt selbst anbieten zu müssen (ähnlich wie Paypal).
das sollte so nicht sein... schalte das Projekt im Sofo Backend mal in den Testmodus und mach ne Bestellung , einmal mit "abbrechen und zurück zum Shop" und einmal komplett durchgehen, sollte sich damit dann eigentlich eingrenzen lassen.
Dann stimmt möglicherweise was mit der Sofo-Integration bei dir nicht, teste das mal komplett durch am besten.
Das Bestellnummern zwischendrin verschwinden ist nicht ungewöhnlich, liegt an den temporären Bestellungen die einige Zahlungsmnodule anlegen (darunter auch sofortueberweisung):
Sobald du auf als User auf "kaufen" klickst und zu Sofo weitergeleitet wirst, legt der Shop eine temporäre Bestellung an, das lässt sich auch im Backend gut nachvollziehen wenn du die entsprechenden Einstellungen im Modul vorgenommen hast (leg dir dafür 3 neue Bestellstatus an : sofo_tmp, sofo_clearance und sofo_bestätigt).
Wenn der User jetzt bei Sofo abbricht und zurück zum shop kommt, wird die temp. Bestellung mit dem status sofo_tmp vom Shop wieder gelöscht und du bist eine Order_id "weiter" . Bricht der Kunde nicht ab, sondern führt die Bestellung erfolgreich aus, so ändert der Shop in diesem Moment den status von sofo_tmp zu sofo_bestätigt - und nur dann solltest du eine Bestellbestätigung erhalten und die Ware versenden!
Mit besten Grüßen!
Mario
Ja der Teil funktioniert, auf der checkout sieht der Code eigentlich auch gut aus (addTransaction und addItem ist schonmal da), allerdings zeigt er mir in analytics bisher nix an - ich gebe nochmal feedback , spätestens morgen müsste ja was zu sehen sein wenns geklappt hat.
Auf jedenfall schonmal Daumen hoch und vielen Dank für die Adaption!
hm ich bekomme damit keine ecommerce Transaktionen/Umsätze angezeigt, bin aber nicht ganz sicher ob die Daten in Analytics da immer live erscheinen wenn es klappt, hab die Testbestellung erst vor 15 Minuten gemacht - @ mitglied: klappt das ecommerce Tracking mit obigem Code bei dir ?
Du bist nicht zu blöd, das ist reichlich verwirrend umgesetzt zur Zeit, und auch nicht Funktionsfähig.
Zum ersten Teil der Frage: weil amazoncheckout ja darauf basiert, dass du dich als Kunde nicht nochmal im shop anmelden musst, sondern die Daten Ähnlichkeit wie bei PP express vom Anbieter ubermittelt werden, zur Kasse kommt man aber erst, wenn man angemeldet ist.
In der E-Mail Vorlage "Signatur"
ok, dann schau mal im Ordner /logfiles/ in die Errors.log.txt, dort sollte sich ein Ansatzpunkt finden
Cache nach dem umschalten im Backend schon geleert? daran liegt es meistens
