Ich löse das zur Zeit, dass ich eine Kundengruppe gemacht habe die mit dem Plattformname versehen ist. Die hat dann den Aufschlag der durchschnittlichen Kosten dieser Plattform. Was mich ärgert ist, dass ich diesen errechneten Preis nicht automatisch als eBay Preis hinterlegt bekomme. Es wäre ja schonmal super wenn dieser Preis genommen wird für neu angelegt Angebotsvorlagen. Das hat dann zwar noch nichts mit Automatischer Preisberechnung zu tun, würde aber schonmal helfen. Bis jetzt ist diese Kundengruppe quasi nur eine REchenhilfe, welche ich dann mit Coppy - Paste einfüge.
Neu Vollautomatische Preiskalkulation!
- Ersteller des Themas Manuel Pietzsch
- Erstellungsdatum
-
- Schlagworte
- preiskalkulation wawi-umfrage wawi-video
ich habe ämir die Nacht damit um die Ohren geschlagen einen workaround zu erstellen.
Bis U2 oder die Wawi das (wieder) können, lasse ich täglich Nachts per Ameise die StandardVK der Wawi exportieren
(DIE sind über meine eigenen SQLs korrekt kalkuliert) -
Diese werden danach automatisch sofort mit den Aufschlägen wieder importiert.
An Sich gar nicht so schlecht, wenn das nicht so unglaublich langsam wäre.
Der Export dauert knapp 60 MInuten, der Import danach 2,5 Stunden....
Bis U2 oder die Wawi das (wieder) können, lasse ich täglich Nachts per Ameise die StandardVK der Wawi exportieren
(DIE sind über meine eigenen SQLs korrekt kalkuliert) -
Diese werden danach automatisch sofort mit den Aufschlägen wieder importiert.
An Sich gar nicht so schlecht, wenn das nicht so unglaublich langsam wäre.
Der Export dauert knapp 60 MInuten, der Import danach 2,5 Stunden....
Marc Costea (marcos software - Unicorn2) hat das hier gelesen, mich sogar heute an seinem Geburtstag angerufen (!! Happy Birthday !!) und mir mit einem SQL Script geholfen, welches vergleichsweise blitzschnell die Preise anhand meiner Vorgaben kalkuliert, speichert und die Übertragung an die entsprechenden Shops initialisiert.
Statt 1-3 Stunden Dauer per AMEISE E- und Import geht das nun in gerade mal ~4 MInuten für alle betreffenden Shops.
Statt 1-3 Stunden Dauer per AMEISE E- und Import geht das nun in gerade mal ~4 MInuten für alle betreffenden Shops.
@Manuel Pietzsch gibt es denn schon weitere/genauere Infos zur Preiskalkulation 2.0?
Oder habe ich irgendwas dazu (in einem anderen Thread) übersehen?
Oder habe ich irgendwas dazu (in einem anderen Thread) übersehen?
Die Frage, die JTL gern hier diskutieren möchte ist: Was ist denn eine Grundfunktion für die Preiskalkulation? Rohertrag, Deckungsbeitrag1 oder doch Deckungsbeitrag2? Jeder hat sicherlich noch ein paar Sonderthemen die berücksichtigt werden sollen?
Es gibt einen Grund, warum eine Implementierung von Navision Dynamics, Sage oder SAP so extrem teuer sind. Weil genau die individuelle Anpassung = Customizing an die spezifischen Anforderungen des Unternehmens eben im Standard nicht drin sind und hier per Programmierung eingegriffen werden muss. Aber klar, macht aus der Wawi die eierlegende Wollmilchsau, packt alles rein, was man vlt. mal brauchen kann und JTL verlangt dann mtl. 199€ pro User. Ist das Gemecker auch wieder groß... Da finde ich den Ansatz von JTL prinzipiell gut, ein Modul zu entwickeln und gesondert abzurechnen, wie bspw. der Zahlungsabgleich. Wer es brauchen kann zahlt, fertig.
Sorry, wollte keine Diskussion vom Zaun brechen, aber das musste ich mal loswerden.
Hi Freunde,
alle sind auf die Stabilisierung der 1.6 und Anbindung weiterer Marktplätze fokussiert.
Also wenn es was neues gibt erfahrt ihr es hier
Gruß
Manuel
alle sind auf die Stabilisierung der 1.6 und Anbindung weiterer Marktplätze fokussiert.
Also wenn es was neues gibt erfahrt ihr es hier
Gruß
Manuel
Guten Tag,
ich möchte anmerken, dass eine Preiskalkulation für unterschiedliche Angebote von Amazon für einen internationalen Versandhandel notwendig ist, da in anderen Ländern z.B. andere Kosten entstehen, andere Mehrwertsteuersätze vorliegen oder auch Wechselkurse sich verändern.
Bei einer größeren Menge an Artikeln und Angeboten muss zudem ebenfalls eine Bearbeitung mehrerer Angebote auf einmal möglich sein, da sich oft eine Preisgrundlager z.B. für bestimmte Produktgruppen und Marktplatzländer ergibt. Um Angebote zu einer ASIN zu unterscheiden, wäre z.B. auch eine abspeicherbare Suchfunktion sinnvoll, da vielleicht manche die SKU mit eine Präfix oder Suffix versehen haben, um diese zu unterscheiden. Diese kann man über eine Suche (SKU startet mit etc.) direkt ansprechen. Ein Zugriff auf die eigenen Felder muss hier auch zwingend notwendig sein, um diese überhaupt sinnvoll nutzbar zu machen. Denn wenn ich keine Eingangsrechnungen verwende, dann ist mein Einkaufspreis beim Lieferanten vorhanden, aber nicht die dazu anfallenden Kosten wie Zoll, Versandkosten, Bearbeitungsgebühren etc.
Vielen Dank
ich möchte anmerken, dass eine Preiskalkulation für unterschiedliche Angebote von Amazon für einen internationalen Versandhandel notwendig ist, da in anderen Ländern z.B. andere Kosten entstehen, andere Mehrwertsteuersätze vorliegen oder auch Wechselkurse sich verändern.
Bei einer größeren Menge an Artikeln und Angeboten muss zudem ebenfalls eine Bearbeitung mehrerer Angebote auf einmal möglich sein, da sich oft eine Preisgrundlager z.B. für bestimmte Produktgruppen und Marktplatzländer ergibt. Um Angebote zu einer ASIN zu unterscheiden, wäre z.B. auch eine abspeicherbare Suchfunktion sinnvoll, da vielleicht manche die SKU mit eine Präfix oder Suffix versehen haben, um diese zu unterscheiden. Diese kann man über eine Suche (SKU startet mit etc.) direkt ansprechen. Ein Zugriff auf die eigenen Felder muss hier auch zwingend notwendig sein, um diese überhaupt sinnvoll nutzbar zu machen. Denn wenn ich keine Eingangsrechnungen verwende, dann ist mein Einkaufspreis beim Lieferanten vorhanden, aber nicht die dazu anfallenden Kosten wie Zoll, Versandkosten, Bearbeitungsgebühren etc.
Vielen Dank
Hallo,Hi Freunde,
alle sind auf die Stabilisierung der 1.6 und Anbindung weiterer Marktplätze fokussiert.
Also wenn es was neues gibt erfahrt ihr es hier
Gruß
Manuel
gibt es bezüglich der Preiskalkulation schon etwas Neues?
Viele Grüße
Hi,
leider nein. Das Team ist absolut auf die Stabilisierung der JTL-Wawi 1.6, das Release von JTL-Vouchers und die Anbindung weiterer Markplätze fokussiert.
Gruß
Manuel
Bin hier auf diesen Thread gestoßen, weil sich bei mir die Preise von Stücklistenkomponenten geändert haben.
Nun festgestellt, dass sich die Preise der STücklistenartikel nicht automatisch auch aktualisiere.
Nun sitzt ich seit Stunden dran und rufe die Artikel einzeln auf und lass den Preis mit einem Klick auf den zugehörigen Button neu berechnen.
Konnte hier keine Funktion dazu finden und über die Ameise die Stülis zu exportieren und dann deren Preise, die ich zudem noch extra aus einer anderen Tabelle mit Sverweis holen muss, kann doch nicht der Lösungsweg sein.
Automatische Stüli-Preis-Berechnung über entsprechend Mehrfachmarkierung wäre schon ein sehr tolle Sache.
Oder in Preiskalkulation 2.0 integriert.
Nun festgestellt, dass sich die Preise der STücklistenartikel nicht automatisch auch aktualisiere.
Nun sitzt ich seit Stunden dran und rufe die Artikel einzeln auf und lass den Preis mit einem Klick auf den zugehörigen Button neu berechnen.
Konnte hier keine Funktion dazu finden und über die Ameise die Stülis zu exportieren und dann deren Preise, die ich zudem noch extra aus einer anderen Tabelle mit Sverweis holen muss, kann doch nicht der Lösungsweg sein.
Automatische Stüli-Preis-Berechnung über entsprechend Mehrfachmarkierung wäre schon ein sehr tolle Sache.
Oder in Preiskalkulation 2.0 integriert.
Leute, votet hier zum Thema:
https://issues.jtl-software.de/issues/WAWI-4096
vielleicht bewegt sich etwas hierzu.
https://issues.jtl-software.de/issues/WAWI-4096
vielleicht bewegt sich etwas hierzu.
Wir lösen die vollautomatische Preiskalkulation mit komplexen Workflows und müssen uns eigentlich, Stand heute, keine Sorgen um falsche, oder falsch berechnete Preise machen.
Allerdings wäre auch für uns die hier in Aussicht gestellte vollautomatische-preiskalkulation interessant.
Allerdings wäre auch für uns die hier in Aussicht gestellte vollautomatische-preiskalkulation interessant.
Zuletzt bearbeitet:
Welche Preise werden hierbei alle berücksichtigt?
JTL-Shops
Amazon
eBay (mit ohne Varianten)
Ihr würdet uns daran nicht zufällig teilhaben lassen?
Die für uns relevanten: WAWI-, SHOP-, SONDER- und STAFFELpreise. Die Preiskalkulation fängt auf Grundlage des DLG beim Wareneingang statt. Mit Amazon und eBay haben wir nichts am Hut. Allerdings ist es ja auch nur eine weitere Schiene in der Preisübersicht des Artikels.
Kurz gesagt, wird die Preiskalkukation in den Workflows durch den Wareneingang angesoßen, nach eigenen Formlen und Bedürfnissen unter Berücksichtigung verschiedener Faktoren erstellt und exportiert und anschließend über eine selbsterstellte Batch-Datei mittels Amaise automatisch importiert und auf allen Kanälen aktualisiert. Daneben werden eigene Artikel-Felder und Grundfunktionen des Artikel wie Warengruppen als Hebel genutzt, um weiter zu differenzieren.
Beispiel Batch-Datei (Artikelpreise_aktualisieren.bat):
FOR /R "E:\Programme\InstallierteProgramme\JTL\Automatischer_Import\" %%G IN (*.csv)^
do ("C:\Program Files (x86)\JTL-Software\JTL-wawi- ameise.exe" -w JTL -d eazybusiness -u XXX -XXX -t IMP6 -i %%G)
FOR /F %%I IN ("E:\Programme\InstallierteProgramme\JTL\Automatischer_Import\preiskalkulation_automatischer_Import*.csv") do (del %%I)
close
Zuletzt bearbeitet:
OK, ja so in etwa hatte ich es in Gedanken, automatisiert dann mit Ameise ... es geht ja, hatten es aber zurückgestellt, da für uns der GLD entscheidend ist, der aber aktuell falsch berechnet wird (für uns ist der zum Zeitpunkt eines Verkaufs gültige EK wichtig).
https://forum.jtl-software.de/threa...hung-von-gewinnmargen-statistiken-etc.171512/
JTL plant hier ja eine zentrale Preisberechnungslogik, diese wäre für uns dann die Lösung, vor allem wenn das Thema GLD gelöst wird und können dann alle Platfformen sauber ansteuern.
https://forum.jtl-software.de/threa...hung-von-gewinnmargen-statistiken-etc.171512/
JTL plant hier ja eine zentrale Preisberechnungslogik, diese wäre für uns dann die Lösung, vor allem wenn das Thema GLD gelöst wird und können dann alle Platfformen sauber ansteuern.
Ein Problem im GLD konnte ich nicht erkennen. Also wir nutzen aber auch die 1.6 und der GLD kann da wahlweise nach Wareneingang, oder nach Lieferantenrechnung erzeugt werden. Einziges Manko was mich stört, sind die Lieferkosten einiger Produzenten, die sich in der JTL-Beschaffung nicht in den GLD einkalkulieren lassen. Dadurch bekomme ich nicht den gewünschten / realen EK den ich brauche um daraus einen VK zu produzieren. Das wiederum verzerrt meine Marge.
der GLD war nie richtig (vor allem nicht für uns) … siehe anderen Thread, mal in Ruhe lesen, dann versteht man die Standpunkte 😊
Zuletzt bearbeitet:
@Manuel Pietzsch
Gibt es schon neue Infos zu diesem Thema?
Sind gerade am Überlegen, ob wir da selbst was basteln, können uns den Aufwand aber sparen, wenn ein release der neuen Preiskalkulation in greifbarer Nähe wäre?
Danke schonmal vorab für die Info.
Interessant fänden wir auf jeden Fall jene Variante, bei der man im Artikelstamm eine Formel zur Berechnung des VK's hinterlegen könnte.
Gibt es schon neue Infos zu diesem Thema?
Sind gerade am Überlegen, ob wir da selbst was basteln, können uns den Aufwand aber sparen, wenn ein release der neuen Preiskalkulation in greifbarer Nähe wäre?
Danke schonmal vorab für die Info.
Interessant fänden wir auf jeden Fall jene Variante, bei der man im Artikelstamm eine Formel zur Berechnung des VK's hinterlegen könnte.
Ich dachte versandkosten werden wenn du über Rechnung Buchst automatisch umgelegt, zumindest war ich bis jetzt der Meinung.
Korrekt, bei mir auch nicht.
Kann auch nicht da nicht der tatsächliche Preis des Lieferanten gezogen wird.
Ähnliche Themen
Ähnliche Themen
-
Automatische Preiskalkulation anhand Basispreis abhängig an Kundengruppe
- Started by Reasy
- Antworten: 0
-
Preiskalkulation auf Grundlage von Lieferantenpreise und Lieferantenbestand
- Started by myt
- Antworten: 1