Neu Manuell eingetragene Einkaufspreise aus Angebot werden bei Auftragserstellung nicht übernommen

[badosan]

Hallo zusammen,

wir schreiben oft Angebote mit Freipositionen. Hierbei tragen wir unseren EK im Angebot auch manuell ein.
Wenn wir nun aus diesem Angebot einen Auftrag erstellen, werden die EKs nicht übernommen.
Das Problem besteht schon seit einigen Versionen, momentan sind wir auf der aktuellsten.

Hat jemand eine Lösung hierzu?

 

[sar.no]

Hi,

ja, das Problem haben wir auch. Ist äußerst unpraktisch insbesondere bei größeren Angebot/Aufträgen.
Wir würden uns auch sehr über eine Lösung hierfür freuen.

Viele Grüße,
Sarah

 

[frankell]

Hi @badosan und @sar.no,

das ist eindeutig ein Bug, den Ihr bei JTL melden solltet. Da muss in der entsprechenden SP, die aus dem Angebot einen Auftrag macht, etwas falsch sein. Ich habe bei einem Test mal zusätzlich eine Versandposition gesetzt. Dann wurde im Auftrag deren EK bei der Freiposition als EK gesetzt.

Es ist aber möglich, über einen manuellen CustomWorkflow den Auftrag zu korrigieren. Wenn daran Interesse besteht, könnt Ihr mich gerne anschreiben.

 

[sar.no]

Habe gerade mal nachgeschaut.
Es gibt wohl ein Ticket zum Thema: https://issues.jtl-software.de/issues/WAWI-65022

Viele Grüße,
Sarah

 

[frankell]

Habe gerade mal nachgeschaut.
Es gibt wohl ein Ticket zum Thema: https://issues.jtl-software.de/issues/WAWI-65022

Viele Grüße,
Sarah

Erstellt am 22.09.2022 und Status Informationsbeschaffung. Steht wohl nicht ganz oben auf der To-Do-Liste von JTL, um das mal vorsichtig zu formulieren.

 

[Markus Hütz]

Erstellt am 22.09.2022 und Status Informationsbeschaffung. Steht wohl nicht ganz oben auf der To-Do-Liste von JTL, um das mal vorsichtig zu formulieren.

Hey,

das Thema wird nicht vergessen. Das entsprechende Team hat nur leider dringendere Aufgaben (GPSR, E-Rechnung, ...).


Mich würde hier aber mal interessieren, ob das aus eurer Sicht nur für Freipositionen so sein sollte. Ich persönlich finde es verkehrt, wenn bei Artikelpositionen der EK verwendet wird, der zum Zeitpunkt der Angebotserstellung gültig war. Aus meiner Sicht wäre bei Artikelpositionen der Einkaufspreis, der zum Zeitpunkt der Auftragserstellung relevant, denn da wird bei Bestellware ja auch erst bestellt, oder? Genauer wäre hier am Ende ja auch nur der EK von dem Artikel der effektiv versendet wird. Und da ist der Auftrag am nahesten dran.


Gruß,
Markus

 

[sar.no]

Hi Markus,

danke für dein Feedback hierzu.

Also, bei den Freipositionen sollte es auf jeden Fall den EK aus dem Angebot mitnehmen, da es ja für diese ja keinen anderen gibt.
Ggf. sollte also auch bei angelegten Artikeln der Preis aus dem Angebot mitgenommen werden, je nachdem ob sich hier differenzieren lässt. Ich würde lieber mit den alten EKs arbeiten, als mit "0" bei den Freipositionen wie es momentan ist.

Ich fände es ehrlich interessant, den Button "Preis neu ermitteln", den es ja im Angebot/Auftrag schon gibt, auszubauen. Der bezieht sich aktuell, glaube ich, nur auf den VK.
Evtl. könnte man hier zwei Buttons machen, einen für EK und einen für VK? Oder es könnte sich ein Fenster öffnen, wo man anwählt, ob EK, VK oder beides automatisch aktualisiert werden soll. Dann könnte man das je nach eigenem Bedarf handhaben, z.B.:
Ein Fall wäre das man das Angebot/den Auftrag komplett aktualisieren will, dann wählt man beides an. Oder man will dem Kunden das Angebot mit aktuellem Datum nochmal zukommen lassen, aber kulanterweise die bisherigen VKs beibehalten, die EKs sollten für die Gewinnrechnung aber aktuell sein.
Umgekehrt gibt es auch manchmal Lieferanten, die einem kulanterweise noch einmal die bisherigen Preise gewähren, wenn die Preiserhöhung erst vor kurzem stattfand. Insofern finde ich es nicht verkehrt, erst einmal die EKs aus dem Angebot in den Auftrag mitzunehmen.
Mit so einer Button-Lösung hätte man daher die beste Kontrolle...

Viele Grüße,
Sarah

 

[frankell]

Hey,

das Thema wird nicht vergessen. Das entsprechende Team hat nur leider dringendere Aufgaben (GPSR, E-Rechnung, ...).


Mich würde hier aber mal interessieren, ob das aus eurer Sicht nur für Freipositionen so sein sollte. Ich persönlich finde es verkehrt, wenn bei Artikelpositionen der EK verwendet wird, der zum Zeitpunkt der Angebotserstellung gültig war. Aus meiner Sicht wäre bei Artikelpositionen der Einkaufspreis, der zum Zeitpunkt der Auftragserstellung relevant, denn da wird bei Bestellware ja auch erst bestellt, oder? Genauer wäre hier am Ende ja auch nur der EK von dem Artikel der effektiv versendet wird. Und da ist der Auftrag am nahesten dran.


Gruß,
Markus

Nicht bös gemeint, aber der Bug ist seit zwei Jahren bekannt, und hierbei geht es erst mal nur darum, den Code der SP entsprechend zu korrigieren, was angesichts der Tatsache, dass die korrekten Daten ja in der DB existieren eigentlich sehr schnell gehen sollte. Wie gesagt, ich könnte das flugs mit einem CustomWorkflow korrigieren. Dafür benötigt man keine zwei Jahre. Alles Weitere - wie andere oder erweiterte Funktionalitäten - können dann auf später gesetzt werden. Ein Bug sollte nicht zwei Jahre warten müssen, bis dringendere Aufgaben anstehen (was doch irgendwie eigentlich immer ist, oder), oder bis man eruiert hat, was man in dem Zusammenhang gleich mit abhandeln könnte.

 

[Markus Hütz]

Hey,

verstehe dich. Aber aktuell ist das Ticket nichtmal als Bug eingestuft. Derzeit läuft es als Feature-Request, welches einen Kommentar, einen Beobachter und drei Votes hat. Sprich dieses Ticket wirkt so, als wäre es kaum jemandem wichtig. Wir können die Dinge auch nur nach und nach abarbeiten und entsprechend priorisieren. Vorrang haben gesetzliche Anpassungen, gefolgt von Tickets die entsprechendes Interesse haben. Sonst werden nachher Fehler behoben die kaum Probleme verursachen und dafür dann Fehler nicht behoben, die viele Probleme verursachen.

Darum auch meine Rückfrage zu dem Thema. Wenn es am Ende nur heißt "Lasst bitte bei Freipositionen den EK stehen" ist das ruck zuck erledigt und ihr hab das von mir aus mit der 1.10, weil daraus keine Folgefehler resultieren können. Ändern wir jetzt aber, dass der Angebots-EK bei allen Positionstypen bestehen bleibt ist die Chance hoch, dass sich danach zu diesem "Problem" mehr Kunden melden als zu dem aktuellen Problem. Ich hoffe ich konnte die Schwierigkeiten bei der Entscheidungsfindung rüberbringen.

Gruß,
Markus

 

[frankell]

Vielen Dank für die Erläuterung.

Ich verstehe diese war und kann den grundsätzlichen Gedankengang zwar nachvollziehen, aber er geht am Thema vorbei.

Denn es kann ja nicht, wie im Ticket beschrieben, nur an einer Neuberechnung liegen, dass der EK einer Freiposition nicht aus dem Angebot übernommen wird. Wie ich oben bereits schrieb, habe ich bei einem Test erlebt, dass als EK der Freiposition der EK der Versandposition (direkt auf die Freiposition folgend) gesetzt wurde. Das ist eindeutig ein Bug. Und dieser sollte a) im Ticket korrekt als solcher deklariert und b) quasi umgehend bereinigt werden, weil das - wie Du richtig sagst - ruckzuck erledigt sein dürfte.
Ich wüsste jedenfalls nicht, wie das beschriebene Verhalten auch nur in einem einzigen Fall gewollt sein kann.

Im Übrigen gibt man nicht grundlos einen EK bei einer Freiposition ein. Die Fälle, dass die Übernahme dessen in den Auftrag nicht gewollt ist, würde ich persönlich als deutlich geringer einschätzen als die, in denen das nicht gewollt ist. Ein EK von 0 im Auftrag gegenüber einem größer 0 im Angebot erscheint mir schon logisch nicht wirklich überzeugend, wenngleich ich nicht ausschließen möchte, dass es Fälle gibt, in denen das gewollt ist.

So oder so: Den EK einer anderen Position zu übernehmen dürfte niemals gewollt sein.

 

[frankell]

Vielen Dank für die Erläuterung.

Ich verstehe diese war und kann den grundsätzlichen Gedankengang zwar nachvollziehen, aber er geht am Thema vorbei.

Denn es kann ja nicht, wie im Ticket beschrieben, nur an einer Neuberechnung liegen, dass der EK einer Freiposition nicht aus dem Angebot übernommen wird. Wie ich oben bereits schrieb, habe ich bei einem Test erlebt, dass als EK der Freiposition der EK der Versandposition (direkt auf die Freiposition folgend) gesetzt wurde. Das ist eindeutig ein Bug. Und dieser sollte a) im Ticket korrekt als solcher deklariert und b) quasi umgehend bereinigt werden, weil das - wie Du richtig sagst - ruckzuck erledigt sein dürfte.
Ich wüsste jedenfalls nicht, wie das beschriebene Verhalten auch nur in einem einzigen Fall gewollt sein kann.

Im Übrigen gibt man nicht grundlos einen EK bei einer Freiposition ein. Die Fälle, dass die Übernahme dessen in den Auftrag nicht gewollt ist, würde ich persönlich als deutlich geringer einschätzen als die, in denen das nicht gewollt ist. Ein EK von 0 im Auftrag gegenüber einem größer 0 im Angebot erscheint mir schon logisch nicht wirklich überzeugend, wenngleich ich nicht ausschließen möchte, dass es Fälle gibt, in denen das gewollt ist.

So oder so: Den EK einer anderen Position zu übernehmen dürfte niemals gewollt sein.

Hallo @Markus Hütz,
wie schaut es aus mit der Anpassung des Tickets, oder gibt es ein Neues, das den Bug adressiert?

 

[Markus Hütz]

Denn es kann ja nicht, wie im Ticket beschrieben, nur an einer Neuberechnung liegen, dass der EK einer Freiposition nicht aus dem Angebot übernommen wird. Wie ich oben bereits schrieb, habe ich bei einem Test erlebt, dass als EK der Freiposition der EK der Versandposition (direkt auf die Freiposition folgend) gesetzt wurde. Das ist eindeutig ein Bug. Und dieser sollte a) im Ticket korrekt als solcher deklariert und b) quasi umgehend bereinigt werden, weil das - wie Du richtig sagst - ruckzuck erledigt sein dürfte.
Ich wüsste jedenfalls nicht, wie das beschriebene Verhalten auch nur in einem einzigen Fall gewollt sein kann.

Moin,

kannst du das bitte mal dem Kundensupport zeigen? Ich habe jetzt mehrere Angebote in Aufträge gewandelt und es ist da nie aufgetreten. Hier werden die Positionen 1:1 kopiert und dann die Stammdaten aktualisiert. Aber ja, wenn dem so ist wäre das ein Bug und dann ein separates dringliches Ticket.


Das aktuelle Ticket werde ich anpassen, damit die Freipositionen ihren EK behalten.

Gruß,
Markus

 

[frankell]

Moin,

kannst du das bitte mal dem Kundensupport zeigen? Ich habe jetzt mehrere Angebote in Aufträge gewandelt und es ist da nie aufgetreten. Hier werden die Positionen 1:1 kopiert und dann die Stammdaten aktualisiert. Aber ja, wenn dem so ist wäre das ein Bug und dann ein separates dringliches Ticket.


Das aktuelle Ticket werde ich anpassen, damit die Freipositionen ihren EK behalten.

Gruß,
Markus

Moin Markus,
danke Dir!
Ich mache dann heute mal ein Ticket dafür auf.
Gruß,
Frank

 

[frankell]

Moin Markus,
danke Dir!
Ich mache dann heute mal ein Ticket dafür auf.
Gruß,
Frank

Ticket ist raus. Fehler tritt sogar bereits bei Duplizieren des Angebots auf.

 

[Markus Hütz]

Wie ich oben bereits schrieb, habe ich bei einem Test erlebt, dass als EK der Freiposition der EK der Versandposition (direkt auf die Freiposition folgend) gesetzt wurde. Das ist eindeutig ein Bug. Und dieser sollte a) im Ticket korrekt als solcher deklariert und b) quasi umgehend bereinigt werden, weil das - wie Du richtig sagst - ruckzuck erledigt sein dürfte.

Das hier tritt bei dir immer sofort nachstellbar auf?

 

[frankell]

Das hier tritt bei dir immer sofort nachstellbar auf?

Konnte wohl auch mittlerweile bei Euch nachgestellt werden, und dementsprechend jetzt auch als Bug gekennzeichnet.