Erstellt vor 8 Monaten

Geschlossen vor 8 Monaten

#2485 closed Verbesserung/Featurewunsch (fixed)

Einkaufslieferschein -> Einlagern -> ? -> Standardlager ändern -> Erneuern -> fehlerhafte Ansicht, ggf. inkonsistente Lagerbewegungs-DB

Erstellt von: jbueren Verantwortlicher:
Priorität: normal Meilenstein:
Komponente: kivitendo ERP Version: 3.1.0
Schweregrad: normal Stichworte:
Beobachter:

Beschreibung

Reproduzieren:
mind. zwei Lager, je mit mind. Lagerplatz1
(Mein Lager / Anderes Lager)

Dann bei einer Ware Standardlager "Anderes Lager" wählen (nicht das erste, ich glaube, dann verhält sich das Problem anders).

Einkaufs-Lieferschein erstellen, besagte Ware eintragen.
? klicken, Lager vom Standardlager (Anderes Lager) auf "Mein Lager" ändern und weiter (hier zeigen Debug-Statements, dass soweit alles i.O. ist).
? nochmal klicken (z.B. zur Überprüfung) -> Lager steht wieder auf "Anderes Lager" (schon mal blöd).
Ok, jetzt das Lager so lassen und weiter und Einlagern. Dann passt der Lagerplatz nicht zum Lager (Standard-Lager, aber Lagerplatz vom vorher gewählten Lager). Die Datenbank ist dann an dieser Stelle inkonsistent.

Analyse:

Problem ist, dass beim HTML Template zweimal selected ausgewählt werden kann. Einmal wenn warehouse.id == wh.id und zum anderen wenn in Stammdaten ein Standardlager eingetragen ist part_info.warehouse_id == wh.id

Für ein Lager klappt in der Tat alles und auch bei nur einmal anklicken und ändern.
Sobald man ein zweites Lager hat und mehrmals die stock_in form aufruft (durch Erneuern oder durch erneutes Klicken auf das Fragezeichen), wird wieder das Standardlager gesetzt.

Ich hab jetzt erstmal eine "schnelle" Korrektur gemacht, die folgende Bedinungen enthält:

a) Setze Standardlager nur, falls noch keine Menge gesetzt ist (stock_info ist demnach noch nicht gefüllt, sprich wir haben den ersten Aufruf der Maske)
b) Wir befinden uns an der ersten Position und haben noch nicht auf Erneuern geklickt (STOCK_INFO.size == 1)

Das ist erstmal ok, was mich aber prinzipiell stört ist, dass die Steuerung (Standardlager- und Standardlagerplatz vorauswählen) in diesem Fall nicht komplett mit jquery / js funktioniert, bzw. ich damals keine "bessere" Idee hatte.

S

Anhänge (1)

check_bin_belongs_to_wh_trigger.sql (811 Byte) - hinzugefügt von bibi@… vor 8 Monaten.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (6)

Geändert vor 8 Monaten durch bibi@…

comment:1 Geändert vor 8 Monaten durch bibi@…

  • wahrscheinlich betrifft das auch die Verkaufs-Seite
  • evtl. wäre ein DB-Trigger sinnvoll, der prüft, ob der Lagerplatz zum Lager gehört (siehe Anhang)

comment:2 Geändert vor 8 Monaten durch m.bunkus@…

Die Trigger gefallen mir :)

comment:3 Geändert vor 8 Monaten durch bibi@…

Merke gerade, dass der Trigger für parts noch erweitert werden muss, denn hier können warehouse_id und bin_id auch NULL sein - dann geht's schief.

comment:4 Geändert vor 8 Monaten durch bibi@…

In f1faf9a9eca4073119f7c7e0f43e70399e041777/erp:

DB-Trigger, um sicher zu stellen, dass ein Lagerplatz auch zum Lager gehört.

Betrifft #2485.

comment:5 Geändert vor 8 Monaten durch bibi@…

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

Auf der Verkaufsseite trat das Problem bei mir offensichtlich nur auf, weil die Tabelle inventory schon inkonsistent war und dadurch falsche Kombinationen aus Lager und Lagerplatz aufgelistet wurden.

Damit sollte das jetzt klappen und ansonsten sollten die Trigger einen Fehler melden.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.