Wow Respekt, 400 Varianten.
Ja in deinem Fall würde ich das ganze gemischt machen. Und natürlich, es gibt viel mehr Möglichkeiten, wenn es nicht stockable ist. Siehe einfach die Sampeldaten Default Products : Product w/child variant w/cart variant
und mit vm3 macht das deutlich mehr Spass. Du solltest es wirklich testen.
Hi Milbo,
Der Kaufvertrag kommt (rechtlich gesehen) nach klicken des "Kaufen"-Buttons zustande. Ab dann sollte ein Shop auch in der Lage sein, automatisiert die Rechnungsinformation an den Kunden zu übersenden
Genau so ist es ja auch. Ob da der Kaufvertrag allerdings wirklich durch ist, sehe ich als fraglich an. Letztendlich steht dem Käufer der Irrtum "angebotene Bezahlmethoden gehen irgendwie nicht" imho zu.
Die Begrifflichkeiten sind bei anderen System übrigens:
- Pending "Bestellvorgang ausgelöst - ausstehende Zahlungen".
- Confirmed "Zahlung beim Verkäufer eingegangen / Zahlungvorgang abgeschlossen".
und wir haben ein "confirmed by shopper" dazwischen. Da wir um das Angebot richtig erstellen zu können bereits alles brauche. Da es ja auch möglich ist, das das payment die Rechnung stellt und garnicht VM.
(abgesehen davon empfinde ich es jetzt als schwierig, das ganze auf missverstandene Begrifflichkeiten zu schieben)
Wieso empfindest du das als schwierig? Es sind imho nur Begrifflichkeiten. Das Problem ist imho rein durch Konfiguration lösbar.
So steht es auch in dem bekannten VM2 Buch
Ehrm, wenn ich wüsst welches du meinst? Allein für den deutschsprachigen Raum gibts imho 3. Mindestens. Die meisten davon habe ich review gelesen. Allerdings sind die meines Wissens alle alt und nicht für vm2.6.
Das ist sehr seltsam. Das müsste richtig sein. Das brauchen schon einige.
Ach ich Blödmann.... jo ich habs nun!
Ganz einfach... wenn man unter Steuern & Rechenregel ---> MwSt. --> Einstellungen unter Land "Verfügbar für Alle". Da war nur Deutschland drin. Jetzt zeigt er, wie gewollt, nur die Nettopreise an und sobald man den Artikel zum Warenkorb hinzufügt, zeigt er im Warenkorb alles nötige an wie MwSt und Versand. TOP!!!!
Danke, aber richtig top wird es mit Shoppers : EU Vat ID checker und dem geolocator plugin. Dann funktioniert es auch richtig nach dem Gesetz. Den alle ausserhalb EU sehen es immer ohne Steuer und innerhalb EU im Zweifel erstmal mit. Zudem muss die euvatid geprüft und gelogged werden. Tja und bald kommt der 1. Januar und dann müssen wir die VAT des jeweiligen Landes nehmen.
Multivendor gibt es für diesen Fall bereits in vm2.6. Erweitertes Multivendor mit allem möglichen gibt es bereits für vm3
Ich glaube andersrum geht es. Guck dir diese Erweiterung an Products : Products Anywhere
Ich würde einfach mal die Sample Daten installieren, da ist das erklärt. oder http://demo.virtuemart.net/def…uct-w-cart-variant-detail
Hola ka3,
das klingt gar nicht gut...
Es muss doch eine Möglichkeit geben das zu realisieren. Das ist doch nun wirklich der Normalfall, ein Produkt mit z. B. verschiedenen Größen, eine funktionierende Bestandskontrolle, sowie eine funktionierende anzeige des Bestandes...
Greetz
habs mir nur grob durchgelesen. In Vm3 gibts virtuelles stocking für parents.
Als Normalfall würde ich es nicht bezeichnen. Es ist auch, egal wie man es löst, es wird immer etwas unlogisch, da es überbestimmt ist. Beispiel?
Produkt hat 50 Varianten, jede Variante ist 1 mal da => Stocking 50 => stocking Grün.
Produkt hat 50 Varianten, jede variante bis auf eine ist keinmal da, aber die eine 50 mal => Stocking 50 => stocking Grün.
und sag mir mal einer, was er selbst als "knapper" empfindet. Ich kann mich nicht entscheiden.
Produktvarianten sind eh eigentlich mehr als eine Art MiniKategorie zu betrachten. Denn Produktvarianten gibt es physikalisch sehr selten 
und ECHTE Varianten sind meist ohne Stocking. Der Druck auf einem T-Shirt z.B. ist eine ECHTE Variante, während T-Shirts in verschiedenen Größen schlicht und ergreifend verschiedene Produkte sind. Wir fassen sie zusammen zu einer Produktfamilie, aber eigentlich wenn man in sein Lager schaut und hat 50 T-Shirt stapel und nur ein Produkt im Store, denke ich man versteht was ich meine.
Da liegt ein Missverständnis vor.
Pending ist nur "Ich mache dir als Verkäufer ein Angebot"
Confirmed by shopper ist "ich, Käufer, stimme dem Angebot zu"
confirmed bedeuted "Der Kunde hat hat dem Angebot zugestimmt und bezahlt"
Der Kaufvertrag kommt erst bei "confirmed" zustande. Das heisst
Die Mail auf Pending zu setzen ist für 99% der shops falsch. Die Rechnung sollte auf dem orderstatus "confirmed" stehen und die Bestätigungsmail, tja kommt eigentlich auf deine Bezahlmethode an.
Irfanview erledigt das super schnell IrfanView - Official Homepage - one of the most popular viewers worldwide
Nettes Tool JJK. VM versucht sogar den Ram auf 96 MB oder so zu erhöhen. Kommt aber auf den Server an, ob der das zulässt.
Ja ehrm, es ist native ohne irgendwas extra möglich. Verstehe das Problem nicht so ganz.
Ich würd ma sagen es hängt mit der größe deines PHP Rams zusammen und die Bilder sind einfach zu groß (MB!).
Umgekehrt wird ein Schuh draus. B2C.
Danke für das kaufen der Membership. Also das template für die Versandkosten details ist seit 2.6.10 in beiden Versionen. eu weites B2B macht das euvatid plugin. Das Template ist im shipment plugin.
Das hängt von dir ab. VM3 läuft auf extensions.virtuemart.net seit mehr als einem Monat.
Einfach das "Wartet" rausnehmen. Überall.
Erstellung der Rechnung ist üblicherweise bei IST Besteuerung "Bestätigt" bzw Confirmed, kürzel C, bei SOLL Versteuerung "Confirmed by shopper".
Bei dir scheint "confirmed" dem "durch sofortzahlung bestätigt" zu entsprechen.
Die Lösung ist schon falsch, mach mal einen Discount, auf den Warenkorb. Klar sie funktioniert für dich und das ist auch gute Arbeit. Allerdings kann es eben auch passieren, dass durch deine Methode der Warenkorb was anderes anzeigt als die Rechnung.
Ja an sich schon ganz okey, ich bin nur immer enttäuscht, dass die Leute so wenig von vm erwarten. Es gibt auch Anleitungen unter
VirtueMart Wiki - VirtueMart und Tutorials - VirtueMart Documentation und Templating & Layouts
Richtig, verbesserungswürdig. Aber einigermassen vernünftig ;-). In kurz, nutze vmdebug('Was isn hier',$this); um rauszufinden, was dein Layout weiss. Da sieht man dann eben, das VM alle Regeln ordentlich sortiert, zusammenrechnet und auch dementsprechend abspeichert. Also verkürzt wäre das hier vmdebug('meine Regeln',$this->cart->cartData); Vmdebug versteht auch mehrere Variablen, also das ginge auch vmdebug('meine Regeln',$this->cart->cartData['VatTax'],$this->cart->cartData['Tax']);
Layouts lassen sich schlecht verkaufen. Entweder man verkauft sie als Bundle z.B. Themes : Theme Shoplicious oder man verkauft es als Anpassung, was den Kunden oft zu teuer ist. Persönlich würde ich so ein Layout für einen 5er verkaufen. Aber dafür einen installer bauen? und wenn ein Kunde von 10 ne Frage hat, frisst der Support wieder alles auf.
Daher die Lösung mit der Membership. In der Membership ist das Layout einfach drin. Ich betone:
Die Member version und die Community version sind die GLEICH! Es gibt keine verschiedenen Versionen! Die Memberversion hat nur etwas "Mehrwert", da eben z.B. derartige Layouts mitgeliefert werden. Diese sind auch GNU, d. h. es ist völlig i. O. eine Membership abzuschliessen und das layout in mehreren Shops zu benutzen, oder als templater in sein Template einzubauen (und zu verkaufen).
Es läuft in der Praxis so. Die "normale" Version wird veröffentlicht. Gerade in der ersten Woche tauchen immer gerne in selten genutzten Features schnell zu lösende Bugs auf. Die Fixes werden eingepflegt und als Memberversion veröffentlicht (oder als Fix im Forum). Es gibt auch immer wieder Wünsche von Silber, oder Gold membern, die werden mit eingepflegt. z.B. wurden die Versandkosten auf der Produktseite von einem Member bezahlt. Die nächste Community Version wird auf Basis der Memberversion weiterentwickelt. Das heisst die nächste Community version hat wieder fast alles von der Member version, bis eben auf die extra Layouts und ähnliches. Der Unterschied besteht also hauptsächlich im zeitlichen Versatz.
Letztendlich fliesst aber auch das wieder in die normale Version. So gibt die Rechnung in VM3 die Steuer immer mehrfach aus. Wegen der einen Zeile 2 layouts zu maintainen war auf Dauer zu teuer . Oder Die Versandkosten sind in der EU so elementar das ich das layout in die normale Version überführt habe, ausserdem war dieses Feature seit Jahren drin, es hat nur keiner genutzt/gekannt 
Tja und was macht die Membership noch? Sie garantiert im Falle von Security Problemen in VirtueMart UND Joomla!, das man eine verantwortliche Ansprechperson hat. Member können das Ticketsystem benutzen. Es ist also vom Handling wie ein normales gekauftes Produkt. Das erhöht natürlich die Sicherheit des Shops.
und wie man bei der letzten Sicherheitslücke sehen konnte. Jeder bekommt den Fix sofort. Unabhängig davon, ob man die Membership gekauft hat oder nicht.
Update: Hät ich mal gewartet und deinen Thread gesehen, Stefan. Ja, fast schöner erklärt als ich :-).
Wo finde ich denn die community version?
Wichtig! Es gibt keine 2 verschiedenen Versionen. Die community version wird durch Aufträge und Bugmeldungen der Mitglieder verbessert und dann als Member version released. Auf der wird dann die nächste Community Version entwickelt. Es ist also nur ein zeitlicher Versatz.
Ja,
OPC ausmachen, steps anschalten.
Die Quantity wird nur über den Core abgewickelt. Templates sollten hier also tatsächlich egal sein. Auch SEF sollte normal sein.
Die Quantity wird abgezogen je nach Order status. Daher ohne die Angaben kann man nicht helfen. Eventuell sind verschiedene Shipments involviert?
Ahja und richtig, gelöst ist das bei dir nicht, eher gefrickelt und läuft irgendwie. Aber hauptsache man hat erstmal einen Notnagel. 
Das muss eben eindeutig sein. dann gehts. Das andere kommt in vm3
