Neu Neues Plugin: Profi Preise - für Flächen- & Volumenberechnungen, prozentuale Aufpreise & eigene Formel

[deliman]

Noch ein Wunsch und ein Hinweis (wurde schon direkt besprochen)...

Wunsch: Das Artikel- bzw. Versandgewicht Anhand Länge/Fläche/Volumen und Anzahl berechnen und bei der Versandkostenermittlung mit berücksichtigen. Das Gewicht via Formel zu berechnen und in einem Freitextfeld anzeigen zu lassen funktioniert schon aber ob das bei der Versandgewichtberechnung auch einen Einfluss hat, weis ich nicht.

Hinweis: Wenn man mehr als einen Berechnungsschritt hinterlegt und eine Artikelauswahl via Konfigurator z.B. für Zusatzartikel macht, funktioniert die Kalkulation nicht mehr.

Und, weder Umlaute noch z.B. ß in den Variantenwerten nutzen, wenn man z.B. eine Farbauswahl nutzen möchte. Bei dem Variationsnamen gibt es keine Probleme aber bei den Werten.

 

[Heinz Schrot]

Ich habe einen Artikel mit 100+ Formeln. Da musste ich die Formeln direkt in die Datenbank schreiben, da der Formelgenerator ab und an was Falsches in die DB schreibt. IMHO betreffen die Bugs nur den Formelgenerator. Im Shop selbst funktioniert es 100%.

 

[deliman]

Problem mit Zahlungsart SOFORT (via Mollie).

Ich habe gerade eine Kundenbestellung reinbekommen und eine Testbestellung gemacht und als Zahlungsart SOFORT via dem Mollie-Zahlungsplugin bezahlt. Im Warenkorb werden die berechneten Werte korrekt angezeigt, auf der Bestellabschlussseite + im Zahlfenster von SOFORT/Mollie auch aber im Shop-Kundenkonto/Shop-Backend und in der Bestellung, die an die Wawi übergeben wird, wird nur noch der Grundpreis ausgewiesen und in der Wawi wird im Auftrag unter Zahlung dann eine "Überzahlung" angezeigt.

Bei der Zahlung wird also korrekt abgerechnet aber bei der Zurückgabe an den Shop gehen scheinbar irgendwelche Daten verloren.

Hat noch jemand anders dieses Verhalten, evt. auch bei anderen Zahlungsarten, beobachten können oder ob das ein spezielles Problem mit dem Plugin von Mollie ist?

Ich muss mal noch weiter testen, da das jetzt nach der Einrichtung der Artikel die ersten Bestellungen von "kalkulierten" Produkten sind.

 

[css-umsetzung]

Problem mit Zahlungsart SOFORT (via Mollie).

Ich habe gerade eine Kundenbestellung reinbekommen und eine Testbestellung gemacht und als Zahlungsart SOFORT via dem Mollie-Zahlungsplugin bezahlt. Im Warenkorb werden die berechneten Werte korrekt angezeigt, auf der Bestellabschlussseite + im Zahlfenster von SOFORT/Mollie auch aber im Shop-Kundenkonto/Shop-Backend und in der Bestellung, die an die Wawi übergeben wird, wird nur noch der Grundpreis ausgewiesen und in der Wawi wird im Auftrag unter Zahlung dann eine "Überzahlung" angezeigt.

Bei der Zahlung wird also korrekt abgerechnet aber bei der Zurückgabe an den Shop gehen scheinbar irgendwelche Daten verloren.

Hat noch jemand anders dieses Verhalten, evt. auch bei anderen Zahlungsarten, beobachten können oder ob das ein spezielles Problem mit dem Plugin von Mollie ist?

Ich muss mal noch weiter testen, da das jetzt nach der Einrichtung der Artikel die ersten Bestellungen von "kalkulierten" Produkten sind.

Leider nichts neues bei Mollie Zahlungsarten.

 

[deliman]

Das klingt nicht gut... Dann kann ich mir wohl das Testen weiterer Zahlungsarten wie Kreditkarte u.ä. sparen, die via Mollie angewickelt werden.

 

[css-umsetzung]

Ich habe ständig ärger mit den Zahlungsarten wenn es bei Plugins um Preismanipulationen geht.
Das schlimme ist, das es auch von Versio zu Version unterschiedlich ist.

Ich bin noch nicht dahintergekommen woran es liegt weil es ja auch nicht immer passiert.

 

[eRock Marketing]

Hallo zusammen,

eine neue Version ist verfügbar, die sich rein mit Bugfixes beschäftigt.

Version 1.03 behebt die folgenden (alle uns bekannten) Punkte:

• Zahlungsanbieter wie PayPal - Preise werden an mehr Stellen aktualisiert, damit keine Differenzen auftreten
• Swatches greifen nun
• Sonderzeichen in Variationswerten sind im Shopbackend wieder auswählbar
• Live Preisberechnung für Internet Explorer (generell für alte Browser)
• Aktion "Freitextfeld befüllen" wurde korrigiert (hatte zuvor das falsche Feld gewählt)

Download, testen und kaufen unter: https://shop.knoell-marketing.de/JTL-Preis-Profi-Flaechenplugin

 

[deliman]

Greift Punkt 1 auch bei Mollie?

 

[eRock Marketing]

Ja, das war ein generelles Problem: Preis wurde "zu spät" aktualisiert, und die Zahlungsplugins hatten noch den Ursprungspreis.
Das ist global behoben (nicht nur für PayPal).

 

[deliman]

Was mir noch aufgefallen ist...

Wenn man bei den Versandarten "versandfrei ab x€" hinterlegt hat, erfolgt die Berechnung der Warenkorbsumme für die Versandfreigrenze scheinbar nach den Grundpreis und nicht nach dem errechneten Preis. So wird zwar der Hinweis a la "es fehlen noch x€ bis zur versandkostenfreien Lieferung" aber bei der Versandart bzw. im Versandrechner wird bereits eine versandkostenfreie Lieferung eingepreist.

Da diese in der Beispielrechnung nur durch den Grundpreis (Kauf nach Länge dann bei Stückpreis unter dem 1m Grundpreis) erreicht wird, lässt mich das darauf schließen. Nun weis ich nicht ob das bei der Versandfrei-Berechnung im Shop generell so abläuft oder das nur im Plugin so ist und man das "umgehen/ändern" kann.

1. Ist die Anzeige im Shop dann doch verwirrend und
2. kostet es Marge/Geld, wenn unsere Versand- und Preiskalkulation so "ausgehebelt" wird.

 

[eRock Marketing]

Hallo und vielen Dank für die Rückmeldung.

Wir werden das bei uns mal durchspielen und da eine Lösung suchen.

Grüße

 

[deliman]

Hallo,

hat das Plugin einen internen Cache, den man nicht selber leeren kann?

Ich habe gerade einen Artikel wieder im Shop aktiviert und in das Plugin mit zur Kalkulation reingenommen, den ich vor einigen Wochen mal drin hatte. Schon beim Versuch, die Einstellungen von einem anderen auf diesen "neuen" Artikel zu dublizieren, kam die Fehlermeldung, das bereits eine Kalkulation vorhanden wäre. In der Kalkulationseinstellung war nichts sichtbar und ich habe neue Regeln eingetragen aber ab einer bestimmten Konstellation/Längeneingabe im Frontend wird das Ergebnis nicht mehr nachvollziehbar.

Die gleiche Kalkulation bringt bei dem anderen Artikel genau die Ergebnisse, die man nachrechnen kann. Bei dem neuen (alten) Artikel scheint im Hintergrund wirklich noch eine alte Kalkulation aktiv zu sein, die dann z.B. Überlängenzuschläge mit dazuaddiert.

Bleiben die Daten eigentlich beim deaktivieren des Plugins erhalten bzw. lassen sich die irgendwie "exportieren" oder sichern für den Fall der Fälle? Teilweise sind die Kalkulationen ja schon etwas umfangreicher und bei mehreren Artikeln, wäre das sehr unschön, wenn man alle Daten wieder per Hand eintragen müsste, sollte es mal ein Problem mit dem Plugin oder dem Shop geben...

 

[eRock Marketing]

Hallo deliman,

das Plugin hat keinen eigenen Cache, es nutzt die Plugin-Tabelle xplugin_km_artikelpreise_basics (Welche Artikel haben Konfigurationen) und xplugin_km_artikelpreise_manipulation (enthält alle Preismanipulationen).
Verknüpft sind die Daten immer über die JTL IDs (z.B. kArtikel). Darüber kann auch exportiert werden, ein direkten Export im Plugin gibt es bislang nicht.

Wenn ein Artikel deaktiviert wird, bleibt die Berechnung da, auch wenn das Plugin deaktiviert wird (nach JTL Standard: Plugintabellen werden erst bei Deinstallation des Plugins entfernt).
Wenn dann später der Artikel wieder aktiviert wird, und damit die Manipulation noch vorhanden ist, kann nicht von anderen Artikeln dubliziert werden, dazu müsste bei dem Artikel erst die vorhandene Manipulation entfernt werden.

Grüße

 

[deliman]

Und wie lösche ich eine evt. vorhandene Manipulation? In den Plugineinstellungen für den Artikel ist ja nichts sichtbar. Muss man dann direkt in der Datenbank an die o.g. Felder ran?

 

[eRock Marketing]

Eine vorhandene Manipulation sollte stets sichtbar sein.
Was gegenteiliges ist mir bisher nicht bekannt, sodass wir uns in dem Fall das einmal anschauen müssten.

 

[deliman]

Eine vorhandene Manipulation sollte stets sichtbar sein.
Was gegenteiliges ist mir bisher nicht bekannt, sodass wir uns in dem Fall das einmal anschauen müssten.

Ich denke, ich weis woran es bei mir liegt. Ich habe die Artikel in der Wawi für den Shop gesperrt/rausgenommen, ohne vorher den Artikel aus dem Plugin rauszunehmen. Daher waren auch immer einige "Geisterartikel" im Plugin ohne Artikelnummer/-Bezeichnung sichtbar. Wenn ich den Artikel wieder hochlade, werden die "Geisterartikel" auch entsprechend weniger...

Trotzdem nach wie vor ein Problem mit der Manipulation vorhanden...

Ich habe jetzt wirklich mal einen ganz neuen Artikel angelegt um damit zu testen - nur Längenberechnung (Eingabe in mm).
1. Manipulation zur Ausgabe im Ergebnisfeld + (Preis x Länge)/1000 (wegen der Umrechnung von mm in m)
2. Manipulation als prozentualer Rabatt wenn die Eingabelänge über 499 mm liegt dann z.B. -30.15
- Bis hierhin funktioniert auch alles. Der Rabatt wird korrekt berechnet - bis man eine Länge ab 1000 mm eingibt, dann wird wieder der höhere Standard-/Grundpreis berechnet.
Normalerweise wollte ich bei dem eigentlichen Artikel noch eine weitere Manipulation mit prozentualem Rabatt ab 1000 mm Länge eingeben aber die greift dann auch nicht mehr. Ich weis, das ich bei anderen Artikeln früher mal weitere Manipulationen und Zuschläge ab 1000 mm Länge berechnet hatte (wo es im übrigen funktionierte - Pluginversion 1.02) aber das sollte ja bei einem anderen/neuen Artikel keinen Einfluss haben.

Im Moment steh ich irgenwie auf`m Schlauch...

 

[karabas]

Gibt es eine Möglichkeit bei den Formeln die Werte oder das Ergebnis auf- bzw. abzurunden?

 

[karabas]

Und noch eine Frage, wenn man mit Sonderpreisen arbeitet wird ja noch als "Alter Preis" nicht konfigurierter Preis angezeigt:


Kann man das irgendwie beeinflüsen?

 

[eRock Marketing]

Hallo,

nein auf die Sonderpreise/Alten Preise/UVP/... kann man da leider keinen Einfluss nehmen, denn er bearbeitet ja nur den tatsächlichen Preis.
Sonst müsste man also den alten Preis auch irgendwie konfigurieren können - darauf ist das Plugin nicht ausgelegt.

Zum Runden: Das geht über einen kleinen Umweg.
Man muss dabei beachten: Die Formel wird einmal durch PHP (für den Preis im Warenkorb) und einmal durch JavaScript (für die Live Preisanzeige beim Artikel) gejagt.
In PHP lautet das einfach "round(...)" in JavaScript hingegen "Math.round(....)".
Dazu also 2 Schritte:

1. In der Formel round(...) angeben, also z.B. round( Breite * Länge) -> dann ist der PHP Teil erledigt
2. Dann in dem Plugin in der aktuellen Version die Datei preise.js bearbeiten (z.B: /includes/plugins/km_artikelpreise/version/104/frontend/js/preise.js):
   Ganz unten in "calculateForm" eine Zeile bei den replaces hinzufügen a la: formel = formel.replace('round(','Math.round(');

Das wärs. Wir haben das nicht fest implementiert, da dies bei anderen Vorhaben zu ungewollten Ersetzungen kommen kann.

 

[karabas]

Warum habe ich kein Brutto-Preis als Auswahl?