Neu Statistik ist so doch nicht zu gebrauchen oder?

[Japsa]

Wenn du 2 Cent im VK runter gehst macht das kein 1,9 Cent im Gewinn aus.

Stimmt, es ist weit mehr

Bei mir ist es etwas so, dass wenn ich mehr verkaufe innerhalb eines Zeitraums X, dann der darauf folgende Zeitraum X ich weniger im EK aufwenden muß - das ist so mit meinem Hersteller / Lieferanten vereinbart und wie bekannt, liegt ja der Gewinn immer im EK begründet

 

[bauhelm-shop]

@Jaspa

Dann ist ja unsere beider Meinung ähnlich.
Umso unverständlicher ist das du Seller Math nicht kostenlos testen willst.

 

[Rico Giesler]

Auftrag 2.0 wird eine bessere Auswertung der Gewinne ermöglichen da hier dann verschiedene Faktoren mit einbezogen werden können.

 

[wawi-dl]

Diese ganze Gewinn-Berechnerei ist egal wie man sie macht, SEHR schwierig und KOMPLEX!
Vor allem gibt es mehrere Strategien ...

Fall 1
Man möchte Gewinne über die komplette Laufzeit eines Artikels ermitteln, man benötigt einen gEK.
Viele Fragen dazu ...
- wann setzt man diesen zurück?
- seit wann wird dieser gEK ermittelt?
- was passiert bei Korrekturbuchungen / defekten Artikeln?
- wurden Versandkosten vom Lieferanten berücksichtigt und anteilig einberechnet?

Fall 2
Man möchte Gewinne NICHT anhand eines gEK ermitteln! Man möchte zB 50 Artikel zum EK1 bewerten, man verkauft ja schließlich zuerst diese 50 Stück.
Kauft man mit der nächsten Charge 1.000 Stück zu einem anderen EK2, soll natürlich hier die passende Kalkulation erfolgen.


Wir können z.B. mit Fall1 überhaupt NICHTS anfangen!
Um am Ende auch korrekte Gewinne ermitteln zu können, müssen die zu dem Zeitpunkt gültigen EKs berücksichtigt werden.
Oder sehe ich das falsch?

 

[xiller]

@wawi-dl. Geht uns ebenso, Fall 2 ist auf die schnelle einfach interessanter "für uns". Ich mache gerade folgendes: Ameise -> ArtikelDaten export und Aufträge export und Merge alles später mit der Artikelnummer.
@JTL: Ansich wäre es schön: man klickt auf f6 (verkauf) Rechts unten sieht man ja die Summe, das dort "sowas" wie gewinn nebendran dasteht? Verkauf Minus EK (von dem Produkt). Wäre cool.

 

[wawi-dl]

...
@JTL: Ansich wäre es schön: man klickt auf f6 (verkauf) Rechts unten sieht man ja die Summe, das dort "sowas" wie gewinn nebendran dasteht? Verkauf Minus EK (von dem Produkt). Wäre cool....

Ja aber da fängt es doch schon wieder an, wie soll Gewinn berechnet werden?
gEK-Strategie falsch/unbekannt, tatsächliche Versandkosten kann man garnicht berücksichtigen -> Gewinn wird also nur vom Warenwert - EK gerechnet, somit auch nur eine Annäherung.

Egal was du machst und wie du es machst, jeder will es anders haben ...

 

[xiller]

Klar, daher schrieb ich, wäre schön und nicht, ich verlange es. Nur das wäre halt etwas, was schnell darstellbar ist. Und wie ich schon zu Dir @wawi-dl geschrieben habe "für uns", also ich verlange es nicht, daher bitte nicht noch eine Wiederholung schreiben, was schon gesagt wurde . So wäre es eben toll, auf die schnelle ein paar Basis zahlen zu vergleichen. Grundbasis VK-EK, dann weitere und weitere Variablen. Schön wäre es eben in den Statistiken, das man sich genau Wünschdirwas zusammenklicken könnte, ausgehend vom kleinsten Nenner VK-EK Pro Artikel. Soweit ich gelesen habe, hat Rico eh geschrieben das mit "Auftrag 2.0" sowas geplant ist. *gefällt mir klick*

 

[Manuel Pietzsch]

Hallo zusammen,

ich wollte hier mal eine Aussicht auf kommende JTL-Wawi Versionen geben zum Thema Gewinn, bzw. Deckungsbeitrag.

Der durchschnittliche Einkaufspreis wird aktuell im Artikel immer live berechnet. Dabei wird der aktuelle Lagerbestand mit dem aktuellen GLD und dem zugebuchten Bestand mit EK verrechnet. Dieser GLD wird zum Zeitpunkt der Auftragserstellung zu jeder Position gespeichert.
Nachteil hierbei ist ganz klar: Die Ware wird evtl. erst noch gekauft und die Preise im Auftrag stehen schon fest, der Gewinn ändert sich also nicht mehr.

Mit kommenden Versionen hat jeder Wareneingang einen Einkaufspreis, dieser wird durch die Eingangsrechnung rückwirkend angepasst. Für jeden Wareneingang wissen wir, wie viel von dem Wareneingang noch auf Lager liegt. Somit können wir zu jeder Zeit einen exakten Wert der Ware ausgeben. Damit wird auch der GLD jederzeit neu berechnet werden können.

Erstellen wir jetzt einen Auftrag, so rechnet der Auftrag erstmal mit dem kalkulatorischen Einkaufspreis, welcher dem GLD des Artikels entspricht. Versenden wir die Ware, wissen wir aus welchem Wareneingang der Versand erfolgte und können somit exakt den Einkaufspreis zurückrechnen. Damit wird eine korrekte Ermittlung der Beschaffungspreise für einen Auftrag möglich sein.

Diese Änderung wird mit der neuen Auftragsbearbeitung der JTL-Wawi kommen, an der wir aktuell arbeiten. Weiter wird es hier möglich sein weitere Kosten zum Auftrag hinzuzufügen. Diese können unmittelbar im Artikel hinterlegt, oder per Workflow zum Auftrag hinzugefügt werden.
Kosten die wir aus Marktplätzen ermitteln können ziehen wir automatisiert über die API und ordnen diese direkt den Aufträgen zu.

Auch unsere JTL-Statistik wird für die Gewinn, bzw. Deckungsbeitragsrechnung, auf diese Werte zurückgreifen und somit eine deutlich bessere DB1 Kalkulation ermöglichen.

Geplant sind diese Änderungen nach aktuellem Stand für die JTL-Wawi Version 1.5 und größer.

Gruß

Manuel

 

[wawi-dl]

Danke Manuel!

Angenommen ich habe 5 Artikel zu je 5 EUR auf Lager, Kunde bestellt aber nun 10 Stück.
Es werden nun 5 Stück nachbestellt, aber zu je 7 EUR!
Wird dann auch der effektive Gewinn ermittelt, da im Schnitt ein Artikel je 6 EUR gekostet hat?
Was passiert denn mit Portokosten des Lieferanten, sowie ggfls. Rabatte und Skonto?

Es wäre klasse, wenn man schon je Auftragsposition den EK speichert, dass man diesen notfalls selbst anpassen könnte, vor allem sichtbar ist irgendwo.
Das gleiche gilt für Gebühren etc. für Plattformen, sowie Zahlungsdienste (PayPal & Co.).

 

[Manuel Pietzsch]

Hi,

genau das ist der Plan. Wenn du auslieferst bezieht sich der Auftrag auf einen (oder mehrere) Warenausgänge, diese werden immer gegen einen (oder mehrere) Wareneingänge gebucht. In die Wareneingänge schreiben wir den EK der Lieferantenbestellung und später der Eingangsrechnung.
Gebühren der Plattformen werden ziehen und dem Auftrag zuweisen.
Transportkosten in der Eingangsrechnung müssen wir (genau wie Rabatte) auf die Positionen verteilen, ob wir das im ersten Schritt schon schaffen zeitlich kann ich nicht versprechen.

DB 2 wird aber weiter nicht möglich sein. Unser Ziel ist zunächst die Marge des Auftrags.

Gruß
Manuel


Edit: EK wird eine Spalte in den neuen Auftragsdetails die an einem Benutzrecht hängen wird, natürlich editierbar.

 

[wawi-dl]

WELTKLASSE! ... das würde in Sachen Kalkulation alles abrunden

 

[Pinkman]

Kosten die wir aus Marktplätzen ermitteln können ziehen wir automatisiert über die API und ordnen diese direkt den Aufträgen zu.

Das wäre echt eine tolle Sache.