Beiträge von HaeFB

    Eine weitere Möglichkeit wäre es, die Print-Funktion in der VirtueMart-Bestellliste zu verwenden.
    Damit könnte man statt der Rechnung einen Paketschein ausdrucken. Man muss dazu das Layout ändern und die entsprechenden Werte einbinden. Allerdings braucht es dazu ein wenig PHP-Kenntnisse und Zeit.

    Wir versenden (auf Kundenwunsch) 80% mit DHL, Rest mit Hermes.
    Bei DHL ist der Paketpreis abhängig von Gewicht und Maßen des Pakets.
    Geduldete Toleranzen sind gering.
    Da ein Paket bei uns meist mehrere unterschiedliche Artikel enthält entscheidet sich beides erst beim Packen.
    Postämter sind inzwischen in der Provinz rar.
    Also geben wir die Pakete täglich dem DHL - Boten mit und müssen deshalb den Paketschein online kaufen.

    Die Adressdaten der Kunden kann man per csv in das DHL-Adressbuch einlesen, trotzdem muss jeder Paketschein indvidüll erstellt werden. Das zu automatisieren übersteigt die Möglichkeiten eines Kleinkrauters.

    Vielleicht bietet DHL für Großkunden andere Lösungen an. Da gehören wir aber nicht zu.

    Also frisch ans Werk.
    Irgendwas muss man ja tun fürs Geld.
    ;)

    Danke beide.
    Es ist eigenes Layout, seit 1820 mitgeschleift (never change a running system):saint:.
    Alle Ansätze, das auf neues Layout zu übertragen sind bisher kläglich gescheitert.

    Problem aber gelöst:
    Häkchen bei "Basispreis inklusive MwSt., aber ohne Preisnachlässe" entfernt, wozu das auch immer vorher drin war.


    Noch eine Erklärung für "COM_VM_CFG_PRICES_BY_CURRENCY ?"

    Moin,

    was ist "COM_VM_CFG_PRICES_BY_CURRENCY" ?


    Weiter wird plötzlich "Basispreis inkl. Steuern 8,67 €" (Preis durchgestrichen) im Frontend angezeigt.
    Idee, wo das herkommt?


    Danke!

    Das hatte ich ja schon ein meinem Post #5 geschrieben. Natürlich ist es möglich, nach der manuellen Umstellung auf 16% den Bruttopreis neu zu setzen. Das hängt jedoch von den Anzahl an Produkten ab. Zudem müsste dann ab dem 01.01.2021 wieder alles händisch rückgängig gemacht werden muss.

    Wenn man nicht gerade mit Porsches, Ebikes, Gaming-Pcs, Einbauküchen oder Einfamilienhäusern handelt:
    Außer Spesen nichts gewesen.

    X(

    Doch Nachtschicht.
    Shop per akeeba nach Xampp gebeamt.
    Alle Einstellungen w.o. vorgenommen.
    Wichtig: Hersteller festlegen schlechte Lösung, besser Produktkategorien einstellen.
    Regelwechsel auf 12.6.20 zum 13.6.20 eingestellt.

    Ergebnis:
    Automatische Umstellung hat nicht geklappt.
    Bei manueller Änderung der Umstellungs-Tage im Adminbereich funktioniert es.


    Auf den Selbstkosten/ Basispreis (bei mir dasselbe) wird die neue Steuer von 5% aufgeschlagen.

    Folge:

    Gewürzglas:
    Alter Preis 3,90€ neuer Preis 3,82€ Diff: 8ct

    Soße:
    Alter Preis 10,00 € neuer Preis 9,82€ Diff: 18ct


    Facit:
    Das macht mich natürlich nicht arm und den Kunden auch nicht reich, aber ich müsste mein ganzes auf Produktpreisen basierendes Rabatt- und Gutscheinsystem in die Tonne kloppen.
    Ich stelle also wohl doch von Hand auf die alten Preise um, erkläre es den Kunden und geb ein paar Zuckerle (Preisnachlass per Gutscheincode oder so, ich verwende AWO Coupon) dazu.


    Frohes Schaffen und bleibt gesund!

    OSRAM / PHILIPPS / LED !!!

    Ich hab das bisher auch so eingestellt, bei jedem Produkt.


    Bei der Steuerregel also nicht "verfügbar für alle", sondern Hersteller und Produktkategorie festlegen und dann beim Produkt "Standard-Regeln".

    Weil es das Steuerauswahlfeld gibt meint Jeremias Dummdödel, man müsste das auch nutzen.

    Warum sagt einem das keiner?

    Einmal Nachtschicht zum Umbauen eingeplant.

    :rolleyes:

    Nachfrage:
    Wenn man mit 2 Steuersätzen arbeitet (19% und 7%) gibts beim Produkt die Einstellung "Angewandte Steuer" (im obigen Bild auf "enth. MwSt. 19%" eingestellt).

    Woher weiß das Programm auf welche Einstellung es beim jeweiligen Produkt bei Zeitwechsel umstellen soll?

    Was passiert, wenn man "Standard-Regeln zuordnen" einstellt? Welches sind eigentlich die "Standard-Regeln"?
    :/?(:?:

    Vor dem update am 2.6.20 sahen die Nummern dank Opentools so aus:

    Anr.: AC20061 (Shop-Y2-M2-Lfdnr.)

    RNr.: AC20204 (Shop-Y2- Lfdnr.)


    Danach so

    Anr.: AC20062 (Shop-Y2-M2-Lfd.)

    RNr.: 200603KSZN01093 (wer will sowas?)

    Also hat die Bestellnummer weiter nach OT-Einstellung funktioniert, die Rechnungsnummer nicht.



    Die "Anleitung" im iStraxx Plugin ist gut für Menschen, die ohnehin wissen, was gemeint ist und deutsch ist eh eine Fremdsprache.

    In den Einstellungen oben gibt es nur
    "Show available data, which can be used for generation".

    Ob gecheckt oder nicht spielt für die Ausgabe der Systemmeldung beim Auschecken (Erzeugung der Nummern) exakt keine Rolle.


    Stellt man dagegen "verbose" in der Tabelle auf 0, ist die Systemmeldung, die in
    "plugins\vmextended\istraxx_anumbers\istraxx_anumbers.php" erzeugt wird, weg.


    Wenn man auf den grünen Button "SUPPORT" klickt, kommt man auf die Seite
    "https://extensions.virtuemart.net/index.php?option=com_beestohelpdesk&view=ticket&Itemid=10188"

    und wird aufgefordert, sich mit Username und Passwort einzuloggen.


    Wozu dann das Ganze?


    HaeF

    Hallo Faro,

    die Bestellnummer ist kein Problem, die interessiert niemanden.
    Für die Rechnungsnummer gibt es Vorschriften. Wenn man online und reallive verkauft, gibt das Probleme.

    Alle Rechnungsnummern müssen fortlaufend sein und der Kunde sollte sie z.B. bei Zahlung per Überweisung auch problemlos übertragen können.

    Übrigens:

    Meine Support-Anfrage an iStraxx war trotz pünktlicher Bezahlung bis heute ohne Resonanz.
    Ich werde mir wohl die eigentlich geplante Virtuemart Membership verkneifen.


    Bleibt gesund!

    HaeF

    Hier die Lösung für vielleicht auch mal Betroffene:

    "iStraxx Automated Numbers" hat in der Datenbanktabelle "xxxxx_virtuemart_extended_plg_istraxx_anumbers" im ersten Datensatz den Parameter verbose="1" gesetzt, was dafür sorgt, dass bei jedem Aufruf der Funktion in der Datei

    "plugins\vmextended\istraxx_anumbers\istraxx_anumbers.php" eine ellenlange Systemmeldung im Frontend erzeugt wird, egal wie die Messageparameter eingestellt sind.


    Ändern auf verbose="0" beendet den Spuk.
    Könnte man eigentlich im Tutorial erwähnen.


    Frohes Schaffen!

    Update:
    Ich habe nun "iStraxx Automated Numbers" gekauft und installiert und es nach mehrfachen Versuchen und dem Verbrauch von einem Dutzend Testnummern zum Laufen gebracht.
    Die Beschreibung https://extensions.virtuemart.…gins/29-automated-numbers

    ist eine echte Zumutung.

    Nun produziert das Teil bei der Bestätigung der Bestellung eine Meldung
    " Nachricht

    0 Automated Numbers created order number, existing user data:"


    mit einer ellenlangen Auflistung wie

    Code
    1. stdClass Object
    2. ( [virtuemart_order_id] => [virtuemart_user_id] => 0 [virtuemart_vendor_id] => 1 [customer_number] => nonreg_FrBama20200604_095612_ [order_total] => 11.4006 [order_salesPrice] => 6.5 [order_billTaxAmount] => 0.74583

    Frage:

    Wenn ich Mitteilungen ganz ausschalte wird der Kunde auch nicht mehr benachrichtigt, wenn er z.B. ein Feld nicht ausgefüllt hat.

    Warum kommt die Nachricht?

    Kann man die obige Nachricht gezielt ausschalten?


    Übrigens:

    Anfrage an Support = Fehlanzeige.
    Shop läuft weiter und produziert Mist, den ich nachher dem Finanzamt erklären können müsste.


    Danke!

    Hallo,

    ich nutzte bisher "Advanced Ordernumbers for VirtueMart" von OpenTools bis VM 3.8.2 mit Joomla 3.9.18 ohne Probleme für Bestell-und Rechnungsnummern.
    OpenTools hat die Unterstützung eingestellt.
    Nach dem Update auf Joomla 3.9.19 bleiben die Bestellnummern wie gehabt, die Rechnungsnummern sehen so aus:
    "Rechnung 2006037EEC01095".
    Sie sehen auch so aus, wenn ich das Plugin deinstalliere.

    Testinstallation mit Joomla 3.9.18 zeigt, dass es an der Joomla-Version liegt.

    Warum murkst Joomla in einer Virtuemart-Konfiguration herum?
    Irgendeine Idee, wo man da suchen könnte?
    Das Problem ist einfach, dass das Finanzamt etwas gegen Umstellungen der Rechnungsnummern hat.


    Hoffe, alle sind noch gesund!
    HaeF