Neu Artikelhistorie falsch!

MHammer

Aktives Mitglied
21. März 2015
24
1
Hallo!

Ich habe ein Problem mit der Artikelhistorie.

Wir arbeiten mit Einkaufsrechnungen. Nun ist es so das bei der Bestellung von Artikeln oft ein anderer Preis in der Lieferantenbestellung hinterlegt ist als dann auf der Einkaufsrechnung (Bonus, Sonderpreis nachverhandelt, oder kein Preis da EK bei Bestellung nicht bekannt...) verrechnet wird.

Wenn nun die Einkaufsrechnung erstellt wird wird damit der durchschnittliche EK berechnet was auch stimmt. In der Artikelhistorie wird der Artikel aber mit dem Preis aus der Bestellung übernommen was ja nicht stimmt, da ich ja die Preise der Bestellung in der Einkaufsrechnung richtig gestellt habe. Die Einkaufsrechnung bezieht sich ja auf die entsprechende Bestellung.

Sehe ich da den Ablauf falsch? Kann ich die Preise in der Historie ändern?

Weiters habe ich noch die Frage was der Knopf "Historie Nachrechnen" eigentlich macht?
Hierzu gibt es leider auch im Guide nichts zu finden.

Danke im voraus
Robert Aichhorn
 

HMS_IT

Sehr aktives Mitglied
29. Januar 2014
780
110
Leipzig
Da Ablauf ist aus meiner Sicht ein klein wenig anders und das könnte auch Dein "Problem" erklären. Ich schildere mal unsere Vorgehensweise, bei uns habe ich zumindest noch keinen signifikanten Fehler in der Preisbildung feststellen können:

Ablauf:
1. Artikel auf die Einkaufsliste,
2. Bestellung generieren und zum Lieferant schicken
3. aus der "Auftragsbestätigung" entnehme ich: Artikel, die geliefert werden und Preise
4. damit aktualisiere ich meine Bestellung
5. wenn Ware kommt: Wareneingang buchen
6. wenn Rechnung kommt: Eingangsrechnung öffnen, Versandkosten, Skonto erfassen und Preise/Mengen prüfen
7. Eingangsrechnung speichern, dabei unbedingt den Haken bei verbuchen setzen.

Nur wenn die Eingangsrechnung verbucht wird, werden auch die EKs im Artikel angepasst. Ach und ja: das geht natürlich nur bei Lagerartikeln, heisst bei welchen mit Bestand...
 

MHammer

Aktives Mitglied
21. März 2015
24
1
Hallo HMS_IT!
Danke für die schnelle Antwort.
Leider liegt hier das Problem. Wir erhalten bei vielen Lieferanten keine AB's und die Rechnung erst nach dem Wareneingang d.h. ich habe die Ware bereits mit dem falschen EK eingebucht.
Die Berechnung des Lagerwertes stimmt nach Verbuchung der Eingangsrechnung ja. Nur wenn ich ansehen will wie ich einzelne Artikel eingekauft habe (z.B. um zu sehen ob ein Zusatzrabatt möglich ist) sehe ich in der Historie einen falschen Preis! Diesen muss ich dann kompliziert über die Einkaufsrechnung heraussuchen.

Wieso wird nicht der Preis aus der Einkaufsrechnung in die Historie übernommen?

lg.
Robert
 

HMS_IT

Sehr aktives Mitglied
29. Januar 2014
780
110
Leipzig
Der Preis wird ja übernommen, aber erst nach Verbuchung der Eingangsrechnung... Ist ja aus meiner Sicht auch logisch, denn wie willst Du ohne Rechnung Ware verbuchen (monetär), wenn Du gar nicht weisst, wieviel Du mit Skonto etc. schlussendlich zahlst?
 

MHammer

Aktives Mitglied
21. März 2015
24
1
Wir verbuchen die Eingangsrechnungen mit Zahlungen und alles!!
Aber wenn im Auftrag bei Wareneingang z.B. 0,- steht und dann mit der Eingangsrechnung 100,- dann habe ich im durchschnitts EK 100,- als letzten EK 100,- aber in der Historie 0,-

Hier liegt mein Problem
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
Dein aktuelles Problem klingt nach "Bug".
-> Würde man dein Artikelkonto neu berechnen und die Historie zeigt 0, dann wäre der Wert der Bewegung 0 und eine Neuberechnung ergäbe einen falschen durchschnittlichen EP.

Aber - mehrfach diskutiert (bis zum Abwürgen der Diskussion durch JTL), bislang unklar ist und bleibt aber in der JTL-WAWI einiges wenn man Eingangsrechnungen verwendet, denn diese ermöglichen ein versetztes Buchen von LAGER und WERT und so lange dies nicht eindeutig und klar von JTL dargestellt wird, kann man es nicht verwenden. Das Resultat wären unklare WERTbestände, wegen abweichenden Preisen bei der Buchung der Eingangsrechnung.
Dies hat auch Konsequenzen auf Aufträge die bestehen oder geliefert wurden (Rechnung erstellt) bevor die Eingangsrechnung gebucht wurde (durchschnittlicher EP), auch hier ist eine Aufrollung nötig und es ist nicht klar ob oder wie das die WAWI macht.

Status Quo ist für mich daher nach wie vor:
Ohne Belege des Lieferanten mit definitivem Preis -> kein Wareneingang. Und wo und wann man überall etwas nachfummeln oder neu erfassen muss , darf aktuell jeder selber herausfinden.
 

MHammer

Aktives Mitglied
21. März 2015
24
1
@JTL Das gehört dringend von JTL angeschaut!! Wir bekommen die Rechnungen oft 2-3 Tage nach Wareneingang. Da ist die Ware oft schon wieder verkauft. Mir stimmt ja weder mein Lagerwert noch meine Gewinnstatistik.... Habe keine Lust wenn ich eine Wawi habe meinen Lagerwert händisch nachzurechnen!
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
Ach du Optimist, solche Diskussionen führen wir schon seit Jahren erfolglos ... kannst es auch in den Wald rufen, da kommt nix, außer dass die Diskussion darüber abgewürgt wird durch Schließen/Sperren des Threads.
Der letzte Stand der Dinge war: "Das ist zu kompliziert und man müsste ja immer alles neu durchrechnen. Das geht aus Performancegründen nicht."

Tja, wenn JTL das Problem und an sich auch einfache Lösungen dazu nicht sehen will, dann ist man machtlos ... und freut sich eben über neuen Artikelstamm und 4711. Shipping-Version und "Widgets" die keiner braucht. Immerhin, es wird irgendwas programmiert für uns. ;)
 
  • Gefällt mir
Reaktionen: hula1499

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
@MHammer - Es ist leider tatsächlich so, dass beim Wareneingang der in der Lieferantenbestellung vermerkte EK im Warenlagereingang und bei Seriennummernartikeln auch im Artikel selbst *fixiert* wird, egal, wie der spätere Preis auf der Eingangsrechnung aussieht. Das ist JTL bekannt und das Einzige, was JTL hier als fehlerhaft und problematisch akzeptiert hat, ist meine Meldung, dass ein EK von 0, z.B. bei einer Ersatzanforderung im Wareneingang und im Artikel immer mit dem aktuellen GLD eingebucht wird. Ob und wann das gefixed wird, bleibt abzuwarten.

Der GLD, also der durchschnittliche Lagerpreis wird aber auch nicht auf Basis der EKs der tatsächlich am Lager liegenden Waren berechnet, was vor dem obigen Hintergrund vielleicht auch eine Gnade ist. Hier wird stattdessen der aktuelle GLD mit der Rechnungs-/Wareneingangsmenge UND mit dem EK aus der Eingangsrechnung fortgeführt. Das entspricht auch tatsächlich der korrekten Art einen GLD zu bilden.

Was durch das (echte!) Problem mit den falschen Preisen im Warenlagereingang und für SN Artikel auch beim Artikel selbst auf der Strecke bleibt, ist einerseits natürlich die Korrektheit der Artikelhistorie, vor allem aber auch die Möglichkeit einer echten Lagerbewertung auf Einzelwertbasis, die nach HGB eigentlich und insbesondere für SN/Chargen Artikel vorgeschrieben ist und die nur "ersatzweise" durch die gewogene oder GLD Methode ersetzt werden darf. Denn wenn beim Artikel und auch beim Warenlagereingang nicht der echte EK liegt, wo soll der dann herkommen.

Der Weg, den @HMS_IT beschreibt, ist hier natürlich ein Heilmittel, aber für die meisten von uns nicht praktikabel. Rechtlich korrekter wäre hier übrigens eine vorherige Preisanfrage, denn ein erteilter und von der Gegenseite angenommener Auftrag ist ein Vertrag nach BGB und und wenn da 10000€ für den Artikel drinsteht, dann sind es 10000€ pro Artikel, auch wenn der aktuelle EK bei 9,99€ liegen würde. Eine Preisanfrage ist unverbindlich, aber für Dich/Mich/Uns wahrscheinlich auch impraktikabel.

Die Sache mit dem Button in der Artikelhistorie ist übrigens genauso leicht erklärt, wie grotesk:

Kurz nachdem die 1.0er Wawi rauskam, fiel den ersten auf, dass die Artikelhistorie "irgendwie nicht stimmte". Ich habe mir das damals gleich durch einen Vergleich der Historie von Artikeln in meiner produktiven 0.99923 mit den gleichen Artikeldaten in der aktuellen 1er angeschaut und sofort gesehen, dass alle Warenlagerbewegungen bei der Migration schlicht ihr Vorzeichen verloren hatten. Aber bevor ich mich zu Wort melden konnte, hatte JTL schon festgelegt, dass die Lösung sei, dass ein Button eingefügt würde, mit dem man die Artikelhistorie "bei Bedarf" nachrechnen kann und hatte den Thread dicht gemacht.

Von allen möglichen und denkbaren Lösungen für das Problem war das nun gerade die mit Abstand dämlichste, denn das zeigt, dass JTL das Problem entweder nicht verstanden oder gar nicht erst analysiert hat. Denn wenn Sie begriffen hätten, dass es sich um einen einmaligen Fehler bei der Migration von der <1er auf die 1er Wawi handelt, wäre es die logische und professionelle Lösung gewesen, beim nächsten Upgrade die Artikelhistorie aller Artikel einfach neu zu berechnen und gut ist. Und falls Sie das Problem analysiert und einen generellen Bug gefunden hätten, tja dann wäre ein Button immer noch genau die Troubleshooting Strategie gewesen, die ich nicht einmal einem Praktikanten in der ersten Woche hätte durchgehen lassen. Einen Button einzufügen bedeutet ja letztlich nichts anderes als zu sagen 1. Die Artikelhistorie ~kann~ aus dem Ruder laufen und 2. wir wissen nicht, wie wir das verhindern können und 3. falls Du, Nutzer, das Gefühl hast, die hier angezeigte Artikelhistorie ist falls, dann klicke hier. - Oh mein Gott...

Ich habe mich damals über diesen Abgrund an Inkompetenz derart geärgert, dass ich mich betrinken musste, inzwischen bin ich weiter und halte es mit Reinhard Mey's genialer Realitätskritik aus "Annabelle", die da lautet "Früher dachte ich korruptes Spießerschwein, wer was schaffen will will, der müsste fröhlich sein. Heute weiß ich, im Gegenteil, im Pessimismus liegt das Heil!". Aber wie sagen die zwei Rheinischen Grundgesetze: "Et küt, wie et kütt" und "Et is no immer jot jegange"... :eek:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: HMS_IT und hula1499

MHammer

Aktives Mitglied
21. März 2015
24
1
@gutberle Danke für deine Antwort!

So wie ich das sehe gibt es ein Problem das nicht als solches erkannt wird und ich daher auch keine Lösung erwarten sollte.
Gibt es vielleicht ein externes SQL Script das mir aus den Einkaufsrechnungen die Preise entnimmt und in der Artikelhistorie einträgt? Ich weis das ist gefährlich aber ich muss in der Artikelhistorie wissen wie ich was eingekauft habe! Hat der in der Historie eingetragene Preis eine weitere Auswirkung auf irgendwelche Statistiken?

@jtl Kann ja eigentlich nicht so schwer sein die Preise aus den Eingangsrechnungen in die Historie zu übernehmen. Bitt zumindest darüber nachzudenken diese Möglichkeit einzuführen. Würde vielen WAWI nutzern helfen denke ich.

lg.
Robert Aichhorn
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
"Der GLD, also der durchschnittliche Lagerpreis wird aber auch nicht auf Basis der EKs der tatsächlich am Lager liegenden Waren berechnet, was vor dem obigen Hintergrund vielleicht auch eine Gnade ist. Hier wird stattdessen der aktuelle GLD mit der Rechnungs-/Wareneingangsmenge UND mit dem EK aus der Eingangsrechnung fortgeführt. Das entspricht auch tatsächlich der korrekten Art einen GLD zu bilden."

Aber nur wenn die Mengen zur Berechnung auch die Mengen sind die zum Zeitpunkt der Bewegung (WE) bestanden haben und nicht nur zum Zeitpunkt der Buchung der ER.
Und die Aufträge, Rechnungen schleppen ggf. immer noch den falschen GLD mit.

Aber das weiß keiner genau, außer man setzt sich stundenlang hin und rechnet alles nach.
Was aber sinnlos ist, weil JTL hier schon seit Jahren nichts ändert und auch nicht ändern will.

-> Also - ER- Workflow einfach vergessen und Einkaufspreise so genau wie möglich festlegen / erfragen und mit Abweichungen leben lernen ...
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
@MHammer - Nein, ein solches Skript habe ich nicht, ob es das gibt, kann ich natürlich nicht sagen. Ich mache es ehrlich gesagt schon seit jeher so, dass ich immer dann, wenn ich eine Eingangsrechnung verbucht habe, mit einem SQL Editor in die DB gehe und händisch die Werte nachtrage.

Ich will Dich aber nicht dazu ermutigen, es mir da gleich zu tun, denn das ist natürlich ein böser Eingriff in die DB Hoheit der Wawi und da die Eingangsrechnung durchaus später als der zugehörige Wareneingang kommt, sind es eben auch nicht immer "die Letzten Warenlagereingänge.

Du musst also schon wissen, was Du tust und wissen, wie Du sicherstellst, dass Du auch die richtigen Einträge änderst, ähem. Entsprechend gebe ich hier auch keine Anleitung, sondern nur den Hinweis, dass es sich um die Spalten tWarenLagerEingang.fEKEinzel und bei SN Artikeln um tLagerArtikel.fEK handelt und dass Du vorher noch in tLager den Wert für kArtikel für Deine Artikel nachschlagen musst, denn in tLagerArtikel und tWarenLagerEingang stehen Deine eigenen Artikelnummern nicht, sondern nur deren kArtikel Nummer. Der GLD steht übrigens in tArtikel.fEKNetto und der letzte EK in tArtikel.fLetzterEK, aber diese beiden bitte in Ruhe lassen, nur schauen, nicht anfassen... o_O
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
"Aber nur wenn die Mengen zur Berechnung auch die Mengen sind die zum Zeitpunkt der Bewegung (WE) bestanden haben und nicht nur zum Zeitpunkt der Buchung der ER.
Und die Aufträge, Rechnungen schleppen ggf. immer noch den falschen GLD mit."

Oha, dass ist eine ganz andere Baustelle, die mich ständig in den Wahnsinn treibt, weil sich das versetzte Verbuchen von EK und GLD bei zwischenzeitlichem Abverkauf, der bei mir die Norm ist , auch auf den Gewinn auswirkt, aber das ändert ja nichts an der Validität der zugrundeliegenden wirtschaflichen Vorgänge.

Also ist die Konsequenz für mich einfach, dass ich die Statistikfunktionen der Wawi ignoriere und das Dashboard so anlege, dass es den Bildschirm maximal bunt macht. Für was anderes taugt das alles bei aller Ehre nichts, solange sich an der EK Bewertung und den Bewertungszeitpunkt nichts ändert.

Immerhin, ich war vor ein paar Wochen auf einen JTL Thinktank eingeladen und dort habe ich und noch zwei andere Teilnehmer den beiden JTL Entwicklungsleitern, die insgesamt sehr präsent und aufmerksam waren, das Problem ~wirklich~ nahebringen können und die Diskussion endete damit, dass JTL zugesagt hat, dass sie hier definitiv mehr Kontrolle für den Nutzer implementieren werden.

Ok, wann das passiert wurde natürlich nicht gesagt, das wäre in der Situation auch zu schwierig gewesen und ob dann auch diese Misere hier gleich mit bereinigt wird, man wird es sehen. Bekannt ist sie ja immerhin schon lange und die Hoffnung ruht darauf, dass wir vielleicht im ThinkTank mehr Bewußtsein für die Konsequenzen haben wecken können..
 

MHammer

Aktives Mitglied
21. März 2015
24
1
@gutberle Danke für deine Ausführungen!! Ich werde mir da ein Script überlegen und wenn es funktioniert kann ich es dir auch gerne zur Verfügung stellen.
Freut mich auch das du im ThinkTank noch einmal auf die Situation aufmerksam gemacht hast.
Die Hoffnung das sich hier etwas tut stirbt ja bekantlich zuletzt.

Schön wäre es hier an dieser Stelle auch von JTL selbst ein Statement zu bekommen ob hier etwas geplant ist bzw. wo es auf der Prioritätenliste steht.

lg.
Robert Aichhorn
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
"Immerhin, ich war vor ein paar Wochen auf einen JTL Thinktank eingeladen und dort habe ich und noch zwei andere Teilnehmer den beiden JTL Entwicklungsleitern, die insgesamt sehr präsent und aufmerksam waren, das Problem ~wirklich~ nahebringen können und die Diskussion endete damit, dass JTL zugesagt hat, dass sie hier definitiv mehr Kontrolle für den Nutzer implementieren werden. "

Na, dann brauchst du hier nicht so viel zu schreiben, dann dürfte es ja zum 4711. mal bei JTL angekommen sein ... ;)

Der Haken an der Sache ist, und ggf. auch ein Knackpunkt, mit Kontrollmöglichkeit wächst auch das Risiko weitere Bugs aufzudecken !
Heute traut keiner den Zahlen lt. Statistik oder irgendwelchen Summen die irgendwo angezeigt werden, rein aus Erfahrung heraus, und nimmt alles nur als "circa" und "ungefähr", ab dem Zeitpunkt wo die WAWI eine WAWI wird und nicht nur eine Auftragsbearbeitung mit Bestandsführung und Versand wird's heikel ...

Immerhin, ab dem Zeitpunkt an dem ein Artikelkonto korrekt geführt wird in Menge und Wert kann man alles jeden Tag neu nachrechnen und bewerten lassen, auch das ist eine Lösung.
1 Klick, 1 Minute Laufzeit und die Zahlen stimmen wieder. :)
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
"Na, dann brauchst du hier nicht so viel zu schreiben, dann dürfte es ja zum 4711. mal bei JTL angekommen sein ... ;)
Du übertreibst, das Thema ist bisher höchstens 0815 Mal hochgekommen und ja, wenn ich ~wirklich~ so großes Vertrauen in meine Überzeugungskünste hätte, würde ich vermutlich Ruhe geben. Scheint, als würde ich dem Braten selbst nicht trauen, oder? o_O
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
Doch, ich vertraue dir, denn keiner hat hier so brav vorgelegt und manuell eingegriffen wie du, allen anderen (inklusive mir) waren bislang mit den Ungenauigkeiten einverstanden und ließen sich mundtot machen.

Nach dem Motto: Wenn in der Buchhaltung unten ein fetter Gewinn steht ist alles wunderbar, woher der Gewinn genau kommt muss man ja nicht wissen, auch nicht wo der Gewinn wächst und wo er schrumpft (im Vergleich zur Vorperiode / Vorjahr in % und Euro) und wenn dann mal eine rote Zahl rauskommt, dann macht man einfach die Bude zu.
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.837
1.548
WENN das Artikelkonto korrekt geführt werden würde und WENN es diesen Knopf gäbe, dann könnte man alles nachrechnen inklusive Korrektur anderer Bewegungsdaten ... WENN man (=JTL) das so machen würde.
 

MHammer

Aktives Mitglied
21. März 2015
24
1
@MichaelH Ahhhhh! Wenn das Wörtchen wenn nicht wäre.... Schade ich dachte du hast eine Lösung die ich nicht gefunden habe!! Arbeite ich also weiter an dem SQL Script.