Lagerverwaltung, in welchem Format Artikel-Preise speichern

[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.