Frage zu Preispflege

dreamar

Mitglied
Hallo,

ich stelle mir gerade die Frage wie wir am besten unsere EKs pflegen. Ich hatte erst gedacht das wir über den MEK gehen, jedoch habe ich gerade gelesen das dieser nicht berechnet wird wenn die Artikel nicht lagergeführt sind. Bei uns werden 95% aller Artikel nicht lagergeführt sein. Leider haben wir es bei einigen Artikeln so, dass diese im EK schwanken. Je nach Menge und Projekt können diese auch variieren. Hätte jemand einen Tipp für mich wie man das am besten realisieren kann? Der allerletzte Ausweg wäre manuell pflegen, aber der Aufwand scheint mir doch recht hoch.
 

planB

Neues Mitglied
Teammitglied
Hallo,

werden diese Artikel denn über das Bestellwesen laufen? Also über Bestellungen und Rechnungseingänge abgewickelt? Wenn ja, könnte Ihr sage Partner eine kleine Anpassung auf Seiten des SQL Servers vornehmen, der regelmäßig die EK Preise aus dem Wareneingängen ermittelt - einfach aus Summe aller Rechnungseingangsbeträge geteilt durch Summe aller Rechnungseingangsmengen und den Wert in das MEK Feld zurückschreibt. Das wäre eine einzige Abfrage, die vom SQL Server Agent alle paar Minuten ausgeführt wird. Das geht allerdings nur mit dem SQL Server Standard, der Express Server hat leider keinen Agent, der das ausführen könnte.
 

dreamar

Mitglied
Danke für die gute Anregung. Nur leider haben wir erstmal SQL express und unsere Rechnungen werden noch nicht digital verarbeitet.
Ich hoffe das wir in 5 bis 6 Wochen in betreib gehen können.
 

planB

Neues Mitglied
Teammitglied
Dann stellen sie die Artikellagerführung bei diesen Artikeln trotzdem auf 'Ja' und scheren sich einfach nicht um die negativen Lagerbestände.
Setzen sie das Hauptlager dieser Artikel einfach auf ein Lager das sie zum Beispiel "Virtuell" nennen und die wirklich lagernden Artikel landen dann im Lager "Echt". Für alle Artikel für die sie EK's wollen, müssen sie dann das Bestellwesen samt Rechnungseingängen nutzen. Der einzige Nachteil ist dann, dass sie negative Lagerbestände in den Einstellungen zulassen müssen. Was ich eigentlich aufgrund der unweigerlich daraus resultierenden Probleme nie empfehle.
 

diakh

Aktives Mitglied
Wenn keine Wareneingänge für die Artikel erfasst werden, kann auch der MEK nicht korrekt berechnet werden?!
Die Erfassung der Rechnungseingänge könnte man sich sparen, wenn die Preise bereits bei der Erfassung der Bestellung bzw. des Wareneingangs feststehen und in den Belegen erfasst werden.
 

dreamar

Mitglied
Ok einen Wareneingang machen wir ja. Es ist ja so bei uns. Wir haben nur Projekte. bei jedem Projekt könnten die Preise sich bei einem Artikel unterscheiden. Kleinere Projekte laufen mit hinterlegten EKs durch und große Projekte wird das Material angefragt und in die Angebotsmaske eingegeben. Beim Wareneingang buchen wir ja die Bestellungen des Systems über den Wareneingang. Kann dann hier eine MEK berechnet werden, wenn keine Lagerführung vorhanden ist?
 

fxbe

Mitglied
Das ginge aber auch ohne Sage100 hier zu verbiegen oder programmtechnisch zu vergewaltigen. Ein ähnliche Anforderung habe ich bereits einmal in Sage50 umgesetzt. Artikelstamm und Auftragspositionen sind in beiden Systemen nahezu identisch.
Lesen sie sich doch einmal diesen Beitrag durch.
In diesem Beispiel ist zwar die Lagerführung aktiviert, da man aber die Verarbeitung extern durchführt kann man auch durchaus auf diese verzichten.
 

diakh

Aktives Mitglied
Das ginge aber auch ohne Sage100 hier zu verbiegen oder programmtechnisch zu vergewaltigen. Ein ähnliche Anforderung habe ich bereits einmal in Sage50 umgesetzt. Artikelstamm und Auftragspositionen sind in beiden Systemen nahezu identisch.
Den "Einkaufspreis nach gewichtetem Lagerwert", der in der Sage 100 dem Mittleren EK entspricht, kann man nur mit Lagerführung auf Basis der Lagerbuchungen und Lagerbestände berechnen.
Ansonsten bleibt nur der letzte EK, der mit jedem Wareneingang/Rechnungseingang aktualisiert wird oder der kalkulatorische EK, der manuell gepflegt werden kann oder auf Basis des mittleren oder letzten EKs geführt werden kann.
Generell würde ich empfehlen, immer den kalkulatorischen Einkaufspreis zu nutzen und als Basis für die Roherlösberechnung oder Lagerbewertung zu verwenden, da hier artikelbezogen definiert werden kann, ob der kalkulatorische EK automatisch auf Basis des mittleren oder letzten EKs oder manuell geführt werden soll.
In der Sage 100 kann definiert werden, welcher EK für die Roherlösberechnung herangezogen werden soll. Dazu braucht man die Sage 100 nicht "verbiegen oder programmtechnisch zu vergewaltigen" und man braucht auch keine zeitgesteuerten externen Berechnungen.

Ok einen Wareneingang machen wir ja. Es ist ja so bei uns. Wir haben nur Projekte. bei jedem Projekt könnten die Preise sich bei einem Artikel unterscheiden.
Wenn mit der Projektverwaltung in der Sage 100 gearbeitet wird, gibt es noch die Möglichkeit, die Einkaufspreise für die Roherlösberechnung projektbezogen ermitteln zu lassen. Die Einkaufspositionen müssen dazu den entsprechenden Projekten zugeordnet werden. Benötigt wird dazu das Zusatzpaket "Erweiterte Projektverwaltung".
 

fxbe

Mitglied
Ich geb Dir natürlich recht, setzt aber was in sage100 vorraus ?
Lagergeführte Artikel. Genau das ist es ja, was er nicht hat oder will.

Ich habe hier nur andere Wege aufgezeigt, die auch möglich sind. Denn viele Wege führen nach Rom. Nach 30 Jahren mit ERP Sytemen (davon 15 Jahre direkt bei einem Hersteller 10 Jahre Programmierung / 5 Jahre Einführung ) habe ich gelernt das es das optimale System sowieso nicht gibt. Alle Systeme haben Ihre Stärken und Schwächen.

Du siehst das vielleicht sehr stark geprägt aus der Sicht der Sage100 Consultant Ebene, was durchaus berechtigt ist. Deshalb auch deine Empfehlung zum Zusatzpaket "Erweiterete Projektverwaltung". Die Frage ist nur welchen Zusatzaufwand man benötigt, um das eigentliche Problem zu lösen.

Ich sehe das inzwischen mit einer etwas anderen Sichtweise. Für mich ist das eigentliche ERP-System keine unumstößliche Bibel mehr, und das was nicht möglich ist, wird mit einfachsten Mittel möglich gemacht. Denn wir alle wissen was eigentliche Sache ist. Jeder noch so gut gemeinte Eingriff in die Standardsource einer Software, erzeugt meistens (nicht immer) neue Probleme an ganz anderen Stellen in der Software.

Momentan betreue ich Kunden folgender Systeme ( Sage50 / Sage100 / Dolibarr / MS AX / Infor / Intentia Movex / Lawson M3 ( fett ist zertifiziert ). Und meistens werde ich dann gebucht wenn der Standard mit seinem Latein am Ende ist.

Ob ich nun dabei ein externes Tool wie zum Beispiel Talend ETL oder eine SQL Database stored procedure einsetzte um eine Anforderung umzusetzen ist eigentlich nebensächlich. n den meisten Fällen ist es jedoch effektiver als aufwendig am Standard rumzubasteln.

Grüß Franz
 

KMoeser

Aktives Mitglied
Teammitglied
Ich hätte da mal ne ganz andere Fragestellung an @dreamar:
Warum wird denn eigentlich die Lagerführung so kategorisch abgelehnt?

Wenn ihr sowieso die Teile projektbezogen kauft und (vermutlich) ja auch irgendwas verkauft, dann wäre doch die Lagerführung kein Problem.
...und damit auch die EK-Aktualisierung.
 

diakh

Aktives Mitglied
Ich geb Dir natürlich recht, setzt aber was in sage100 vorraus ?
Lagergeführte Artikel. Genau das ist es ja, was er nicht hat oder will.

Ich habe hier nur andere Wege aufgezeigt, die auch möglich sind. Denn viele Wege führen nach Rom. ...

Lagergeführte Artikel werden aber nur vorausgesetzt, wenn der MEK automatisiert berechnet werden soll.

Wenn der Standard die Anforderungen nicht abdeckt, kann man über externe Lösungen nachdenken, auch wenn ich speziell in der Sage 100 andere programmiertechnische Lösungsansätze vorziehen würde, jedoch sind die genauen Anforderungen und Prozesse ja noch gar nicht geäußert worden?!

Wofür soll der EK verwendet werden (Preiskalkulation, Roherlösberechnung, etc.)?
Macht es Sinn, für die Artikel, die projektbezogen eingekauft und nicht auf Lager geführt werden, einen MEK ( = Einkaufspreis nach gewichtetem Lagerwert) zu berechnen?

Die Einkaufspreise können über den Artikellieferantenstamm gepflegt werden.
Wird das Bestellwesen verwendet, werden die letzten Einkaufspreise im Artikelstamm geführt und über die Artikelkartei kann man den Preisverlauf auswerten.

Die Roherlösberechnung würde ich über den KEK machen.
Bei den Artikeln ohne Lagerführung übernimmt man den LEK als KEK, bei den Artikel mit Lagerführung den MEK.
Bei Artikeln, die nicht eingekauft werden (Fertigungsartikel, Dienstleistungsartikel) kann man den KEK manuell pflegen.
Wenn wirklich projektbezogene Einkaufspreise relevant sind, verwendet man die Funktion aus der Projektverwaltung.

Alles Standard.
 

fxbe

Mitglied
Ich hätte da mal ne ganz andere Fragestellung an @dreamar:
Warum wird denn eigentlich die Lagerführung so kategorisch abgelehnt?

Wenn ihr sowieso die Teile projektbezogen kauft und (vermutlich) ja auch irgendwas verkauft, dann wäre doch die Lagerführung kein Problem.
...und damit auch die EK-Aktualisierung.
Das trifft genau den Kern !

Ich bin eigentlich ein "Verfechter" davon, nicht das ERP aufwendig und kostenintensiv an die Firma anzupassen. Sondern meistens ist es einfach besser, den Fimenprozess an die Software anzupassen.

Ich weis meistens kommt hier das Gegenargument "..das man diese eine Firma nicht mit anderen Firmen vergleichen kann, den sie haben ja ihre spezielle Prozesse". Bricht man diese Prozesse jedoch einmal wirklich auf, dann stellt man meistens fest, das diese aus Zeiten stammen die vor jeder Verwendung einer ERP Software festgelegt wurden. Also aus der Not geboren.

Sehr oft durfte ichmich zum Beisspiel mit Anforderungen herumschlagen, nach dem Motto wir brauchen aber alle Listen im neuen System die wir bisher hatten. Ein Punkt der fast alle Einführungskosten sprengt. Hackt man aber einmal wirklich penetrant nach. Wer welche Liste verwendet und warum, dann stellt man sehr oft fest das 80% der Listen eigentlich für die Tonne sind !

Das klassische GiGo Prinzip also, "Garbige IN - Garbige Out" (wenn man nichts oder nur Müll eingibt, dann bekommt man auch nur Müll aus dem System zurück ! ). Das Problem ist meistens nicht das ERP System, sondern sitzt vor dem Monitor. ;)

Grüße effixx
 
Oben