✔ Rechnen mit Dezimalstellen

Habe eine Datenbank mit Artikeln drin. Die Preise sind in einem Varchar feld mit 2 Stellen hinter dem Komma Wenn ich jetzt in der Datenbank die Preise mit Punkt habe dann habe ich folgenendes Rechenergebniss :

2 Stck mal epreis 69.90 = 139.8
235 Stck mal epreis 69.90 = 16426.5
davon ist der Anteil Mwst = 2650.608

macht zusammen 16566.3

soweit so gut

nun hab ich aber einmal nur eine Stelle hinter dem Komma, und einmal 3 Stellen. Sieht ja nix aus .. oder ? Also hab ich mir gedacht, setze ich number_format ein dann habe ich folgendes ergebniss :

2 Stck mal epreis 69.90 = 139.80
235 Stck mal epreis 69.90 = 16,426.50
davon ist der Anteil Mwst = 24.93

macht zusammen 159.8

Da sagt mein Kunde jetzt, die Differenz soll ich aus eigener Tasche bezahlen, was ja nicht der Sinn meiner Programmiererei sein sollte .-))

Der relevante Code dazu sieht so aus :In einer while Schleife wird der Warenkorb ausgelesen, die lass ich jetzt mal weg, und dort ist dann die Rechnung drin:

$gpreis = $stck * $epreis;
$zusammen .=$gpreis;
$mwst = ($zusammen/100)*16;

oder aber dann mit number_format :

$gpreis =number_format(($stck * $epreis),2);
$zusammen .=$gpreis;
$zusammen1=number_format($zusammen,2);
$mwst = number_format(($zusammen/100)*16,2);


Änder ich jetzt in der Datenbank im Preisfeld den Punkt in ein Komma, dann rechnet er nicht mit den Stellen hinter dem Komma, egal, ob ich mit number_format arbeite oder ohne.

Das Problem ist also wohl das Komma im Tausender Bereich, aber ich hab keine Idee, wie ich das wegbekomme
Bin für jede Hilfe dankbar.

Gruß
Robert .-)

Nimm mal einen numerischen MySQL-Spaltentypen und lass MySQL die Berechnungen machen.

Dank dir Gumbo, für den Tip
mit decimal(6,2) hab ich es schon probiert, hat aber keinen Erfolg gebracht.
Und wie ich mit mysql Rechnen soll, hab ich keine Ahnung.
Aber ich glaube, es funktioniert wenn ich number_format nicht zum rechnen benutze
sondern nur für die Anzeige. Muß das jetzt erstmal ordentlich testen.
Bei meiner Beispielrechnung jedenfalls hat es schon mal geklappt.
Jedenfalls hab ich jetzt ein korrektes Ergebnis. Stören tut mich jetzt noch, dass das Komma und der Punkt immer noch vertauscht sind .-((

Aber ok .. vielleicht finde ich da ja auch noch was

Mit MySQL zu rechnen, ist nicht schwer, beispielsweise:

He, sieht wirklich einfach aus, das probier ich mal ..

Danke auch .-)

Hallo!

Das Problem ist halt dass PHP die englische Schreibweise zum rechnen braucht.
Also ein Komma als Tausendertrennzeichen und ein Punkt als Dezimaltrennzeichen.
Ich meine mich auch ganz dunkel daran zu erinnern, dass es auf php.net irgendwo steht.

Ob Du nun mit nummer_format() für die Ausgabe arbeitest, solltest Du eher von Fall zu Fall entscheiden.
Ein Beispiel wo dieses zur Verwirrung führen könnte, währe z.b. osCommerce (ein Online Shopsystem).
Dort kannst Du einstellen dass der Punkt als Tausendertrennzeichen und das Komma als Dezimaltrennzeichen genutzt werden soll.
Wenn Du allerdings neue Artikel einstellen oder die Preise für bereits bestehende Artikel ändern willst, musst Du trotzdem die englische Schreibweise anwenden.

Gruss Dr Dau

Das Problem ist halt dass PHP die englische Schreibweise zum rechnen braucht. Also ein Komma als Tausendertrennzeichen und ein Punkt als Dezimaltrennzeichen.

Zum Vergrößern anklicken....

Zahlen werden ohne Tausendertrennzeichen notiert.

Mit der setlocale()-Funktion kann PHP übrigens lokalisiert werden, sodass auch dezimale Integerwerte korrektformatiert ausgegeben werden: Fragt mich aber nicht, was die einzelnen Parameter bedeuten – keine Ahnung!

Also ob Tausendertrennzeichen wirklich gebraucht werden, bin ich mir nun nicht ganz sicher.
Aber bei setlocale() müsste man bei einer mehrsprachigen Seite darauf achten, dass die Parameter je nach ausgewählter Sprache gesetzt werden.

setlocale() hat gegenüber nummer_format() aber auch ein wesentlichen Vorteil, es braucht nur einmal am Anfang des Scripts angegeben werden.

Der 2. Parameter (also de_DE usw.) sind abhängig davon was im System eingestellt ist.
Es würde also auch ein Parameter ausreichend sein..... nämlich den, den der Hoster bei sich eingestellt hat.
Dann währe das Script aber möglicherweise nicht portabel zu anderen Systemen..... darum gibt man möglichst viele Parameter an.
Ich würde noch um de_DE@euro erweitern, dann sollte man eigentlich schon auf der recht sicheren Seite sein.

Beim 1. Parameter (also E_*) könnte in seinem Fall evtl. auch E_NUMERIC ausreichend sein.
E_ALL könnte ggf. an anderer Stelle zu unerwünschten Umwandlungen führen (z.b. deutsches Datumsformat obwohl ein englisches gewünscht ist).

Oki Leute . .dankt Euch für die reichliche Info.
Nun hab ich jedenfalls wieder was zu tun in der kalten Zeit um das mal auszutesten .-))
Obwohl ich mich schon fast daran gewöhnt habe mit dem Komma als Tausender Trennzeichen zu leben. Mein Kunde hat übrigends gemeint , er verkauft sowieso nix über 1000 euronen .. lach
Gruß
Smeagel .-))