projekt kivitendo

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.

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.

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

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.