Skip to main content

Hallo zusammen,

ich habe das Thema schon ein paar Mal mit unterschiedlichen Ansprechpartnern seitens Xentral sowie Xentral-Partnern besprochen.
Mich interessiert wie ihr, als Community, zu dem Thema steht.

Ich versuche einmal, dieses doch sehr komplexe Thema, zusammen zu fassen.
Wenn ich etwas falsch verstanden habe oder erkläre, bitte ich gerne um Korrektur.

Xentral kann einen kalkulierten Einkaufspreis für Artikel errechnen.
Diese Berechnung erfolgt auf Grundlage der Bestellmengen und Preisen aus abgeschlossenen Bestellungen.
Dieser Durchschnittswert verändert sich dann nach dem First-in-First-out Prinzip.

Diese Art der Berechnung kann je nach Branche / Lieferverhalten der Lieferanten, zu Problemen führen:

Eine Bestellung wird erst dann abgeschlossen, wenn die gesamte Ware geliefert wurde.
Wenn also 90% der Ware bereits nach 3 Werktagen eintrifft und die restlichen 10% eine Lieferzeit von X Monaten hat, wird in der Zwischenzeit kein neuer EK errechnet.

Der Wert wird anhand des Preises aus der Bestellung errechnet. Sollte auf der Rechnung ein anderer Preis für den Artikel stehen, wird dieser nicht berücksichtigt.

Selbst bei abgeschlossenen Bestellungen, findet die Berechnung anhand der Bestellmengen und nicht der gelieferten Mengen statt. Wurde eine Position also nicht vollständig geliefert (weil nicht mehr verfügbar z.B.) und man schließt diese Bestellung trotzdem ab, wird trotzdem mit der Bestellmenge gerechnet.

Wer also nicht immer alles sofort geliefert bekommt und in Rechnungen mal einen Abweichenden Preis hat, hat im System keinen korrekten Lagerwert.
Je größer die Schwankungen in den Einkaufspreisen sind, desto größer wird dieses Problem.


Meine derzeitige (langfristig nicht zufriedenstellende Lösung) sieht wie folgt aus:
Laut HGB §240 Absatz 3, kann man den Inventarwert mit einem Gewogenen Durchschnitt errechnen.

Ich nutze also einen Report der alle gelieferten Mengen der Bestellungen (im Zeitraum X-Y) ausliest.
Diese Mengen werden mit dem Einkaufspreis aus der dazugehörigen Bestellung multipliziert.
Aus allen Bestellungen / gelieferten Mengen wird dann der gewogene Durchschnittswert errechnet.
Hierbei ist der Status der Bestellung irrelevant. Wichtig ist nur die gelieferte Menge.
Alle diese Informationen hat das System, ich lasse alles von einem Report errechnen.
Diese Werte spiele ich dann über einen Import zurück in die Xentral Datenbank (Artikel, kalkulierter EK) ein.
Somit kann die Lagerbestandsberechnung mir einen realistischen Lagerwert anzeigen.

Für mich ist dies ein sehr großer Aufwand um etwas doch so essentielles abzubilden.
Habt ihr dieses Problem auch? Wenn ja, habt ihr es anders gelöst als ich?
Wenn nein, wieso habt ihr das Problem nicht?

Meine Lösung funktioniert nur so lange, der Preis in den Bestellungen auch dem Preis in der Rechnung entspricht.
Hier Differenzen zu finden, ist auch nur manuell möglich.

Weitere Probleme entstehen durch die Nachvollziehbarkeit von Bestellten/gelieferten/abgerechneten Warenlieferungen:
Ganz konkret bekommen wir zu einer Bestellung 5-50 Lieferscheine.
Jeder Lieferschein resultiert in einer Rechnung.
Xentral bietet keine Möglichkeit einem Wareneingang eine Lieferscheinnummer zu hinterlegen, geschweige denn, eine Verbindlichkeit auf einen konkreten Wareneingang zu beziehen.

Wäre dies möglich, könnte man nicht nur gelieferte und berechnete Mengen vergleichen, sondern auch Preisdifferenzen zwischen Bestellung und Verbindlichkeit ausweisen.
Gibt man diese Preisdifferenzen als „gerechtfertigt“ Frei, so sollte auch der Durchschnittliche EK anhand der Verbindlichkeit neu errechnet werden.

Ich hoffe, ich konnte das Thema einigermaßen verständlich darstellen und freue mich auf eure Meinung / euer Feedback dazu.

 

Gruß

Niels

Moin @niels.jakobs ,

ich befürchte, dass euer Fall bei der ursprünglichen Programmierung nucht bedacht wurde. 

Um diese Lagerbewertung korrekt abbilden zu können, müsste entweder sehr viel an der jetzigen Logik geändert werden oder die Gesamte art der Lagerbewertung auf einzelne Lagerobjekte, die durch den Wareneingang erzeugt werden, ersetzt werden. 

Diese Objekte würden dann den Preis aus der Bestellung erhalten. Über das Buchen der Rechnung muss dieser Werz dann für den entsprechenden Wareneingang korrigiert werden (z. B. wg. Bezugsnebenkosten).

Das müsste auf jeden Fall mal auf die Roadmap!.

Andere (Systeme sind hier deutlich besser aufgestellt. 

Wie seht ihr das?

 

@Max_P @niels.jakobs 

Da bin ich ganz bei euch.

Wir führen die Berechnung des tatsächlichen Einkaufspreises in einem externen Programm durch (Excel) und importieren dann den Wert in Xentral.

Besser wäre natürlich, wenn das ERP schon die Möglichkeit bieten würde, alle anfallenden Nebenkosten, Umrechnungskurse etc. passend zum jeweiligen Wareneingang zu erfassen.

Aber es wird ja noch nicht mal der Wareneingang mit einer Bestell Position verknüpft. Aus meiner Sicht müsste gesamte Bereich Bestellwesen/Lagerbestandsbewertung überarbeitet bzw. neu und richtig gebaut werden. 

@HB3 ,wahrscheinlich muss dann aber alles, wad mit dem Lager zusammen hängt neu gemacht werden.

Das dürfte dann ein Mammutprojekt werden. 

@Max_P @niels.jakobs 

Da bin ich ganz bei euch.

Wir führen die Berechnung des tatsächlichen Einkaufspreises in einem externen Programm durch (Excel) und importieren dann den Wert in Xentral.

Besser wäre natürlich, wenn das ERP schon die Möglichkeit bieten würde, alle anfallenden Nebenkosten, Umrechnungskurse etc. passend zum jeweiligen Wareneingang zu erfassen.

Aber es wird ja noch nicht mal der Wareneingang mit einer Bestell Position verknüpft. Aus meiner Sicht müsste gesamte Bereich Bestellwesen/Lagerbestandsbewertung überarbeitet bzw. neu und richtig gebaut werden. 

Dann habt ihr, genau wie wir, einen Workaround dafür gebaut.
Korrekt, die Verknüpfungen auf Positionsebene zwischen Bestellung, Wareneingang und Verbindlichkeit müssten gegeben sein. 
Zusatzkosten (Versand usw.) gehören meiner Meinung nach nicht in den Lagerwert und müssen in der Verbindlichkeit auf andere Konten gebucht werden.
 

Moin @niels.jakobs ,

wenn du den Lagerwert für die Buchhaltung brauchst (Bestandsverändwrungen, Inventarbewertung) müssen die Bezugskosten enthalten sein.

§ 255 Abs. 1 HGB ist da eindeutig. 

Ohne diese ksnn es sein, dass ein Steuerprüfer davon ausgeht, dass die Werte künstlich gering gehalten werden um den Gewinn uns damit die Steuer zu senken.

Das kann dann auch fix als Steuerhinterziehung ausgelegt werden. 

Hallo Max,

guter Einwand, also noch etwas, dass man bei einer Programmierung beachten müsste.

Gruß

 

@niels.jakobs Hi Niels,

 

wir hatten das Problem bzgl. der Lagerwerte ebenfalls und haben für uns den folgenden Weg:

 

Sobald eine Bestellung geliefert wird lagern wir über diese ein und schließen die Bestellung ab. Sobald die Bestellung abgeschlossen wurde, wird der kalk. EK im ARtikel aktualisiert. Hier muss natürlich der EK Preis stimmen bzw. angepasst werden.

 

Auch bei einer Teillieferung gehen wir diesen Weg, nur öffnen wir die Bestellung nach dem abschließen umgehend wieder für eine Nachlieferung. Somit wurde der Lagerwert aktualisiert und es kann nachgeliefert werden.

 

Ja es bleibt das Problem mit den Bezugsnebenkosten, die auf die einzelnen ARtikel nicht gerechnet werden, da gehen wir aber den manuellen WEg und rechnen dies am Ende auf den Lagerwert auf.

 

Gruß, Daniel

Hallo zusammen,

 

wir müssen uns auch eine eigene Lösung bauen, weil simple Dinge wie die Verknüpfung von Einkaufspreis mit Wareneingang / Bestellung nicht korrekt funktionieren wie @HB3 berichtet.

Schade, da hätte ich mir von einem ERP System auch mehr erwartet. Zumal die Daten dazu vorhanden sind.

Moin @Julius Michel ,

ich finde es auch schade. 

Vor allem, weil die Bewertungen den realeb Prozessen entsprechen müssen. 

Nucht alle können klar nach FIFO arbeiten. 

Daher sollte es hier die Wahlmöglichkeiten FIFO, LIFO, einfacher Durchschnitt und gewichteter Durchschnitt gebem.

So sehe ich das zumindest. 

Antworten


Allgemeine NutzungsbedingungenCookie-Einstellungen