Beiträge von marquez



    Prinzipiell geht das auch sehr gut, aber wenn es um verschatelte Sachen geht bei der Darstellung, wie bei dem Grundpreis, der sich zusammensetzt aus:


    COM_VIRTUEMART_PRODUCT_UNITPRICE
    und
    COM_VIRTUEMART_UNIT_SYMBOL


    dann geht das nicht so einfach !


    Denn:
    der erste Part hat normalerweise sowas drin wie:
    preis pro %s:


    Wobei %s sich auf den zweiten bezieht.


    Die Darstellung wäre somit richtig, aber:


    Wenn es so gewünscht ist wie in meinem Fall (siehe Thread), dann geht das so nicht, da nach der Ausgabe von COM_VIRTUEMART_PRODUCT_UNITPRICE noch der berechnete Preis kommt.
    Würde ich also COM_VIRTUEMART_PRODUCT_UNITPRICE wie folgt "overriden": (preis pro %s:)
    würde es hinterher so aussehen:


    (preis pro 1kg:) 9,99 €


    Gewünscht ist aber:
    (preis pro 1kg: 9,99 €)

    Es ging um die Formatierung.
    Die Darstellung des Grundpreises unmittelbar beim Endverkaufspreis wie vorgeschrieben "gibts" eben nicht "schon".
    Was solls.
    Wer auch Fertigpackungen mit ungeraden Gewichten verkauft und dasselbe Problem hat, kann sich gerne melden.


    Wieso trägst Du denn nicht bei "Produkte Maße und Gewichte" das ein, was Du hast. Es wird doch alles auf den Basispreis berechnet und dargstellt ! Das funktioniert schon alles ziemlich gut, so wie Milbo gesagt hat. Du musst nur ggf. aufpassen, ein Punkt als Separator zu nehmen und kein Komma ! Damit hatte ich mir mal die Karten gelegt und einen "Fehler" ewig lange gesucht, der keiner war !

    http://forum.virtuemart.de/vir…-menge-produktseite-1098/


    Wegen der Nummer Orders : Order Number plugin


    hmm aber das kann nur Ordernummern, warum auch immer, ich hab ihm sogar den Code geschickt um auch die Kundennummern änderbar zu machen. Prinzipiell gibts da ein Plugin für.


    Änderbar soll die Kundennummer doch als Admin im BE zumindest manuell sein. Allerdings gibts da bei der 2.0.22 probleme, und das halte ich dennoch auch nicht für der Weisheit letzter Schluss. Am einfachsten und sinnvollsten wäre es doch, wenn es so wäre wie ich oben beschrieben habe.


    Was den Link angeht von Dir, die Erweiterung kenne ich, aber wir haben uns für com_vminvoice entschieden, da man damit auch die Ordernummern anpassen kann, und noch viel mehr Möglichkeiten hat (in Sachen Rechnungen, LS etc.)


    Was die Sache mit dem Basispreis angeht, muss ich mir den Thread noch mal genauer anschauen, auf den Du verweist. Grundsätzlich habe ich bei VM2 in der 2.0.22´er Version noch den ein oder anderen Bug gefunden, den ich mal reporten werde, wenn ich Zeit finde. Es entzieht sich nämlich z.B. meiner Logik, wieso ich bei korrekter Einstellung einmal angezeigt bekomme "preis pro KG" und einmal "preis pro DML" ! (Die Thematik mit DML kenne ich, es geht hier auch nur um den Unterschied, obwohl in beiden Produkten die identischen sachen ausgewählt und eingetragen sind !)

    Hi,


    bisher noch nicht. Ich brauch(t)e für mich das so angepasst, dass man "einfach" einen custom Zeichen am Anfang und ein Custom zeichen am Ende hat. Bsp:
    mit der normalen Methode steht da: preis pro 1kg
    gewünscht ist aber: (preis pro 1kg)


    wenn Du die beiden Klammern ausserhalb der Methode einfach darstellen lässt, passt die optik nicht, und man müsste da wieder "rumbasteln". Da ist / wäre es einfacher entweder die beiden Sachen direkt einzubinden in eine modifizierte Methode, so wie ich es derzeit mache, oder aber beides als Parameter mit an die Methode übergeben zu können. Und so wie ich das gesehen habe, kann man solche Parameter so nicht einfach mit einschleusen.



    Ein ähnliches Problem ist mit den Kundennummern. Mir stellt sich die Frage, wieso diese anhand des Benutzernamens MD5 codiert erzeugt werden, wenn ich mich nicht verguckt habe, bei der Registration. Logischer wäre doch, eine Startnummer zu vergeben (von mir aus konfigurierbar), und von dort zu schauen, welches die letzte Kundennummer war, und anhand dessen eine neue zu vergeben.
    Bsp: Vorgegeben als Startnummer 10000
    Danach bekommen die Kunden automatisch (autoincrement): 10001 , 10002 etc.

    Hallo,


    ich habe eine (für mich) unlösbare Aufgabe, und zwar möchte ich neben der "createPriceDiv", die in helpers/currencydisplay.php ist, eine weitere Methode haben, die sich zu 99% identisch bis auf ein paar kleine modifikationen verhält. Dies per copy & paste in die Datei einzubinden und zu modifizieren ist mir bekannt.


    Was mir nicht bekannt ist, ob es eine Möglichkeit gibt, eine solche Methode "irgendwie über eine externe" Datei einzubinden, ohne solche Core veränderung vornehmen zu müssen, so dass eine Updatesicherheit gegeben ist. Geht das irgendwo auch mit Overrides, oder hat jemand eine generelle Ahnung wie sich das überhaupt lösen lässt.


    Ein Eingriff in obige Datei ist in meinen Augen wirklich nur eine Notlösung. Leider fehlt mir das nötige Wissen, um es entsprechend meiner Frage selbst lösen zu können.


    Danke für Eure Antworten / Hilfe

    lol, also wenn du schon den Core hackst,


    warum änderst du nicht gleich die eine Zeile wo das Ding gebaut wird? Oder warum nicht ein plugin? Es sind nur 2 trigger.



    Hi,


    ich stehe auch aktuell vor dem Problem.


    Allerdings sollte nach Möglichkeit bei der Registration eine Kundennummer per Autoincrement vergeben werden. Also entweder konfigurierbar, oder zur Not auch Fest mit einer Startnummer.


    So wie ich das gerade in der Core gesehen habe, scheint es aktuell so zu sein, dass der Benutzername als MD5 hierfür herangezogen wird, was den langen String erklärt.


    Jetzt meine Frage:
    Gibt es eine Möglichkeit was externes und somit updatesicheres zu bekommen, wo die Kundennummern per Autoincrement beim Anlegen der Benutzer erzeugt werden können ?


    Für Tipps wäre ich Dankbar.



    P.S.
    Zur Not würde mir auch helfen wenn mir jemand einen Codeschnipsel für die Core einwerfen könnte, wo der Bereich zu ändern ist, so dass die DB erst ausgelesen wird, bevor die Kundennummer mitgeschrieben wird.


    Besten Dank.

    Hallo,


    ich habe hier eine Aufgabe für eine Virtuemart 2.0.20 zu vergeben, welche folgendes können sollte im Idealfall:


    1. Ein Guthabensystem was einem Kunden zugeordnet werden kann anhand eines Systems, was wie folgt prinzipiell aussieht: Kunde bestellt im Monat Januar für 500,-€ Bonusfähige Produkte, dann soll er im Februar eine Art Kundenguthaben bekommen in Höhe von 10% -> 50€, welches ihm bei seiner Bestellung im Februar von seiner Rechnungssumme direkt abgezogen wird. es muß allerdings auch als entsprechender Abzug zu erkennen sein, ähnlich wie bei Rabattcoupons o.ä. Hat seine Bestellung einen niedrigeren Wert, z.B. 20€, so hat er noch ein Restguthaben von 30,-€ usw. Solange, bis das Guthaben aufgebraucht ist. Es soll zudem das Guthaben nur für diesen Monat Gültigkeit haben, und sich jeden Monat basierend auf den Bestellwert des Vormonats neu berechnen.


    2. Der Kunde soll nach Möglichkeit in einer Übersicht sein entsprechendes Guthaben sehen können, sowohl gesamt, als auch aktuell, und Gültigkeitsdauer.


    3. Er soll nach Möglichkeit eine Email erhalten, wenn er ein Guthaben erhält.


    Und im Idealfall sollte das alles automatisch funktionieren, ohne dass man sich als Admin einloggen muß in Joomla. Sprich, am Monatsanfang müsste eine entsprechende Routine das alles abarbeiten.


    Hat da jemand Erfahrung in solch einer Programmierung ?


    Wenn ja, wie hoch liegt der Zeitaufwand und die Kosten dafür, und wann könnte derjenige damit loslegen, denn es "brennt" eigentlich schon ein wenig.


    Thx,

    Guten morgen,


    ich hänge mich einfach mal hier ran.


    Ich bin fieberhaft auf der suche nach einer Komponente / Plugin, womit ich von Virtuemart2 die relevanten Daten für eine Buchhaltung wie Sage bekomme, so dass die exportierte Datei dann direkt oder mit Zwischenschritt durch Excel in Sage importiert werden kann. Irgendwie komme ich scheinbar mit CSVI nicht weiter, da mir dieses nur Produkte, Gesamtpositionen der Bestellung usw exportiert. Die wichtigen Daten für eine FIBU wie Sage werden lt. meinen Informationen so nicht exportiert. Die FiBu braucht wohl soweit fast alles an Daten, was auch in der Bestellübersicht bzw in der Rechnung zu sehen ist wie Netto- / Bruttopreis, welche Artikel genau, Steuer, Versandkosten usw.


    Leider scheine ich da keine Schnittstelle zu finden, bzw. die einzige, die ich gefunden habe basiert auf Lexware. Allerdings wird sowas für Sage benötigt.


    Ich habe irgendwo gelesen, dass es über den Umweg per JTL WAWI gehen könnte, allerdings soll gar keine Desktop WAWI eingesetzt werden, und ohne den Connector zu JTL kann ich das auch schlecht testen.



    Würde mich sehr über eine Antwort freuen.


    Danke,
    Marquez

    Danke für die Antwort.


    Gäbe es denn eine Komponente, die eine Rabattstufe (prozentual) erzeugt auch wieder in Abhängigkeit vom Monatsumsatz des vormonats ?


    Also bsp:
    Kundenumsatz März = 300€ -> Rabatt für April bestellungen = 10 %
    Kundenumsatz April = 500€ -> Rabatt für Mai bestellungen = 15 %


    Danke nochmal für de Hilfe.

    Hallo,


    ich stehe mit Virtuemart gerade vor einem für mich unlösbarem Problem, wo mir meine bisherigen suchen leider auch nicht weiter geholfen haben. Hier meine Problemstellung:


    Es soll im Shop in Abhängigkeit vom Monatsumsatz im Folgemonat ein aus dem generierten Bestellwert ein Gutscheincode erzeugt werden.


    Bsp: Kunde kauft im Monat März für 300€ Ware ein, soll er im Monat April eine Mail bekommen, mit einem Gutscheincode, der einen entsprechenden Wert (als Bsp: 10%, so dass der Gutschein 30€ resultierend) hat, so dass er bei seiner April Bestellung den Code eingeben kann, und diesen Wert in Abzug bekommt.


    Die bisherigen Lösungen die ich gefunden habe, basierten i.d. Regel darauf, daß entweder der Rabatt / Gutschein sofort eingeräumt wurde, oder aber bei der Folgebestellung auf den Bestellwert ein prozentualer Rabatt gewährt wurde. Ich möchte aber, daß zwar der Gutschein sich prozentual berechnet (s.o.), aber nicht auf die aktuelle Bestellung, sondern basierend auf der Bestellung vom Vormonat.


    Ich hoffe, ich habe es halbwegs verständlich erklärt :)



    Also entweder habe ich einen Denkfehler in dem von mir gewünschten Szenario, oder "das gibts noch nicht".


    Besten Dank für Eure Hilfe.




    P.S. zum Einsatz kommt Joomla 2.5 und Virtuemart 2.0.20