Neu Stichtagsinventur / Bilanz

[Stephan K.]

Hallo,

es ist ja allseits bekannt, dass JTL kein Interesse an einer Stichtagsinventur hat. Es wird zwar so im Guide für WMS genannt, bezieht sich aber lediglich auf eine ad-hoc/live- Inventur und führt die Begrifflichkeit ad absurdum (Clickbait?).

Mit SQL kann man eine Stichtagsinventur erhalten (war schon vor Jahren im Forum Thema und flammt fast jährlich immer mal wieder auf). Leider habe ich hier nur die durchschnittlichen EKs und keine Aufteilung, welcher Artikel nun genau wie viel gekostet hat.

Kennt sich jemand derart damit aus, dass man eine Auflistung der jeweiligen Positionen der EKs bekommt?

Als Beispiel:

5x 1 € Artikel
5x 2 € Artikel
Die SQL-Stichtagsinventur listet mir hier nur 10x 1,50 € Artikel mit den Durchschnittspreisen (also Gesamt) auf.

Ansonsten bin ich auch gerne für Tipps dankbar, wie man sonst in eine Bilanz startet mit ordentlicher Inventur oder ob das mit JTL nur so Larifari möglich ist.
Da JTL manche Funktionen nur für Großkunden programmiert, gehe ich davon aus, dass ich nicht der einzige bin, der vor diesem Problem steht/stand.

 

[gutberle]

Am nächsten zu einer echten Stichtagsinventur kommst Du mit dem ViCtorStat Tool von @Visitmedia | Marc - Dein Beispiel von oben mit der Aufsplittung der Lagereinheiten der Artikel nach EK kann das aber auch nicht abbilden.

Eigentlich ist das Tool von Marc echt ehrenhaft und ihm und Visitmedia gebührt Dank dafür, aber für meine Bedürfnisse reicht es auch nicht und ich bin deshalb dabei, mir selbst was zu schreiben. Für die SN/Chargenartikel aus tLagerArtikel ist das noch trivial und längst fertig, aber für die Auswertung der normalen Lagerartikel, bei denen man die Bestände über die Warenlagerein- und ausgänge fortführen muss, ist das schon komplexer (zumindest in SQL) und mir fehlt im Moment noch die Zeit dafür. Da ich aber dieses Jahr aus internen Gründen super-früh bilanzieren muss, bin ich gezwungen, den Worten ganz bald Taten folgen zu lassen.

Ich poste dann hier, was ich erstellt bekomme und will auch mal versuchen, daraus eine workflow-fähige Version zu machen, die alles gleich in eine CSV Datei schreibt. Eigentlich sollte das kein wirklich großer Aufwand werden, aber der Teufel ist halt ein Eichhörnchen ...

 

[Marc Völker]

@gutberle danke für die Lorbeeren. Was genau fehlt dir den? Weil eigentlich deckt sie das gewünschte genau ab, wir Exportieren hier natürlich auch die Lagerbewertung auf basis des GLD 8Durschnittspreise, jedoch genauso auch auf die beim Wareneingang erfassten Real EKs. Letzeres setzt aber vorraus, dass alle Wareneingänge auch über Lieferantenbestellungen lief, dann klappt das. SN Artikel sind was spezielles. Da diese leider nicht bezogen auf Reale Lagerartikel bezogen adressiert werden können, was ich aber auch ehrlich gesagt nicht wirklich dafür nötig (wäre nur für so Minusbuchungen mal was nettes. Wenn die eine Referenz zu ihrem wareneingang hätten)
Chargen und MHDs werden eh direkt mit im Wareneingang / Ausgang erfasst, sprich daher unproblematisch. Aber für die Bewertung auch eher 2 rangig.

Zur Not haben wir auch eine erweiterte Variante da, welche bis 2017 auch die Periodenverkäufe eines jeden Artikels darstellt. (Gerade relevant wenn man Lagerbestand auch Abschreiben möchte) Da schauen wir auch, dass wir bis Ende 2018 ein Tool entwickeln, mit dem die Warenwerte auch Real abgeschrieben und entwertet werden können. (Technisch nämlich kein Problem)
Ansonsten Stichtags Inventur heisst ja nur soviel wie, wir machen eine Inventur zu einem festen Datum, und werten diese aus, Parallel dazu ist ja hier von einer Stichtags Lagerbewertung die Rede.
WMS bringt hier gerade eher das Thema Laufende Inventur auf den Tisch, eben weg von der Stichtagsinventur, um sich so diese einfach zu Sparen.
Was natürlich nichts daran ändert, dass man eben dennoch eine Stichtags Lagerbewertung brauch, und gelegentlich die Inventur Differenzbuchungen ausdruck / Exportiert.

Ansonsten @gutberle schick mal was dir fehlt, wenn es ne kleinigkeit ist, packe ich das in die nächste version mit rein. Integrieren das eh die nächsten Wochen mit diversen Tools direkt in den ViCtor. Dann kommt auch was wie Lagerauswahl dazu. Aktuell überlegen wir sogar noch, ob es nicht eine lösung gibt, dass wir für FBA eine Stichtags Lagerbestandsbewertung möglich machen. Das ist aber wirklich komplex.

Wie du eine Workflow fähige Version machen möchtest, das würde mich schon interessieren

 

[Stephan K.]

Hallo miteinander,

das scheint ja genau das zu sein, was mir gefehlt hat! Danke schon ein Mal an dieser Stelle an @gutberle und natürlich @Visitmedia | Marc für die Verlinkung bzw. Erstellung des Tools. Ich schau es mir mal heute nachmittag an.
Durch die fehlenden Tags bzw. allgemein die Forensuche kam ich nicht auf diesen Beitrag, dafür nur andere, weniger hilfreiche.

Die Lieferantenrechnungen pflege ich nicht mit JTL ein, da das oftmals ad-hoc geschieht und keine langen Anlaufzeiten hat. Ware bestellt, ist am nächsten Tag da und die Artikelerstellung bzw. EKs werden gleich auf ein Mal erledigt. Auch bei Nachschub werden nur Wareneingänge so angelegt.
Ist ggf. eine Überlegung wert, hier den Prozess umzustellen, aber ich finde da JTL etwas umständlich.

Zur Not wird die Inventur halt hoffentlich nach § 240 HGB Abs. 4 und nicht bindend nach § 254 HGB (Einzelbewertung) erstellt werden dürfen. Das ist eigentlich eher die Ausnahme. Mal sehen.

 

[gutberle]

@Visitmedia | Marc - Danke für Deine ausführliche Antwort und natürlich insbesondere für Dein Angebot bei Kleinigkeiten auch noch einmal Arbeit zu investieren. Das weiß ich wirklich zu schätzen!

Meine Probleme, also der Grund, warum ich mit Deinem Tool allein nicht klarkomme, ist leider keine "Kleinigkeit", sondern liegt zum Teil daran, wie wir "lagerhalten" und dann auch an ein paar seit vielen Jahren bekannten Unzulänglichkeiten der Wawi im Zusammenhang mit der Buchung von Wareneingängen, der Behandlung von Um- und Korrekturbuchungen und den bekannten Problemen im Zusammenhang mit dem GLD.

Zum Einen haben wir multiple Lager die alle separat bewertet werden müssen, als da wären, Standardlager, Retourenlager, Reparaturlager, Transferlager, Komissionslager (multiple, geldwerter Vorteil...), Demolager und Ausschußlager. Manche dieser Lagertypen sind schon speziell, wie zum Beispiel das Ausschußlager. Wir dürfen abgelaufene Medizinartikel nämlich nach Finanzamtsweisung nicht direkt abschreiben, wenn wir sie noch für interne Testzwecke benutzen, z.B. EKG Elektroden, sondern müssen ihren Lagerwert dann linear abschreiben. All so was halt ...

Dann gab es bis ~1.3 das Problem, dass Wareneingänge, deren EK auf der Bestellung mit 0€ angegeben wurden, weil es sich entweder um kostenlose Beigaben oder bei uns meistens um Ersatzbestellungen für Rücklieferungen defekter Artikel handelt, statt mit 0€ immer mit dem aktuellen GLD eingebucht wurden. Das kommt bei mir praktisch bei jeder Lieferantenbestellung der letzten Jahre vor, großes Kino, und das kriegt kein Standard-Tool hin, sondern dazu muss ich zurück auf die Lieferantenbestellungen, also zumindest ein JOIN tiefer, um das zu finden und geradezuziehen.

Dann sind da noch die vielen Probleme mit den GLD Updates bei der Nutzung von Eingangsrechnungen und bei überlappenden Lieferungen und Eingangsrechnungen, bei denen die Ware das Lager schon wieder verläßt, bevor die ER eingebucht wird. Ich kann im Moment nicht sagen, wie schlimm das noch ist, aber "historisch" gesehen" war das für mich ziemlich gravierend, weil diese Abfolge bei mir die absolute Regel ist und ich musste für die Lagerbewertung am Jahresende bisher immer massiv alles zurechtbiegen, um auf korrekte Lagerwerte zu kommen.

Deshalb war ich auch so begeistert von Deinem Tool und seiner Fähigkeit, das Lager auch auf Basis der Werte aus dem Wareneingang, sagen wir mal ~ auf WE-EK Basis, zu bewerten. Dann musste ich aber feststellen, dass Inventurbuchungen, Um- und Korrekturbuchungen und auch Umlagerungen z.B. von Artikeln mit Seriennummern, Chargen, usw. die einen diskreten EK haben, die Artikel immer mit dem aktuellen GLD wieder einbuchen und da es sich bei Umlagerungen um Artikel z.B. mit der gleichen SN handelt, die raus- und reingehen, ist nach der Umlagerung nirgends mehr in der DB ein Hinweis auf den ursprünglichen EK zu finden, der ist einfach mit dem aktuellen GLD überschrieben und tLagerArtikel.kLieferantenbestellung zeigt dann auch auf die Umlagerung. Damit ist jegliche Möglichkeit, noch einmal an den tatsächlichen EK dieses Artikels zu kommen FUTSCH! Tja, stimmt der GLD, ist das vielleicht egal, stimmt er aber nicht, dann ist das nicht nur Scheiße, sondern dieser Mechanismus zwingt Dein Tool auch in die Spur, denn nach einer Inventur, wie der vom Ende des letzten Jahres, bei der praktisch kein Artikel ohne Inventur-Justage durchging, sind auch in Deinem Tool WE-EK=GLD ... und damit dann beide falsch, gratuliere.

Dagegen kommst Du mit Deinem Tool auch nicht an und wenn ich es mir so recht überlege, dann habe auch ich eigentlich nur zwei Chancen: Entweder ich programmiere mir selbst ein Tool, dass alle Lager Zu- und Abgänge bis auf die Lieferantenbestellungen zurückführt und dann extern alles in Beziehung setzt und die korrekten Lagerwerte berechnet. Das hätte den Vorteil, dass ich nicht auf SQL Logik beschränkt bin, aber den Nachteil, dass die DB unverändert falsche Werte führt. Oder aber ich gehe mit meinen Lieferantenbestellungen so weit in der Zeit zurück, wie mein Lager am 31.12.2017 zurückgereicht hat, korrigiere alle Artikel-EKs auf die tatsächlichen Werte und aktualisiere dann die GLDs der Artikel auf Basis der Vorwärtsberechnung und nutze dann den SQL Code aus Deinem Tool pro Lager, um die Lagerwerte zu berechnen.

P.S. Workflow-fähig heißt hier manueller Workflow und ich sehe da eigentlich kein Problem. Je nachdem, ob ich mit dem, was JTL in {% capture query %} Konstrukten zuläßt, klarkomme, also ohne ohne Schreibzugriffe auf dbo. und ohne TempDB zu brauchen (ist ja auch verboten, warum?), dann wäre es leicht, einen Workflow damit zu füttern. Sonst je nach Komplexität eben über einen View oder über eine eigene SP oder eben ganz über ein externes Tool, ich gehe da auf jeden Fall den Weg des geringsten Widerstandes, denn Zeit zum Programmieren ist leider das, wovon ich Heutzutage am allerwenigsten habe.