Neu Verkauf - EK netto der gesamten Bestellung

[WaWi]

Guten Morgen,

für die Nachbearbeitung unserer Verkäufe benötigen wir eine rasche Übersicht des EK netto gesamt in Verknüpfung mit der jeweiligen Bestellung. Leider gibt es in der Listenansicht im Verkauf die Spalte EK nicht, wir hoffen aber, dass jemand eine Idee hat, wie wir diese in einer individuellen Listenansicht einbauen können. Im Prinzip benötigen wir den SQL Code nur für EK netto pro Verkauf, Versandgewicht pro Paket und ab Wawi 1.6. noch zusätzlich die Verpackungskosten/Kartonkosten. Dann wären alle anfallenden Kosten pro Sendung auf einen Blick ersichtlich und mit diesen 3 Zusatzinformationen zum jeweiligen Verkauf wäre uns unheimlich geholfen.

Danke vorab für entsprechende Ideen.

 

[Dreizack Medien]

Mit Listenansichten wird das etwas schwierig werden. Da gibt es 2 Probleme. Zum einen gibt es keine Tabelle, die den Gesamt EK hinterlegt hat, aber gut....könnte man mit etwas Kniffelei berechnen. Problem 2 ist, dass es ja keinen einheitlichen EK geben muss. Ihr könnt ja auch einen Artikel von 2 oder mehr Lieferanten bekommen und diese jeder Lieferant kann euch einen anderen EK geben. Die Wawi kann nicht wissen zu welchem Preis ihr den speziell verkauften Artikel eingekauft habt. Wenn Ihr für jeden Artikel nur einen Lieferanten habt, dann könnte man drüber nachdenken. Das wäre aber definitiv keine allgemein gültige, sondern eher eine im Kern individuelle Lösung für euch.

 

[WaWi]

Den Gesamt EK haben wir bisher nur mit Formel in einer Packliste berechnen können. Ist aber super umständlich, macht viel Papiermüll und Druckkosten.
Der durchschnittliche EK netto der Artikel ist dazu ausreichend, da dieser, wenn ordentlich gepflegt, immer aktuell ist. Wir sehen da auch kein Problem mit mehreren Lieferanten, da die Wareneingänge sofort nach dem Lagereingang von uns in der Wawi verrechnet werden und somit der EK immer aktuell und richtig berechnet ist.

 

[MichaelH]

Du meinst also den dEP - der wird beim WE berechnet und beim Erstellen des Auftrags vom Artikel übernommen und im Auftrag nicht korrigiert, wenn der WE nach Erstellung des Auftrages gemacht wird.

 

[WaWi]

Genau den meine ich.

Eine entsprechende CSV Datei mit der Ameise zu erstellen scheitert auch an der Verknüpfung des durchschnittlichen EK der Bestellung mit ebendieser.

 

[Dreizack Medien]

So oder so ist es schwierig eine korrekte Aussage über denn EK eines Auftrages zu treffen. Wie MichaelH schon angedeutet hat, wird der EK eines Auftrages nirgendwo in der Datenbank hinterlegt. Man könnte eben nur mit aktuellem EK rechnen, was aber das Ergebnis verfälscht sobald sich irgendwo der EK ändert.

 

[WaWi]

Das stimmt, in unserem Fall funktioniert es aber sehr gut, da wir sehr tagesaktuell arbeiten und sehr konstante Preise haben. Aber der Einwand stimmt natürlich und ist uns auch bewusst. Aber es ist derzeit die beste Datenquelle in diese Richtung die wir haben.

 

[Dreizack Medien]

Das stimmt, in unserem Fall funktioniert es aber sehr gut, da wir sehr tagesaktuell arbeiten und sehr konstante Preise haben. Aber der Einwand stimmt natürlich und ist uns auch bewusst. Aber es ist derzeit die beste Datenquelle in diese Richtung die wir haben.

Sooooo....es hat mich nicht in Ruhe gelassen. Bitte mal testen

SELECT
Bestellung.tBestellung_kBestellung,
Sum(Artikel.fEKNetto * Bestellung.nAnzahl) as 'Summe EK'
FROM
tbestellpos as Bestellung
LEFT JOIN tArtikel as Artikel
ON Bestellung.tArtikel_kArtikel = Artikel.kArtikel
WHERE Bestellung.tBestellung_kBestellung = @Key
GROUP BY Bestellung.tBestellung_kBestellung

 

[WaWi]

Hallo,

Wow, danke für die Mühe. Funktioniert soweit prima, nur der EK wird fast immer doppelt gerechnet. Die meisten Bestellungen die ich kontrolliert habe, zeigen genau den doppelten Wert an. Also der Weg stimmt schon mal. Bei einzelnen Rechnungen wurde nur eine Position doppelt gerechnet, die andere korrekt und bei einer Bestellung stimmt der EK haargenau. Muss mal sehen, wo da der Fehler liegt. Offensichtlich rechnet die Formel bei einzelnen Artikeln richtig, auch wenn diese in größerer Menge bestellt werden. Stücklisten werden doppelt gerechnet. (also auch bei 4 Einheiten einer Stückliste wird nur der doppelte Wert berechnet.)

Zudem wird eine zweite Spalte angezeigt (tBestellung_kBestellung) mit einem 5-stelligen Wert. Die konnte ich noch gar nicht zuordnen.

 

[Dreizack Medien]

Hallo,

Wow, danke für die Mühe. Funktioniert soweit prima, nur der EK wird fast immer doppelt gerechnet. Die meisten Bestellungen die ich kontrolliert habe, zeigen genau den doppelten Wert an. Also der Weg stimmt schon mal. Bei einzelnen Rechnungen wurde nur eine Position doppelt gerechnet, die andere korrekt und bei einer Bestellung stimmt der EK haargenau. Muss mal sehen, wo da der Fehler liegt. Offensichtlich rechnet die Formel bei einzelnen Artikeln richtig, auch wenn diese in größerer Menge bestellt werden. Stücklisten werden doppelt gerechnet. (also auch bei 4 Einheiten einer Stückliste wird nur der doppelte Wert berechnet.)

Zudem wird eine zweite Spalte angezeigt (tBestellung_kBestellung) mit einem 5-stelligen Wert. Die konnte ich noch gar nicht zuordnen.

Darf ich mir das mal bei euch per Teamviewer anschauen? Ich würds gerne korrigieren....ich tippe mal auf die Stücklistenpositionen...ich habe das bei mir nur mit Standardartikeln getestet. Wahrscheinlich muss man die nur bei der Berechnung vernachlässigen. Dann können wir hier auch eine Lösung für alle posten, die ein ähnliches Problem haben.

Die Zweite Spalte ist eigentlich nur die interne Bestellnummer.

Schreib mir mal ne Nachricht, dann schau ich da gern mal drüber und dann korrigieren wir das.

 

[Groundhog]

Das wäre auch für uns interessant..... Ich hänge mich da mal dran. Wenns ne Lösung gibt die funktioniert, wäre uns das sehr geholfen.

 

[Dreizack Medien]

Na dann machen wir munteres Lösungen raten

Versucht das hier mal:

SELECT
Bestellung.tBestellung_kBestellung as "Bestell-ID",
CAST(Sum(Artikel.fEKNetto * Bestellung.nAnzahl) as NUMERIC(20,2)) as 'Summe EK'
FROM
tbestellpos as Bestellung
LEFT JOIN tArtikel as Artikel
ON Bestellung.tArtikel_kArtikel = Artikel.kArtikel
WHERE Bestellung.tBestellung_kBestellung = @Key AND Artikel.kStueckliste=0
GROUP BY Bestellung.tBestellung_kBestellung

Das schließt Stücklisten von der Berechnung aus und kürzt die Summe auf 2 Stellen nach dem Komma

 

[Groundhog]

Funktioniert hier gut...ich kann keine Doppelberechnung bei höheren Stückzahlen feststellen....Stücklisten muss ich erst kontrollieren...der Rest läuft aber zumindest super

Kannst du noch ein Feld für den Netto VK hinzufügen und ein Berechnungsfeld mit dem rechnerischen Nettogewinn aus VK-EK?

 

[Dreizack Medien]

@WaWi Frage zu den Stücklisten: Haben eure Stücklisten einen eigenen EK angegeben oder soll sich der EK aus den Komponenten ergeben?

 

[Dreizack Medien]

Das sollte den EK, VK und Gewinn berechnen.

SELECT EK.BestellID, EK.Summe_EK, VK.Summe_VK, VK.Summe_VK-EK.Summe_EK as Gewinn
FROM
(SELECT
Bestellung.tBestellung_kBestellung as BestellID,
CAST(Sum(Artikel.fEKNetto * Bestellung.nAnzahl) as NUMERIC(20,2)) as Summe_EK
FROM tbestellpos as Bestellung
LEFT JOIN tArtikel as Artikel
ON Bestellung.tArtikel_kArtikel = Artikel.kArtikel
WHERE Bestellung.tBestellung_kBestellung = @Key
AND Artikel.kStueckliste=0
GROUP BY Bestellung.tBestellung_kBestellung) as EK,
(SELECT
Bestellung.tBestellung_kBestellung as BestellID,
CAST(Sum(Bestellung.fVKNetto * Bestellung.nAnzahl) as NUMERIC(20,2)) as Summe_VK
FROM tbestellpos as Bestellung
WHERE Bestellung.tBestellung_kBestellung = @Key
GROUP BY Bestellung.tBestellung_kBestellung) as VK
WHERE
EK.BestellID = VK.BestellID

 

[zwitsch]

Durch Verwendung von Artikel.fEKNetto ergibt sich bei EK-Preisänderungen mit dieser Auswertung immer ein anderes Ergebnis.

Mit dem fEKNetto aus der Tabelle BestellPos passiert das nicht.

 

[Dreizack Medien]

@zwitsch ließ dir bitte den Anfang durch, das haben wir schon geklärt. Das Ganze ist dennoch problematisch, auch mit fEKNetto aus der BestellPos, denn wenn du in deinem Stücklistenartikel einen anderen EKNetto hinterlegst, dann wird dieser ganz unabhängig von den EKNettos der Einzelbestandteile ran gezogen.
Wenn du bei der Stückliste keinen Netto EK angibst, dann wird die Spalte fEKNetto bei BestellPos auch leer sein, genau wie die Einzelnen Bestandteile.

 

[WaWi]

Hallo,

Wow, du gibst aber Gas - Kompliment, die ursprüngliche EK Formel funktioniert einwandfrei. Wir berechnen den EK aus den Stücklisten Komponenten und alle Tests haben ergeben, dass der EK immer wie gewünscht ausgegeben wird.

Die EK, VK, Gewinn Formel ist auch fein, natürlich aus betriebswirtschaftlicher Sicht nur bedingt korrekt, da nicht alle fixen und variablen Kosten berücksichtigt werden können und dadurch kein echter Gewinn ausgegeben wird. Aber für die Deckungsbeitragsrechnung durchaus eine interessante Kennzahl.

Danke nochmal.

 

[Dreizack Medien]

Sehr gerne, ich freue mich über ein Like und falls noch was ist oder noch erweitert werden soll...gerne melden