Neu Vollautomatische Preiskalkulation!

Wissenssammler

Sehr aktives Mitglied
27. März 2016
439
77
Kottenheim
Ich bin nicht gewillt die Provisionen und Gebühren der diversen Marktplätze zu tragen, oder meinen Statndard-Preis entsprechend anzuheben. Kunden sollen da kaufen können wo es günstig ist und entsprehcned belohnt werden. Nicht pauschal alle bestraft....
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.
 
  • Gefällt mir
Reaktionen: Manuel Pietzsch

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.653
141
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....
 

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.653
141
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.
 
  • Gefällt mir
Reaktionen: Wissenssammler

HMS_IT

Sehr aktives Mitglied
29. Januar 2014
780
110
Leipzig
Sorry, aber in meiner Branche muss ich an jeder ecke das Geld zusammenhalten. da kann ich nicht noch zusätzlich geld ausgeben für eine WAWI Grundfunktion.

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.
 

LUGIUM

Gut bekanntes Mitglied
16. Februar 2018
74
56
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
 

JTL4Tom

Gut bekanntes Mitglied
15. November 2016
141
11
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.
 
  • Gefällt mir
Reaktionen: Wissenssammler

SHAAN

Sehr aktives Mitglied
26. August 2020
590
162
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.
 
Zuletzt bearbeitet:

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.923
568
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 vollautomatische-preiskalkulation interessant.
Welche Preise werden hierbei alle berücksichtigt?

JTL-Shops
Amazon
eBay (mit ohne Varianten)

Ihr würdet uns daran nicht zufällig teilhaben lassen?
 

SHAAN

Sehr aktives Mitglied
26. August 2020
590
162
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:
  • Gefällt mir
Reaktionen: wawi-dl

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.923
568
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.
 

SHAAN

Sehr aktives Mitglied
26. August 2020
590
162
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.

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.
 

koiandreas

Aktives Mitglied
16. September 2021
14
0
@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.
 

Wissenssammler

Sehr aktives Mitglied
27. März 2016
439
77
Kottenheim
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.
Ich dachte versandkosten werden wenn du über Rechnung Buchst automatisch umgelegt, zumindest war ich bis jetzt der Meinung.