Beiträge von Milbo

    Es gibt einige Stati, welche fest zugeordnet sind.


    Der Warenkorb von VM läuft seit VM2 exakt nach der deutschen Juristischen Sicht (ich habe mich genau daran orientiert und das hat zwar anfangs für etwas verwunderung gesorgt, aber inzwischen ist genau das Vorschrift).


    Einmal gibt est P bzw Pending oder Schwebend, es entspricht dem Ware aufs Band legen. Der Kunde äussert die Absicht etwas zu kaufen. Der Kassierer im Supermarkt gibt die Waren ein. In diesem Moment ist in der Kasse ein Auftrag entstanden. Irgendwie muß man den ja festhalten. Das ist P. und nennt den Betrag.
    Jetzt erst bestätigt man juristisch betrachtet den Kauf, in dem man der Bezahlung zustimmt. Wie auch immer die dann geschieht. Wenn man z.B. eine Creditkarte nutzt, bezahlt man auch juristisch betrachtet später (die Kreditkartenfirma bürgt aber dafür, daher,...).
    Dafür haben wir U, confirmed by shopper, vom Kunden bestätigt. Je nach Besteuerung (ist oder soll) wird eine Rechnung erstellt. VM ist standarmässig auf IST-Besteuerung eingestellt (Rechnungserstellung bei C).
    Der Status C für Confirmed, Bestätigt steht an sich für einen abgeschlossen Kaufvertrag. Momentan impliziert es auch, daß die Ware bezahlt wurde, aber genau das wird mit dem nächsten Update behoben. Es gibt dann eine neue Variable, "paid", wieviel wurde bezahlt.


    Ansonsten gibts halt noch R für Refund und X für Cancel (D Denied benutzen nur manche Bezahlmethoden). Es ist nicht sinnvoll diese Orderstati anders zu verwenden. Der Core hat relativ wenig Stellen mit fest eingebauten Orderstati, aber auch viele Erweiterungen setzen darauf.


    Es gibt momentan das Problem, das manche Kunden eine Rechnung brauchen, um die in ihrer Firma vorzulegen und daher kam ich auf den Gedanken das ganze mit einer extra Variable zu lösen. Der Witz ist natürlich später, das die Bezahlmethode das füllt. Man kann dann auch also auch einfacher Ratenzahlungen schreiben. Aber das wird dauern bis die angepasst sind und daher wird die Variable Paid automatisch gesetzt durch einen Orderstatus,.. und welcher ist das? C natürlich.


    Btw, warum ist Pending nicht in den emails für Kunden? Weil viele wie du dann darüber stolpern und fragen, und das ist besser als vorher, da haben es die Leute einfach wild genutzt und sich gewundert, warum VM nicht richtig läuft.

    COM_VIRTUEMART_PRODUCT_ENQUIRY_LBL ist der key.


    Lösch bzw verschiebe deine Sprachdateien in das jeweils relative Verzeichnis.


    es gibt /adminstrator/languages und /languages, aber eben auch immer in den Komponenten, Modulen bzw Plugins selber (/administrator/components/com_virtuemart/languages bzw /components/com_virtuemart/languages). Da sollten sie eigentlich hin. VM gibt diesen Sprachdateien den Vorzug.

    Also, das mit den Regeln funktioniert. Vermutlich wurde eine Regel für die gesamte Bestellung und nicht pro Produkt erstellt.


    Es gibt mehrere Lösungen. Aber es ist richtig, die customfield Lösung funktioniert nicht wirklich.


    Man kann entweder einen Versand bauen, der nur über X kg angezeigt wird, und dem Produkt X kg geben (auch wenns leichter ist).


    Oder man kann eine Kategorie "Versand" erstellen, die hängt man ans Produkt und eine Rechenregel "Preisaufschlag nach Steuern PRO produkt", dann dort die Kategorie "Versand" einstellen.

    Hallo ins Forum,


    bei einer Kundenseite gibt es schon seit einiger Zeit den Wunsch einen Sperrgutzuschlag in Höhe von 10€ lediglich für Produkte einer bestimmten Kategorie zu erstellen.


    An die Steuer denken!



    folgendes ist nicht gewünscht:
    [LIST]
    [*]Lösung über selbsterstellte Felder, da dies ein aktives Mitwirken des Bestellers vorraussetzt


    wieso denn das?



    [*]Lösung über child products, da durch die Vielzahl der vorhandenen Kombimöglichkeiten(z.B. 170 Designs) zu große Artikeldaten erzeugt.


    Wie was? Falsche Denkweise. Es kostet nur ein Parentprodukt.



    das einfachste wäre es meiner Meinung nach eine Rechenregel zu erstellen und dort die Einträge wie im mitgesendeten Anhang zu tätigen. Leider werden die Kategorien gänzlich ignoriert und einfach für alle Produkte bzw. Bestellungen 10€ aufgeschlagen.


    Was kann helfen?


    Welche Rechenregel wurde denn erstellt? Eine Preisaufschlag nach Steuern pro Rechnung?

    "Ist in den Einstellungen der Kundengruppe "Kein Rechnungskunde" ein Haken bei "zusätzliche Kundengruppe" gesetzt?"


    Genau dieser Checkbox regelt das
    "Könnte es eventuell sein, dass bei dem betroffenen Kunden irgendwie "unsichtbar" noch die default-Gruppe hinterlegt ist?"


    Also deine Gruppe ist keine zusätzliche Gruppe und daher verdrängt deine Gruppe die default gruppe. So sollte es zumindest sein. Das kann man auch nicht in der DB rausfinden, weil das intern gesetzt wird.

    Und PayPal smart buttons setzt auf Express auf, es hat "nur" ein anderes Js von paypal. Bei Paypal express bzw Credit muss man die Buttons kompliziert konfigurieren, für verschiedene Sprachen (siehe der ganze KRam unten).
    Smart buttons erledigt das alles entspannt und enthält auch Paypal Credit, wenn das Land des Käufers dies unterstützt. Es ist sozusagen das "internationale" Paypal Plus. Es ist auch etwas fraglich, wie lange Paypal Plus noch als "german" Lösung bleibt.

    Servus, danke für deinen Bugbericht.


    Also mir ist da ein Fehler passiert in vmpsplugin.php (administrator/compononents/com_virtuemart/plugins). Da steht in Zeile 1075

    Code
    1. if(!empty($method->cost_percent_total)) $method->cost_percent_total = 0.0;
    2. if(!empty($method->cost_per_transaction)) $method->cost_per_transaction = 0.0;


    Das muß natürlich ohne die ! sein, das ist ein Fallback, falls die Methode keine 0, sondern nen " " leeren String gespeichert hat.

    Code
    1. if(empty($method->cost_percent_total)) $method->cost_percent_total = 0.0;
    2. if(empty($method->cost_per_transaction)) $method->cost_per_transaction = 0.0;

    Servus Red, die Sache ist relativ einfach,


    da gibts eine Option, die is bei dir nicht angehakt. "List Paypal method also among other methods"
    das ist recht weit oben, über die Überschrift "Bestellstatus".


    Desweiteren ist eigentlich das Paypal Express veraltet. Paypal empfiehlt die Smart buttons zu nehmen (einfach nur die Checkbox anhaken). Das ist sozusagen das neue Paypal Express.

    So, ich habe festgestellt, dass der Fehler mit dem Mutterprodukt zu tun hat und das Produkt inkl. der Kinder per Multi Variants noch mal neu eingefügt.


    Hmm, was war der Fehler? Weil sowas sollte nicht passieren. Welche Version nutzt du? Der Code dort sieht so aus

    Code
    1. $myoption = false;
    2. if(isset($field->options->$product_id)){
    3. $myoption = $field->options->$product_id;
    4. }
    5. if(!isset($myoption[$k])){


    Wie da aus $myoption ein object wird. Sehr rätselhaft mir fällt höchstens ein extra check ein wie

    Code
    1. $myoption = false;
    2. if(isset($field->options->$product_id)){
    3. $myoption = $field->options->$product_id;
    4. }
    5. if($myoption and !isset($myoption[$k])){

    Servus, interessantes Problem. Also ich kenne es teilweise und habe etwas ähnliches erst gestern gefixed.


    Ich habe ein suchbares Customfield erstellt und das in ein Patternprodukt eingetragen (unveröffentlichtes Stammprodukt) und die leere Option tauchte im Dropdown auf.


    Also das ist in der Tat nicht so trivial wie es scheint in deinem Fall. Beispiel, man hat ne List von specs, die soll immer gleich aussehen, jeder kennt es, daß da mal Werte nicht eingetragen sind. Bzw nur X da steht für "ist vorhanden". Ich glaube daher sieht man auch die leeren. Denn sonst zerhauts einen ja das Format.


    Tja und wie jetzt die leeren verstecken? Gleich keinen Wrapper zeigen? oder nur im Wrapper nix zeigen. ich plädiere "gleich keinen Wrapper zeigen" und ne extra param im customfield, so kann man es wählen.


    Wäre ne Membership.


    Oder als override in customfield.php (sublayouts) unter case 'M' also line 445 einfach das einsetzen


    if(empty($customfield->customfield_value)) continue;


    müsste reichen.