#2037 closed Fehler (fixed)
Preis in Rechnungen, Angebote, etc wird überschrieben
| Erstellt von: | Ciatronical | Verantwortlicher: | m.bunkus@… |
|---|---|---|---|
| Priorität: | normal | Meilenstein: | 3.0.0 |
| Komponente: | kivitendo ERP | Version: | 2.7.0 |
| Schweregrad: | normal | Stichworte: | Rechnungsmaske Preis |
| Beobachter: |
Beschreibung
Bedingung: Preis für Artikel/Dienstleistung? wurde hinterlegt.
Trage ich für diesen Artikel in der Rechnungsmaske einen neuen Preis ein so wird dieser beim Erneuern durch den für den Artikel gespeicherten Preis ersetzt.
Das ist jedoch nur für den Fall richtig wenn der Preis in der Rechnungsmaske nicht eingetragen wird. (0,00)
Im Demo:
Neue Rechnung::
Artikelnummer->1004 TAB TAB Menge->4 TAB TAB TAB Preis->42 ENTER
Als Preis steht nun 35€ statt 42€ in der Zeile.
Das sollte jedoch nur geschehen wenn kein Preis eingegeben wurde.
Der Preis muss nun mühselig mit der Maus fokussiert und geändert werden.
Anhänge (2)
Änderungshistorie (12)
comment:1 Geändert vor 2 Jahren durch m.bunkus@…
- Meilenstein auf 3.0.0 gesetzt
comment:2 Geändert vor 2 Jahren durch wulf@…
- Status von new nach assigned geändert
- Verantwortlicher von m.bunkus@… nach wulf@… geändert
comment:3 Geändert vor 2 Jahren durch wulf@…
- Status von assigned nach accepted geändert
comment:4 Geändert vor 2 Jahren durch wulf@…
- Lösung auf fixed gesetzt
- Status von accepted nach closed geändert
comment:5 Geändert vor 2 Jahren durch bibi@…
- Lösung fixed gelöscht
- Status von closed nach reopened geändert
@wulf
Ich denke, das funktioniert so nicht:
if ($pkr->{price_unfmt} == $pkr->{default_sellprice} || $form->{'sellprice_'.$i} * 1 > 1) {
- hier ist sellprice_$i formatiert, also kann z.B. "1,34" sein und ist damit keine Zahl.
- wieso wird sellprice_$i auf größer 1 geprüft und nicht auf größer 0?
Es geht nur, wenn man ganzzahlige Preise größer 1 eingibt.
Eine weitere Auswirkung ist z.B., dass es beim Kunden voreingestellte Preisgruppen kaputt macht, wenn der (normale) Verkaufspreis größer 1 ist (siehe Bilder: bei Kunde2 ist die "tolle PG 3" voreingestellt).
Ich mache den Bug mal wieder auf.
Geändert vor 2 Jahren durch bibi@…
Geändert vor 2 Jahren durch bibi@…
comment:6 Geändert vor 2 Jahren durch wulf@…
- Lösung auf fixed gesetzt
- Status von reopened nach closed geändert
comment:7 Geändert vor 2 Jahren durch wulf@…
- Lösung fixed gelöscht
- Status von closed nach reopened geändert
comment:8 Geändert vor 2 Jahren durch wulf@…
- Status von reopened nach assigned geändert
- Verantwortlicher von wulf@… nach m.bunkus@… geändert
wie in Braunschweig besprochen, mit dem ursprungs-Bug kann man zur Not leben. Habe den Milestone aber mal auf 3.0 gelassen.
Ich bin zu doof fuer den Preisgruppenwahnsinn...
comment:9 Geändert vor 2 Jahren durch bibi@…
- Lösung auf fixed gesetzt
- Status von assigned nach closed geändert
comment:10 Geändert vor 2 Jahren durch bibi@…
@wulf: da war ich wohl eher zu doof, damals meine eigenen Variablennamen richtig zu schreiben.
@all: das das jetzt schon länger verkehrt war, wäre es schön, wenn alle mal ein bisschen Preisgruppen testen könnten.
In 2b9d5f3496283b4a0c505a3d116ec279cac13019/erp: