Lagerverwaltung, in welchem Format Artikel-Preise speichern

[hoika]

Hallo,

dass Preise nicht in Float (Euro), sondern als Integer zu speichern sind
(also mindestens in Cent) ist klar.

Nun habe ich aber das Problem, dass ein Artikel z.B.
eine 100er Packung Schrauben für 1,50 EUR sein kann.
1 Schraube kostet also 0,015 Cent.

Reiße ich jetzt die Verpackung auf (ich brauche z.B. 10 Schrauben),
bleiben 90 übrig.

Was kosten die jetzt ?
Wie speichere ich die 0,015 Cent ?

1. Nicht Cent, sondern 1/100 Cent als Integer speichern
2. die Packungsgrösse in den Preis mit einfließen lassen
also Lagerwert ist 90 * 1,50 / 100 ) 1,35 EUR.


Wie würdet ihr das machen ?

Danke


Heiko

[Union]

Die Lösung mit Zähler / Nenner halte ich schon mal für einen guten Ansatz. Aber mit integer ist das Ganze unflexibel, man denke nur mal an flüssige Stoffe oder Meterware. Und ausserdem könnte es ja theoretisch einzelne Produkte geben, die 1/1 gelagert werden aber einen Preis < 1 ct haben. Des Weiteren würde ich auch die Währung in den Daten speichern.

[mkinzler]

Was ist die kleinste zu lagernde/auslagernde Einheit?

[ChrisE]

Hallo Heiko,

es so speichern wie du es beschreibst:
Preis pro Packung. Dadurch braucht man aber noch die Menge in einer Packung.
Dadurch errechnete sich der Wert immer so genau wie möglich.

So würde ich es machen.

Gruß, Chris

[DeddyH]

Abgesehen davon stimmt die Rechnung nicht: wenn 100 Schrauben 1,50 EUR kosten, liegt der Stückpreis pro Schraube bei 1,5 Cent und nicht bei 0,015 ;)

[HeinzJ]

Haben nicht gewisse DMS auch den Currency Typ zur Auswahl. MSSQL z.B. bietet "money" als typ an.

[angos]

Zitat:

Zitat von ChrisE

Hallo Heiko,

es so speichern wie du es beschreibst:
Preis pro Packung. Dadurch braucht man aber noch die Menge in einer Packung.
Dadurch errechnete sich der Wert immer so genau wie möglich.

So würde ich es machen.

Gruß, Chris

Genau das ist imho die beste Lösung.

[hoika]

Hallo,

OK, dann mache ich es auch so.

Danke


Heiko

[bernau]

Die dazu interessante Frage ist, speichert Ihr euere Preise als Netto-Preis oder Brutto-Preis.

Bei Rechnungsstellung von Firma zu Firma, werden auf der Rechnung alle Netto-Preise aufgelistet und am Ende die MwSt. addiert.

Bei Rechnungsstellung an einen Endverbraucher werden die Einzelbruttopreise aufgelistet und am Ende die "enthaltene" MwSt ausgewiesen.

Was macht Ihr, wenn Ihr Firmenkunden und Endverbraucher in der Software Verwalten müsst? Wie speichert Ihr die Preise?

[hoika]

Hallo,#

zuerst einmal haben wir keine Endverbraucher ;)
2. werden es Netto-Preise sein, weil die MwSt z.B. in Österreich anders ist.


Heiko

[guidok]

Ich würde auch ggf. ein weiteres Feld in der DB einfügen "PreisPer" und das kann dann sein, z.B. Stück, VPE, Meter, Liter, usw.

[hoika]

Hallo,

die Einheit (oder sogar Packung) kommt natürlich rein, klar.


Heiko

[mschaefer]

Irgendwie tauchen solche Sachen immer wieder auf....

1.
Bei Preisen würde ich zum Datentyp-Currency raten oder
im Zweifel Float, wobei die Eingabe auf 2 oder 4 Stellen
nach dem Komma begrenzt werden sollte (4´er bei Liter Öl usw.)

2.
Würde ich den Preis mit der Verpackungseinheit koppeln.
Die Verpackungseinheit ist dabei nicht teilbar.

3.
Eine neue Verpackungseinheit (einzelne Schraube) erhält
einen eigenen Preis. Der muss mit dem der Verpackungseinheit
Schachtel nichts zutun haben (einzeln sind die teuerer).

4.
Auf welcher Basis ist Dein Preis bezüglich MwSt. Oft sind
Bruttopreise eingetragen. Der Vorteil sind gerade Beträge
auf den Rechnungen für Endkunden.
Auf den Rechnungen für Firmenkunden gibt es dann krumme
Beträge, wobei hier meist aufgerundet wird. Das wird
dann auch gerne wieder durch Rabatte Glattgestellt...

usw.

Grüße // Martin

[SubData]

Bruttopreise speichern würde ich nicht empfehlen.
Wenn sich mal wieder zufällig die Mwst. ändert, müsste die ganze Datenbank durchgerechnet werden.
Ausserdem stimmt dann die Berechnung für's Ausland nicht mehr.

[Sir Rufo]

Zitat:

Zitat von SubData

Bruttopreise speichern würde ich nicht empfehlen.
Wenn sich mal wieder zufällig die Mwst. ändert, müsste die ganze Datenbank durchgerechnet werden.
Ausserdem stimmt dann die Berechnung für's Ausland nicht mehr.

Das hat eigentlich nur bedingt etwas damit zu tun:

1. Der Einkaufspreis ist der Preis ohne Vorsteuer, denn der Lieferant bekommt die Vorsteuer gar nicht, denn die muss der abführen und ich bekomme die Vorsteuer von FA wieder. Somit ein rein kalkulatorischer Posten.

2. Des weiteren kann bei unterschiedlichen Stückzahlen ein anderer Vorsteuer-Betrag entstehen.

1 Teil kostet 0,10€ => +19% => 0,119€

Da die Rechnung aber nur in ganzen Cent geschrieben wird:

1 Teil kostet 0,11€ => -19% => 0,092€ ???

Durch das Hin- und Her kommt es zu Rundungsfehlern, darum schon mal

Definitionen Einkaufspreis (IMMER ohne Vorsteuer):
- Brutto-EK => Listen-EK
- Netto-EK => Listen-EK - Konditionen
- Netto-Netto-EK => Listen-EK - Konditionen - Skonto

cu

Oliver

[bernau]

Zitat:

Zitat von SubData

Bruttopreise speichern würde ich nicht empfehlen.
Wenn sich mal wieder zufällig die Mwst. ändert, müsste die ganze Datenbank durchgerechnet werden.
Ausserdem stimmt dann die Berechnung für's Ausland nicht mehr.

Auch hier kommt es wohl drauf an, welche Kunden du hast. Wenn du Einzelhändler bist, dann ist es sehr wahrscheinlich, daß der Bruttopreis gleich bleibt und die Preise so nach und nach angepasst werden (oder vor der MwSt-Erhöhung). Wenn die Preise Brutto gespeichert sind, dann änderst du einfach den MwSt-Satz und alles ist OK.

In meiner eingehenden Frage geht es auch nicht nur um Lagerhaltung sondern auch um Rechnungsstellung. Im B2B-Bereich arbeitet man nur mit Netto-Beträgen. Das man speichert alle Rechnungspositionen als Nettopreis auf der Rechnung ab. Das ist klar.

Was macht ihr, wenn ihr für den Einzelhandel, Rechnungsdaten speichert. Werden die einzelnen Artikel bei euch Netto gespeichert oder Brutto?

[bernau]

Zitat:

Zitat von Sir Rufo

2. Des weiteren kann bei unterschiedlichen Stückzahlen ein anderer Vorsteuer-Betrag entstehen.

1 Teil kostet 0,10€ => +19% => 0,119€

Da die Rechnung aber nur in ganzen Cent geschrieben wird:

1 Teil kostet 0,11€ => -19% => 0,092€ ???

<klugscheiss ein>

0,119 wird aufgerundet und ist somit 0,12€

Der Nettobetrag von 0,12 ist 0,1008 und somit wieder 0,10€

<klugscheiss aus>

0,10€ ist für ein Beispiel ein ganz ungünstiger Betrag.

Nehmen wir den Preis 1,85€ inkl. Mwst. Das macht Netto 1,554621 EUR. Gerundet sind das Netto 1,55€ Wenn wir da aber 19% draufrechnen sind das 1,8445. Gerundet also 1,84€ inkl. Mwst. Wer den Cent findet kann ihn behalten.

[Phoenix]

Zitat:

Zitat von bernau

Wer den Cent findet kann ihn behalten.

Das Finanzamt ;-)

[Hansa]

Das mit dem Brutto/Netto hat er doch schon mal ausgeklammert. Die Problemstellung ist doch ganz klar : berechnet werden können nur mit Bargeld zu bezahlende Rechnungen. 1144,123344 EUR kann man weder korrekt bar bezahlen noch überweisen. Da helfen auch keine Cents. Es muss immer ein pro Rechnungspostionen genau in EURO/Cents zu ermittelnder Betrag erscheinen, der dann aufgeführt wird. Für die genaue Mwst. wird dann eben gerundet.

Um das jetzt einigermaßen im Rahmen zu halten, empfiehlt es sich Untergebinde anzulegen. Ungefähr so : Schiff -> LKW -> Palette -> Umkarton -> Karton -> Schachtel -> Stück. Muss nicht so extrem sein. :mrgreen: Jeder Preis bezieht sich dann auf das entsprechende Gebinde auf Cent genau. Je mehr, umso billiger. Das bedeutet für die Einzelschraube, die einzeln für genau 1,5 c verkauft werden müsste : sie kostet eben lose 2 c. Abrunden geht nicht, sonst würden einige Schlaumeier bei Schachtelgrößen von 30 Stück nicht etwa 45c bezahlen, sondern eine Schraube rausnehmen, um nur 29 c dafür zu bezahlen. 8)

[alzaimar]

Für Rechnungen etc. mag das angehen, aber bei kalkulatorischen Preisen muss man nun mal etwas genauer rechnen bzw. speichern. Ich würde einfach BCD nehmen (da gibt es dann keine Rundungsprobleme wie bei Floating Point) und für den Zahlungsverkehr die einschlägig bekannten Rundungsvorgaben des Finanzamtes nehmen.

In der Finanzwelt wird z.B. auf vier Stellen (100'stel Cent) genau gearbeitet, jedenfalls bei den Aktien- und Währungskursen.