Erstellt vor 5 Jahren
Geschlossen vor 3 Jahren
#1426 closed Fehler (fixed)
Artikelpreise in gebuchten Rechnungen falsch
| Erstellt von: | Christian_Winkler@… | Verantwortlicher: | p.reetz@… |
|---|---|---|---|
| Priorität: | normal | Meilenstein: | |
| Komponente: | kivitendo ERP | Version: | 2.6.1 |
| Schweregrad: | schwerwiegend | Stichworte: | Verkauf |
| Beobachter: | s.schoeling@…, wulf@…, grichardson@…, bibi@…, p.seher@…, j.perz@… |
Beschreibung
Wird einem Kunden mit hinterlegter Preisgruppe eine Rechnung geschrieben und ein anderer Preis berechnet als in der Preisgruppe festgelegt, so wird bei Aufruf der gebuchten Rechnung über Berichte-> Rechnungen in der Liste noch der richtige Endbetrag angezeigt. Wird nun diese Rechnung aufgerufen, wird nicht der berechnete Preis angegeben, sondern der im Artikelstamm für die jeweilige Preisgruppe hinterlegte Preis. Dadurch stimmen die ganzen nachfolgenden Summen nicht mehr.
Bei Kunden ohne Preisgruppe tritt dieser Fehler nicht auf.
Änderungshistorie (13)
comment:1 Geändert vor 4 Jahren durch p.seher@…
- Beobachter p.seher@… hinzugefügt
comment:2 Geändert vor 4 Jahren durch p.seher@…
comment:3 Geändert vor 4 Jahren durch j.perz@…
- Lösung auf fixed gesetzt
- Status von new nach closed, j.perz@rechenkraft.at geändert
Grund ist, dass im "Preisgruppe" Select Feld (drop-down) 2 Elemente als "selected" markiert werden. Zunächst einmal der manuell eingegebene Preis (korrekterweise) und weiters außerdem noch der Preis, der zur beim Kunden hinterlegten Preisgruppe gehört (fälschlicherweise, weil ja der manuell eingegebene Preis overrulen sollte).
Das passiert in SL/IS.pm Zeile 2063:
if ($pkr->{pricegroup_id} eq $form->{customer_klass}) {
...
Diese Zeile gehört geändert in:
if ($pkr->{pricegroup_id} eq $form->{customer_klass} && !$form->{"sellprice_$i"}) {
Damit wird die Preisgruppe und der dazugehörige Preis nur gesetzt, wenn noch kein manueller Preis existiert!
Schlagt mich bitte nicht, wenn der Fix an der falschen Stelle ist oder sonst was nicht passt - lx-o ist nicht gerade programmiererfreundlich gestaltet :-)
Habs hier bei uns kurz getestet, da tuts!
lg,
j
comment:4 Geändert vor 4 Jahren durch Christian_Winkler@…
- Lösung von fixed nach invalid geändert
Ich habe den Code wie beschrieben geändert. Die Preise werden jetzt in gebuchten Rechnungen richtig dargestellt, aber beim Erstellen einer neuen Rechnung werden die dem Kunden hinterlegten Preisgruppen nicht mehr standardmäßig zugeordnet. Sie müßen jetzt manuell ausgewählt werden.
Mit freundlichen Grüßen
Christian Winkler
comment:5 Geändert vor 4 Jahren durch Christian_Winkler@…
- Lösung invalid gelöscht
- Status von closed nach reopened geändert
das Problem ist natürlich noch ein Bug. Bin auf einen falschen Auswahlbutton gekommen.
mfg
Christian Winkler
comment:6 Geändert vor 4 Jahren durch j.perz@…
stimmt, is uns dann auch aufgefallen :)
hab das jetzt bei uns lokal gefixt ... trotzdem bleibt der gesamte preisgruppen+rechnungs code so verkackt und kaputt, dass auch meine kleinen änderungen zwangsläufig hässliches flickwerk sein müssen :(
man muss im IS.pm in der preisgruppenauswahl sagen wenn die rechnung noch nicht existiert und der kunde eine preisgruppe hinterlegt hat, dann preisgruppen select machen. wenn die rechnung schon existiert und kein manueller preis eingegeben ist, dann ebenfalls die preisgruppe setzen.
lg
j
(In reply to comment #3)
Ich habe den Code wie beschrieben geändert. Die Preise werden jetzt in
gebuchten Rechnungen richtig dargestellt, aber beim Erstellen einer neuen
Rechnung werden die dem Kunden hinterlegten Preisgruppen nicht mehr
standardmäßig zugeordnet. Sie müßen jetzt manuell ausgewählt werden.
Mit freundlichen Grüßen
Christian Winkler
comment:7 Geändert vor 4 Jahren durch bibi@…
- Beobachter bibi@… hinzugefügt
Durch den Fix an #1185 tritt dieser Fehler meines Erachtens nicht mehr auf. Wichtig ist evtl. anzumerken, dass, wenn man als Preisgruppe "keine" wählt, nach dem Erneuern die Kundenpreisgruppe genommen wird. Wählt man den leeren Eintrag, oder gibt einen neuen Preis ein, dann gilt der manuelle eingegebene Preis.
Evtl. kann jmd., der eine Installation aus den aktuellen git-Quellen hat das bestätigen.
Grüße
Bernd
comment:8 Geändert vor 4 Jahren durch grichardson@…
- Beobachter grichardson@… hinzugefügt
(In reply to comment #6)
Durch den Fix an #1185 tritt dieser Fehler meines Erachtens nicht mehr auf.
Wichtig ist evtl. anzumerken, dass, wenn man als Preisgruppe "keine" wählt,
nach dem Erneuern die Kundenpreisgruppe genommen wird. Wählt man den leeren
Eintrag, oder gibt einen neuen Preis ein, dann gilt der manuelle eingegebene
Preis.
Evtl. kann jmd., der eine Installation aus den aktuellen git-Quellen hat das
bestätigen.
Grüße
Bernd
Hi Bernd,
ich habe die Preisgruppen an mehreren Stellen angepasst, deine Codeänderung habe ich auch überschrieben, im Prinzip zwar mit dem gleichen Code, allerdings war bei meinen Tests das parse_amount nicht nötig.
Der Punkt mit dem "keine" war mir nicht aufgefallen, in der Tat wird dann die Kundenpreisgruppe ausgewählt, allerdings nicht der Preis angepasst, hier ist also noch ein Fehler.
comment:9 Geändert vor 4 Jahren durch bibi@…
(In reply to comment #7)
ich habe die Preisgruppen an mehreren Stellen angepasst, deine Codeänderung
habe ich auch überschrieben, im Prinzip zwar mit dem gleichen Code, allerdings
war bei meinen Tests das parse_amount nicht nötig.
Ich denke doch. Zwei Szenarien:
1) Gibt man einer Ware bei einer Preisgruppe z.B. den Preis 0,20 , so wird das z.B. in einem Angebot offensichtlich als 0 interpretiert und dann wird nicht der Preis der Preisgruppe genommen, sondern der Verkaufspreis (natürlich, wenn der Kunde zu dieser Preisgruppe gehört).
2) Ändert man in z.B. einem Angebot den Preis von dem voreingestellten Preisgruppenpreis, dann ändert sich nach Erneuern richtigerweise der Preis und die Preisgruppe wird leer. Aber nur dann, wenn der Preis sich vor dem Komma ändert. Eine Änderung von z.B. 9,30 auf 9,20 ändert zwar den Preis, aber die Preisgruppe bleibt selektiert.
Viele Grüße
Bernd
comment:10 Geändert vor 4 Jahren durch grichardson@…
(In reply to comment #8)
(In reply to comment #7)
ich habe die Preisgruppen an mehreren Stellen angepasst, deine Codeänderung
habe ich auch überschrieben, im Prinzip zwar mit dem gleichen Code, allerdings
war bei meinen Tests das parse_amount nicht nötig.
Ich denke doch.
Hi Bernd,
hast Recht, hab beim Testen nicht ordentlich mit Nachkommastellen gearbeitet.
Einen Bug habe ich aber noch gefunden: wenn ich bei einem Artikel mit Preisgruppenpreis den Verkaufspreis ändere wird die Preisgruppenauswahlbox auf leer gesetzt, setze ich diese manuell wieder zurück auf die alte Preisgruppe wird der Verkaufspreis nicht anpasst. Das passiert aber nur bei der gleichen Preisgruppe, bei einer anderen Preisgruppe ist das Verhalten wie gewünscht.
comment:11 Geändert vor 4 Jahren durch wulf@…
- Beobachter wulf@… hinzugefügt
FYI
hatte auch folgendes Problem:
Bestehende Rechnung wird in der Uebersicht
Einkauf->Berichte->Rechnungen mit korrekten Summen angezeigt, beim
Aufruf der einzelnen Rechnung enthalten die Postionen den Preis 0.00
Die Summe der Rechnung ist auch 0.00
Mit rev 806a4de799c8b6 Thu Jan 20 11:56:59 2011 +0100
scheint es wieder zu tun in 9ecaae9 Wed Jan 19 14:54:20 2011 +0100
war es noch broken.
comment:12 Geändert vor 3 Jahren durch s.schoeling@…
- Beobachter s.schoeling@… hinzugefügt
Wenn ich mir den Bug hier durchlese sieht es so aus als ob alle Punkte abgearbeitet wurden. Geoffrey? Bernd? Kann der zu?
comment:13 Geändert vor 3 Jahren durch Christian_Winkler@…
- Lösung auf fixed gesetzt
- Status von reopened nach closed geändert

Dramatischer Bug, da selbst beim klicken des Buttons "erneuern" noch immer der manuell eingegebene Preis steht. Auch beim click auf "Drucken und Buchen" wird im PDF der manuell eingegebene Preis ausgegeben. ABER wie schon beschrieben, abgespeichert wird der Preis der in der Preisstaffel angegeben ist.
Resultat:
Kunde bekommt Rechnung mit richtigen Betrag.
Im LXO und damit in der Buchhaltung ist der falsche Betrag hinterlegt.