Fehler #254
Artikeldetailansicht: Historie unvollständig und "Erneuert am" kaputt
40%
Description
kivitendo 3.5.0-beta (verifiziert mit Online-Demo auf kvitendo.de)
In der Artikeldetailansicht (über Stammdaten → Berichte → Artikel → Suchen → einen aufgelisteten Artikel anklicken bzw. über die Artikelschnellsuche):
1) Klick auf 'Historie' zeigt höchstens einen Teil der in der Datenbanktabelle history_erp gespeicherten Einträge zu diesem Artikel, manchmal auch gar nichts
2) In der Historie fehlen die bisher angezeigten Spalten mit der Artikelnummer und der Buchungsnummer: wurden diese absichtlich weggelassen oder nicht?
3) Das Feld 'Erneuert am' ganz oben rechts in der Detailansicht (über Listenpreis, Verkaufspreis etc.) zeigt nach dem Anpassen eines Preises weiterhin das vorher bereits angezeigte Datum. Das Aktualisieren des Datums klappt nicht mehr.
Files
Associated revisions
Preis-Update-Trigger für parts für letzte Preis-Update-Datum entfernt.
Der Trigger funktioniert so ohnehin nicht, da die Spalte bei einem
"AFTER UPDATE" neu gesetzt wird, aber dann damit nichts mehr passiert.
Das Datum würde auch per jeder Änderung gestezt, nicht nur bei Preisänderungen.
Zudem gibt es nun die part_price_history.
Refs #254 (redmine)
Preis-Update-Trigger für parts für letzte Preis-Update-Datum entfernt.
Der Trigger funktioniert so ohnehin nicht, da die Spalte bei einem
"AFTER UPDATE" neu gesetzt wird, aber dann damit nichts mehr passiert.
Das Datum würde auch per jeder Änderung gestezt, nicht nur bei Preisänderungen.
Zudem gibt es nun die part_price_history.
Refs #254 (redmine)
History
Updated by G. Richardson over 7 years ago
Andreas Rudin schrieb:
3) Das Feld 'Erneuert am' ganz oben rechts in der Detailansicht (über Listenpreis, Verkaufspreis etc.) zeigt nach dem Anpassen eines Preises weiterhin das vorher bereits angezeigte Datum. Das Aktualisieren des Datums klappt nicht mehr.
Das wurde in der Tat vergessen. Das ist jetzt aber auch so halb überflüssig geworden, seit in der Preisinformation die Preisentwicklung mitprotokolliert wird, man könnte auch einfach von dort das letzte Datum anzeigen. Allerdings gibt es im Artikelbericht die Möglichkeit nach dem "Erneuert am" Datum zu sortieren, was natürlich schön einfach ist, wenn es als eigene Spalte in parts.partupdate existiert.
Was könnte man machen:
- da die Preishistorie schon per Trigger nach dem Update auf parts aktualisiert wird könnte man in add_parts_price_history_entry dort zusätzlich ein
UPDATE parts SET priceupdate = now() where id = NEW.id;
einbauen, finde ich aber etwas unschön, da der Trigger nach dem UPDATE auf parts läuft und dann wiederum parts aktualisiert. Zudem müßte man den Code, der OLD.lastcost und NEW.lastcost vergleicht, duplizieren.
- man könnte einen "BEFORE UPDATE" Trigger auf parts setzen, der den OLD.lastcost/NEW.lastcost Vergleich macht und NEW.priceupdate = now(); direkt beim Speichern setzt. Und dann könnte der Trigger in add_parts_price_history_entry nur noch auf eine Veränderung von parts.priceupdate reagieren.
- parts.priceupdate komplett rausschmeißen und in den Berichten und der Artikelseite immer das Datum des letzten Eintrags aus parts_price_history anzeigen. Der Bericht muß dann allerdings etwas mehr arbeiten und alle Artikel danach zu sortieren ist etwas komplizierter.
Updated by G. Richardson over 7 years ago
1) Klick auf 'Historie' zeigt höchstens einen Teil der in der Datenbanktabelle history_erp gespeicherten Einträge zu diesem Artikel, manchmal auch gar nichts
D.h. es fehlen ganze Zeilen aus der history_erp zu dem Artikel? Das bräuchte ich ein konkretes Beispiel, wie das nachzustellen ist.
2) In der Historie fehlen die bisher angezeigten Spalten mit der Artikelnummer und der Buchungsnummer: wurden diese absichtlich weggelassen oder nicht?
Artikelnummer habe ich eben hinzugefügt, das ist ja noch sinnvoll, wenn die sich ändert. "Buchungsnummer" ist nicht wirklich interessant, oder?
Die alte Historienmaske ist ganz furchtbar, deshalb wurde das nur für Artikel einmal neu gestrickt. Eigentlich müße man die Historie komplett überarbeiten, aber bevor da gar nichts steht... Was derzeit fehlt ist eine Sortierung der Spalten.
3) Das Feld 'Erneuert am' ganz oben rechts in der Detailansicht (über Listenpreis, Verkaufspreis etc.) zeigt nach dem Anpassen eines Preises weiterhin das vorher bereits angezeigte Datum. Das Aktualisieren des Datums klappt nicht mehr.
Im Chat gab es eine Diskussion, ob das Feld in der Form so überhaupt sinnvoll ist, da es nur sellprice/listprice/lastcost betrifft und die Preise immer häufiger aus anderen Quellen stammen. Außerdem gibt es jetzt den Reiter Preisinformation, wo man die gleiche Information bekommt.
Updated by Jan Büren over 7 years ago
- Priority changed from Hoch to Normal
- % Done changed from 0 to 40
Andreas, kannst hier die Fragen von Geoff noch aufgreifen?
Ansonsten sehe ich das nicht als 3.5 kritisch an und priorisiere das entsprechend.
Updated by Andreas Rudin about 7 years ago
- File Artikel_Historie.png Artikel_Historie.png added
- File Datenbanktabelle_history_erp.png Datenbanktabelle_history_erp.png added
- File Tabelle_parts_price_history.png Tabelle_parts_price_history.png added
| | 1) Klick auf 'Historie' zeigt höchstens einen Teil der in der Datenbanktabelle history_erp gespeicherten Einträge zu diesem Artikel, manchmal auch gar nichts
| D.h. es fehlen ganze Zeilen aus der history_erp zu dem Artikel? Das bräuchte ich ein konkretes Beispiel, wie das nachzustellen ist.
Ja, anbei ein Beispiel:
Beim Artikel mit der id 29997 (Artikelnummer K20179809) sind in der Tabelle history_erp 10 Einträge vorhanden. Davon werden aber nur 5 Stück in der Artikeldatailmaske beim Klick auf "Historie" angezeigt (es fehlen zum Beispiel die Einträge vom 2.4.2017). Es sieht so aus, dass nur die Einträge aufgeführt werden, bei denen in der Spalte "what_done" 'part' steht.
Updated by Andreas Rudin about 7 years ago
G. Richardson schrieb:
Andreas Rudin schrieb:
3) Das Feld 'Erneuert am' ganz oben rechts in der Detailansicht (über Listenpreis, Verkaufspreis etc.) zeigt nach dem Anpassen eines Preises weiterhin das vorher bereits angezeigte Datum. Das Aktualisieren des Datums klappt nicht mehr.
Das wurde in der Tat vergessen. Das ist jetzt aber auch so halb überflüssig geworden, seit in der Preisinformation die Preisentwicklung mitprotokolliert wird, man könnte auch einfach von dort das letzte Datum anzeigen. Allerdings gibt es im Artikelbericht die Möglichkeit nach dem "Erneuert am" Datum zu sortieren, was natürlich schön einfach ist, wenn es als eigene Spalte in parts.partupdate existiert.
Was könnte man machen:
- da die Preishistorie schon per Trigger nach dem Update auf parts aktualisiert wird könnte man in add_parts_price_history_entry dort zusätzlich ein
UPDATE parts SET priceupdate = now() where id = NEW.id;
einbauen, finde ich aber etwas unschön, da der Trigger nach dem UPDATE auf parts läuft und dann wiederum parts aktualisiert. Zudem müßte man den Code, der OLD.lastcost und NEW.lastcost vergleicht, duplizieren.
- man könnte einen "BEFORE UPDATE" Trigger auf parts setzen, der den OLD.lastcost/NEW.lastcost Vergleich macht und NEW.priceupdate = now(); direkt beim Speichern setzt. Und dann könnte der Trigger in add_parts_price_history_entry nur noch auf eine Veränderung von parts.priceupdate reagieren.
- parts.priceupdate komplett rausschmeißen und in den Berichten und der Artikelseite immer das Datum des letzten Eintrags aus parts_price_history anzeigen. Der Bericht muß dann allerdings etwas mehr arbeiten und alle Artikel danach zu sortieren ist etwas komplizierter.
Im Chat gab es eine Diskussion, ob das Feld in der Form so überhaupt sinnvoll ist, da es nur sellprice/listprice/lastcost betrifft und die Preise immer häufiger aus anderen Quellen stammen. Außerdem gibt es jetzt den Reiter Preisinformation, wo man die gleiche Information bekommt.
Wenn da in Zukunft irgendein Datum stehen soll, so müsste klarer gekennzeichnet sein, was damit gemeint ist:
Letztes Update des Artikels an sich (Datum aus history_erp), letzte Preisänderung (irgendeines Preises), letzte Änderung der Verkaufspreises, letzte Änderung des Einkaufspreises? etc.
Da effektiv alle diese Informationen schnell via Klick auf "Historie" oder "Preisinformationen" verfügbar sind, würde ich vorschlagen, das Feld hier ganz wegzulassen.
So wie es jetzt ist, stiftet es nur Verwirrung und liefert schlichtweg falsche Informationen.
Also zunächst mal löschen und dann allenfalls in Ruhe überlegen, ob und was wirklich sinnvoll ist.
Gruss
Andreas
Updated by G. Richardson about 7 years ago
Andreas Rudin schrieb:
Beim Artikel mit der id 29997 (Artikelnummer K20179809) sind in der Tabelle history_erp 10 Einträge vorhanden. Davon werden aber nur 5 Stück in der Artikeldatailmaske beim Klick auf "Historie" angezeigt (es fehlen zum Beispiel die Einträge vom 2.4.2017). Es sieht so aus, dass nur die Einträge aufgeführt werden, bei denen in der Spalte "what_done" 'part' steht.
Kannst du feststellen, bei welchen Aktionen what_done gefüllt wird und bei welchen es leer bleibt? Ich denke what_done sollte immer geschrieben werden.
Artikelstamm: "Erneuert am" aus parts_price_history holen …
… und in "Preisänderung am" umbenennen.
Das ganze ist mit Rose gelöst und holt die Preise aus parts_price_history.
Das hat den Nachteil, dass im Artikelbericht nicht nach der Preisanpassung
sortiert werden kann und es wahrscheinlich nicht performant ist.
Der aktuelle Trigger für parts.priceupdate funktionierte nicht, und hätte
auch bei jeder Änderung eines Artikels das Datum angepasst. Dafür kann man auch
mtime nehmen.
Todo 1: Spalte priceupdate (und den Trigger) aus parts löschen (und alle
Vorkommen finden).
Todo 2: Query auf SQL umschreiben und soriteren wieder ermöglichen.
Refs #254 (redmine)