Keine Versandarten gefunden

Hallo!

nun habe ich auch dieses Problem.

“Keine Versandarten gefunden. Bitte kontaktieren Sie uns telefonisch oder per E-Mail”

Es ist aus quasi dem Nichts aufgetaucht. Ich habe hier schon Threads durchgelesen, das Tool installiert, aktiviert, deaktiviert etc.
Es nutzt nichts. Bis zum. zum 13.08. muss es gegangen sein.

Bei meinem ganzen Testen habe ich zudem das Phänomen, dass es machmal geht, gehe ich eine Schritt zurück und wieder vor im Prozess oder klicke noch einmal auf Kasse, dann geht es wieder nicht.

Ich versuche alles tunerzufahren und von vorne anzufangen.

Eine Zahlungsart: Vorauskasse
Länder DE /AUT
Benzutzergruppe alle / Benutzer keine

Eine Versandart DPD
Zahlungsart Vorauskasse zugewiesen
Benutzergruppe / Benutzer keine

Eine Versadkostenregel
Artikelkategorien alle / Artikel keine
Benutzergruppe / Benutzer keine
Länder keine

Geht aber nicht. Die Erweiterung sagt mir:
“Versandarten: DPD:Keine gültige Versandkostenregel gefunden”

Ich blicke nicht mehr durch…

Vielleicht hat jemand eine Taschenlampe mit etwas Licht parat??

wenn du “auch” dieses Problem hast, dann hast du bestimmt auch die Forensuche benutzt und alle anderen Threads zum selben Thema gelesen und auch das Modul von Leofonic gefunden, das dir aber gar nichts gebracht hat?

Hast du auch die Versandkostenregel zu den Versandarten zugewiesen?

Ja, leider, deswegen habe ich “auch” geschrieben. Ich bin schon ganz wirr vom zuordnen etc.
Ja, das Modul gibt eben “Versandarten: DPD:Keine gültige Versandkostenregel gefunden” aus.

Kann man auch mit dem Value 5 bei debug einstellen in der config, habe ich auch gemacht.

Also, so ein hartnäckiges Problem, und zuvor ging alles. Dann dieses komische Verhalten und das bei nun vollkommen abgespeckten Eingaben…

Ja die eine Versandkostenregel ist der einen Versandarten zugeordnet.

wenns vorher ging, kann och mir nur eine grundlegende Änderung vorstellen. Z.b. das Land ist anders, oder ide Produkte nicht mehr in der Kategorie.
Hast du es mal mit einem anderen Benutzer probiert?

Es geht kein Benutzer, auch nicht ohne Kundenkonto. Welche Rolle spielen die Artikel in Kategorien?
Ich habe jetzt mal “
Bestellungen aus dem Ausland auch dann erlauben, wenn keine Versandkosten für das Land vorhanden sind!” aktiviert.
Neben er Meldung des Moduls “DPD:Keine gültige Versandkostenregel gefunden” gibt Oxid nun noch “Derzeit ist keine Versandart für dieses Land definiert…” aus.
Das meint aber vermutlich das gleiche, zumal ich nun AUT auch deaktiviert habe.

Hallo,

ich bin mir nicht ganz sicher, aber entferne doch bitte mal die Zuordnung aller Benutzergruppen.

[QUOTE=ab2211;182242]
Eine Zahlungsart: Vorauskasse
Länder DE /AUT
Benzutzergruppe alle / Benutzer keine
[/QUOTE]
Wurden keine Benutzergruppen zugeordnet, gilt die Zahlungsart für alle Benutzergruppen, also auch für Benutzer, die der Shop noch gar nicht kennt und eingeordnet hat.

Gruß
Jürgen

Nee, geht auch nicht.

gehe zurück auf Los … :
lege einfach mal ein [U]neue[/U] Zahlungsart + Versandart + Versandkostenregel an und mach nur die [U]notwendigsten[/U] Zuordnungen …

[QUOTE=patchwork.de;182257] … :
lege einfach mal ein [U]neue[/U] Zahlungsart + Versandart + Versandkostenregel an und mach nur die [U]notwendigsten[/U] Zuordnungen …[/QUOTE]

hat das geholfen?

Hallo @ab2211,

kannst Du mal herausbekommen, welche MySQL-Version bei Dir im Einsatz ist? Wir haben hier so einen Verdacht…

Gruß

[QUOTE=Marco Steinhaeuser;182355] … welche MySQL-Version bei Dir im Einsatz ist? [/QUOTE]

… und ob es nach dem 13.08 ein Upgrade des mysql gab …

Wir haben genau das gleiche Problem - seit ca. 2-3 Tagen.

Bei uns kam erst der Fehler, dass Bestellungen keine Versandart mehr angezeigt haben und nachdem man diese als “versendet” markiert hat, wandelte sich die Zahlungsart in “Empty” um. Nun geht aber fast gar nichts mehr.

Sind gerade auch dabei zu erfragen ob es ein MySQL-Update gab - bin gespannt. :slight_smile:

Für alle mit dem selben Problem, haben es gerade mit Julischka gelöst:
Die index.php des Shops um folgendes erweitern:

$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

Danach sollten die Fehler weg sein.

Leider hilft das nicht immer. Wir hatten auch so einen Fall nach Update auf MySQL 5.7 und wir hatten serverseitig alles so eingestellt, wie es hier (in den Kommentaren) angegeben wurde: https://bugs.oxid-esales.com/view.php?id=6247 . Sah auch zunächst so aus, als würde das helfen, aber nach ein paar Tagen tauchte das Problem wieder auf.

Siehe auch hier: http://forum.oxid-esales.com/showthread.php?p=182365#post182365.

[KORREKTUR]
Ich sehe gerade, dass ‘derived_merge’ gar nicht enthalten ist in den Settings, die im Bugtracker angegeben wurden. Vielleicht ist das dann doch der entscheidende Hinweis! Ich werde mal testen.

Ich habe gerade eine Bestellung aus dem Ausland hereinbekommen,es ist also nur sporadisch.
“Derived merge off” hilft leider nichts.

Auch Browser- cookies löschen, hilft nichts.

Liegt es vielleicht an einem Modul? Benutzt Ihr auch alle amazon-payment von JAG?

@patchwork.de:Englische Fehlermeldung kam bei skipped View, weil ich englisch als Hauptsprache habe.

Ich habe im falschen thread gepostet. Es wollte eigentlich dieser http://forum.oxid-esales.com/showthread.php?t=40141 sein.


Oxid 4.9.7
Server:
Perl-Version: 5.20
MySQL-Version: 5.7
.htaccess:
AddHandler x-httpd-php54 .php

Hallo - nach der Umstellung auf MySQL 5.7 laufen die Versandkostenberechnungen nicht mehr wie gewohnt. Es kommt bei bislang funktionalen Versandregeln zu sporadischem Fehlverhalten der Berechnung der Versandkosten im Shop. Auch ein Update auf die 4.10.1 bringt keine Änderung.

@Marco äußerte einen Verdacht. Welcher wäre das?

Vielleicht hat es etwas damit zu tun, daß manchmal keine Versandkosten für das Land gefunden werden.

Ein Workaround ist, die index.php so zu ändern:

require_once dirname(FILE) . “/bootstrap.php”;
//wegen Problem mit mySql 5.7
$oDb = oxDb::getDb();
$sQ = “SET SESSION optimizer_switch = ‘derived_merge=off’”;
$oDb->execute($sQ, array());

[QUOTE=Marco Steinhaeuser;182355]Hallo @ab2211,

kannst Du mal herausbekommen, welche MySQL-Version bei Dir im Einsatz ist? Wir haben hier so einen Verdacht…

Gruß[/QUOTE]

Ich habe in meiner Not auch bei Alfahosting nachgefragt, ob sich etwas geändert hat. Angeblich haben sich PHP und MySql Versionen in dem Zweitraum geändert.

Administration: Confixx 3.3.1
PHP-Version(en): 4.4, 5.2 bis 5.6, 7.0
Perl-Version: 5.20
MySQL-Version: 5.7

PHP ist aktuell auf 5.3.

“die einzigen Änderungen in letzter Zeit fanden, wie angekündigt, am 19.08.2016 statt. Hier wurden die PHP-Versionen sowie die MySQL-Version aktualisiert.”

Man mag es kaum glauben, aber nach Ewigkeiten, geht es nun wieder! Anfangs dachte ich, einmal kurz drüberschauen würde reichen…

Für mich war dann, nebst der Provider-Anfrage, wirklich nur noch ein “Reset” hilfreich.
Doch, das schlimme ist: Wo der Fehler lag weiss ich nicht!