Gelöst Stichtagsbezogene Lagerbewertung [WAWI-37044, WAWI-37043, WAWI-33817, WAWI-32600, WAWI-8316]

[Loads]

Gibt es für die 1.8 mittlerweile eine Lösung die Stichtagsinventur aus der Wawi heraus zu machen?
Wir hatten einen Script der automatisch zu jedem ersten des Monats die Lagerbestandsdatei als CSV ausgibt.
Ausgerechnet zu 1.1. hat das Script nun nicht funktioniert.
Ich vermute mal es liegt an der 1.8.10 dass das Script nicht mehr funktioniert und ausgeführt wurde?

 

[FloX]

Wir haben zwar noch die 1.7 aber jetzt wäre auch nur die rückwirkende Lagerinventur ausschlaggebend das wir auf die 1.8 updaten.
Oder gibt es einen RC der die Funktion bereits implementiert hat? Dann könnte ich mir wenigstens über ein Testsystem die Daten ziehen die ich brauche.

Viele Grüße

 

[Stephan K.]

Alle Jahre wieder. Wie schade, dass das Skript nicht mit der 1.8.10 funktioniert! Laut euren Meinungen hier, hätte das Skript ja endlich mal was taugen können und stammt von einem User und keinem Mitarbeiter.
Inventur wünsche ich mir hier schon so seit 2014/2015 von JTL.
Das ist grundlegend für ein ERP und solange JTL da nichts bewegt, verdient es diesen Namen nicht für so etwas Großes.

 

[CptSwoo]

Guten Morgen zusammen.

Ich habe gem. der SQL die einfache LAgerbewertung ausgeführt und stoße da jetzt auf ein paar Probleme:

1. Es ist dort ja kein Stichtag vermerkt, da habe ich mir aus der anderen SQL den entsprechenden Befehl kopiert und eingefügt. Kann ich irgendwie prüfen, ob da auch passiert ist?
2. Die Berechnung des Gesamtwertes klappt noch nicht.
Wir haben Fall:
a) Durchschnittlicher EK ist drin, und auch Anzahl der Artikel, aber beim Gesamtwert steht 0
b) Gesamtwert wurde errechnet, ist aber nicht der durchschnittliche EK x Anzahl Lager sondern ein anderer Betrag (Wie sich der zusammen setzt weiß ich noch nicht)
3. Kann man diese Lagerbewertung auch auf ein Lager begrenzen? Wir haben mehrere WMS Lager, brauchen diese Bewertung aber nur für ein Lager davon.

Ich hoffe jemand von euch kann mir hier weiterhelfen.

Besten Dank im Voraus!

 

[FloX]

Bei mir hats geklappt. Du hast aber schon das ZIP-Archiv von Seite 1 genommen? Dort sind 3 Scripts und soweit ich mich erinnere 2 davon Stichtagsbezogen. Ein mal mit Artikelliste und ein mal nur Gesamt die Summe.

Viele Grüße

 

[CptSwoo]

Bei mir hats geklappt. Du hast aber schon das ZIP-Archiv von Seite 1 genommen? Dort sind 3 Scripts und soweit ich mich erinnere 2 davon Stichtagsbezogen. Ein mal mit Artikelliste und ein mal nur Gesamt die Summe.

Viele Grüße

Moin!

Ja genau das habe ich genommen und dann den Befehl der Stichtagsbezogenen auf die einfache angewandt.

Ich schaue heute Abend aber auch noch einmal, ob wir nicht auch mit einer der anderen beiden arbeiten können.

Vielen Dank!

 

[belbet]

Hi Freunde,

aktuell wird darüber diskutiert wie ich stichtagsbezogen meinen Lagerwert ermitteln kann. Dazu habe ich euch ein kleines SQL bereitgestellt.

Wenn ihr hier noch spezielle Anforderungen habt bitte einfach hier ins Forum schreiben.

Gruß

Manuel

Guten Tag,

ich bekomme ständig die Fehlermeldung "Meldung 208, Ebene 16, Status 1, Zeile 3 Ungültiger Objektname "dbo.tWarenLagerEingang"."

Was mache ich falsch?

 

[Manuel Pietzsch]

Guten Tag,

ich bekomme ständig die Fehlermeldung "Meldung 208, Ebene 16, Status 1, Zeile 3 Ungültiger Objektname "dbo.tWarenLagerEingang"."

Was mache ich falsch?

Du musst die Datenbank oben links auswählen wo „master“ steht

 

[MyShishaShop.de]

Gibt es für eine Lösung die Stichtagsinventur aus der Wawi heraus zu machen?

 

[Loads]

Ich bekomme auch die Fehlermeldung "Meldung 208, Ebene 16, Status 1, Zeile 3 Ungültiger Objektname "dbo.tWarenLagerEingang".
Die kommt auch wenn ich auf die Datenbank gehe wo Master steht.
Woran kann es noch liegen?

Edit: Jetzt hat es doch geklappt wenn ich erst das Management Studio öffne und von dort die Datei lade.

 

[magnum]

Ist das noch der Standardprozess oder geht es mittlerweile in der 1.8er Wawi?

 

[Ahok]

Leider verstehe ich das mit FIFO und GLD nicht wirklich. Kann mir jemand sagen, ob es in der aktuellen Datei Lagerwert je Artikel von Bedeutung ist ob GLD oder FIFO? Da steht eine Zeile EK nach GLD drin, aber nichts von FIFO. Kann ich das ignorieren oder könnte es wichtig sein?

 

[Tacticaltrim]

Hi,
wir sind nun auch auf WaWi 1.9.4.3 - ist die Lagerbewertung noch immer nur über ein SQL möglich? Das Problem scheint doch wohl jeder hier zu haben, sollte doch eigentlich umsetzbar sein oder habe ich es nur noch nicht gefunden. Vielleicht kennt jemand noch einen anderen Workaround?

 

[Derdiedas]

Es ist mir absolut schleierhaft, warum diese für jeden einzelnen JTL Kunden der mit physikalischen Lagerbeständen arbeitet (und das dürfte die überwiegende Mehrheit sein), unabdingbare und essentielle Funktion nicht endlich Teil der Wawi wird. Seit jeher müssen wir umständlich dieses Script ausführen. Das ist schon bizarr.

 

[Star Piercing]

Glaube das sollte mit JTL-BI möglich sein, Problem auch hier, es ist seit Jahren in Entwicklung und ein Release Termin wohl erst in X Jahren.

 

[Aphax]

Das Thema Lagerbewertung war uns so wichtig, dass wir da eine eigene BI Lösung für unsere Kunden entwickelt haben. Die Daten aus u.a. twarenlagereingang und -ausgang werden in eigene Tabellen geschrieben und Summen für historische Werte gebildet.
Ob ich da nun Excel an die Tabelle hänge, PowerBI oder andere Tools ist egal. Wir haben PowerBI dran gehangen und nun kann man sich vernünftig täglich den Lagerbestand/-wert (gefiltert nach was auch immer, Warengruppe, Hersteller etc.) und historische Werte z.B. Monatsendwerte anzeigen lassen.

Wer da Interesse dran hat, gern per PN melden. Anhand einer kleinen Demo sieht er/sie dann die Möglichkeiten und was man sich an Zeit spart -> 1-Klick

 

[sjk]

Hi @Manuel Pietzsch
Darf ich hier mal stellvertretend für alle fragen, wann die Lagerbewertung endlich eingebaut wird? Wenn ich mich richtig erinnere habe ich irgendwo in diesem Thread mal gelesen, dass das bereits in der Umsetzung war und eine Version 1.7/1.8 oder so avisiert wird, wegen Abhängigkeiten unter der Haube.
Im Fall der Fälle würde ich lieber nicht sagen müssen, dass die Lagerbewertung mit einem SQL Script, das ich aus dem Forum runtergeladen habe, erstellt wurde. Ich weiß, dass es korrekt ist und von wem das Script kommt aber erklär das mal dem/der ein oder anderen Prüfer:in.

Und wenn das ganze in der Zwischenzeit JTL-BI-exklusiv geworden ist wäre es jetzt mal an der Zeit für eine klare Aussage, finde ich.

 

[sjk]

Hi, zwei Wochen später frage ich mich warum der Thread auf gelöst steht. Keines der Tickets im Titel steht auf gelöst, das Ticket zur Stichtagsbezogenen Lagerbewertung steht nicht mal im Titel: https://issues.jtl-software.de/issues/WAWI-37044
Es ist schön, dass wir das Script erhalten haben, danke. Aber es ist doch wohl eher ein hotfix?

Ich denke das werden wir alles noch im Rahmen der JTL-Wawi 1.6 abschließen und auf der Basis dann die Lagerbewertung nach Stichtag (so auch die Inventur) aufsetzen. Unterm Strich (ohne etwas zu versprechen) rechne ich mit der JTL-Wawi 1.7 und somit mit einer Umsetzung im kommenden Jahr 2020.

Klar, hier wurde nichts versprochen, aber es hörte sich nach einem klaren Plan an das Ganze mittelfristig in die GUI zu bringen. Vier Jahre später muss man das Gefühl haben, dass die Funktion trotz riesigem Thread und vielen Likes im Issue Tracker unter den Tisch gefallen ist. Bitte gebt uns doch mal ein klares Update.

 

[Manuel Pietzsch]

Hi, zwei Wochen später frage ich mich warum der Thread auf gelöst steht. Keines der Tickets im Titel steht auf gelöst, das Ticket zur Stichtagsbezogenen Lagerbewertung steht nicht mal im Titel: https://issues.jtl-software.de/issues/WAWI-37044
Es ist schön, dass wir das Script erhalten haben, danke. Aber es ist doch wohl eher ein hotfix?


Klar, hier wurde nichts versprochen, aber es hörte sich nach einem klaren Plan an das Ganze mittelfristig in die GUI zu bringen. Vier Jahre später muss man das Gefühl haben, dass die Funktion trotz riesigem Thread und vielen Likes im Issue Tracker unter den Tisch gefallen ist. Bitte gebt uns doch mal ein klares Update.

Guten Morgen,

gerne gebe ich dazu ein kurzes Update. Aktuell erarbeite ich gemeinsam mit Kunden einen Algorithmus der komplett über die Datenbank läuft um den GLD zu jeder Warenbewegung ermitteln zu können.
Ziel ist es euch und unserem Support etwas an die Hand zu geben um nachzuvollziehen wie sich der GLD ergibt. Wenn dieser Algorithmus steht werde ich schauen ob wir es ermöglichen diesen manuell aus der JTL-Wawi zu aktivieren. Der Vorteil wäre (so jedenfalls mein aktueller Plan), dass die gesamte Berechnung an zentraler Stelle in der Datenbank stattfindet und sich nicht jedes Modul selbst um die Berechnung kümmern muss.
Wenn zu jeder Warenbewegung der GLD gespeichert ist, dann kann eine nachvollziehbare Stichtagsinventur in der JTL-Wawi angedacht werden. Hier kann ich aber leider keinen zeitlichen Ausblick geben. Sobald der Algorithmus aber steht, werde ich ihn gerne schon vorab hier mit euch teilen (klingt jetzt komplizierter als es ist).

Hier etwas mehr Infos wie ich es umgesetzt habe:

Algorithmus​

First Steps:

• Bei Umlagerungen und Retouren muss der Bezug zum Ursprungswareneingang erhalten bleiben

Second Steps:

• Für jede Warenbewegung wird der GLD berechnet (rekursiv)
• Hat der initiale Wareneingang keinen EK, wird er mit dem Wert der ersten Eingangsrechnung bewertet, die zum Artikel gefunden wird
  • Lieferantenbestellung wenn keine Eingangsrechnung zur Lieferantenbestellung vorhanden
• Der GLD der letzten Warenbewegung ergibt den GLD des Artikels
• Das Buchen einer Eingangsrechnung muss den GLD aller danach erfolgen Warenbewegungen (ohne Bezug zur einem älteren Wareneingang) neu berechnen
• Kann ein Bezug zum Ursprungswareneingang hergestellt werden (Retoure, Lagerumbuchung) wird der GLD aus dem Ursprungswareneingang übernommen

Kurz und knapp: Der GLD ändert sich nur durch

1. Wareneingänge die sich auf bestehende Wareneingänge beziehen (Retouren, Lagerumbuchungen)
2. Wareneingänge auf Lieferantenbestellungen
3. Buchung von Eingangsrechnungen

Gruß

Manuel

 

[MichaelH]

• Hat der initiale Wareneingang keinen EK, wird er mit dem Wert der ersten Eingangsrechnung bewertet, die zum Artikel gefunden wird
  • Lieferantenbestellung wenn keine Eingangsrechnung zur Lieferantenbestellung vorhanden

"initial", damit meinst du die erste Lagerbewegung des Artikels überhaupt ?
Denn generell darf es nicht so sein, dass ein Preis von einer Bestellung übernommen wird, eine Bestellung ist immer "fiktiv" und muss keinesfalls den wahren Preis darstellen.

Grundsätzlich verstehe ich die Änderung von der bisherigen Berechnungsart zur neuen Berechnungsart nicht und welchen Zweck diese erfüllen soll.

Denn auch bei der bisherigen Berechnungsart kann ich jederzeit einen Lagerwert korrekt nachrechnen und zwar über den gesamten Datenbestand und der Lagerwert muss immer den gleichen Wert ergeben, wäre dies nicht der Fall, gäbe es Fehler in der Berechnung bzw. in der Führung des Artikelkontos.

Interessant wird es dann, wenn ich mit der neuen Berechnungsart eine Lagerbewertung am Jahresende erstelle, diese wie immer speichere (auch monatlich) und die "neue" Lagerbewertung mir im Nachhinein einen anderen Lagerwert ausgibt. D.h. in der Zukunft und auch bei Umstellung der Berechnungsart (einmalig).
Habt ihr das schon mal in der Praxis getestet ?
Gibt es Differenzen und wie hoch sind diese ?

Zusammenfassung aus meiner Sicht:
Egal wie ihr es macht und welchen Zweck es erfüllen soll, ein Lagerwert darf sich nie rückwirkend ändern, zumindest nicht für das Jahresende (Lagerwert für die Bilanz), denn dieser Wert ist Teil des Vermögens einer Firma.
Insofern müsstet ihr also Verfahren vorsehen welche dies verhindern. Abgrenzung ?
Auch fehlen aus meiner Sicht heute Korrekturmöglichkeiten im Bestellprozess bezogen auf Bestellung, Wareneingang und ER - was tun wenn Werte falsch sind und diese heute nicht mehr korrigiert werden können, so wie es aktuell der Fall ist ?
Mit falschem Lagerwert leben auf ewige Zeiten ?!?
Erfassungsfehler gibt es und wird es immer geben, denn wo Menschen arbeiten passieren auch Fehler, mag man sich an den Kopf greifen wegen solcher Fehler, doch Mensch bleibt Mensch.