Lagerplatz ist nur ein Textfeld in parts und hat keinen Bezug zu Lager

[jbueren]

Sinnvoll wäre eine Verknüpfung zu Lager / Lagerplatz insofern es ein Lager gibt.

Irgendwann war das auch mal beim Bugsprint vorbesprochen.

Ich hab jetzt bei der Migration eigentlich alle Fälle soweit vorbedacht, insofern parts.bin irgendwo einen Eintrag hat, migrier ich wie folgt:

1) Kein Lager vorhanden

Lager kann als Textfeld angelegt werden und Lagerplätze werden automatisch zugewiesen

2) Lager vorhanden

Falls ein Freitext-Lagerplatz genau wie ein vorhandener Lagerplatz lautet, kann dieser per Knopf zugewiesen werden. Ferner können die Freitext-Lagerplätze als neue Lagerplätze zusätzlich erstellt werden.

Damit sollte sich dann bei der Migration keiner beschweren.

Ich mach den trac hier auch deswegen auf, um dann eher eine "Entwickler-Doku" als Referenz zum Commit zu haben

Migration mit Übernahme Freitextfeld

neues lager automatisch erstellen

Was ist mit Lagerplätzen, die mit demselben Namen in verschiedenen Lagern vorkommen?

Was ist dann nach der Migration mit Artikeln, für die es in mehreren Lagern Standardlagerplätze gibt?

Sind schon weitere Integrationsfunktionen hierfür von dir vorgesehen (z.B. Vorbelegung im Eingangslieferschein oder im Lager-Menü)?

Hast du getestet, was passiert, wenn man einen Artikel einem Lagerplatz zuordnet und den Lagerplatz dann über die Systemsteuerung zu löschen versucht? Hier sollte eine aussagekräftige Fehlermeldung kommen und nicht nur die Fehlermeldung der Datenbank durchgereicht werden. Genauer: die Checkbox zum Löschen sollte nicht einmal auftauchen.

Auslagern über Standardlagerplatz

Nerv. Jetzt hab ich viel geschrieben und dann mit dem Anhang hochladen das Textfeld zerschossen.
Hier nur kurz:

Was ist mit Lagerplätzen, die mit demselben Namen in verschiedenen Lagern vorkommen?

Kann manuell bei der Migration überlagert werden, bzw. alles kann auch manuell überlagert werden (automatische Zuordnung ist nur eine Vorschlagsliste).

Was ist dann nach der Migration mit Artikeln, für die es in mehreren Lagern Standardlagerplätze gibt?

Nicht vorgesehen. Ein Standardlagerplatz in einem Lager. Das alte Feld hatte ja diesselbe Bedeutung.

Hast du getestet, was passiert, wenn man einen Artikel einem Lagerplatz zuordnet und den Lagerplatz dann über die Systemsteuerung zu löschen versucht?

Super Punkt. DB-Fehler kommt. Haken wird jetzt aber auch entfernt.

Im Lager-Menü wird entsprechend beim Einlagern vorbelegt, beim Umlagern gibt es die Möglichkeit auch den Standardlagerplatz für diesen Artikel zu ändern (alle Teile ziehen sozusagen standardmässig um).

Im Lieferschein gibt es dann endlich das "Schnell-Auslagern" ohne alle Fragezeichen durchzuklicken.
Falls nicht genug vorhanden ist, wird entsprechend eine Meldung generiert.

Leider brauch ich auf Kundenwunsch auch ein Auslagern, selbst wenn dann ein Minus im Lager entsteht, dass würde ich im Standard nicht so sehen, allerdings kann man das entsprechend "tief" in der Mandantenkonfiguration mit dem Hinweis 'Vorsicht bissiger Leopard' verstecken.

Ich kann auch den Knopf "Auslagern über Standardlagerplatz" in der Konfiguration verstecken, falls der nicht gewünscht ist (s.a. Screenshot).
Allerdings nimmt der nicht viel Platz weg und das Feature ist dann etwas prominenter erkennbar.

Soweit, ansonsten kurz telefonisch abstimmen.

Replying to jbueren:

Kann manuell bei der Migration überlagert werden, bzw. alles kann auch manuell überlagert werden (automatische Zuordnung ist nur eine Vorschlagsliste).

Fein.

Nicht vorgesehen. Ein Standardlagerplatz in einem Lager. Das alte Feld hatte ja diesselbe Bedeutung.

Naja, das alte Feld war zu nichts zu gebrauchen. Sobald wir anfangen, hier Dinge auf Datenbankebene zu verknüpfen, müssen wir etwas über den Tellerrand von "so war es vorher" hinausschauen. Und da ergibt das absolut Sinn, mehrere Lagerplätze vorsehen zu können:

• Artikel, für die ein Lagerplatz physikalisch einfach nicht ausreicht (= mehrere Lagerplätze innerhalb desselben Lagers)
• Bei mehreren Standorten kann ein Artikel durchaus für jedes Lager einen eigenen Standardlagerplatz haben (= in mehreren Lagern je ein Lagerplatz)
• ...und die Kombination aus beidem

Im Lager-Menü wird entsprechend beim Einlagern vorbelegt, beim Umlagern gibt es die Möglichkeit auch den Standardlagerplatz für diesen Artikel zu ändern (alle Teile ziehen sozusagen standardmässig um).

Für Situation "nur ein Lager" durchaus passend.

Für die Zukunft sollte man das aber weiter fassen. Sinnvoll wäre dann auch, Benutzern einen Standardlagerort zuweisen zu können... so nach dem Motto "Frau Musterfrau arbeitet immer aus München und bekommt daher die Standardlagerplätze aus dem Münchner Lager" während "Herr Mustermann aus Hamburg das Hamburger Lager vorbelegt bekommt".

Verstehst, was ich meine?

Naja, das alte Feld war zu nichts zu gebrauchen. Sobald wir anfangen, hier Dinge auf Datenbankebene zu verknüpfen, müssen wir etwas über den Tellerrand von "so war es vorher" hinausschauen. Und da ergibt das absolut Sinn, mehrere Lagerplätze vorsehen zu können:

• Artikel, für die ein Lagerplatz physikalisch einfach nicht ausreicht (= mehrere Lagerplätze innerhalb desselben Lagers)

Gut. Das ist aber sehr weit über den Tellerrand, dann muss man hier auch die Lagerfunktionen generell anpassen (ein Teil über mehrere Lagerplätze in inventory abbilden etc).

Prinzipiell ist das jetzt erstmal nicht "verbaut", ich würde das aber als neues Feature abgrenzen.
Sobald das kommt, kann ich gerne die Stammdaten-Lagerplatz Funktion analog zu Lieferant und Lieferantennummer dynamisieren, dass ist dann der kleinste Aufwand.

• Bei mehreren Standorten kann ein Artikel durchaus für jedes Lager einen eigenen Standardlagerplatz haben (= in mehreren Lagern je ein Lagerplatz)
• ...und die Kombination aus beidem

Ist ok, aber eher als neues Features. Verbaut ist das ja nicht (s.o.).

Für Situation "nur ein Lager" durchaus passend.

Ja, auch für Situation ein neues Lager kommt hinzu und wir verschieben Teile aus dem alten Lager in das neue Lager.

Für die Zukunft sollte man das aber weiter fassen. Sinnvoll wäre dann auch, Benutzern einen Standardlagerort zuweisen zu können... so nach dem Motto "Frau Musterfrau arbeitet immer aus München und bekommt daher die Standardlagerplätze aus dem Münchner Lager" während "Herr Mustermann aus Hamburg das Hamburger Lager vorbelegt bekommt".

Standardlager und Standardlagerplatz ist jetzt in der Tabelle defaults, hier kann man gerne dann benutzerbezogen "überlagern".

Verstehst, was ich meine?

Klar. Unsere Rückmeldung vom Kunden ist eher in die andere Richtung, das Lagerverfahren eher einfacher gestalten, anstatt weiter aufzubohren.

Mein Ziel ist es jetzt zum einen die Möglichkeit das Verfahren konfigurativ auf "Bestandslager" mit nur einem Lagerplatz runterzuschrauben und ferner die bisher überhaupt nicht vorhandene Verknüpfung Stammdaten -> Lager endlich anzubieten.

Danach wird sowieso mehr aus Kundensicht an Ideen kommen ...

Replying to jbueren:

Gut. Das ist aber sehr weit über den Tellerrand, dann muss man hier auch die Lagerfunktionen generell anpassen (ein Teil über mehrere Lagerplätze in inventory abbilden etc).

Ömm... zumindest die Lieferscheine können jede Position auf beliebig viele Lagerplätze aufteilen. Dafür benötigt es keinerlei Anpassung.

Prinzipiell ist das jetzt erstmal nicht "verbaut", ich würde das aber als neues Feature abgrenzen.

Naja. Das sind halt die Wünsche, die praktisch sofort von Benutzerseite kommen werden.

Klar. Unsere Rückmeldung vom Kunden ist eher in die andere Richtung, das Lagerverfahren eher einfacher gestalten, anstatt weiter aufzubohren.

Die Funktion zeitgleich mächtiger und trotzdem einfacher zu bedienen zu machen ist kein Widerspruch :)

Replying to m.bunkus@…:

Replying to jbueren:

Ömm... zumindest die Lieferscheine können jede Position auf beliebig viele Lagerplätze aufteilen. Dafür benötigt es keinerlei Anpassung.

Das hab ich dann falsch verstanden. Ich dachte die Teile sind so groß, dass sie auf Lagerplatz 1 bis 4 lagern müssen (20 m Brett oder so).

Naja. Das sind halt die Wünsche, die praktisch sofort von Benutzerseite kommen werden.

Beauftragungen sehe ich ja gerne ;-). Von unseren Benutzern kommt hier erstmal nichts.

Die Funktion zeitgleich mächtiger und trotzdem einfacher zu bedienen zu machen ist kein Widerspruch :)

Das find ich ja auch super ;-).
Das sind wir uns ja sowieso einig.

Nene, die Teile sind alle total klein :) Nur lagern wir davon dermaßen große Mengen, dass sie sich weigern, auf nur einem Lagerplatz platz zu nehmen :)

So. Der Migrations-Schritt ist jetzt mit Commit 82c4717d48bbdb8d30c9671e71ecb0d6d8eac963 drin.

Drei Kleinigkeiten mit denen ich nicht ganz so glücklich bin:

Form->get_lists('warehouse') liefert keine Leer-Eintrag zurück, andere Listen können ja dann in der multibox, bzw. L auf leer gesetzt werden, dass geht ja hier nicht so einfach, da ja noch JavaScript? benötigt wird. Ich hab den leeren Wert jetzt in Perl noch hinzugefügt:

my $no_default_bin_entry = { 'id' => '0', description => '--', 'BINS' => [ { id => '0', description => } ] };

Vielleicht macht das eher Sinn, diesen Eintrag nochmal _get_warehouse als Parameter zu ergänzen, bzw. eine Lösung im Template-Code zu haben.

Das ist dann auch schon die Überleitung zu der zweiten Kleinigkeit, die JavaScript?-Funktion function warehouse_selected benötige ich öfters, deshalb hab ich die dann in commons/ ausgelagert.
Allerdings brauch ich die [%- USE LxERP %], [%- USE JavaScript? -%] _{, dann zweimal, einmal in der aufrufenden Datei und dann in der common-Datei, da sich ansonsten locales.pl zumindestens beschwert.}

Funktionieren tut das aber auch, wenn man nur einmal die Direktiven einbindet.

Als ich die Funktion dann ausgelagert hatte, hab ich gemerkt, dass ich die für templates/webpages/client_config/form.html so nicht verwenden kann, da hier die Variablen in SELF anstatt in FORM übergeben werden.
Vielleicht gibt es hier einen kleinen Trick, damit man das auch noch zusammenführen kann.

So. Anbei der Changelog, der soweit die Funktion dokumentiert und gleich auch noch ein Screenshot für die Mandantenkonfiguration:

• Lagerverwaltung sinnvoller mit Stammdaten verknüpft Freitextfeld-Lagerplatz in Stammdaten durch Lager und Lagerplatz ersetzt. Entsprechende Vorauswahl beim Einkaufslieferschein. Der Standardlagerplatz wird schon direkt vorausgewählt. Ferner wird der Standardlagerplatz unter Lager -> Einlagern entsprechend auch vorausgewählt. Den Standardlagerplatz kann man unter Mandantenkonfiguration voreinstellen. Der voreingestellte Standardlagerplatz ist dann die Vorauswahl für neu angelegte Waren. Sowohl Einkaufs- als auch Verkaufslieferschein haben einen neue Funktion, Ein- / Auslagern über Standardlagerplatz. Diese Funktion ist an- bzw.. abschaltbar in der Mandatenkonfiguration (standardmässig an). Die Funktion lässt sich noch wie folgt konfigurieren:
  • Falls kein Standardlagerplatz in den Stammdaten hinterlegt ist, verwende den vorkonfigurierten Standardlagerplatz.
  • Falls der Bestand nicht ausreicht zum Auslagern oder eine Mindesthaltbarkeit, bzw.. Chargennummer vergeben ist (welches ein Abbruchkriterium beim Auslagern ist), lager dennoch aus und verwende hierfür den vorkonfigurierte Fehlbestands-, bzw. Fehlbuchungslagerplatz

Mandantenkonfiguration für Lager

Replying to jbueren:

So. Anbei der Changelog, der soweit die Funktion dokumentiert und gleich auch noch ein Screenshot für die Mandantenkonfiguration:

Hi Jan,

im Screenshot fehlt die MHD-Option. Ist das ein Versehen oder Absicht?
Grüße

Bernd

Absicht. Die kommt weiter unten. In dem Screenshot ist jetzt nur die Differenz abgebildet.

Im Kern ist die Erweiterung jetzt drin.

Bei der Migration ist noch ein kleiner Fehler beim automatischen Erkennen der Lagerplätze und falls Moritz das besser findet schieb ich die sub transfer_in_out_default { noch nach SL/DO.pm

Der Hinweis von Sven war auch gut, hab mich aber dann für die client_config.html dagegen entschieden da ich hier zuviel extra noch für das Lager brauchte.

Soweit

Mit dem letzten Commit 71d04fc6249e3d857262e6f0f08a84a0697c7bbd ist das Ticket soweit abgeschlossen.

Hast du getestet, was passiert, wenn man einen Artikel einem Lagerplatz zuordnet und den Lagerplatz dann über die Systemsteuerung zu löschen versucht?

Super Punkt. DB-Fehler kommt. Haken wird jetzt aber auch entfernt.

Sorry, etwas parallel eingestellt. Anyway:

Was soll passieren bei Lager auf ungültig setzen:

a) ignorieren
b) verbieten, wenn es zugewiesenen Standardlager in Stammdaten gibt
c) Lagerplatz-Zuordnung löschen
d) Lagerplätze in Stammdaten als 'ungültig' anzeigen

Ich würde lieber das Feature hier weiter diskutieren, da hier auch Screenshots und vorherige Anmerkungen (s.o.) schon vorhanden sind und die weiteren Commits dann auch transparenter auf das Trac-System zeigen.