Neu Lagerbewertung

frankpeters

Gut bekanntes Mitglied
30. August 2010
267
21
Okay... schade. Wäre ja eigentlich ne feine Sache, wenn JTL auch für das FBA-Lager eine Historie aufbauen würde - eben damit man auch hier rückrechnen kann.
Solange das nicht geht, muss ich dann doch leider bei meinem Ameisen-Export über Batch + Windows-Aufgabe am jeweils 1. eines Monats bleiben :(

Wir arbeiten gerade an einer solchen Lösung. Falls Interesse besteht, einfach PN.
 
Zuletzt bearbeitet:

Mexx18689

Gut bekanntes Mitglied
16. Dezember 2015
238
5
Warm wir der Wert bei EK laut WE nur mit 6,9 angezeigt?

Es sind 43 auf Lager und der Preis ist 6,9. Wie kann das Gesamtergebnis dann nur 6,9 sein?
 

Anhänge

  • Bildschirmfoto 2019-09-08 um 12.34.31.png
    Bildschirmfoto 2019-09-08 um 12.34.31.png
    83,6 KB · Aufrufe: 69

Marc Völker

Moderator
Mitarbeiter
15. April 2014
1.886
191
Hürth
Der WE EK resultiert aus dem Einkaufspreis der beim Wareneingang gesetzt wurde, sprich aus der Lieferantenbestellung, oder Eingangsrechnung. Ist da nichts gesetzt, bleibt das leider bei vielen positionen 0, daher ergibt sich dann diese summe.

In deinem fall geht nur der EK aus dem GLD.
 

Jensus247

Mitglied
2. September 2019
2
0
Hi, tolles Tool. Eine Sache habe ich noch wo ich nicht durchblicke.

ich habe zwei Mandaten. Wenn ich das Tool nutze, dann sehe ich nur die Lager vom ersten Mandant (eb_standard).

1575287654892.png

Ich brauche eine Lagerbewertung des 2. Mandaten. Wie kann man das bewerkstelligen?
 

Mexx18689

Gut bekanntes Mitglied
16. Dezember 2015
238
5
Hallo an Alle,

Die Software arbeitet ja auch Rückwirkend.

Wie kann es dann sein das trotzdem die Ergebnisse unterschiedlich sind?

Siehe Bild.

Links das Bild vom September, rechts das Bild von gestern. (Beides erstellt für den 01.09.2019)
 

Anhänge

  • Bildschirmfoto 2019-12-21 um 12.10.45.png
    Bildschirmfoto 2019-12-21 um 12.10.45.png
    553,4 KB · Aufrufe: 82

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
Hallo @Mexx18689.

das ist ganz einfach zu erklären.

In die Berechnung aller Werte bis auf die in der 6. Spalte von links gehen die Werte der Variable fEKNetto ein, und die ist nichts anderes als der *aktuelle* GLD. Wenn Du also zwischen dem 01.09.2019 und dem 21.12.2019 für irgendeinen Artikel einen Wareneingang mit einem vom dann aktuellen GLD dieses Artikels abweichenden EK hattest, dann ändert sich dessen GLD - und jetzt kommt's - ...

Das Tool von Marc errechnet anders als man denken sollte, *nicht* den zum Wunschzeitpunkt der Lagerbewertung vorliegenden GLD pro Artikel, sondern nimmt immer den GLD - von HEUTE -. Damit sind aber alle Spalten die das Tool auswirft, in die der GLD eingeht, also ALLE außer der 6. Spalte mit der Bezeichnung "Gesamt Ek Laut WE', per definition immer falsch, es sei denn es wird der aktuelle/heutige Lagerwert angefordert. Aber auch dann würde ich auf die ganzen GLD basierten Werte keinen Pfifferling geben, denn die Wawi kann leider auch selbst noch nicht korrekt mit dem GLD umgehen.

Und wenn ich schon am stöhnen bin, dann muss ich leider sagen, dass auch die 6. Spalte leider immer mehr oder weniger falsch ist, weil bei Seriennummernartikeln zwar (aus tLagerArtikel) immer eine spezifische Seriennummer ausgebucht wird , dort aber keine Referenz auf den zu dieser Seriennummer gehörigen Warenlagereingang existiert. Was macht die Wawi also: Sie bucht (in tWarenLagerEingang) einfach eine Seriennummer aus dem ältesten Warenlagereingang zu diesem Artikel aus. - Damit laufen die real im Lager liegenden Werte der Seriennummernartikel und deren Wert "Gesamt Ek Laut WE" aber immer auseinander.

Dennoch ist - unter der Annahme annähernd stabiler EKs für die Seriennummernartikel - die 6. Spalte immer noch die beste und geaueste von allen, denn einen großen Einfluß hat dieser Umstand ja nur, wenn sich die alten Wareneingänge zum Artikel stark im EK von den neuen Wareneingängen unterscheiden.

Gruß,
Ingmar
 
Zuletzt bearbeitet:

Mexx18689

Gut bekanntes Mitglied
16. Dezember 2015
238
5
Das Problem ist, das wir nur Zeile 5 verwenden können. Da wir in der Vergangenheit (2017/2018) Wareingänge noch nicht angelegt hatten bzw ohne Preis. Und da wir davon noch Bestand haben, errechnet das System falsch. Siehe Bild, dort hatten wir einen Wareneingang den wie nie in der Bestellung angelegt hatten. Somit wird dieser nicht mitgezählt. Auch wenn wir es nachträglich machen, geht das nicht. Haben alles versucht. Somit bleibt uns nur Zeile 5....
 

Anhänge

  • Bildschirmfoto 2019-12-23 um 11.30.44.png
    Bildschirmfoto 2019-12-23 um 11.30.44.png
    157,8 KB · Aufrufe: 35

Shopworker.de

Offizieller Servicepartner
SPBanner
4. Januar 2011
4.114
542
Arnsberg, Sauerland
Hallo Mex,

Auch wenn wir es nachträglich machen, geht das nicht. Haben alles versucht. Somit bleibt uns nur Zeile 5....

Du meinst vermutlich Spalte 5 ;) ...

Du könntest per Ameise die aktuellen EKs oder eine Spalte mit den Preisen, die du zur Berechnung heranziehen möchtest exportieren und dann der Tabelle (z.B. in Excel mit der Funktion SVerweis) diese Werte zuweisen ... das wichtigste (die Stückzahlen) hast du ja ...
 

wawi-dl

Sehr aktives Mitglied
29. April 2008
5.923
568
Ich kann @gutberle nur bestätigen, für die Bewertung des Lagers sollte man immer den Wareneingang EK verwenden, nicht den GLD!

Aus früheren Zeiten wurde der GLD mal falsch berechnet, es gibt aber auch noch sehr viele weitere Faktoren, die den GLD verfälschen können!
Allein wenn ein Mitarbeiter verlorene Ware im Lager findet, diese wieder einbucht im System, weis man nicht mit welchem EK damals gebucht wurde, der Mitarbeiter korrigiert einfach (nur mal als Beispiel).

Führt man also eine Lagerbewertung auf Grundlage GLD durch und meldet diese Werte an, Jahre später wird eine Prüfung durchgeführt und man hat abweichende Werte, seid ihr in Erklärungsnot!
Der GLD ist schön und gut, bietet aber keine Grundlage für Lagerbewertungen, würde ich daher ohnehin bei dieser Auswertung "rausnehmen", damit man auf keine falschen Ideen kommt.

@Marc Völker
Es würde vielleicht auch helfen, wenn man neue Versionen mit neuen SQLs besser versionieren würde, vielleicht auch mit Unterscheidungen zur JTL-Wawi Version.
Aus gegebenem Anlass komme ich hier aber auch gerne mal auf dich zu :)
 

ongnamo

Sehr aktives Mitglied
31. März 2013
992
79
mal eine Frage: Inweiweit werden hierbei EKs von einer nicht-EUR Lieferantenwährung in EUR umgerechnet?

Grüße
Thomas
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
Die Währungskonvertierung wird zum Zeitpunkt der Einbuchung in das Lager vorgenommen, tWarenLagerEingang enthält also immer Euro-Werte, basierend auf den Wechselkursen, die bei Einbuchung aktuell waren. Das ist aus Lagersicht auch komplett richtig und dass das eventuell vom Wechselkurs zum Zeitpunkt der Rechnungserstellung, des Rechnungsempfangs oder der Rechnungseinbuchung abweicht, ist kein Thema, denn das ist "Buchhaltung".
 

ongnamo

Sehr aktives Mitglied
31. März 2013
992
79
Danke! Wenn die Spalte "Gesamt Ek Laut WE" des Tools den in EUR umgerechneten Wert aus tWarenLagerEingang heranzieht, dann ist es ja gut.

Da ich den Lagerwert für die Erstellung einen Schlussbilanz benötige, frage ich durchaus aus Sicht der "Buchhaltung". Bin allerdings keine Buchhalter/Stb und hoffe, dass der Wert Menge x EK in EUR (umgerechnet zum Datum der Einbuchung) richtig ist. Falls jedoch Lagereingangswert auf Basis des Fremdwährungswertes der Lieferantenrechnung in EUR umgerechnet werden muss, könnte das ein Problem sein, da es insbesondere bei stärker volatilen Währungsrelationen zwischen Fremdwährung und EUR zu größeren Differenzen kommen kann. Weißt du zufällig, welcher Ansatz richtig ist?
 

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
Nein, das ist tatsächlich ganz einfach, ich habe mich mit dem etwas opulenten Hinweis auf die "Buchhaltung" aber vielleicht etwas mißverständlich ausgedrückt. Buchhaltung und Lagerwert sind hier wirklich zwei Paar Schuhe.

Das Aktiva Konto "Bestand Waren" In der Bilanz enthält den Lagerwert oder die Summe der Lagerwerte zum Stichtag und da der Wert einer Ware in einem Lager immer der Wert sein muss, der an dem Tag gültig war, an dem die Ware in das Lager eingebucht wurde (lassen wir mal AfA und sonstige Abschreibungen außer Betracht), wird für den Lagereingang immer der Betrag in der Fremdwährung x AktuellerWechselkurs genommen. Damit stehen in der Bilanz dann in "Bestand Waren" (SKR03 3980) korrekte Werte und das ist grundsätzlich auch das, was in der Spalte "Gesamt Ek Laut WE" des Tools von Marc steht, plusminus mein Einwand von oben zu den Seriennummernartikeln.

Jetzt bekommst Du aber auch Rechnungen in Fremdwährung zu Deinen Einkäufen und was auch immer hiervon zum Bilanzstichtag noch aussteht, steht im Passiva Konto "Verbindlichkeiten aus Lieferungen und Leistungen" (SKR03 1600) in der Bilanz. Jetzt sagen wir aber mal Du hast sogar noch zwei 50%ige Zahlungszeitpunkte. Dann gibt es ein Datum der Rechnungserstellung, ein Datum des Rechnungszugangs und zwei Datumsangaben zu jeweils einer Zahlung. Ich denke, damit wird das Dilemma schon klar. Effektiv KOSTET Dich die Ware den Eurobetrag, der von Dir an den Zahlungszeitpunkten geleistet wurde, aber zu diesem Zeitpunkt MUSS die Eingangsrechnung ja schon in der Buchhaltung fixiert sein. damit Deine Zahlungen dagegen gebucht werden können. Die Buchung gegen einen "Permanentstapel" ist ja nicht mehr zulässig.

Deshalb macht man es so, dass man IMMER das Datum der Rechnungserstellung hernimmt und die Buchhaltungssoftware (sofern sie taugt) den eingebuchten Fremdwährungsbetrag intern mit dem zum Rechnungsdatum tagesaktuellen Wechselkurs umrechnet und so als Eurobetrag einbucht. Differenzen zwischen dem so "virtuell" geschuldeten Eurobetrag und den effektiv geleisteten Euro-Zahlungen werden dann auf zwei speziellen Konten "Erträge aus der Währungsumrechnung" (SKR03 2660) und "Aufwendungen aus Währungsumrechnungen" (SKR03 2150) geführt.

Und Achtung, das sind nicht die gleichen Konten, die Du vielleicht für "Rundungsdifferenzen" kennst und die nur "ein paar Cent" aufweisen sollten. Die oben genannten Konten haben bei mir in den Bilanzen immer Werte von einigen bis zu etlichen Tausend Euro und zwar beide, weil die Volatilität ja zwei Richtungen kennt.
 
Zuletzt bearbeitet:

ongnamo

Sehr aktives Mitglied
31. März 2013
992
79
Wow. Besten Dank für die ausführliche Darstellung. Erspart mir das Lehrbuch und ist hoffentlich auch für den einen oder anderen Leser des Threads interessant. :)