Grundlegendes Problem in checkout_process.php?

So ist es! Das ist absurd, denn letztendlich sollte - ob Offerte oder nicht - der Kunde dann eine Bestellung aufgeben, wenn er auf Kaufen klickt. Egal, welche Zahlweise er wählt. Bricht er beim Zahlvorgang ab, ist es unlogisch, dass eine Bestellung generiert wird. Vielleicht hat es sich der Kunde ja auch anders überlegt.

Sobald die Bestellbestätigung raus ist, haben wir die Offerte angenommen - Kaufvertrag ist damit geschlossen. Da der Shop die Bestellung generiert, der Kunde aber keine Bestellbestätigung bekommt, ist der Lagerstand im A*** Mir ist auch aufgefallen, dass manchmal der Lagerbestand nicht reduziert wird. Ich muss nun bei jeder fett markierten Bestellung prüfen, ob der Lagerbestand wirklich abgezogen wurde. Das ist völlig irre, wenn man mehr als ein paar Bestellungen am Tag hat.

 

Ja, das Problem sehe ich auch bei vielen Shops.

Aber es gibt tatsächlich auch Shops, die gar keine sofortigen externen Zahlungsmöglichkeiten anbieten, weil die Produkte nicht einfach aus dem Lager geholt und verschickt werden können, sondern zuvor noch in irgendeiner Weise konfektioniert werden müssen (bis hin zur Sonderanfertigung, aber nicht nur).

In diesen Fällen ist der derzeitige Checkout-Ablauf ideal:
1. Kunde drückt auf "kaufen"
2. Bestell-Eingangs-Bestätigung wird verschickt und Lagerbestand sinkt
3. Verkäufer prüft die Bestellung
4. Verkäufer mailt Auftragsbestätigung (ausserhalb von Gambio), mit Zahlungsaufforderung zur Vorkasse (Überweisung oder PayPal oder...)
(wie gesagt: Im Checkout wurde zuvor nur Vorkasse und Nachnahme angeboten!)
5. Kunde zahlt
6. Verkäufer verschickt nach Zahlungseingang

Wie gesagt: bitte vergesst diese Art von Shops nicht bei einer evtl. Check-Out-Umstellung.
Ich denke, die beste Variante wäre die Auswahlmöglichkeit...

 

Deine Lösung, Avenger, scheint ja zu funktionieren.
Ich hab das ja mal eingebaut und komme bis paypal und wenn ich dann parallel schaue ist der Bestand noch nicht reduziert.
Nur bei der Rückleitung von PP in den Shop kommen die hier beschriebenen Fehlermeldungen:
http://www.gambio-forum.de/threads/...ut_process.php?p=114581&viewfull=1#post114581

Hast Du ne Erklärung, woran das liegen könnte?

 

Ich habe den "Fehler" gefunden, der zu den SQL Fehlern geführt hat, manchmal liegt es nur an einem Buchstaben.

Bei

PHP:

foreach ($update_sqls as $update_sql)
        {
          xtc_db_query($update_sqls);
        }

ist ein "s" zuviel und es muss lauten:

PHP:

foreach ($update_sqls as $update_sql)
        {
          xtc_db_query($update_sql);
        }

Damit funktioniert schonmal die nachgelagerte Lagerbestandsanpassung.

Allerdings sind mir noch 2 kleinere Probleme aufgefallen, derer ich mich noch versuchen werde.

1. Das SOFORT Plugin kennt die "alte" Gambio-Weise und passt nach abgebrochener Zahlung den Lagerbestand wieder nach oben an. Das ist hierbei natürlich doof, weil das ja gar nicht mehr nötig ist. Diese Funktion muss dann abgeschaltet werden.

2. Die Session wird nicht verworfen, wenn ein Kunde eine temporäre Zahlungsweise abbricht und dann zum Shop zurückkehrt und z.B. Vorkasse wählt. Dann wird am Ende durch die checkout_process.php der Lagerbestand doppelt angepasst, also einmal für die Vorkasse-Zahlungf und einmal noch für die nicht verworfene Session. Die Session muss natürlich vor einer Vorkasse Zahlung verworfen werden.

Werde mir das heute abend mal angucken.

MfG

 

So, die beiden Probleme sind behoben, eigentlich war es nur 1, was sich aber auf beide genannten Dinge auswirkte.

Damit das SOFORT Plugin den Lagerbestand bei einem Abbruch nicht wieder drauf rechnet, muss in der Datei /callback/sofort/sofort.php nach folgendem gesucht werden:

PHP:

    function _gambio_remove_order($order_id, $restock = false, $canceled = false, $reshipp = false) {
        //following code is NOT formatted for better comparison in case of future changes!
        
        if ($restock == 'on' || $reshipp == 'on')
        {
            // BOF GM_MOD:
            $order_query = xtc_db_query("
                                        SELECT DISTINCT
                                            op.orders_products_id,
                                            op.products_id,
                                            op.products_quantity,
                                            opp.products_properties_combis_id,
                                            o.date_purchased
                                        FROM ".TABLE_ORDERS_PRODUCTS." op
                                            LEFT JOIN ".TABLE_ORDERS." o ON op.orders_id = o.orders_id
                                            LEFT JOIN orders_products_properties opp ON opp.orders_products_id = op.orders_products_id
                                        WHERE
                                            op.orders_id = '" . xtc_db_input($order_id) . "'
            ");

und

PHP:

op.products_quantity,

ersetzt werden durch

PHP:

0 as products_quantity,

Außerdem ist beim Code von Avenger noch ein xtc_db_query doppelt.

PHP:

xtc_db_query(xtc_db_query($status_update_sql));

ändern in

PHP:

xtc_db_query($status_update_sql);

Damit sollte die Lösung von Avenger dann rund laufen für die Zahlarten Vorkasse, Paypal und Sofort-Überweisung.
Was mit den anderen Zahlungsweisen ist, habe ich nicht getestet.

Mit freundlichen Grüßen

 

Nach längerer Testphase (nun auch im LIVE-Betrieb) kann ich vermelden, dass alles zur allerbesten Zufriedenheit klappt.
KEINE Abbrüche mehr, die nicht vom Kunden bewusst gewollt sind.
Gerade das Problem, wenn nur noch 1 Artikel da ist, dass dieser dann schon vor dem Bezahlen vom Lagerbestand abgezogen wird, ist weg und der Kunde kann auch gerne nochmal von Paypal zurück und SOFORT-Überweisung oder etc. wählen.

Auch durch Paypal 2.3 ist nochmal eine Verbesserung zu spüren gewesen.

 

Was meinst Du mit gar keine Bestandsprüfung?
Der Kunde kann aber nicht 5 bestellen, wenn nur noch 1 Teil da ist, oder?

Eigentlich ist das ja auch schon wieder ein weiteres Thema.
Das Problem mit den Abbrüchen bei geringem Warenbestand ist bei uns jetzt komplett weg, weil dieser erst NACH dem Bezahlen runtergesetzt wird.
Das dort laut Deinen Schilderungen eine zusätzlich Prüfung fehlt, ist ja schon wieder ein neuer Bock....

 

Das geht nicht grundsätzlich. Theoretisch wäre es aktuell nur möglich, wenn 2 Bestellungen gleichzeitig gemacht werden (fast ohne Zeitunterschied). Denn im Warenkorb und so sind die Prüfungen weiterhin enthalten. Ein einfaches durchklicken mit Paypal oder ähnlichen Modulen ist so nicht möglich.

MfG,
Timo

 

Hallo zusammen,
die Lösung von Avenger funktioniert ja nicht mehr bei Shops ab V3.

Hat vielleicht jemand eine Ahnung, wie ich die Lösung in diesem Post: http://www.gambio.de/forum/threads/grundlegendes-problem-in-checkout_process-php.9757/#post-72474 auch in der neuen Gambio Version umsetzen kann?

Danke...

 

Hallo, gibt es diesbezüglich denn noch keine Lösung???

 

Nein, da hat sich nichts geändert.