Kalkulatorischer EK

D

dreamar

Mitglied
Hallo,

ich tue mich noch ein wenig schwer mit dem kalkulatorischen EK. Wieso kann ich nicht einfach im Artikel unter Lieferanten, den Lieferanten und den dazugehörigen Preis mit Rabatt eingeben, den Hauptlieferanten bestimmen und das ist mein kalkulatorischer EK? Wieso muss der kalk. EK noch manuell eingegeben werden?
Ist der eingetragene Listenpreis minus Rabatt (Einkaufspreis) echt losgelöst vom kalkulatorischen EK?
 
Zuletzt bearbeitet:
Hi,

wenn es bei euch so ist, könnte man das doch einfach mit einem Trigger machen. Wenn es allerdings Staffelpreise oder -Rabatte gibt wären die ebenso wenig drin wie Beschaffungsnebenkosten.

Viele Grüße

Sascha
 
dreamar schrieb:
Wieso kann ich nicht einfach im Artikel unter Lieferanten, den Lieferanten und den dazugehörigen Preis mit Rabatt eingeben, den Hauptlieferanten bestimmen und das ist mein kalkulatorischer EK? Wieso muss der kalk. EK noch manuell eingegeben werden?
Ist der eingetragene Listenpreis minus Rabatt (Einkaufspreis) echt losgelöst vom kalkulatorischen EK?
Zum Vergrößern anklicken....

Sie können den kalkulatorischen EK automatisch auf Basis des letzten Einkaufspreises führen lassen. Dann wird der kalkulatorische EK automatisch bei jedem Wareneingang / Rechnungseingang aktualisiert.

Mit Trigger ist eine Programmierung auf Datenbankebene gemeint, die nach dem Update der entsprechenden Datensätze den Wert berechnet und in das Feld übernimmt (ich würde von sowas abraten).
 
Auch wichtig zu wissen:

Der kalkEK basiert auf der Basismengeneinheit
und nicht etwa auf der Einkaufsmengeneinheit / Preiseinheit oder Verkaufsmengeneinheit / Preiseinheit.
Unterschiedliche Lieferanten können unterschiedliche Einkaufsmengeneinheiten / Preiseinheiten haben.

Daher kann der kalkEK gar nicht das Ergebnis von einem Lieferanten- Einzelpreis abzüglich Rabatt sein sondern muss mindestens auf die Basismengeneinheit umgerechnet werden.

Daher ist der Vorschlag von diakh die Preispflege EK auf „letzten EK verwenden“ vermutlich der sauberste Weg.
 
cmayer schrieb:
Auch wichtig zu wissen:

Der kalkEK basiert auf der Basismengeneinheit
und nicht etwa auf der Einkaufsmengeneinheit / Preiseinheit oder Verkaufsmengeneinheit / Preiseinheit.
Unterschiedliche Lieferanten können unterschiedliche Einkaufsmengeneinheiten / Preiseinheiten haben.

Daher kann der kalkEK gar nicht das Ergebnis von einem Lieferanten- Einzelpreis abzüglich Rabatt sein sondern muss mindestens auf die Basismengeneinheit umgerechnet werden.
Zum Vergrößern anklicken....

Korrekt - daher habe ich auch bewusst "den Wert berechnet" und nicht "den Wert übernimmt" geschrieben.

Die Frage ist ja auch, wozu der kalkulatorische EK verwendet werden soll (Roherlösberechnung, Lagerbewertung).
Wenn ich die aktuellen Einkaufspreise vom Hauptlieferanten auswerten möchte, würde ich die aktuellen Einkaufspreise vom Hauptlieferanten auswerten und nicht den kalkulatorischen EK abfragen.
 
Trigger ist eine Sage Funktion die auf dem SQL Server läuft. Man kann eigene Trigger einführen, die eben eine bestimmte Funktion ändert. Das haben wir in der Vergangenheit auch schon öfters vorgenommen. Die Trigger können mittels SQL auch deaktiviert werden (z.B. um kurzfristig eine Funktion auszuheben, um die Änderung machen zu können); aber die Trigger haben ihre volle Funktion nur dann, wenn die halt laufen. Abstellen von Triggern ist immer sehr kritisch zu sehen. Eigene Trigger aber einzubauen ist erlaubt. Die System Fachhändler können dort jeweils unterstützen. Wir selber haben uns aber von den Triggern abgelöst (benötigt man doch recht spezielles Wissen und die Manpower halt).
 
Bei uns ist es so, das wir auf Einkaufspreisebene kalkulieren. Das heißt alle Preise in der Preisliste werden über den kalkulatorischen EK als Startpunkt berechnet. Also kalk. EK + Bezugskostenzuschlag + Gemeinkostenzuschlag + Gewinnzuschlag = Einzelpreis. Hinter vielen Artikeln kann ich aber unter Lieferanten einen Listenpreis abzgl. Rabatt pflegen. Diese Preise kommen aber nicht der Angebotskalkulation zu gute, sondern nur wen ich einen Einkaufsbeleg generiere. Leider ist so der Pflegeaufwand für die Preise doppelt, da ich unter Lieferanten die EKs pflege und dann müssen sie noch für die Angebotserstellung manuell unter kalk. EK gepflegt werden. Und den MEK nutzen ist auch schwierig, da wir noch keine Rechnungseingangsverarbeitung haben und die Preise auch projektbezogen schwanken können. Daher wäre die beste Möglichkeit man pflegt die Lieferanten und wählt einen Hauptlieferanten aus. Die EKs des Hauptlieferanten werden unter Liefernaten gepflegt und als kalk. EK übernommen. Wenn das ginge Daumen hoch.
 
Dann wäre das tatsächlich ein Thema für einen Update-Trigger auf Datenbank-Ebene (KHKArtikelLieferant)
Staffelpreise bzw. Staffelrabatte wären dann halt außen vor.

Den Automatismus könntest du dann aber aus der Sage- Oberfläche heraus nicht „abschalten“ - und würde auch für alle Artikel gelten, sofern du dir nicht noch ein Kriterium wie ein USER-Feld etc. anlegen lässt.
Ein USER-Feld bei KHKArtikelVarianten „EK des Hauptlieferanten in kalkEK übernehmen“ ja/nein

Man müsste die Umrechnung auf die Basismengeneinheit im Trigger vornehmen - und eventuelle Preiseinheiten im EK berücksichtigen. Kriterium wäre zudem, dass der Lieferant des aktualisierten Datensatzes (Update) auch Hauptlieferant sein muss - und ein zu definierendes „Kriterium“ (USER-Feld an der Oberfläche) erfüllt sein musss, damit die Aktion durchgeführt wird.

Die Idee ist gar nicht so abwegig wie man zunächst meinen könnte.

So ein Trigger wird auf Datenbankebene in T-SQL erstellt - das sollte für den betreuenden Fachhändler kein großes Problem und auch ein überschaubarer Kostenpunkt sein.
 
breithecker schrieb:
Hi,

wenn es bei euch so ist, könnte man das doch einfach mit einem Trigger machen. Wenn es allerdings Staffelpreise oder -Rabatte gibt wären die ebenso wenig drin wie Beschaffungsnebenkosten.

Viele Grüße

Sascha
Zum Vergrößern anklicken....
Gibt es eine Möglichkeit bei manueller Pflege des Kalk EK die Werte per Assistent zu importieren im Standard - oder benötigt man hier eine Sonderlösung ggf. auf Datenbankebene einmalig einspielen via Support?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben