Neu Plattformkosten auf Auftragspositionsebene in die JTL WaWi schreiben

[maggi1989]

Hallo liebe Community,

ich bräuchte eine Idee oder ein Best Practice wo man Plattformkosten auf Auftragspositionsebene am besten in die JTL WaWi schreibt. Leider haben Auftragspositionen keine eigenen Felder. Ich habe bei Auftragskosten noch keinen Weg gefunden, wie ich das überhaupt befüllen kann, ebenso wie bei Auftragspositionseigenschaften. Am liebsten wäre es mir über die API oder notfalls auch die Ameise. SQL Inserts sind immer mit ein wenig Bauchschmerzen verbunden. Ich danke euch schon mal für eure Tipps!

VG Markus

 

[John]

Dafür gibts leider nicht fertiges. Da kannst Du Dir höchstens eine eigene Tabelle per SQL anlegen und darin Arbeiten...

 

[maggi1989]

Legst du sowas dann direkt in der eazybusiness an oder lieber in einer Art StagingArea?

 

[frankell]

Hallo Markus,

Du kannst Dir in der DB ein eigenes Schema anlegen, das Du für Deine eigenen Tabellen verwendest. Die bleiben auch von Updates verschont.

Viel spannender ist aber die Frage, was Du damit anfangen möchtest. Die Funktion der Auftragskosten ist nach wie vor eher rudimentär und abseits von Eigenen Felder kannst Du auch nichts in die GUI einfügen. Die Kosten also wirklich übersichtlich und positionszuordenbar in die Auftragsmaske zu bekommen, ist aktuell nicht möglich.

Ich hab für einen Kunden eine Auswertung gebaut, die auf Eigenen Feldern bei der Firma beruht. Dort kann er die Kosten einstellen, wie sie anfallen. Die Auswertung zieht sich die Werte von dort je nach Plattform des Auftrags. Du kannst aber natürlich auch alles rein auf DB-Ebene machen und Auftragsauswertungen in der Wawi auf Basis von Eigenen Übersichten anzeigen lassen, sowohl je Auftrag als auch kumuliert.

VG,
Frank

 

[maggi1989]

Hallo Frank,
wir betreiben einen eigenen Data Lake für die Business Intelligence, jedoch war mein Ziel immer die Rohdaten zur Überprüfung in der WaWi sichtbar zu machen.
In diesem Fall geht das also leider nicht und es wird eine Tabelle in der Staging Area mit Upsert Logik, dass wir die Daten im DataLake als Full Load ziehen können ohne die Historie zu verlieren.
Wir haben die Plattformkosten der jeweiligen Plattform als Kalkulationsartikel in der WaWi, dass die Fachabteilung Preisänderungen selbstständig pflegen können. Meistens ändern sich ja nur die Werte und nicht die Kalkulationslogik.

VG Markus

 

[Robin M.]

Hallo Markus,

der Weg über ein eigenes Schema ist richtig — die nativen Auftragskosten sind zu rudimentär, und ein eigenes Schema übersteht die Updates.
Wir betreiben selbst JTL-Wawi multichannel (Amazon, eBay, Otto, Shop) und sind genau aus deinem Grund auf eine eigene Auswertung außerhalb der WaWi gegangen.

Eine Sache, die bei uns rückblickend die eigentliche Arbeit war — und die ich dir mitgeben würde, bevor du das Schema festzurrst: Das Speichern der Plattformkosten auf Positionsebene ist der einfache Teil. Die saubere Zurechnung ist das Harte. Zwei, drei Fragen, an denen wir uns die Zähne ausgebissen haben:
– Wie ordnest du Versandkosten bei Multi-Positions-Aufträgen zu — gewichtsbasiert oder gleichmäßig? Das verzerrt den Positions-Reingewinn massiv.
– Ziehst du die echten kanalspezifischen Gebühren pro Bestellung (Amazon/eBay/Otto unterscheiden sich stark, FBA hält noch zusätzlich ein) oder arbeitest du mit Pauschalen über die Kalkulationsartikel?
– Wie verbuchst du Retouren/Erstattungen zurück auf die Ursprungsposition? Sonst sieht der Reingewinn auf dem Papier besser aus, als er ist.

Wenn du das im Data Lake gleich richtig modellierst, sparst du dir später viel Nacharbeit. Falls hilfreich, teile ich gern, wie wir die drei Punkte gelöst haben.
Oder hast du ein ganz anderen Hintergrund wofür du die Daten genau brauchst, also was ist das eigentlich Ziel?

 

[maggi1989]

Hallo Robin,

danke für die ausführliche Antwort. Gott sei Dank läuft bei uns Amazon über die Sellerboard, denn dort ist die Logik sehr kompliziert. Das andere haben wir über Kalkulationsartikel gelöst, die je nach Gewicht, Größe und Anzahl im Auftrag für Versandkosten und nach Preis und Kategorie für die Plattformprovision zugeteilt werden.. Meistens sind es Gott sei Dank keine Sammelbestellungen und die Gleichverteilung ist auch in Ordnung, da sich die Produkte nicht groß unterscheiden in der Größe. Retouren werden über die Auftragsid rückgebucht für den Teil der dann auch erstattet wird.
Das eigentliche Ziel ist genau diese möglichst genaue Auflistung der Kosten zur Deckungsbeitragsrechnung und Werbebudgetsteuerung.

VG Markus

 

[Robin M.]

Hi Markus,

danke fürs Konkretisieren — mit „DB-Rechnung + Werbebudgetsteuerung" als Ziel wird's klarer, und ich glaube, du machst's dir an einer Stelle unnötig schwer.

Kurz zu den drei Knackpunkten aus meinem letzten Post, wie wir's gelöst haben:

- Versand: zweistufig. Vor dem Versand eine Vorausberechnung (Methode nach Gurtmaß/Gewicht zur billigsten passenden Methode) — solange noch keine Lieferscheine da sind. Sobald die Lieferscheine vorliegen, rechnen wir zurück: dann mit den echten Versandkosten, die nach demselben Verteilwert wieder auf die Positionen aufgeteilt werden. Heißt: erst Schätzung fürs Tagesgeschäft, dann exakte Zurechnung auf Ist-Basis für die DB-Rechnung.

- Gebühren: echte kanalspezifische Gebühren aus den Transaktionsberichten statt Pauschale. Bei Amazon kommt das ohnehin aus der SP-API — Pauschalen verzerren dir gerade die DB-Rechnung, die du sauber haben willst. (Sellerboard macht das für Amazon genau so, nur eben Amazon-only.)

- Retouren: über die Order-ID auf die Ursprungsposition zurückgebucht, und dabei Verkauf / Erstattung / Retoure getrennt geführt — sonst siehst du den Gewinn-Impact einer Retoure nicht.

Der eigentliche Punkt: Wenn das Ziel die Deckungsbeitragsrechnung ist, ist „Kosten auf Wawi-Positionsebene zurückschreiben" eventuell der falsche Hebel. Du brauchst die Zahlen in einer Auswertung (DB je Artikel/Hersteller/Kanal, FBA vs. FBM getrennt) — nicht zwingend zurück in der Auftragsmaske. Das spart dir das ganze geschützte-Schema-Gefummel und das Risiko bei Wawi-Updates.

Offenlegung, damit's sauber ist: Wir haben genau das in ein Produkt gegossen (VALQON) — Wawi read-only anbinden, kanalgenaue Kosten/Retouren reinrechnen, DB pro Artikel/Hersteller/Plattform raus. Wir sind gerade in der Gründungsphase und suchen eine Handvoll JTL-Händler, die das mit echtem Feedback mitformen — klingt für mich, als würdest du genau in der Tiefe denken, um die's uns geht. Wie wir die Zurechnung im Detail machen (gerade Versand & Retouren), zeig ich dir gern — frag einfach. Und falls dich das Produkt interessiert: auf valqon.de kann man sich für die Gründerliste eintragen, unverbindlich.

Robin

 

[maggi1989]

Hi Robin,

bei uns funktioniert eigentlich alles sehr gut. Wir bilden direkt die gleiche Logik des Fullfillers ab und müssen daher nicht rückrechnen was auf dem Lieferschein steht. Bei dem Thema ging es um Preisänderungen, die wir trotzdem als Full-Load abbilden möchten. Ich wollte nur keine Extratabelle erstellen aber das hat sich nicht vermeiden lassen in dem Fall. Problematisch sind bei uns vor allem AboutYou und Zalando gewesen, weil die API der beiden sehr wenig bietet und sie eine hohe Komplexität in der Kostenstruktur haben.
Wir sind aber trotzdem eigentlich sehr zufrieden mit jetzigen Lösung.
Wir unterhalten eine eigene IT mit 4 Mitarbeitern und haben schon ein komplettes BI Dashboard für alle Non Amazon Marktplätze gebastelt. Ich glaube euer Angebot richtet sich eher an Leute, die in dem Bereich noch nichts haben. Trotzdem danke für das Angebot und viel Erfolg. Als Tipp noch aus unserer Praxis. Gerade Amazon ist sehr breit aufgestellt mit solchen Lösungen, aber in unserem Bereich Fashion sind es die anderen Marktplätze die API mäßig wenig abbilden und deshalb viel Individuallösungen verlangen. Viel Erfolg euch.

Viele Grüße

Markus

 

[Robin M.]

Hi Markus,

klingt, als wärt ihr da schon richtig sauber aufgestellt — mit eigener IT und eigenem BI für die Non-Amazon-Kanäle braucht ihr von außen nichts, da hast du völlig recht.

Der Tipp mit AboutYou und Zalando ist Gold wert, danke dafür. Genau dieser Fashion-Bereich — schwache APIs, fummelige Kostenstruktur, viel Individuallösung — ist bei uns aktuell noch nicht abgedeckt; wir sind heute tief in den Standardkanälen (Amazon SP-API, eBay, Otto). Solche Praxis-Hinweise sind für uns in der Phase viel Wert!

Nur zur Einordnung, falls jemand später mitliest und es verwechselt: Bei uns muss niemand Lieferscheine oder Kosten manuell zurückimportieren — das läuft alles automatisch über den read-only- Connector, der Kunde hält nur seine Artikelstammdaten in JTL sauber.
Aus genau diesen Verkaufs- und Kostenhistorien machen wir zwei Dinge: einmal saubere Auswertungen über alle Kanäle, und zum anderen lassen sich daraus deckungsbeitragsgetriebene Exporte je Kanal bauen. Beispiel: „Artikel X soll auf Otto mindestens 10 % DB bringen" — die echten Artikelkosten ziehen wir aus der Historie (oder berechnen sie voraus) und erzeugen daraus einen sauberen Ameise-Export, den der Kunde dann selbst in die Wawi zurückspielt. Es geht also nie ums „Kosten in die Auftragsposition schreiben", sondern um saubere Zahlen rein wie raus.

Was mich an eurem Setup ehrlich reizt:
Die API-armen Fashion-Kanäle wie AboutYou und Zalando stehen bei uns auf der Roadmap. Hätten wir dafür ein Gründungsmitglied, das genau diese Painpoints im Tagesgeschäft hat, könnten wir diese Schnittstellen gleich von Anfang an sauber implementieren — und ihr könntet dabei aktiv mitgestalten, wie sie am Ende funktionieren.

Sollte also irgendwann doch mal das Interesse bestehen renizuschauen oder wenn du einfach nur mal gegen eine zweite Meinung sparren willst, melde dich gern, ganz unverbeindlich!

Dir und dem Team weiterhin viel Erfolg!

Robin

 

[frankell]

— schwache APIs, fummelige Kostenstruktur, viel Individuallösung —

Mich deucht, da wär ne KI am Werk.

 

[Robin M.]

Wer verfasst den heutzutage noch selber Texte / Mails? 🧐🙃