Neu Vollautomatische Preiskalkulation!

[jn.tbr]

Hallooooo

gibt es was neues zu dem Thema? Das ist wirklich ein sehr spannendes Thema, was durchaus viele schmerzen nehmen kann

 

[wawi-dl]

Das wird so schnell nicht kommen.

Abhilfe schaffen " Eigene Felder" und Workflows die auf Artikeländerungen reagieren und Preise neu kalkulieren.
Hilft uns zumindest bei Webshops.

 

[Dalibor Josic]

Man kann durchaus mit eigenen Workflows sämtliche Preise automatisch kalkulieren lassen und automatisch zu den Plattformen übertragen lassen.
Kundengruppenpreise, Kundenindividuelle Preise, Amazon, eBay, Plattformen die über UNICORN 2 laufen, etc.
Auch die Währung wird berücksichtigt, wenn ihr z.B. auf Amazon.pl verkauft und die Preise in Zloty ausgegeben werden.
Natürlich ist dieser Aufwand nicht kostenlos, da hier eine individuelle Programmierung geleistet wird.

Falls jemand diesbezüglich Interesse hat, dann gerne ein PN schicken.

 

[Weedmaster-Flash]

Das wird so schnell nicht kommen.

Abhilfe schaffen " Eigene Felder" und Workflows die auf Artikeländerungen reagieren und Preise neu kalkulieren.
Hilft uns zumindest bei Webshops.

würdest du den Workflow Aufbau mit eigenen Feldern mal zeigen?

 

[wawi-dl]

Wir wollten keine Tools dafür bauen, natürlich könnte man das, haben wir eigentlich auch fast fertig in der Schublade.
JTL hat noch nicht alle Felder hinterlegt, dass man für Plattformen Preise setzen kann, mal sehen wanns kommt.


Eigene Felder in Artikel sieht bei uns so aus:


Workflow dazu unter Artikel geändert und Wareinlagerung Plusbuchung:





ABER, es ist auf unsere BEDÜRFNISSE angepasst, vor allem die Preisberechnung!
Zudem fehlt aktuell noch der Korrekturfaktor.

{%- assign VKNetto = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK-Aufschlagsfaktor -%}
{%- if VKNetto <= 0.0084 -%}
0,01
{%- elsif VKNetto > 0.0084 and VKNetto <= 0.0168 -%}
0,02
{%- else -%}
{{ Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK-Aufschlagsfaktor | FormatNumber: 'N4' }}
{%- endif -%}

 

[apalusa]

Hier ein Issue Ticket um per Workflow die Preise von Webshops (z.B. Unicorn2) aber auch die neuen SCX Verkaufskanäle setzen zu können, bitte fleißig dafür voten, das wäre schonmal ein guter Anfang:
https://issues.jtl-software.de/issues/WAWI-66088

 

[wawi-dl]

danke, bestes Ticket

 

[jn.tbr]

Wir wollten keine Tools dafür bauen, natürlich könnte man das, haben wir eigentlich auch fast fertig in der Schublade.
JTL hat noch nicht alle Felder hinterlegt, dass man für Plattformen Preise setzen kann, mal sehen wanns kommt.


Eigene Felder in Artikel sieht bei uns so aus:
Den Anhang 91081 betrachten

Workflow dazu unter Artikel geändert und Wareinlagerung Plusbuchung:

Den Anhang 91084 betrachten



ABER, es ist auf unsere BEDÜRFNISSE angepasst, vor allem die Preisberechnung!
Zudem fehlt aktuell noch der Korrekturfaktor.

{%- assign VKNetto = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK-Aufschlagsfaktor -%}
{%- if VKNetto <= 0.0084 -%}
0,01
{%- elsif VKNetto > 0.0084 and VKNetto <= 0.0168 -%}
0,02
{%- else -%}
{{ Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK-Aufschlagsfaktor | FormatNumber: 'N4' }}
{%- endif -%}

Sau Geil!

Ich hab das mal übernommen und ein wenig gespielt- leider kenne ich mich noch nicht 100% aus
Aufschlag hab ich nun gerafft, wenn man 50% haben will, sagt man 1,5- das passt und klappt super. Allerdings hab ich Fragen dazu und hoffe du magst mir helfen...:

1. Wie kann ich denn anschließend die Preise glätten auf eine *.95 oder *.45 oder so?
2. Kann ich so auf einem Schlag bei Speicherung des Artikels B2B, B2C und Kanäle preise anpassen?
3. Wie hast du das beim WE gemacht? Einfach das selbe nur eben Workflow ab Wareneingang?
4. kann man den EK des günstigsten oder lieferbaren Lieferanten nehmen, statt den durchschnittliche EK? bzw. eine art "fallback" dass wenn der EK nicht da ist, man den EK nimmt oder eben UVP? Den UVP Fallback hab ich hinbekommen....


Ich denke aber es ist sinnvoller, das nicht nach jedem speichern diesen Workflow zu machen sondern bei vielen Artikeln eventuell das teil nachts laufen lassen...

{%- assign VKNetto = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK_Aufschlagsfaktor -%}
{%- if VKNetto <= 0.0084 -%}
{{ Vorgang.Allgemein.PreiseEinheiten.UVP }}
{%- elsif VKNetto > 0.0084 and VKNetto <= 0.0168 -%}
{{ Vorgang.Allgemein.PreiseEinheiten.UVP }}
{%- else -%}
{{ Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | Times: Vorgang.EigeneFelder.Preisermittlung.VK_Aufschlagsfaktor | FormatNumber: 'N4' }}
{%- endif -%}

 

[SebiW]

Stelle ich auch mal meinen Meldeworkflow rein falls jemand ähnliche Bedürfnisse hat.
Ich bin im Endeffekt wieder davon abgekommen daszu automatisieren, da wir zu viele Sonderfälle und Produktgruppen haben.
Ich habe zwar ein paar vorbereitete Workflows (Mindestpreis berechnen, VK Preis für Plattform Shop / Ebay / Ama berechnen (inklusive Versandklasse und Aufschlägen für Werbung etc)), habe das Projekt im Endeffekt aber abgebrochen, weil die Komplexität und damit die Fehlerwahrscheinlichkeit zu hoch wurde.
Insbesondere für Stücklisten muss man echte Klimmzüge machen, da bei Änderung des EK0s von Komponenten keine Workflows für Stückliste angestoßen werden. Heisst Änderung regelmässig via Ameise anstoßen usw.
Spätestens jetzt mit den neuen Marktplatzanbindungen ist das auf Workflowebene imho nicht mehr automatisiert lösbar wenn man kein sehr homogenes Artikelfeld hat. Haben wir nicht.
Und wenn ich dann meine Artikel eh dauernd prüfen muss kann ich sie auch gleich händisch setzen.

Ich informiere mittlerweile nur noch die entsprechenden Sachbearbeiter wenn da was nachgepflegt werden muss.

WF: GLD Netto geändert
Prüfen ob sich der GLD Netto bei Änderung eines Artikels ebenfalls geändert hat. Dafür wird ein Funktionsattribut KALK-GLD-ALT benötigt.

1. Bedingung: GLD Netto gleich 1

Erweiterte Eigenschaft: GLD Netto

HTML clipboard {% assign GLD-ALT = Vorgang.Attribute.Global.Autokalkulation.KALK-GLD-ALT.Einsprachig | FormatNumber: 'N2', 'de-DE' -%}
{% assign GLD-NEU = Vorgang.Allgemein.PreiseEinheiten.Ø_Einkaufspreis-Netto | FormatNumber: 'N2', 'de-DE' -%}
{% if GLD-ALT == GLD-NEU-%}
0
{% else -%}
1
{% endif %}

1. Aktion: Wenn ja, Meldung an Sachbearbeiter.
2. Aktion: Neuen GLD Netto in Attribut schreiben (Wichtig, nach Aktion 1, sonst schickt man 2 mal die gleiche Zahl für GLD alt und neu)

Im Endeffekt fällt da jetzt eine Mail "Hallo Sachbearbeiter, Artikel 123 hat sich geändert, Preis alt ist 1, Preis neu ist 2, schau Dir das mal an" raus.

 

[wawi-dl]

Schade @SebiW ... ich hatte damals deine Anregung aufgefasst, für uns passt es ganz gut.
Probleme gibt es nur in 1.5.X.X, da die Staffelpreise zwar im Artikel richtig angezeigt werden (werden beim öffnen eines Artikel berechnet, stehen so NICHT in der DB), aber nicht an den Shop gehen, die Änderungen werden noch nicht erkannt.
Wir hoffen, dass seitens JTL endlich mal die Preiskalkulation kommt, dann könnten wir alle Plattformen evtl. automatisieren.


@jn.tbr
Das haben wir noch in Arbeit, haben wir aber erstmal zurückgestellt.
Im Grunde müsste man die Nachkommestellen strippen und untersuchen und dann durch eigene Werte ersetzen.
Man braucht dazu aber mehrere Variablen, um den String zu zerlegen und zusammenzusetzen.

Unsere Idee:
0,1 - 0,3 = 0,25
0,3 - 0,6 = 0,50
0,6 - 0,8 = 0,75
0,8 - 1,0 = 1,00

ACHTUNG, bei WE ist alles im Grunde identisch, NUR dass der Workflow zeitversetzt sein muss!
In JTL wird leider die Menge erst gebucht und dann der Artikel geändert, somit würde der Workflow ins leere laufen.

 

[Verkäuferlein]

Auch wenn ich hier spät einsteige, grundsätzlich würde ich für die automatische Preisaktualisierung stimmen, auch wenn Teile aus der Preiskalkulation 2.0 auch interessant sind.

Das Grundproblem fängt aber eigentlich viel früher an und sollte mal als erstes gelöst werden, nämlich welche Preise gibt es überhaupt in der Wawi und in welchem Zusammenhang stehen diese. Das ist ja glücklicherweise auch ein Stück weit schon in den hier eingefügten Tickets benannt worden.

Danach gibt es dann aber so viele Faktoren, die für eine saubere Preiskalkulation sinnvoll sind und die leider auch nicht statisch sind, dass das Konzept von JTL längst überholt ist, wenn man sich mal ein bisschen die Zeichen am Horizont anguckt.

Uns wäre schon geholfen, wenn anhand des EKs mittels eines Faktors die Stücklisten, Varianten, Plattform und Shoppreise sauber in Abhängigkeit zum EK gesetzt werden könnten.

EK (aktuell oder für zukünftige Einkäufe) ändert sich
-> Stücklisten-Preise werden angepasst
-> Plattform-Preise werden angepasst
-> Kundengruppen-Preise werden angepasst
-> Staffel-Preise werden angepasst
-> Sonder-/Aktions-Preise werden angepasst

Als erstes bedarf es also einer Übersicht, auf welche Preise sich eigentlich eine Anpassung an irgendeinem Preis auswirkt, also welche Abhängikeiten bestehen.

Und anschließend kann man sich dann an die deutlich komplexere "Kalkulation" machen. Für die meisten Punkte fehlen dazu aber noch die Daten in der Wawi.

Um mal ein paar Beispiele - insbesondere von Variablen Faktoren - zu nennen (diese müssten also alle irgendwo in der Wawi ersteinmal vorhanden bzw. hinterlegt sein und mit der zugehörigen Logik arbeiten, damit überhaupt soetwas wie eine automatische Kalkulation möglich ist bzw. müssen sich auch zeitlich abhängige Faktoren hinterlegen lassen):
- Dieselzuschlag beim Paketdienst
- Saisonzuschlag beim Paketdienst
- Klimazuschlag beim Paketdienst
- Anzeigen / Zusatzprovisonen auf Plattformen
- Aktionen mit Plattformen ( Coupons / Gutscheine mit Händlerbeteiligung)
- Saisonzuschläge auf Plattformen (siehe z.B. Amazon USA)
- Rabatte für Mehrfachkäufe auf Plattformen
- Kosten für Verpackungsmaterial
- Kosten für Lizenzierungen (ElektroG / WEEE, VerPackG)
- Rabatt- und Skontovereinbarungen
- Lieferantenrabatte
- WKZ

Und dann mache ich mir Sorgen, dass zum einen die Programmierung 100% sauber sein muss (dazu sag ich mal nichts zu aktuellen Zusammenhängen) und zum anderen auch noch alle Werte fehlerfrei hinterlegt sein müssen, da man ansonsten sehr schnell sehr viel Geld verbrennt.

Dazu kommen dann noch Artikel, die aus verschiedenen Gründen auch wieder aus der Kalkulation rausfallen, weil es Gründe gibt, sie anders zu behandeln.

 

[Weedmaster-Flash]

Auch wenn ich hier spät einsteige, grundsätzlich würde ich für die automatische Preisaktualisierung stimmen, auch wenn Teile aus der Preiskalkulation 2.0 auch interessant sind.

Das Grundproblem fängt aber eigentlich viel früher an und sollte mal als erstes gelöst werden, nämlich welche Preise gibt es überhaupt in der Wawi und in welchem Zusammenhang stehen diese. Das ist ja glücklicherweise auch ein Stück weit schon in den hier eingefügten Tickets benannt worden.

Danach gibt es dann aber so viele Faktoren, die für eine saubere Preiskalkulation sinnvoll sind und die leider auch nicht statisch sind, dass das Konzept von JTL längst überholt ist, wenn man sich mal ein bisschen die Zeichen am Horizont anguckt.

Uns wäre schon geholfen, wenn anhand des EKs mittels eines Faktors die Stücklisten, Varianten, Plattform und Shoppreise sauber in Abhängigkeit zum EK gesetzt werden könnten.

EK (aktuell oder für zukünftige Einkäufe) ändert sich
-> Stücklisten-Preise werden angepasst
-> Plattform-Preise werden angepasst
-> Kundengruppen-Preise werden angepasst
-> Staffel-Preise werden angepasst
-> Sonder-/Aktions-Preise werden angepasst

Als erstes bedarf es also einer Übersicht, auf welche Preise sich eigentlich eine Anpassung an irgendeinem Preis auswirkt, also welche Abhängikeiten bestehen.

Und anschließend kann man sich dann an die deutlich komplexere "Kalkulation" machen. Für die meisten Punkte fehlen dazu aber noch die Daten in der Wawi.

Um mal ein paar Beispiele - insbesondere von Variablen Faktoren - zu nennen (diese müssten also alle irgendwo in der Wawi ersteinmal vorhanden bzw. hinterlegt sein und mit der zugehörigen Logik arbeiten, damit überhaupt soetwas wie eine automatische Kalkulation möglich ist bzw. müssen sich auch zeitlich abhängige Faktoren hinterlegen lassen):
- Dieselzuschlag beim Paketdienst
- Saisonzuschlag beim Paketdienst
- Klimazuschlag beim Paketdienst
- Anzeigen / Zusatzprovisonen auf Plattformen
- Aktionen mit Plattformen ( Coupons / Gutscheine mit Händlerbeteiligung)
- Saisonzuschläge auf Plattformen (siehe z.B. Amazon USA)
- Rabatte für Mehrfachkäufe auf Plattformen
- Kosten für Verpackungsmaterial
- Kosten für Lizenzierungen (ElektroG / WEEE, VerPackG)
- Rabatt- und Skontovereinbarungen
- Lieferantenrabatte
- WKZ

Und dann mache ich mir Sorgen, dass zum einen die Programmierung 100% sauber sein muss (dazu sag ich mal nichts zu aktuellen Zusammenhängen) und zum anderen auch noch alle Werte fehlerfrei hinterlegt sein müssen, da man ansonsten sehr schnell sehr viel Geld verbrennt.

Dazu kommen dann noch Artikel, die aus verschiedenen Gründen auch wieder aus der Kalkulation rausfallen, weil es Gründe gibt, sie anders zu behandeln.

Hi zusammen,

die Auflistung von Verkäuferlein ist sehr detailliert und auch richtig. Jedoch glaube ich nicht das diese so detailliert mit den Werten in der WaWi eingepflegt werden muss.
Ich denke die Punkte wie Dieselzuschlag, Klimazuschlag, Anzeigen etc. müssen mit der gesamten Kalkulation der Marge oder des Rohertrages "abgedeckt" sein. Jeder sollte seine Zahlen kennen und daraus einen Handlungskostenzuschlagssatz in % errechnen. Und dieser muss dann in der "normalen Kalkulation" berücksichtigt sein. Oder anders herum müssen wenn ich z.B. mit 25% Marge rechne diese Kosten davon mitgetragen werden.
Ich glaube nicht ,dass eine "vollständige" Kalkulation unter Hinzunahme aller (genannten) Faktoren was in der WaWi zu suchen haben. Diese Werte und Zahlen müssen meiner Meinung nach an anderer Stelle ermittelt und berechnet werden.

 

[wawi-dl]

Also es war jetzt auch nicht die Rede davon, gleich Deckungsbeiträge mit reinzunehmen, dann werden wir nicht mehr fertig.
Es dreht sich im ersten Moment mal um VK Setzung durch Margen, hier sollte natürlich eine passende Berechnung erfolgen.

@Verkäuferlein soweit alles richtig, SellerMath würde dann auch ins Spiel kommen.

 

[Verkäuferlein]

Hi zusammen,

die Auflistung von Verkäuferlein ist sehr detailliert und auch richtig. Jedoch glaube ich nicht das diese so detailliert mit den Werten in der WaWi eingepflegt werden muss.
Ich denke die Punkte wie Dieselzuschlag, Klimazuschlag, Anzeigen etc. müssen mit der gesamten Kalkulation der Marge oder des Rohertrages "abgedeckt" sein. Jeder sollte seine Zahlen kennen und daraus einen Handlungskostenzuschlagssatz in % errechnen. Und dieser muss dann in der "normalen Kalkulation" berücksichtigt sein. Oder anders herum müssen wenn ich z.B. mit 25% Marge rechne diese Kosten davon mitgetragen werden.
Ich glaube nicht ,dass eine "vollständige" Kalkulation unter Hinzunahme aller (genannten) Faktoren was in der WaWi zu suchen haben. Diese Werte und Zahlen müssen meiner Meinung nach an anderer Stelle ermittelt und berechnet werden.

Wir leben ja aktuell in verrückten Zeiten, aber die aktuellen Dieselzuschläge machen ja mitunter gut und gerne 20-30% des Paketpreises aus und sind halt variabel.
Gleiches gilt für Saisonzuschläge (2 Zeitfenster mit jeweils 2 Monaten).
...

Nehmen wir mal das Beispiel ebay, da kommst Du mit 25% Marge je nach Kategorie schon nicht aus, wenn Du alle Marketinginstrumente spielen willst. Verkaufsprovision (auch auf Versandkosten) + 0,35 Euro + Mengenrabatt + 10% Coupon-Aktion. Ebay verdient, der Kunde freut sich und Du tauscht nur Ware gegen Geld.

Will man deshalb dann auf alle Artikel eine riesen Marge kloppen oder ggf. flexibel entscheiden, welche Artikel z.B. besonders vermarktet werden!?

Also es war jetzt auch nicht die Rede davon, gleich Deckungsbeiträge mit reinzunehmen, dann werden wir nicht mehr fertig.
Es dreht sich im ersten Moment mal um VK Setzung durch Margen, hier sollte natürlich eine passende Berechnung erfolgen.

@Verkäuferlein soweit alles richtig, SellerMath würde dann auch ins Spiel kommen.

Alle aufgeführten Kosten-/Rabatt-Positionen haben nur eingeschränkt mit dem Deckungsbeitrag zu tun, da es Artikel/Angebotsspezifische Kosten sind. Gemeinkosten sind hier ja noch gar nicht berücksichtigt, müssten aber natürlich auch mit einkalkuliert werden.

Insofern sage ich ja, es wäre zunächst einmal vollkommen ausreichend, wenn man in Abhängigkeit des EK alle verknüpften Preise (auch in Stücklisten und auf unterschiedlichen Plattformen) erst einmal in einer Übersicht sehen könnte und damit die Auswirkungen einer Preisänderung erblickt.

Im nächsten Schritt kann man dann entsprechend mit Faktoren arbeiten, die aber wieder auf Artikelebene in Kombination mit Plattform (Angebotsebene), etc. sein müssten.

Und wenn man es dann ganz genau machen will und da eine Automatik draus machen möchte, dann muss man halt auch die variablen (schwankenden, indexbasierten, saisonal begrenzten, aktionsbedingten, etc. pp.) Kosten berücksichtigen.

 

[jn.tbr]

An sich ist das richtig. Letztenendes kann man das alles unterteilen- streng genommen, muss man aber nur seinen eigenen VK kalkulieren- eBay und Amazon Arbeiten doch mit prozentualen Aufschlägen bei der Provision- wenn man also seinen Verkaufspreis hat, und hier eine MArge XY, dann muss man meines wissens doch nur auf den VK Netto die Provision Brutto aufschlagen (da eBay ja auf die Mehrwertsteuer die Provision nimmt- völlig abstrus!). Daraus ergibt sich ja dann eine minimal abweichende Marge zu deinem normalen Shop-VK, oder?

Also braucht man zur automatischen Kalkulation 2 Werte und hier und da nen Fallnetz...:

Kalkulation auf Hersteller, Kategorie und Artikel Basis (so müsste alles abgedeckt sein).
Artikel schlägt Kategorie schlägt Hersteller schlägt Fallnetz....

Was braucht man?
- Aufschlag in €
- Aufschlag in %

(EK + Aufschlag in €) + Aufschlag in % (einfach ausgesprochen) und schon hast du fixe Kosten und variable kosten mit eingerechnet (hier kann man die verschiedenen DB stufen gern beachten). Wenn der Artikel also keine Kalkulation hat, gehts auf Kategorie und so weiter. Man kann noch mit einer Globalen Aufschlag- und Mindesmarge arbeiten, welche dann als Fallnetz dient zum Beispiel.

Im Artikel sollten dann Checkboxen sein, die den VK festschreiben oder so, weil man so auch "Abwerten" kann, ohne dass die automatische kalkulation drüberjuckelt...

eBay und Amazon nehmen diesen errechneten Wert und hauen da eben die prozentuale Provision Brutto auf den VK netto drauf- also bei 14% eBay Provision rechnet man eben mit 16,66 % und etwaige fixe gebühren.

Also an sich, braucht man nicht allzuviele Einstellungen meiner Meinung nach, oder?

 

[SebiW]

Hu @jn.tbr - darüber hatten wir uns ja auch schon via PN unterhalten. Dein Vorschlag genügt, so lange die Artikel möglichst homogen sind.
Komplexer wird es schon, wenn mehrere Steuerklassen ins Spiel kommen und am Ende "schöne" Preise stehen sollen.
Noch komplexer wird es, wenn SCX oder Unicorn ins Spiel kommt - das ganze muss dann für jeden angebundenen Marktplatz laufen.
Noch komplexer wird es, wenn Ladengeschäfte mit eigener Kalkulation dazu kommen.
Noch komplexer wird es, wenn FBA oder anderes Fulfillment ins Spiel kommt - hier müssen artikelspezifische Aufschläge formuliert werden können.
Noch komplexer wird es, wenn Provision ins Spiel kommt.
Noch komplexer wird es, wenn unterschiedliche Kundengruppen ins Spiel kommen.
Noch komplexer wird es, wenn die Ware nicht homogen ist - also bspw günstige Kleinware andere Aufschläge braucht als große teure Palettenware.
Noch komplexer wird es, wenn verschiedene Firmen mit unterschiedlichen Shopstrategien dazu kommen.
Noch komplexer wird es, wenn Staffelpreise und Mischrabatte hinzu kommen.
Noch komplexer wird es, wenn UVP Vorgaben dazu kommen.
Noch komplexer wird es, wenn Saisonware mit entsprechenden Preisschwankungen dazu kommt.
Noch komplexer wird es, wenn die Artikel im direkten Wettbewerb stehen und Repricing benötigt wird.
Noch komplexer wird es, wenn man Rabattaktionen, Abverkäufe etc mit abbilden will. Eine Wawi die bspw am Black Friday hart immer wieder die Rabattpreise überschreibt wäre unfein.

Nicht alles davon betrifft alle. Aber irgendwas davon betrifft so gut wie jeden. Eine Automatik, die am Ende nur für einen Bruchteil der Artikel der JTL Kunden funktioniert macht keinen Sinn.
Die Automatik muss jetzt auch nicht alles davon abdecken. Aber zumindest für Basisgeschichten wie FBA und den hauseigenen Repricer sollte das schon funktionieren.
Und natürlich muss man auch dazu in der Lage sein händisch einzelne Artikel rauszugreifen und anders zu kalkulieren - und auch dann sollte die Automatik die ganzen Zusatzpreise auf Basis eines solchen händischen Eingriffs weiter berechnen. Also braucht es auch mehr als einen einfachen Prozentaufschlag auf den EK0. Ich will ja gerade nicht, dass die Marge meines Topsellers in den Boden geht nur weil ich ihn mal 2% billiger eingekauft habe.

Blöde gesagt: Wenn ich ein ganz einfaches Szenario habe brauche ich auch keine Automatik. Das ist mit einmal Export, Excel drüber, Import in 5 Minuten erledigt. Eine Automatik brauche ich um Komplexität einzufangen.

 

[jn.tbr]

Hey,

naja das meiste ist mit der Einstellung in Hersteller, Kategorie und Gruppe bereits abgetan. Ansonsten braucht man noch weitere Dinge- die Sachen die du aufgezählt hast, haben letzendlich nichts mehr mit der Kalkulation an sich zu tun, sondern sind sonderdinge die extra laufen müssen...

- ein Matching, welches die Preise entsprechend Wettbewerbstauglich macht mit Einstellmöglichkeiten der Mindesmarge bzw. einfach auch mit diesen werten (€ und % Aufschlag)
- Aktionssteuerung, in dessen Zeitraum die Automatik nicht greift, in der man Artikel in eine Aktion packen kann und entsprechend die Preise für Aktion festsetzt, und nach Beendigung automatisiert wieder in die Kalkulation hebt

Quasi:

Automatische Kalkulation: Preis-Verfügbarkeits Berechnung:
Verantwortlich für die reine Kalkulation der Preise, inkl. den Besonderheiten die man braucht- meines Erachtens braucht man da keine komplexe Berechnungen...:
- Aufschlag in €
- Aufschlag in %
- Fallback (Mindesmarge)

Und das Ganze auf Kategorie, Hersteller und Artikelebene- so kann man beispielsweise alles steuern, wenn man eine Kategorie oder Hersteller Kalkulation hat die reicht, muss man net in jeden Artikel einzeln gehen und hat zur Not ein Fallback. Hier kann sowas rein wie "nicht über UVP" oder auf Artikelebene VK festschreiben zum Abwerten oder eben nen Mindestpreis um höher als die Kalkulation zu verkaufen. die Verkaufskanäle wie eBay und Amazon rechnen die Provisionen nach Kategorien- hier kann man das system der kategorien übernehmen, kann diese direkt in der kategorie verknüpfen und nen provisionssatz + fixwert hinterlegen... dann muss man sich hier keine Sorgen machen.

Matching:
Ein System, in dem man Mindestmarge und Mindestplatz einträgt, welches dann völlig automatisiertmit den Preisen innerhalb von deiner vorgaben kalkuliert- auch gern in Kategorie, Hersteller und Artikel

Aktionssteuerung:
Wies schon der Name sagt eine Möglichkeit innerhalb von festgelegten Zeiträumen automatisiert Aktionen zu planen und zu steuern, welche nach Ablauf wieder normal die Preise anheben. Sokann man im Januar schon Blackfirdsay Planen und muss sich keine Sorgen machen.... überspitzt gesagt.


Ich wüsste aktuell kein Szenario, was man damit nicht abdecken kann..

 

[SebiW]

Kategorieebene ist vielleicht bei Dir eindeutig, bei uns aber in keinster Weise. Artikel können in verschiedenen Kategorien liegen - würde für uns als Fallback schonmal ausfallen.
Hersteller / Marke ist bei uns ebenfalls nicht eindeutig, da sprechen wir eher schon über Kombinationen von Warengruppe & Hersteller.
Dazu kommen dann noch Kleinigkeiten wie OSS Steuerklassen (Auf Basis welcher Steuer in welchem Land berechnest Du für welche Artikel wie den Brutto?)

Dein Szenario ist einfach, deshalb genügt für Dich eine einfache Lösung. Aber nochmal: Wenn ich ein einfaches Szenario habe BRAUCHE ich auch keine komplexe Automatik.

Ich kann Dir aber mit absoluter Sicherheit sagen: Ein einfacher Aufschlag in € oder % deckt unsere Bedürfnisse und die vieler anderer Firmen ab einer gewissen Größe absolut nicht mehr ab.
Wir sind Hersteller. Unsere B2C Preise müssen in gewisser Relation zu unseren B2B Preisen stehen. Da kommen dann auch noch Parameter wie Produktionskosten, White Labeling uvm dazu.
Und es hilft mir gar nix, wenn ich am Ende des Tages zwar eine automatische Berechnung habe, diese aber erfordert, dass ich ständig händisch bei den Artikeln eingreife und einzelne Aufpreissparameter anpasse.
Im einen Projekt brauche ich so eine Automatik durchgehend, im nächsten will ich sie für Artikelgruppen händisch anstoßen können, im übernächsten habe ich wieder Bedarf nach stabilen VK Preisen auf manchen Marktplätzen und fließenden Preisen auf anderen.

Für jedes komplexe Problem gibt es immer eine einfache Lösung. Und die ist immer falsch

 

[jn.tbr]

Also.. ich komme aus einem Millionen Konzern- einer meiner früheren Arbeitgeber mit sehr preisvolatilen Artikel hat genau so eine Berechnung gehabt- und das funktioniert seit 15 Jahren. Ich denke, mit soeiner sache kann man schon sehr viele Unternehmen abdecken. Klar- diese Sonderdinge müssen defintitiv anders geregelt sein. aber das ist für einige Unternehmen nicht Notwendig, wenn ich mir die Foren hier so durchlesen.. hm.. schwieriges unterfangen...

 

[Verkäuferlein]

Was braucht man?
- Aufschlag in €
- Aufschlag in %

(EK + Aufschlag in €) + Aufschlag in % (einfach ausgesprochen) und schon hast du fixe Kosten und variable kosten mit eingerechnet (hier kann man die verschiedenen DB stufen gern beachten). Wenn der Artikel also keine Kalkulation hat, gehts auf Kategorie und so weiter. Man kann noch mit einer Globalen Aufschlag- und Mindesmarge arbeiten, welche dann als Fallnetz dient zum Beispiel.

Aber was daran ist dann die "automatische Kalkulation", das ist eine ganz normale "manuelle" Kalkulation und wie gesagt, wenn man ein bisschen in die Zukunft blickt eigentlich schon heute überholt. Mit variablen Faktoren meine ich ja nicht die variablen Kostenanteile im Sinne des Deckungsbeitrags, sondern dass die Kalkulationsfaktoren halt variabel sind (z.B. im Dezember anders als im Januar) und dass eine automatische Kalkulation soetwas und die weiteren Abhängigkeiten berücksichtigen können sollte.

Tendenziell wird das auch immer dynamischer (siehe meine Beispiele ein paar Beiträge drüber), weil immer mehr Dienstleister Ihre Preisgestaltung variabel bzw. dynamisch gestalten und damit auch meine Kalkulation mit dieser Dynamik mitlaufen können muss.

Das hat insofern auch relativ wenig mit dem Deckungsbeitrag an sich zu tun, da es ja erstmal darum geht die "variablen Kosten" im Sinne des Deckungsbeitrages (DB1) zu benennen, aber eben nicht fix, sondern in "Echtzeit". Die Deckungsbeitragsrechnung geht ja eher von linearen Kostenverläufen im Bereich der variablen Kosten aus und das ist eben das Problem in der Kalkulation, dass es dies immer weniger gibt und daher eine stärkere Dynamik in der Kalkulation erforderlich ist. Sinn der Kalkulation ist es ja überhaupt einen positiven Deckungsbeitrag zu erreichen bzw. diesen möglichst vorhersagen zu können.

Im Onlinehandel ist es aus meiner Sicht aber nahezu unmöglich, den Deckungsbeitrag vorherzusagen bzw. im Vorhinein zu errechnen. Nehmen wir nur an, ich kalkuliere ein versandkostenfreies Angebot für eine Plattform, dann müsste ich ziemlich präzise auch einen Mengenrabatt kalkulieren, um einen gleichbleibenden Deckungsbeitrag zu erreichen (wäre auch eine Möglichkeit, was eine automatische Kalkulation berücksichtigen könnte).

In der Realität möchte ich aber einfach nur mit einem positiven Ergebnis herauskommen. Soll heißen: Kauft der Kunde 1 Artikel, habe ich einen anderen Deckungsbeitrag als, wenn der Kunde 2, 3,... Artikel kauft, weil sich die variablen Kosten im Sinne des DB1 nicht linear zur gekauften Menge verhalten.