Beiträge von Mario_b

    ok ich korrigier mich, so unerklärlich ist es doch nicht , diese neuberechnung bei zweimaligem speichern ist schuld gewesen..


    Wenn ich folgendermaßen vorgehe :

    1. ersten Artikel hinzufügen ->speichern
    2. Versandkosten hinzufügen (14,50)->speichern
    3. einen weiteren Artikel hinzufügen ->speichern

    bekomme ich :

    1 x Dell Laptop DEMO 001 756.30 EUR 756.30 EUR
    1 x Dell Laptop DEMO 3 001 840.34 EUR 840.34 EUR

    Zwischensumme: 1.596,64 EUR
    DP 14,50 EUR
    UST 19% 303,36 EUR
    Gesamtsumme: 1.754,84 EUR

    hier wird zunächst nur einmal UST berechnet, wenn ich danach NOCHMAL abspeicher ohne was zu ändern, passt das gesamtergebnis wieder, vielleicht hilft das als lösungsansatz bzw lässt erahnen was da eigentlich schiefläuft?:

    Zwischensumme: 1.596,64 EUR
    DP 14,50 EUR
    UST 19% 303,36 EUR
    Gesamtsumme: 1.914,50 EUR

    mir schwirrt grad etwas der kopf, insgesamt lässt sich, mal abgesehen von der aktuell nötigen, "Doppelabspeicherung", aber wohl sagen, das das problem hauptsächlich die Versandkosten brutto/netto thematik betrifft, was dann m.E.folgendermaßen aufgebaut sein sollte :

    Versandkosten netto eingeben

    Zwischensumme(Artikelpreis netto)
    Versandkosten netto
    Neu : SUMME NETTO
    zzgl ust 19:
    Summe brutto

    Okay, dann mal los :

    Voraussetzungen :
    1 kundenkonto Händler

    Einstellungen unter Kundengruppe:
    Preise inkl ust : NEIN
    "Ust in RG ausweisen: JA"

    Nach "kunden->neue Bestellung->Artikel einfügen" (wie gesagt Händlerkunde!)-> Laptop Demo (Artikelnr 001) wird zunächst nur der Nettopreis berechnet:

    Zwischensumme: 756,30 EUR
    UST 19% 143,70 EUR
    Gesamtsumme: 756,30 EUR

    Wenn ich diese Order nun einfach nochmal Abspeicher (speichern und neu berechnen-Button) bekomme ich das folgende, richtige Ergebnis :

    Zwischensumme: 756,30 EUR
    UST 19% 143,70 EUR
    Gesamtsumme: 900,00 EUR

    Füge ich nun Versandkosten 14,50 € (brutto) hinzu, erhalte ich folgendes :

    Deutsche Post 14,50 EUR
    Zwischensumme: 756,30 EUR
    UST 19% 143,70 EUR
    Gesamtsumme: 914,50 EUR

    Die Gesamtsumme stimmt in diesem Fall auch, allerdings ist die ausgewiesene ust falsch :
    versandkosten 14,50 ergeben netto : 12,185 € + Artikelnetto 756,30 = 768,485 *1,19 =914,50 (korrekt) , ABER : die ust wird mit 143,70 angegeben, das haut nicht hin :
    richtig wäre 768,485 /100 *19 = 146,015 ust

    rechnen wir die summen aus obigem beispiel zusammen, sieht man auch schon dass es nicht hinhaut : vk netto 12,185 + artikelnetto 756,3 + ust 143,70 = 912,185 , es fehlen hier also die 2,315 ust aus den Versandkosten.

    Richtig anstrengend bzw mir gerade nicht erklärlich, wirds allerdings wenn ich einer Bestellung noch einen weiteren Artikel hinzufüge, dazu gleich mehr im nächsten post. Bitte spielt damit auch ein wenig herum so wie ich hier, dann sieht man leider schnell, dass es insgesamt noch nicht passt !

    ich pers. bin mit estugo sehr zufrieden, nicht der günstigste Anbieter aber dafür stimmt der Support, die setzen dir die Servereinstellungen so wie du sie haben willst und du hast 2-3 Ansprechpartner mit Namen und musst dich nicht durch gesichtslose Hotlines oder Supportformulare quälen wenn du unkompliziert hilfe suchst.

    Zu deienr anderen Frage : die Menge wird direkt in der "procucts"-table gespeichert (products_quantity)

    ich mach das bei zwei Kunden über `n kleines Importscriptdirekt über die Datenbank, die bestandsführende Stelle legt mir alle paar Stunden `n csv auf den Server, dieses enthält eben bestandsangaben +eindeutige Artikelnummer, das wird eingelesen und der Shopbestand damit laufend aktualisiert.
    Mit besten Grüßen

    Mario

    Moin,

    nach der Installation des V2 Trackingsmoduls aus eurem Shop nach Anleitung gibt es einen SQL Fehler beim Aufruf der Kundenbestellungen (Gehe auf Kunden->Bestellungen) "you have an error blabla"

    mit folgender Änderung klappts dann wieder, ist aber Quick`n Dirty :

    innerhalb der order_overview.php

    Original :

    $orders_split = new splitPageResults($_GET['page'], ($_GET['anzahl']!='')?$_GET['anzahl']:'20', $orders_query_raw, $orders_query_numrows);
    $orders_query = xtc_db_query($orders_query_raw);
    $rows = 1;

    umbauen/ergänzen in:

    $orders_query = xtc_db_query($orders_query_raw);
    $orders_query_numrows = xtc_db_num_rows($orders_query);
    $orders_query_numrows = ($orders_query_numrows == 0) ? 1 : $orders_query_numrows;
    $orders_split = new splitPageResults($_GET['page'], ($_GET['anzahl']!='')?$_GET['anzahl']:'20', $orders_query_raw, $orders_query_numrows);
    $rows = 1;

    greets

    Mario

    Hm na sagen wir mal so... das System hat auch seine Tücken! aber du hast schon recht, ansich ist es mit das beste was ich derzeit kenne und du scheinst ja nur 1 Produkt zu vertreiben, da wird sich der Stress wahrscheinlich in grenzen halten ;)

    ok ich habs endlich endlich gefunden, das Thema hat mich wahnsinnig gemacht udn ich hab immer an den falschen stellen gesucht... ^^

    hier mein Post aus dem normalen (nicht-Plus) forum dazu:

    Hey,

    bei aktiviertem 1 page checkout gibt es ein massives Problem : Die eingetragenen Bankdaten werden teilweise nicht übermittelt, d.h. man hat dann eine Bestellung auf Lastschrift ohne die nötigen Daten diese auch einzuziehen - das Problem betrifft alle V2 und V2.1 Shops, der Fehler ist im Demoshop nachvollziehbar.

    Folgendes passiert: die Lastschriftdaen werden ja nicht in der Session gespeichert sondern nach Klick auf den Speichern Button nur als "checkout_hiddens" im Formular hinterlegt. DasProblem : wenn der Kunde einen ANDEREN speichern Button als den bei den Zahlungsmodulen drückt, also z.B. Versandart, aber genauso Abweichende Lieferadresse etc, NACHDEM er den Speichernbutton gedrückt hat, werden die Checkout_hiddens zurückgesetzt und die Bestellung wird durchgeführt, wie gesagt OHNE Lastschriftdaten!

    Also nochmal kurz zusammengefasst : so ist alles ok:

    Kunde klickt erst auf den Versandart speichern-Button
    Kunde gibt bankdaten ein und klickt bezahlart speichern-Button
    Kunde klickt auf bestellen -> alles ok

    So gehts schief (und das kommt oft vor...) :
    Kunde wählt Zahlart aus, gibt Bankdaten ein und drückt speichern
    Kunde sucht sich erst anschließend die Versandart aus und drückt speichern -Bankdaten weg, checkout aber möglich
    ODER
    Kunde wählt alternative Liefer/Rechnungsadresse-> ebenfalls Bankdaten weg
    usw usw (bei anschließender verwendung von Gutscheincodes gehten die Dateh ebenfalls verloren)

    Meinn Quickfix :

    includes/xajax.checkout.php

    Alle vorkommen folgender Zeile (AUSSER die in der updatePaymentModule() Funktion! ) auskommentieren.

    also z.B.um Zeile 260 innerhalt der updateShippingModule
    document.getElementById('checkout_hiddens').innerH TML = '$payment_button';

    auskommentieren da hierdurch bei klick auf den Speicherbutton die Bankdaten gelöscht werden (die Variable payment_button ist in dieserFuntkion nämlich leer)

    Die Zeile kommt noch mehrfach vor, z.B. bei usGVund den Funktionen zum aktualisieren der Shippingoder billing-adress, dort am besten ebenfalls rausnehmen.

    Wie gesagt, das ist nur ein Quickfix, eleganter wäre es wohl, wenn die Daten in der in der Session abgelegt würden bzw man das problem an EINER stelle (banktransfer.php)löst und nicht an X stellen in der xajax.checkout.php wie hier von mir vorgesschloagen.

    Wie gesagt, derFehler ist jederzeit in eurem Testshop nachvollziehbar, und es ist ein ziemlich heftiger, es wäre also schön,. wenn ihr dies im nächstenQF berücksichtigen könntet!

    Mit besten Grüßen aus Hamburg

    Mario

    Hey Gevev,

    Das Lastschriftmodul dient nur dazu dir die Bankdaten des Kunden übermitteln zu lassen, sodass du anschließend ein e Lastschrift auslösen kannst, hier werden aber keinerlei dtaus dateien o.ä.erzeugt, d.h. du bekommst damit die Bankdaten , mehr passiert aber auch erstmal damit nicht!

    Mit besten Grüßen

    Mario

    Hey,

    bei aktiviertem 1 page checkout gibt es ein massives Problem : Die eingetragenen Bankdaten werden teilweise nicht übermittelt, d.h. man hat dann eine Bestellung auf Lastschrift ohne die nötigen Daten diese auch einzuziehen - das Problem betrifft alle V2 und V2.1 Shops, der Fehler ist im Demoshop nachvollziehbar.

    Folgendes passiert: die Lastschriftdaen werden ja nicht in der Session gespeichert sondern nach Klick auf den Speichern Button nur als "checkout_hiddens" im Formular hinterlegt. DasProblem : wenn der Kunde einen ANDEREN speichern Button als den bei den Zahlungsmodulen drückt, also z.B. Versandart, aber genauso Abweichende Lieferadresse etc, NACHDEM er den Speichernbutton gedrückt hat, werden die Checkout_hiddens zurückgesetzt und die Bestellung wird durchgeführt, wie gesagt OHNE Lastschriftdaten!

    Also nochmal kurz zusammengefasst : so ist alles ok:

    Kunde klickt erst auf den Versandart speichern-Button
    Kunde gibt bankdaten ein und klickt bezahlart speichern-Button
    Kunde klickt auf bestellen -> alles ok

    So gehts schief (und das kommt oft vor...) :
    Kunde wählt Zahlart aus, gibt Bankdaten ein und drückt speichern
    Kunde sucht sich erst anschließend die Versandart aus und drückt speichern -Bankdaten weg, checkout aber möglich
    ODER
    Kunde wählt alternative Liefer/Rechnungsadresse-> ebenfalls Bankdaten weg
    usw usw (bei anschließender verwendung von Gutscheincodes gehten die Dateh ebenfalls verloren)

    Meinn Quickfix :

    includes/xajax.checkout.php

    Alle vorkommen folgender Zeile (AUSSER die in der updatePaymentModule() Funktion! ) auskommentieren.

    also z.B.um Zeile 260 innerhalt der updateShippingModule
    document.getElementById('checkout_hiddens').innerHTML = '$payment_button';

    auskommentieren da hierdurch bei klick auf den Speicherbutton die Bankdaten gelöscht werden (die Variable payment_button ist in dieserFuntkion nämlich leer)

    Die Zeile kommt noch mehrfach vor, z.B. bei usGVund den Funktionen zum aktualisieren der Shippingoder billing-adress, dort am besten ebenfalls rausnehmen.

    Wie gesagt, das ist nur ein Quickfix, eleganter wäre es wohl, wenn die Daten in der in der Session abgelegt würden bzw man das problem an EINER stelle (banktransfer.php)löst und nicht an X stellen in der xajax.checkout.php wie hier von mir vorgesschloagen.

    Wie gesagt, derFehler ist jederzeit in eurem Testshop nachvollziehbar, und es ist ein ziemlich heftiger, es wäre also schön,. wenn ihr dies im nächstenQF berücksichtigen könntet!

    Mit besten Grüßen aus Hamburg

    Mario

    Hallo Allerseits,

    ich habe (seit längerem) folgendes Problem : in allen von mir eingesetzten V2 Shops gibt es Probleme mit dem Lastschriftmodul.

    Es kommt regelmäßig, aber für mich bisher nicht reproduzierbar, zu folgendem Phänomen :

    Bestellungen mit Lastschrift gehen ein, ohne dass die entsprechenden Bankdaten aufgenommen wurden, der Ärger bei den Händlern ist jedesmal groß.

    Was ich bisher eingrenzen konnte :

    Fax-Bestätigung ist überall deaktiviert, daran liegts also nicht
    Die Banktransfer-table gibt einen Hinweis : die betroffenen Bestellungen enthalten neben der Order_id nur die banktransfer_status "10" , laut der Datei bedeutet dies, dass kein Kontoinhaber übermittelt wurde (allerdings hätte dann die Bestellung nicht erfolgreich durchgeführt werden dürfen). Evtl spielt hierbei das "Vorausfüllen" des Kontoinhabers eine Rolle ? (der Kontoinhaber wird aus den Kundendaten vorausgefüllt).

    Ich krieg den Fehler nicht reproduziert, egal was ich mache es klappt alles... allerdings kommt der Fall viel zu häufig vor um ignoriert zu werden , 15-20% der Lastschriftzahlungen meiner Projekte sind betroffen, wie gesagt verteilt auf diverse Shops..

    Es scheint allerdings kein "reines" commerce:seo V2(.1) Problem zu sein, sondern vielmehr am dort verwendeten Ajax 1Page-Checkout Modul zu liegen : ich habe den 1Page checkout auch in einem XTC Shop laufen, dort taucht das Problem ebenfalls auf, da der Checkout aber ein ganz wesentlicher Bestandteil von Commerce:seo ist, hoffe ich, dass ihr euch der Thematik annehmt, ich habe hier im Forum auch schon Posts mit der gleichen Problematik gefunden (dden 1 Page abschalten ist aber KEINE Lösung!)

    Mit besten Grüßen aus Hamburg

    Mario

    moin moin, ich fand das auch zunächst verwirrend, eigentlich fand ich die darstellung wie sie vorher war besser, also dort die cseo-tools, die habt ihr ja jetzt auf die anderen punkte verteilt irgendwie oder?

    noch eine Anregung : ihr habt ja die commerce_seo_url_cronjob.php (sehr sehr praktisch, subba feature!) aber ich denke die nutzt kaum eienr da ihr das nirgends so recht kommuniziert...