Preiseinheit: je 100 Stück

[Former Member]

Hallo,

gibt es eine Lösung um auch Preiseinheiten je 100/1.000 Stück verwalten zu können, ohne über unzählige Nachkommastellen hantieren zu müssen (nicht gewünscht)?

Am Beispiel Schrauben:

Verkauft/eingekauft werden sollen 10 Schrauben. Diese kosten beispielsweise EUR 52,35 je 100 Stück.

Da SBO nur einzelne Stück im Preis verwalten kann, rundet es auf EUR 0,52 als Stückpreis und auf meinem Beleg landet dann EUR 52,00.

Mit den Faktoren in SBO kann man zwar schön Limo-Kisten und Palleten "basteln", aber nicht das Gegenteil. Es ist zwar möglich mit dem Faktor 0,01 das ganze abzubilden. Allerdings erscheint dann auf den Belegen:

0,1 Schrauben - Stückpreis EUR 52,35 - Gesamtpreis EUR 5,24

Aber haben Sie auf anhieb verstanden, das Sie gerade 10 Schrauben gekauft haben? Das sollte natürlich auch auf dem Beleg dann erscheinen:

10 Schrauben - Stückpreis EUR 52,35 - Gesamtpreis EUR 5,24

Hat jemand soetwas schonmal realisiert?

Grüße

Michael

[Former Member · Accepted solution]

In der Version 2007 wäre dies meines wissens nach nur durch die Definition von Preisangaben mit 4 Dezimalstellen abbildbar.

Dies bedingt dann auch die entsprechende Stückweise Bestandsverwaltung zum Preis von 0,5235 EUR. Eine derartige Umstellung auf Preise mit 4 Dezimalstellen kann jedoch nicht wieder rückgängig gemacht werden (lediglich das Look & Feel des Ausdruckens könnte man weiterhin beinflussen).

Sofern es immer gleiche Abgabemengen gibt, kann man prüfen in wie weit sich ein Verwaltungsaufwand von Verkaufsstücklisten (z.B. 10er Pack) zu festen Preisen rechtfertigen läßt.

In der Version 8.8 gibt es in den Belegen (_nicht_ in den Artikelstammdaten) wiederum freie Verkaufsmengeneinheiten. So kann ich dann beispielsweise eine Einheit (1 Stück) 10er-Pack verkaufen die aus z.B. aus 10 Lagereinheiten besteht (also eine korrekte Lagerbuchung von 10 Stück vornimmt). Beim nächsten mal Verkaufe ich dann 1 Stück 15er-Pack usw.

Der Eintrag der Einheit (10er-Pack, 15er-Pack usw.) und der Anzahl Artikel in dieser Einheit erfolgt dabei manuell nach Bedarf, je Belegzeile; die Berechnung erfolgt aufgrund der Anzahl Artikel (daher gilt auch hier die Notwendigkeit der 4-stelligen Preisangaben wie in der Version 2007 sonst haben wir wieder Rundungsprobleme).

Ich hoffe die Antworten helfen. Vielleicht kennt jedoch jemand einen besseren Weg oder ein entsprechendes Add-On ?!

Mit freundlichen Grüßen

aus dem hohen Norden

Heiko Szendeleit

[Former Member · Accepted solution]

Heiko,

danke für deine schnelle, ausführliche Antwort.

Richtig sinnvoll und vernünftig scheint mir das alles noch nicht zu sein.

Verrückt, wenn man bedenkt, das sowas in den 70igern auf einer Kienzle-Anlage zu den Anfängen der EDV bereits problemlos mit der Angabe "Preismengeneinheit =100" zu bewerkstelligen war. Das waren noch Zeiten, als man das einfach eingeben konnte

Nochmals Danke für deine Bemühungen.

Michael

Edited by: Michael Weil on Dec 15, 2009 3:26 PM

[Former Member]

Hallo,

für die Wahl der Bestandsmengeneinheit bei einem Artikel sollte mit einbezogen werden, wie die Ware gelagert wird. Werden Schrauben 100 Stück Packungen gelagert oder werden alle Schrauben einzeln in einer Kiste gelagert. Entspricht die Bestandsmengeneinheit der Lagerart, haben es die Benutzer leichter.

Wenn es geht, würde ich Preise mit 2 Dezimalstellen führen und dafür Cent Artikel in größeren Bestandsmengeneinheiten führen.

Wird ein mit Bestandsmengeneinheiten 100 St. geführter Artikel als Stück verkauft, so muss die Verkaufsmengeneinheit 'Stück' und Artikel pro Verkaufsmengeneinheit 0,01 sein. Der Bestand wird aber dann mit 2 Dezimalstellen geführt.

Wird 1 Stück verkauft, ändert sich der Bestand von 1 auf 0,99.

Ich hoffe, das ist hilfreich.

Gruß

Thomas

[Former Member]

Hallo,

wir haben das etwas anders gelöst, wobei wir an den 4-Nachkommastellen nicht drumherum gekommen sind.

also alle Preise mit 4 Nachkommastellen

Jeder Preis für unsere Kunden und Lieferanten wir per 1 Stück mit eben 4 Nachkommastellen im System in Preislisten gepflegt.

Beispiel:

Preisliste per 1 = Müller - (Basis: Müller Faktor = 1) (Zur Pflege als PL im GP-Stamm)

Preisliste per 100 = Müller100 (Basis: Müller - Faktor = 100)

Da wir unsere Preise an manche Kunden per 1 oder auch mal per 100 berechnen müssen, haben wir uns dazu entschieden, alle Preise und Preislisten die nach draußen gehen als per 100 zu machen.

Innerhalb von SAP wird mit per 1 gerechnet, jedoch auf den Belegen steht dann als Einzelpreis der Preis aus der FAKTOR-100 Preisliste.

Schraube XYZ Preis per 1 = 0,9456 EUR entspricht 94,56 EUR per 100.

Über eine formatierte Suche wurde in unseren Belegen jeweils der Preis der Basispreisliste gesucht, zurückgegeben wird jedoch der Preis per 100 aus der jeweiligen Faktor-100 Preisliste.

Das Feld (Preis per 100) erscheint dann per Coresuite auf dem Beleg.

Nachteile:

- Jeder GP hat 2 Preislisten (1. per 1 Stück die gepflegt wird ! 2. die per 100, die abhängig von der per 1 ist mit dem Faktor 100)

- alle Belege müssen das neue Feld "Preis per 100" (Formatierte Suche in Belegposi) bekommen.

Ich hoffe, ich konnte Dir wenigstens mitteilen, wie es bei uns läuft... ob es Dir hilft, weiß ich nicht !

Gruß und schönen Tag.

Markus

[Former Member]

Markus,

interessant wie sich jeder hier "Hilfskrücken" bastelt. Sicher auch nicht das gelbe vom Ei, aber ebenfalls ein interessanter Ansatz, den ich sicher auch einmal ausprobieren werde. Vielen Dank dafür.

Muss ich dann sowohl Preise und Beträge auf 4 Nachkommastellen ändern um Probleme zu vermeiden, oder reicht es aus nur bei den Preisen (schlimm genug) mit 4 Stellen zu arbeiten ?

Michael

[Former Member]

Morgen Michael,

wir haben nur die Preise auf 4 Stellen... die Beträge auf 2.

Wir haben lange mit unseren Beratern überlegt, wie wir das Problem am sinnvollsten lösen könnten... 100%ig ist das nicht.

Die Kollegen aus der Verwaltung haben sich aber vorerst damit abgefunden, da für uns die 100er Preise bei einigen Kunden schon immer Pflicht waren.

Ledigleich bei den Ausdrucken (wenn das Teil einen Stückpreis von 1.000 EUR hat) ... da muß man sich dran gewöhnen, da hier auf dem Beleg auch mehr Platz verbraucht wird.

Wäre toll, wenn Du Deine Lösungsansätze bei Verfügbarkeit hier kurz darstellst.

Gruß und schönen Tag

Markus

[Former Member]

Nachtrag...

Beträge: 2

Preise: 4

Kurse:4

Mengen:3

Prozent:4

Einheiten:3

Dezimalstellen:2

Gruß

Markus

[Former Member]

Hallo Markus,

Papier ist geduldig. Wer sagt, das man immer mit den vollen Nachkommastellen drucken muss? Auch wenn ich mich wiederhole: Mit Coresuite ist das kein Problem, und in der von mir beschriebenen Lösung bleiben kaum Wünsche offen. Wir haben das schon des öfteren so umgesetzt, und keine Klagen von unseren Kunden. Das einzige woran man sich gewöhnen muss sind die vielen Nachkommastellen am BILDSCHIRM auf der Maske. Im Druck... siehe meine Lösung oben.

Gruß

[Former Member]

Hallo Michael,

das ist ein leidiges Thema, aber ich denke sooo schlecht ist das mit B1 nicht zu lösen. Am Beispiel der Schrauben mal ein Szenario... Foraussetzung, man möchte tatsächlich die einzelne Schraube bestandsmäßig führen. Wenn das nicht so ist, kann man ja sehr einfach die Bestandsmengeneinheit anders definieren (z.B. Karton Schrauben). Aber mal angenommen man möchte die Schraube als Stück (Bestandsmengeneinheit) führen:

Artikel 4711, Schraube, Bestandsmengeneinheit "Stk.", Verkaufsmengeneinheit Stk., Einkaufseinheit "Karton" zu 1000 Stück. Die Preise in den Preislisten beziehen sich ja immer auf die Bestandsmengeneinheit. Trägt man da also z.B. bei der Einkaufspreisliste 0,0052 ein, wären das im Einkauf 5,20 Euro bei Menge 1 (was ja 1000 Schrauben sind = 1 Karton). Man kommt also nicht um die Erhöhung der Dezimalstellen hin. Allerdings ist Papier ja geduldig, und ich habe in einem vergleichbaren Projekt einmal folgende Lösung implementiert: Benutzerfeld auf Zeilenebene (und auch im Artikelstamm), "Preis pro". Hier trägt man eine Zahl ein, ev. von formatierter Suche vom Artikelstamm in die Belegzeile kopieren. Im Belegdruck (--> Coresuite dann einfach rechnen, und anders darstellen.

So denke ich das dies Thema nicht wirklich ein Problem ist. Meines Wissens verändert (sprich signifikant verbessert) es sich auch nicht mit 8.8.

Gruß + hoffe das hilft

Andreas

[Former Member]

Hallo Andreas,

genau das ist das grundsätzliche Problem, das sich die Preise immer auf die Bestandsmengeneinheit beziehen.

Das bedeutet bei einer laufenden Installation, wenn ein Lieferant auf Preiseinheit 100 Stück umstellt, ich die Dezimalstellen für den gesamten Betrieb erweitern muss.

Mal ganz abgesehen von den unzähligen Beschwerden der Benutzer, was das soll mit 4 Nachkommastellen hantieren zu müssen,warnt SAP selbst in der Hilfe von SBO vor der Verwendung:

<< Hinweis

Die Einstellung der Dezimalstellen beeinflusst die Berechnungen in SAPBusinessOne und die Werte, die in der Datenbank gespeichert werden. Wenn Sie beispielsweise für Beträge zwei Dezimalstellen auswählen und für besonders kleine Preise und Mengen mit sechs Dezimalstellen arbeiten, könnten Summen ungenau sein.

Ende des Hinweises. >>

Oder erwartet SAP dann auch, dass ich auf den Belegen die Stückpreise und Gesamtpreise mit 4 Dezimalstellen hantiere?

Wenn bei dem selben Mandanten größere Anlagen im 7-stelligen Bereich verkauft werden und dazu Schrauben eingekauft werden, bedeutet das 11-stellige Ausdrucke (plus Punkte und Komma = 14!!!). Schriftgrad 4 damit es keinen Zeilenumbruch gibt?

Also die Kunden zur Verwendung der Dezimalstellen zwingen weil Programmtechnisch nicht darstellbar und gleichzeitig darvor warnen ... erschließt sich mir jetzt noch nicht ganz was SAP da macht.

Da ich aber wohl der einzige bin, der damit ein Problem hat - meine Recherchen bezüglich "Preiseinheiten" waren bis auf Zustimmung, dass dies bedauerlicherweise fehlt, ergebnislos - wird sich an der Programmgestaltung wohl auch nichts ändern.

Ich werde diesen Beitrag als beantwortet markieren, eine "echte" Lösung scheint mir zur Zeit und auch zukünftig nicht in Sicht.

Grüße

Michael