Abgelehnt [WAWI-19736] - Gewinnausweis in Angeboten wird bei EK Änderungen nicht aktualisiert in der 1.2.3.6

[gutberle]

Ausgangslage: In der alten 0.9er Wawi wurde der Gewinnausweis unten rechts im Angebot bei jeder EK Änderung des Artikels bei erneutem Aufruf des Angebots automatisch aktualisiert.

Bewertung: Das war so auch korrekt, denn der Gewinn ist ja gerade bei Angeboten, sprich bevor ein Auftrag erteilt, Ware geliefert und die Rechnung erstellt wurde, immer die aktuelle Differenz zwischen dem aktuell im Angebot eingetragen VK eines Artikels und dem aktuell im Artikel selbst eingetragenen EK.

Problem: In der aktuellen 1.2.3.6er Wawi wird der Gewinnausweis nach der Erstellung des Angebots aber überhaupt nicht mehr aktualisiert, es sei denn man löscht den oder im Zweifel sogar alle Artikel und legt sie neu an, siehe hier.

 

[Rico Giesler]

Hallo @gutberle
Vielen Dank.
Ich habe es an die Entwicklung weitergegeben.

 

[Canalratte]

Wurde denn dieser Fehler mit der 1.3 behoben?
Für mich ist eine korrekte Berechnung der Kalkulation essentiell und hat mich bislang abgehalten von der 0.99 upzugraden.
Jetzt wird aber zum 31. Januar 2018 der Support für Ebay und Amazon Abgleich mit der 0.9x eingestellt - und habe jetzt ein richtiges Problem, sofern der Fehler nicht behoben wurde..
Bitte um kurzen Status.

 

[gutberle]

@Canaratte - Nein, der Fehler besteht leider weiterhin, auch in der aktuellen BETA 1.3.14.0

Bist Du Dir aber sicher, dass Dich dieser Fehler an dieser Stelle wirklich so sehr behindert? Sicher wollen wir alle, dass der Gewinn (wohl eher der Rohertrag oder die Marge) auch in den Angeboten korrekt ausgewiesen wird. Aber das heißt ja nicht, dass die Wawi den Gewinn auch in den Statistikfunktionen falsch berechnet.

 

[gutberle]

... bevor ich jetzt allerdings so verstanden werde, als ob ich das alles gar nicht schlimm finde, das ist nicht der Fall! - Der falsche Gewinnausweis unten rechts ist nur eben ein kleines Symptom=Ergebnis des eigentlichen und wirklich gravierenden Problems.

Dass auch in der aktuellen 1.3.14 BETA die Preise in einmal erstellten und gespeicherten Angeboten auf keine Änderungen an den Artikel EK-Preisen, den Kundengruppenpreisen, den indiv. Kundenpreise, den Staffelpreisen oder auf Änderungen an den Standardrabatten der Kundengruppen reagieren, ist eine echte KATASTROPHE.

Schlimmer noch, ändert man irgendwelche dieser vielen Preise, nachdem man ein Angebot erst einmal angelegt und gespeichert hat, dann greifen nach der Änderung auch keine Staffeln mehr, sondern jede eingegebene Menge wird einfach mit dem eingangs vorliegenden EK-Netto multipliziert und gut ist.

Das ist eine professionellen Warenwirtschaft echt unwürdig und ehrlich gesagt würde ich eigentlich schon davon ausgehen, dass ein kapitaler Bock wie dieser innerhalb von 6 Monaten zumindest mal angegangen werden könnte ...

 

[Canalratte]

Es behindert enorm - bzw wird für uns ab 1.0 nicht mehr nutzbar.
Wir konfigurieren nach Kundenvorgabe und verkaufen Serversysteme, welche aus zig Komponenten bestehen.
Alle Komponenten dazu sind in der Wawi bereits angelegt - haben jedoch keinen oder einen falschen EK, sofern diese nicht am Lager sind.

Im 1. Step erstellen wir die Konfiguration nach Kundenwunsch in form eines Angebotes über alle benötigten Komponenten. Danach wird der EK für die Komponenten ermittelt, welche nicht am Lager sind.
Danach wird der VK ermittelt >> dies funktioniert aber nur, wenn der EK im Angebot aktualisiert wird und der Gewinn korrekt angezeigt wird - bis 0.9xx hat das wunderbar funktioniert - mit dem wir nun immer noch arbeiten.

 

[Canalratte]

Wenn JTL hier nichts machen möchte, müsste ich als Alternative einen Workarround basteln, der dann bei jeder Angebots/Auftrags-Änderung per Workflow eine SQL Query ausführt, die im aktuellen Angebot die Positions-EKs mit den Aktuellen Produkt-EKs überschreibt.
Dann wäre das Problem glatt gelöst.

Ich bräuchte nur jemanden, der die Tabellen in der DB inkl der neuen so gut kennt, und diesen String bauen kann. Um die Ausführung könnte ich mich dann selbst kümmern.
So stünde einem Upgrade auf 1.x nichts mehr im Wege.

Wenn jemand Bock hat, das zu übernehmen, oder mir die Tabellen nennen kann ist herzlich willkommen.

VG
Jürgen

 

[gutberle]

@Canaratte - Da wirst Du leider kein Glück haben, denn dazu mußt Du keine SQL Query ausführen, sondern ein SQL Update und JTL hat alle Update-artigen SQL Befehle gesperrt. Aus gutem Grund natürlich, denn sonst könnten die alle Entwickler entlassen und stattdessen 30 Supporter mehr einstellen...

Auch eine Änderung der tatsächlich (aka "erstaunlicherweise") direkt bei der Angebotsposition gespeicherten Positions-EKs per Workflow geht nicht, weil die Workflows für Angebote zwar die Aktion "Werte setzen" kennen, aber keine "Positionen". Das war's, sorry.

 

[versuchsmal]

Aber interessieren würde mich das schon warum JTL Wawi nun diese Funktion nicht mehr kann.
Ich denke das, das heute einfach zum Standart gehört.

 

[gutberle]

@versuchsmal - JTL hat auf dem Weg von der 0.9 zur 1.0 angefangen, Module von C++ nach C# zu portieren, um in Zukunft schneller entwickeln zu können. Dieser Prozess ist langwierig, ist ja auch ein ausreichend komplexes Programm und das heißt, dass hier immer noch reichlich C++ Module neben C# Modulen existieren und dann wird auch noch sukzessive an der Datenbankstruktur gearbeitet.

Und gerade dieser letzte Punkt ist es, der dann immer mal wieder dazu führt, dass eine Funktion, die "doch schon" in der 0.9 funktioniert hat, plötzlich in der 1.x nicht mehr funktioniert, einfach, weil da ein "Disconnect" aufgetreten ist - und das passiert selten, weil man nicht aufgepasst hat, das gibt es auch, aber das wird dann meist als Bug erkannt und gefixt, sondern meistens liegt das daran, dass die zugrundeliegende Datenbasis oder aber die Interfaces jetzt anders sind und man weiß als Entwickler, dass das nicht mehr funktioniert, aber man müsste viel Aufwand darin investieren, "diese Kleinigkeit" wieder zum Laufen zu bringen.

Das betroffene Modul ist dann aber zwangsläufig alte C++ Code Basis, sonst wäre der Disconnect ja gar nicht aufgetreten und dann sagt jeder vernünftige Entwicklungsleiter "njet" dazu, Zeit darauf zu verwenden. Das "Problemchen" muss dann warten, bis das Modul nach C# portiert wird und dann geht das "Problemchen" von alleine (naja...) wieder weg.

Das klingt alles nicht wirklich "kundenorientiert", aber so funktioniert Entwicklung und so muss Entwicklung funktionieren, sonst wird das ein Faß ohne Boden und eine Geldsenke ohne Ende. Ich denke, wir müssen JTL hier einfach zugestehen, dass DIE hierbei die Prioritäten setzen und nicht wir ...

 

[Canalratte]

Hallo Gutberle,

also ich kann das nicht nachvollziehen - ich kann die Datenbank beliebig mit Update beschreiben - natürlich nicht aus der Wawi selbst heraus. Aber aus .NET heraus klappt das prima. Hab das eben probiert.
Ich hätte jetzt ein kleines Programm mit .NET geschrieben, das den SQL Befehl zum kopieren des EKs absetzt, und diese kleine exe dann per Workflow bei Angebotsänderung ausführt - fertig.
Warum sollte das nicht gehen, wenn ich alle relevanten tabellenpositionen/Namen kenne?

Viele Grüße
Jürgen

 

[gutberle]

Hallo Jürgen,

tja, wenn Du so einen großen Hammer nimmst, dann geht natürlich alles, immerhin gibt Dir JTL ja mit dem Benutzer "sa" und einem sogar frei von Dir gewählten Passwort alle Rechte auf der DB. Was ich oben meinte ist, dass JTL es Dir nicht erlaubt von innerhalb der Wawi mit den dort anbgebotenen Möglichkeiten direkte DB Schreibzugriffe zu machen.

Aber zu jedem großen Hammer gehört eben auch nicht nur das eigene Wissen darum, wie man ihn anwendet, sondern auch worauf man ihn anwendet und worauf besser nicht. Und Deine Fragen in Post #7 von oben zeigen ganz deutlich, dass Du besser die Finger davon lassen solltest, denn Du hast zwar den Hammer und weißt offenbar auch, wie man ihn verwendet, aber den Rest hast Du leider nicht und so kann das zwangsläufig nur im Chaos enden

Sorry, aber das ist mir zu heiß, ich bin hier raus ...

Gruß,
Ingmar

 

[Rico Giesler]

Hallo @Canalratte
Wie @gutberle richtig schreibt ist ein SQL-Update per Workflow (derzeit) nicht möglich.
Wenn du das direkt in der DB machst geht das natürlich, davon raten wir aber DRINGEND ab, denn sonst können wir bei Folgefehlern oder Problemen nicht weiterhelfen.

Wir entwickeln aktuell eine neue Auftragsbearbeitung mit einer umfangreichen Margenberechnung. Weiter wird die Einkaufspreisemittlung, sowie die GLD Berechnung deutlich praxisorientierter.
Die Entwicklung (da sehr viele Änderungen) ist aber recht umfangreich und wird somit noch eine ganze Weile dauern.

Derzeit bleibt dann nur die Option die Artikel im Angebot nochmal raus zu nehmen und neu hinzuzufügen um eine Neuberechnung herbeizuführen.