Neu automatische Preisberechnung anhand der EK-Preise - wie geht es richtig?

cdx

Sehr aktives Mitglied
13. März 2013
1.597
52
Im Forum gibt es mehrere Beiträge was die Preisberechung der VK Preise angeht.
Leider gibt es da keine sinnvolle Lösung die automatisiert abläuft.
Wie macht ihr das?

Beispiel: Ich habe einen Artikel mit 2 Lieferanten.
Lieferant 1 hat einen EK von 5 aber keine Artikel auf Lager
Lieferant 2 hat einen EK von 7 Euro und die Artikel auch da...
Nun möchte ich idealerweise nicht einfach den günstigsten Preis hernehmen sondern den günstigsten Preis von dem Lieferanten der die Artikel auch da hat.
Dazu soll der EK (in dem Fall die 7 Euro) mit einem Faktor als VK neu berechnet werden.
Da es ja aber bei verschiedenen Artikeln verschiedene Faktoren geben kann (weil die Margen anders sind) muss ich diesen Faktor ja idealerweise irgendwo angeben können.
Wenn sich also mein EK ändert (oder der günstigste Lieferant den Artikel wieder auf Lager hat) soll sich der VK automatisch anpassen.

Geht sowas überhaupt und wenn ja wie geht es richtig?
 

cdx

Sehr aktives Mitglied
13. März 2013
1.597
52
Ich denke dass hier einige Händler sind, die beispielsweise Elektronikartikel anbieten.
Da ändern sich die Preise ja auch regelmäßig.
Würd mich echt interessieren ob ihr da einen Workflow nutzt oder das händisch löst oder per Ameise oder anderweitig...
 

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.653
141
Ich denke dass hier einige Händler sind, die beispielsweise Elektronikartikel anbieten.
Da ändern sich die Preise ja auch regelmäßig.
Würd mich echt interessieren ob ihr da einen Workflow nutzt oder das händisch löst oder per Ameise oder anderweitig...

Workflows können das (bisher) nicht.
Händisch? > 250.000 Artikel mit bis zu 10 Lieferanten ? ROTFL

Ich mache das seit Jahren per SQL, automatisiert.
Dafür ist das "SQL Server Managementstudio" ja da.

EK Anhand der lieferfähigen Lieferanten setzen
ICH verwende je nach Lust und Laune bzw. Saison, mal den niedrigsten SQL = min(), mal den Durchschnitt = avg() oder auch max()

"Faktor" (wie es oben genannt wurde) beim Artikel hinterlegen (s. WIKI)
Nicht vergessen das es je nach Marktplatz verschiedene Faktoren / Provisionen gibt ;)
AMAZON 15-18%, ebay 9-15%, AYN 8-12%, Rakuten 5-9% usw. usf.

Na und dann - ebenfalls per SQL - rechnen und speichern lassen.
 

cdx

Sehr aktives Mitglied
13. März 2013
1.597
52
Hallo dith...
Danke für die Anregung.
Hatte gehofft dass es auch mit jtl bordmitteln realisierbar ist...
ALLE müssen doch irgendwie ihre preise in die wawi eintragen.
Vor allem bei schwankenden preisen müsste das auch automatisiert gehen...
Daher ist es für mich nicht so ganz nachvollziehbar warum zu dem Thema kaum was in der wiki steht und auch im forum nichts weiter zu finden ist.
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
Beispiel: Ich habe einen Artikel mit 2 Lieferanten.
Lieferant 1 hat einen EK von 5 aber keine Artikel auf Lager
Lieferant 2 hat einen EK von 7 Euro und die Artikel auch da...
Nun möchte ich idealerweise nicht einfach den günstigsten Preis hernehmen sondern den günstigsten Preis von dem Lieferanten der die Artikel auch da hat.
Dazu soll der EK (in dem Fall die 7 Euro) mit einem Faktor als VK neu berechnet werden.
Da es ja aber bei verschiedenen Artikeln verschiedene Faktoren geben kann (weil die Margen anders sind) muss ich diesen Faktor ja idealerweise irgendwo angeben können.
Wenn sich also mein EK ändert (oder der günstigste Lieferant den Artikel wieder auf Lager hat) soll sich der VK automatisch anpassen.

Geht sowas überhaupt und wenn ja wie geht es richtig?

Dein Ansatz hat mMn den Denkfehler, dass morgen Lieferant 1 den Artikel wieder auf Lager haben wird und übermorgen nicht, du also plötzlich täglich massive Preisschwankungen hast > Kunden die heute Produkt A für 10€ gekauft haben und es morgen für 8€ haben könnten, "nerven" dann via E-Mail weil sie nicht verstehen, dass sich dein Einkaufspreis vermutlich verbessert hat, einige davon machen aus Protest dann nen Widerruf wenn du dich weigerst nachträglich den besseren Preis zu gewähren.

Zur Umsetzung, haben das für einen Kunden bereits gelöst der täglich zwei CSV Listen von Lieferanten bekommt die nach diversen Kriterien zusammengeführt werden und dann je nach Einkaufspreis/Hersteller der VK Preis berechnet wird. Der selbe Ansatz wäre hier mMn die Lösung. Statt den CSV Listen (sofern es keine gibt) nimmt man dann die in der Wawi beim Artikel hinterlegten Lieferantendaten und berechnet auf deren Basis eben die Preis nach Wunsch, spielt das dann wieder via Ameise ein.

Mit Wawi Boardmitteln sehe ich da aktuell keine Möglichkeit, wäre aber auch möglich, dass ich sie nur noch nie gesehen habe, die Wawi ist ja mittlerweile ein recht umfangreiches Tool.
 

cdx

Sehr aktives Mitglied
13. März 2013
1.597
52
Hallo Christian.
Vielen Dank für das Feedback. Wir werden die Kalkulation nochmal überdenken. (zum Beispiel mit dem Durchschnittlichen EK) Aber der wird ja scheinbar nur gesetzt wenn es auch einen Einkauf gab oder?
Ich finde es sehr kurios dass wir hier scheinbar mit der Frage allein da stehen. (Bis auf BNC ;) )
Es müsste doch eigentlich alle Händler betreffen.
Macht ihr das alle händisch mit einer CSV wo ihr euch dann die Preise zusammenbaut oder wie?

Mit Wawi Boardmitteln sehe ich da aktuell keine Möglichkeit, wäre aber auch möglich, dass ich sie nur noch nie gesehen habe, die Wawi ist ja mittlerweile ein recht umfangreiches Tool.
Schade... Wenn selbst die SPs hier keine interne Lösung kennen wird es wohl schwierig... :(
 

cdx

Sehr aktives Mitglied
13. März 2013
1.597
52
Ich muss das Thema nochmal hoch holen...
Wie macht ihr eure Preisaktualisierung?
Würde mich sehr über Antworten freuen...
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
Eigentlich sind die Möglichkeiten zur direkten Preiskalkulation in der Wawi und auch in der Ameise "ehrenhaft", aber ich glaube nicht, dass allzu viele Leute das benutzen, denn hier beißt sich meines Erachtens die Katze in den Schwanz: Gedacht sind die Verfahren für die schnelle und "automatisierte" Aktualisierung vieler Preise, wirklich sinnvoll sind sie aber nur, wenn man nur wenige Preise zu aktualisieren hat. - Warum?

Beides sind ja leidlich automatisierte Verfahren, "leidlich" deshalb, weil ich sowohl das Ganze innerhalb der Wawi händisch auf bestimmte Artikel anwende, die Last der Selektion und das "dabei wachbleiben" also bei mir liegt. Habe ich nur wenige Artikel, Kategorien und/oder Lieferanten, dann ist das vielleicht noch in Ordnung, bei vielen ist es aber deutlich zu zeitaufwändig.

In der Ameise tritt das aber noch deutlich zutage, denn CSV ist schlicht ein Tabellenformat und kommt normalerweise aus Spreadsheets (ok, nicht zwingend). Habe ich die Daten aber erst einmal im Spreadsheet, warum sollte ich dort leicht durchführbaren Berechnungen dann ausgerechnet auf die Ameise verlagern.Dann kommt noch dazu, dass das Ganze - je mehr Artikel und Lieferanten man hat - umso schwieriger mit der Ameise umzusetzen wäre, weil man alle Besonderheiten in einzelnen CSVs abbilden müsste.

Ich selbst bin, was die Artikelanzahl angeht, mit knapp über 500 sicherlich einer der kleineren Händler hier und ich habe auch nur ~20 Lieferanten. Aber, jeder Lieferant hat seine preislichen Besonderheiten, es gibt mehrere Lieferanten-Währungen, ich brauche aber "gerade" Preise, und so weiter, und so weiter. Also habe auch ich mich dafür entschieden, meine Preise in einem inzwischen ziemlich ausgefeilten Spreadsheet zu verwalten. Alles, was variabel ist, wie Rabatte und Staffeln hat Spalten, Währungen und Glättungsfaktoren werden zentral abgelegt und das Ding berechnet natürlich auch gleich Margen in % und €, für den schnellen Überblick, ob's passt. Dann habe ich mir ein Excel Makro geschrieben, dass die gerade gefilterten Daten in eine Ameisen-Import konforme CSV schreibt und die ist dann schnell in die Wawi importiert.

Hat ein Händler aber sehr viele Artikel und Lieferanten wird das noch deutlicher und dann steigt auch die Wahrscheinlichkeit, dass man über EDI und ähnliches gehen muß und spätestens dann verwaltet man seine Preislisten und Artikelpreise eh außerhalb der Wawi. Aber dort wie hier gilt, dass die Preise die Grundlage des Geschäfts sind und für mich ist meine Preisliste deshalb auch so etwas wie ein "Abbild" meiner Handelspräsenz und allein deshalb würde ich die Preisberechnung nie über Ameise oder Wawi machen.

Edit: Was ich mit dem letzten Satz meine ist, dass ein Spreadsheet, in dem alle Werte inklusive Margen, usw. nicht nur enthalten sind, sondern über bedingte Formatierungen auch noch farblich hervorgehoben sind, ALLES auf einen Blick zeigt. Das kriegt man ansonsten nie hin...
 
Zuletzt bearbeitet:

bubu

Sehr aktives Mitglied
5. November 2013
416
73
Bolken (SO)
@gutberle
Dankle für deine gute Beschreibung, ich handhabe das ähnlich - aber mit dem Unterschied, dass ich pro Warenbereich (meist auch gleich der Lieferant) ein Excel führe. Ebenfalls wegen der diversen Eigenheiten und Einkaufs-Shippingkosten.

Warum ich überhaupt hier in diesen Thread gefunden habe:
Bei uns hat die MWST geändert, und zwar um 0.3% (sowas gibts nur in der Schweiz.....). Gut, ob 0.3% oder 5% ist egal, man muss alles anpassen, da der Shop nach der MWST-Aendeung voller "komischer" Preise ist. Ich bin da grad dran. Leider bin ich nicht so automatisiert und mache das von Hand: Excel --> JTL

Dabei bin ich auf etwas Eigenartiges gestossen: Die Anzeige des durchschnittlichen Einkaufspreises auf der Frontseite des Artikels.

- Mein Shop ist in der Grundwährung CHF
- Ich habe einen Lieferanten im EU-Bereich mit EUR
- Auf dem Reiter "Lieferanten" gebe ich dann auf dem Lieferanten auch den EUR-Einkaufspreis ein.

So weit so gut ....

So wie ich das verstehe müsste der durchschnittliche EP ja in CHF angezeigt werden, da auf dem Artikel alle Preis ein CHF sind. neben dem Feld steht aber: "Letzter EK xxx.yy €"

Weiss jemand, wie da der Zusammenhang genau ist? In der Doku habe ich nichts gefunden. Leider.

LG, und einen guten Jahresstart

Markus
 

Horst-Dieter

Aktives Mitglied
28. Juli 2017
91
11
Hannover
Beispiel: Ich habe einen Artikel mit 2 Lieferanten.
Lieferant 1 hat einen EK von 5 aber keine Artikel auf Lager
Lieferant 2 hat einen EK von 7 Euro und die Artikel auch da...
Nun möchte ich idealerweise nicht einfach den günstigsten Preis hernehmen sondern den günstigsten Preis von dem Lieferanten der die Artikel auch da hat.
Dazu soll der EK (in dem Fall die 7 Euro) mit einem Faktor als VK neu berechnet werden.
Da es ja aber bei verschiedenen Artikeln verschiedene Faktoren geben kann (weil die Margen anders sind) muss ich diesen Faktor ja idealerweise irgendwo angeben können.
Wenn sich also mein EK ändert (oder der günstigste Lieferant den Artikel wieder auf Lager hat) soll sich der VK automatisch anpassen.

Hallo. Genau diesen Text wollte ich gerade eingeben und sehe, dass cdx schonvor laanger Zeit schneller war.

Wir lesen jeden Tag die neuen Preise und neuen Bestände mit der Ameise per Batch ein. In unregelmäßigen Abstanden werden die Artikel geupdatet oder importiert.
Ich kann bei der Menge (>100.000) nicht feststellen, welcher Artikel zur Zeit verfügbar und auch günstig ist.
Ich möchte aber den VK auf Basis eines gültigen EKs berechnen lassen. In der Ameise givt es den VK-Modi, der bei klar definiertem EK den VK berechnet.

Habe ich nun drei Lieferanten für einen Artikel ( nehmen wir mal einen Leitz Ordner, den fast jeder anbietet), und ich lasse drei Importe mit der Ameise laufen, je eine Datei pro Lieferant, dann wird der VK vom EK des dritten (letzten) Lieferanten berechnet. Wenn das der teuerste Lieferant ist, liege ich immer über den Preisen der Mitbewerber.

Ich bin auch hochgradig an einer Lössung wei cdx sie beschrieben hat interessiert. Egal ob Wawi intern oder extern.
Hat irgend jemand schon eine Lösung ohne SQL-Kenntnisse parat.
 

Horst-Dieter

Aktives Mitglied
28. Juli 2017
91
11
Hannover
Eine Lösung, die aber nur händisch funktioniert, habe ich gefunden.
Unter Artikel gibt es die Preiskalkulation, die als Basispreis den Durchschnitt aller Lieferanten-EKs benutzt.
So kann ich den VK aus dem Durchschnitt berechnen lassen.
Wenn das nun auch noch mit der Ameise funktionieren würde, dann könnte man die Preisänderungen auch wieder über eine batch korrigieren lassen.

Vielleicht könnte man das mal an die Entwickler weiterleiten, ob das umsetzbar ist.
 

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.921
568
Welche Anforderungen stellt ihr denn an solch eine Kalkulation?
- Artikelpreise je Kategorie überarbeiten?
- Artikelpreise mit Faktor X Gewinnmarge?
- Artikelpreise berechnen anhand ØEK oder muss es ein fester Lieferant sein?
- Artikelpreise sollen auch min./max. VK erhalten für Repricer?
 

gnarx

Sehr aktives Mitglied
18. Januar 2018
3.823
525
Man kann ja in WF`s rechnen (wir wollen das in nächster Zeit einbauen), hier mal ein Beispiel:

{% assign Anzahl = Vorgang.AuftragsPositionen.ArtikelPositionen.Anzahl | FormatNumber: 'N2', 'de-DE' | ToDouble -%}
{{ Anzahl | DividedBy: 2 }}
{{ Anzahl | Times: 5 }}

Hier gibt es die Filter dazu: https://guide.jtl-software.de/Kategorie:JTL-Wawi:Filter:StandardFilters

Wenn ich das richtig gelesen hab kann man ja auch smarty aktivieren, da könnte man dann mit math mehrstufige Berechnungen durchführen, also Formeln in Klammern usw..
https://www.smarty.net/docsv2/de/language.function.math.tpl
 

Horst-Dieter

Aktives Mitglied
28. Juli 2017
91
11
Hannover
@wawi-dl
Ich gehe da sehr minimalistisch ran.
Ich benutze den VK-Modus beim batch-Einlesen, deshalb brauche ich einen EK auf den ich mich berufen kann.
Da der Mittelwert aller zugeordneten Lieferanten wahrscheinlich sehr nah bei allen EKs sein dürfte, wäre ich mit dem Mittelwert der EKs aller Lieferanten schon sehr zufreiden.

Ein Ek eines festen Lieferanten zu benutzen habe ich ja jetzt schon und wird es dann wohl auch in Zukunft geben.