seit das MRP-Fertigungsmodul besteht, bis in V19.0.0 hinein kann man in MO-Fertigungsaufträgen munter Waren produzieren ohne Material verbrauchen zu müssen, obwohl eine BOM am MO-Fertigungsauftrag hängt und den Verbrauch steuern sollte.
Wie geht das?
Wenn man hier auf " verbrauchen oder produzieren" klickt
und jetzt hier z.B. 33 produzieren will und nach der Zahleneingabe die ENTER Taste drückt, bucht das System munter drauf los ohne Material zu verbrauchen…
Das darf auf keinen Fall so leicht zu missbrauchen sein - wäre jedenfalls meine bescheidene Meinung dazu!
Hier brauchen wir dringend einen Übertrag des Wertes von der „rechts“ Seite zur „linken“ Seite uns zwar in dem Verhältnis, wie die BOM es vorgibt.
ob etwas ein Bug oder ein Feature ist, hängt vielfach vom Anwendungsfall ab…
Richtig ist, dass Fertigungsaufträge in Dolibarr weitgehende Freiheiten lassen, die tatsächlichen Verbräuche und produzierten Mengen zu erfassen (insbesonder wenn der linke Button ohne „ALLES“ verwendet wurde).
Bei klar strukturierten, stabilen Fertigungsprozessen wird es da keine Abweichungen zur Stückliste geben und es ist dann sogar hilfreich, wenn das Programm den Benutzer zwingt, sich an die vorgegebenen Werte zu halten. Es gibt aber auch Fertigungsprozesse oder allgemeiner Arbeitsabläufe, bei denen Abweichungen normal sind und bei denen in den Fertigungsaufträgen erfasst werden soll, was tatsächlich an Input verwendet wurde und was an Output rausgekommen ist. Beispiel: Es findet in der Fertigung eine Qualitätsprüfung eingesetzter Vorprodukte statt und manche werden ausgesondert. Dann wird entsprechend mehr verbraucht als in der Stückliste erfasst wurde.
Für mich sieht der Wunsch nach einer strikten Kontrolle der Mengen und der anteiligen Aufteilung bei der Produktion von Teilmengen eher nach einem Feature-Request aus (so wie im Lager z.B. negative Bestände deaktiviert werden können). Alternativ lässt sich das gewünschte Verhalten auch mit einem externen Modul realisieren.
Aber egal ob Bug oder Feature Request: Ohne entsprechende Meldungen auf GitHub wird sich vermutlich nichts ändern…
wir mussten in diesem Modul eh viel selbst noch rein programmieren, da bei unseren Fertigungsprodukten die linke Seite mehrere Duzent Positionen enthält. Das kann man händisch nur mit einer hohen Fehlerquote erledigen.
Was mich halt extrem stört, ist, dass ein einfaches „Return“-Drücken die Buchung auslöst, obwohl ich ja nur den Wert eintragen wollte und irgendwo muss ich halt anfangen einzutragen.
Aber diese Fehlinterpretation von Returns hat man auch in fast allen Chats. Dort wird auch gleich losgepostet, obwohl man vielleicht nur erstmal einen „Gedanken“-Absatz machen wollte…
GitHub ist so ne Sache: dafür ist mir die Zeit inzwischen zu schade. Ich hab 3 oder 4 - meiner Meinung nach - handfeste Bugs gepostet und hatte dann Diskussionen, mit Programmierern an der Backe, die alles schönredeten und die Issues dann geschlossen haben.
Sorry- aber das brauch ich dann auch nicht.
Ok, dann verstehe ich das eigentliche Problem jetzt besser. Das Verhalten der Enter-Taste ist in diesem Fall tatsächlich unschön.Beim Generieren der Input-Felder könnte man mit etwas JavaScript das Event ‚Enter-Taste‘ abfangen… Das betrifft aber viele (alle?) Formulare.
wir mussten in diesem Modul eh viel selbst noch rein programmieren, da bei unseren Fertigungsprodukten die linke Seite mehrere Duzent Positionen enthält. Das kann man händisch nur mit einer hohen Fehlerquote erledigen.
habe ich mal vor einiger Zeit ein Modul programmiert:
Evtl. Hilft es Dir weiter. P.S. aktuell programmieren wir einen BDE-Melder in C# welcher über die WebApi den Fertigungsprozess sinnvoll abwickelt…
Dann bleibt in Dolibarr eigentlich nur noch die Datenhaltung und für die Verwaltung eine Übersicht.
