Grundlegendes Problem in checkout_process.php?

Thema wurde von Avenger, 14. Februar 2013 erstellt.

  1. Petra

    Petra G-WARD 2013/14/15

    Registriert seit:
    27. August 2011
    Beiträge:
    6.998
    Danke erhalten:
    1.225
    Danke vergeben:
    227
    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*** :D 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.
     
  2. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    6. Juni 2012
    Beiträge:
    427
    Danke erhalten:
    64
    Danke vergeben:
    67
    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...
     
  3. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Auch da hast Du m.E. Recht....

    Und es wäre auch technisch möglich (und sinnvoll), die für den Zahlungsvorgang gespeicherte Bestellung wieder zu löschen...

    Denn der Besucher wird dann ja wieder auf die Zahlungsseite geleitet, und kann den Checkout-Vorgang wiederholen, wobei wieder eine neue Bestellung entstehen würde, falls er das will.

    Nur darf dann der Lagerbestand wirklich erst angepasst werden, wenn die Zahlung erfolgt.
     
  4. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62
  5. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62


    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
     
  6. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62
    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:
    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
     
  7. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62
    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.
     
  8. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Es gibt aber ein anderes potentielles Problem, wie ich mittlerweile herausgefunden habe:

    bei allen Zahlungsarten, die eine externe Anwendung zur Zahlung verwenden, wird gar keine Bestandsprüfung gemacht!

    In "checkout_process.php" wird eine Bestandsprüfung nur vorgenommen, wenn die Zahlungsart nicht eine der folgenden ist:

    PHP]f(STOCK_ALLOW_CHECKOUT == 'false'
    && $_SESSION['payment'] != 'paypalng' // PayPalNG
    && $_SESSION['payment'] != 'paypal'
    && $_SESSION['payment'] != 'paypal_gambio'
    && $_SESSION['payment'] != 'paypalgambio_alt'
    && $_SESSION['payment'] != 'sofortueberweisung_direct'
    && $_SESSION['payment'] != 'pn_sofortueberweisung'
    && $_SESSION['payment'] != 'clickandbuy_v2'
    && $_SESSION['payment'] != 'postfinance_epayment'
    && strpos($_SESSION['payment'], 'sofort_') === false
    && strpos($_SESSION['payment'], 'moneybookers') === false
    && strpos($_SESSION['payment'], 'vrepay') === false
    && strpos($_SESSION['payment'], 'ipayment') === false)
    {[/PHP]Das geht m.E. gar nicht, und könnte die Ursache dafür sein, dass immer wieder Artikel bestellt wurden, die keinen Bestand mehr hatten.

    Das Argument, dass bei diesen Zahlungsarten dieser Code mehrfach durchlaufen würde (vor und nach der Zahlung) ist m:E. nicht stichhaltig, da man anderweitig sicher stellen kann, dass die Bestandsprüfung nur vor der Zahlung geprüft wird:

    PHP:
    if(STOCK_ALLOW_CHECKOUT == 'false' && !isset ($_SESSION['tmp_oID']))
    {
    Eine gesetzte "$_SESSION['tmp_oID']" ist nämlich das Kennzeichen dafür, dass zuvor auf eine externe Zahlungsart verzweigt wurde.
     
  9. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62
    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....
     
  10. Avenger

    Avenger G-WARD 2012/13/14/15

    Registriert seit:
    26. April 2011
    Beiträge:
    4.771
    Danke erhalten:
    1.478
    Danke vergeben:
    89
    Doch, kann er, weil der Bestand bisher nicht geprüft wird bei diesen Zahlungsarten.

    Aber das wird demnächst geändert.

    http://www.gambio-forum.de/threads/...t_process-quot?p=128917&viewfull=1#post128917

    Kannst das aber vorab ja schon mal anpassen...
     
  11. Timo (Gambio)

    Timo (Gambio) Administrator

    Registriert seit:
    23. Juni 2011
    Beiträge:
    1.688
    Danke erhalten:
    651
    Danke vergeben:
    46
    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
     
  12. maxwell

    maxwell Erfahrener Benutzer

    Registriert seit:
    2. März 2012
    Beiträge:
    148
    Danke erhalten:
    18
    Danke vergeben:
    62
  13. Detektormann

    Detektormann Mitglied

    Registriert seit:
    25. März 2014
    Beiträge:
    24
    Danke erhalten:
    0
    Danke vergeben:
    12
    Hallo, gibt es diesbezüglich denn noch keine Lösung???
     
  14. Wilken (Gambio)

    Wilken (Gambio) Erfahrener Benutzer

    Registriert seit:
    7. November 2012
    Beiträge:
    18.737
    Danke erhalten:
    7.309
    Danke vergeben:
    2.208
    Nein, da hat sich nichts geändert.