Was ist den die Fehlermeldung?
ConnectionString vielleicht falsch? Es sollte eigentlich in allen Versionen bis heute funktionieren
Neu Lagerbewertung
- Ersteller des Themas IchBinEs
- Erstellungsdatum
ConnectionString vielleicht falsch? Es sollte eigentlich in allen Versionen bis heute funktionieren
Das zeigt, dass dein Connection String in der .config falsch ist. Du kannst mir den gerne mal per PN schicken und das PW unkenntlich machen. Aber da wird was falsch sein.
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:
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.
In deinem fall geht nur der EK aus dem GLD.
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).
Ich brauche eine Lagerbewertung des 2. Mandaten. Wie kann man das bewerkstelligen?
ich habe zwei Mandaten. Wenn ich das Tool nutze, dann sehe ich nur die Lager vom ersten Mandant (eb_standard).
Ich brauche eine Lagerbewertung des 2. Mandaten. Wie kann man das bewerkstelligen?
Hallo Jens,
du musst im String
du musst im String
eazybusiness durch deine Mandantennummer ersetzen ...
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
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:
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
Hallo Mex,
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 ...
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 ...
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
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
mal eine Frage: Inweiweit werden hierbei EKs von einer nicht-EUR Lieferantenwährung in EUR umgerechnet?
Grüße
Thomas
Grüße
Thomas
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".
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?
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?
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.
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:
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.
Ähnliche Themen
| Titel | Forum | Antworten | Datum | |
|---|---|---|---|---|
| In Diskussion Idee für Workflow - Lagerbewertung zum Monatsende an das Steuerbüro | JTL-Workflows - Ideen, Lob und Kritik | 3 |
Ähnliche Themen
-
In Diskussion Idee für Workflow - Lagerbewertung zum Monatsende an das Steuerbüro
- Started by Blaumeise
- Antworten: 3