Zum Hauptinhalt springen

Warengruppen, Bewertungmethoden, Bestandskonten

Warengruppen konfigurieren: Bewertungsmethoden und Bestandskonten für Waren und Materialien zuweisen und Bestandspreise automatisch berechnen.

Bewertungsmethoden und Bestandskonten in Warengruppen

1. Übersicht und Prozessdarstellung

Über die Warengruppen ordnen Sie Produkten der Produktarten Ware und Material wichtige buchhalterische Eigenschaften zu. Die folgende Darstellung zeigt den grundlegenden Prozessablauf:

Warengruppe

|

├─> Bewertungsmethode (einmalig festgelegt)

| |

| └─> Bestandspreis-Berechnung

| |

| ├─> Warenbewegungen (Bestellung, Wareneingang, Rechnung)

| └─> Aktualisierung Bestandspreis pro Produkt

|

└─> Bestandskonten

|

├─> Bestandskonto

└─> Bestandsveränderungskonto

|

Die Konfiguration kann auf der obersten Ebene für alle Waren oder für einzelne Warengruppen unterschiedlich gestaltet werden.

image-20240927-085022.png

2. Bewertungsmethoden

2.1 Grundlagen der Bewertungsmethoden

Bewertungsmethoden dienen der korrekten Abbildung der Kosten, um somit Erträge und Umsätze immer in die gewünschte Relation setzen zu können.

Wichtiger Hinweis: Die Bewertungsmethode kann nach initialer Anlage eines Produktes nicht mehr verändert werden!

2.2 Verfügbare Bewertungsmethoden

Aktuell können Sie zwischen drei verschiedenen Bewertungsmethoden wählen:

  • Gleitender Durchschnitt

  • First in, First out (FIFO)

  • Last in, First out (LIFO)

2.3 Bestandspreis-Berechnung

2.3.1 Automatische Berechnung durch Warenbewegungen

Durch die Warenbewegungen aus Bestellung und Wareneingang errechnet Scopevisio gemäß Bewertungsmethode den Bestandspreis für jedes einzelne Produkt. Dieser sorgt stets dafür, dass auf allen Produkten im Feld Bestandspreis die korrekten Kosten berechnet werden.

2.3.2 Bestandspreis bei neu angelegten Produkten

Neu angelegte Produkte erhalten bis zur ersten Lagerbewegung als Bestandspreis den Einkaufspreis aus der Lieferanten-Preis-Tabelle, der des Standard-Lieferanten oder der des ersten gültigen sonstigen Lieferanten. Dies erfolgt, um unabhängig von der Tatsache, ob das Produkt bereits gekauft worden ist, eine Grundlage für die Kalkulation von Verkaufspreisen auf Produkten, Angeboten und Aufträgen zu haben.

2.3.3 Bestandspreis bei Stücklisten

Bestandspreise in Produkten, die sich aus einer Stückliste zusammensetzen, werden summiert.

2.4 Verwendung der Bestandspreise

2.4.1 Anzeige in Angeboten und Aufträgen

Bestandspreise der Produkte werden ebenfalls in Angeboten und Aufträgen angezeigt und können somit eine Kalkulation von kumuliertem Bestandspreis zu Verkaufspreis darstellen. Damit ist eine Aussage zu Erträgen eines einzelnen Auftrages und Angebotes auf Zeilenebene einzelner Produkte möglich. Dies setzt eine saubere Datenpflege voraus.

2.4.2 Auswertung und Berichtswesen

Insgesamt lassen sich Bestandspreise über Datenquellen auslesen, um im Berichtswesen verwendet zu werden. Typische Berichte wären hier:

  • Ertrag pro Produkt

  • Ertrag pro Kundenauftrag über Zeit

  • Bestandspreis zu Verkaufspreisen über Zeit

  • Mengen-Produkt-Umsätze zu Wareneinsätzen

3. Buchungskonten

3.1 Konfiguration der Buchungskonten

Für alle Warengruppen oder eine einzelne Warengruppe pflegen Sie die Buchungskonten als kontextspezifische Regelliste unter

Buchungskonten (Kontextspezifisch).

Jede Zeile der Liste ist eine Buchungsregel mit fünf Angaben:

Spalte

Bedeutung

Kontonummer

Das zu bebuchende Konto aus Ihrem Kontenrahmen.

Kontotyp

Rolle des Kontos in der Buchung — Bestand, Bestandsveränderung oder Aufwand.

Buchungsart

Bewegungsrichtung — Einbuchen, Ausbuchen, Umbuchen von, Umbuchen zu.

Buchungskontext

Produktart, für die die Regel gilt. Leer = für alle Produktarten.

Dokument

Dokumentenart, für die die Regel gilt — z. B. Wareneingang, Lieferung, Kommissionierung, Inventur. Leer = für alle Dokumentenarten.

Die Konten erwarten wir entsprechend des in Ihrem Mandanten verwendeten Kontenrahmens (SKR03, SKR04 oder kundenspezifischer Kontenplan) und müssen Teil des aktuell gültigen Kontenrahmens sein, um hier gesetzt werden zu können. Ohne Konten kann keine Lagerbewegung erzeugt werden.

3.2 Die drei Kontotypen

Bestandskonto. Auf dem Bestandskonto wird der Wert des Lagerbestands geführt. Bei jeder Lagerbewegung wird das Bestandskonto angesprochen. Mindestens ein Bestandskonto ist zu setzen — ohne hinterlegtes Bestandskonto kann keine Lagerbewegung gebucht werden.

Bestandsveränderungskonto. Standard-Gegenkonto zum Bestandskonto. Es bildet Lagerbewegungen wertneutral ab — als reine Verschiebung zwischen Konten, ohne die Bewegung zu qualifizieren.

Aufwandskonto. Alternatives Gegenkonto zum Bestandskonto. Es wird verwendet, wenn die Lagerbewegung direkt als betrieblicher Aufwand sichtbar werden soll — typische Anwendungsfälle:

  • Bei Kommissionierung: Wareneinsatz Küche, Wareneinsatz Bar.

  • Bei Bedarfsanforderung: interner Aufwand Housekeeping, Aussendienst

  • Bei Inventurabbuchung: Schwund, Verlust, Verbrauch

Aufwands- und Bestandsveränderungskonto schließen sich pro Buchung aus — pro Lagerbewegung wird genau ein Gegenkonto zum Bestandskonto angesprochen. Welches, ergibt sich aus der Regelliste.

3.3 Welche Regel für eine Buchung greift

Bei jeder Lagerbewegung wählt das System die passende Regel anhand der Spezifität: es gewinnt die Regel mit den meisten zur Buchung passenden, gefüllten Kriterien. Je vollständiger Sie die Regelliste pflegen, desto weniger manuelle Nacharbeit entsteht im Buchungslauf — Wareneinsatz, Schwund oder Aufwand werden direkt auf das gewünschte Konto gebucht. Einmal spezifiziert, fortlaufend gebucht — automatisch und ohne Nacharbeit.

  • Eine Regel ohne Buchungskontext und ohne Dokument ist die allgemeine Default-Regel. Sie greift, wenn keine speziellere Regel passt.

  • Eine Regel mit gefülltem Buchungskontext greift, sobald die Produktart der Warengruppe diesem Kontext entspricht, und überschreibt damit die Default-Regel.

  • Eine Regel mit gefülltem Dokument greift, sobald die Buchung aus dem entsprechenden Dokumenttyp stammt, und überschreibt die Default-Regel ebenfalls.

  • Eine Regel mit gefülltem Buchungskontext und gefülltem Dokument ist am spezifischsten und gewinnt gegen einseitig gefüllte Regeln.

Bestandskonto und Gegenkonto werden unabhängig voneinander aufgelöst. Für das Gegenkonto entscheidet zusätzlich der Kontotyp.

Beispiel. Eine Warengruppe der Produktart RHB enthält folgende Regeln:

Konto

Kontotyp

Buchungsart

Kontext

Dokument

3980

Bestand

Einbuchen

3950

Bestandsveränderung

Einbuchen

0978

Aufwand

Ausbuchen

Inventur

3970

Bestand

Einbuchen

RHB

3955

Bestandsveränderung

Einbuchen

RHB

Bei einem Wareneingang in dieser Warengruppe greifen 3970 als Bestandskonto und 3955 als Gegenkonto — beide RHB-spezifisch, die allgemeinen Regeln 3980 und 3950 werden überschrieben. Bei einer Inventurabbuchung greift 0978 als Aufwandskonto, weil die Inventur-Regel die allgemeinste Bestandsveränderungs-Regel dominiert. Das passende Bestandskonto für die Ausbuchung wird aus der Einbuchungs-Regel der betroffenen Bestände abgeleitet.

3.4 Wirksamkeit von Kontenänderungen

Die Wirksamkeit einer Kontenänderung unterscheidet sich nach Kontentyp:

Bestandskonto. Änderungen werden erst mit der nächsten positiven Wareneingangsbuchung wirksam. Hintergrund: Werte können nicht von einem Konto abgebucht werden, auf dem keine Bestände ausgewiesen werden. Bestände, die vor der Änderung eingebucht wurden, werden weiterhin gegen das frühere Bestandskonto ausgebucht, bis sie das Lager verlassen haben.

Bestandsveränderungskonto und Aufwandskonto. Änderungen sind ab dem Zeitpunkt der Speicherung wirksam. Neue Buchungen referenzieren ab dieser Sekunde die aktuelle Regelliste.

Ausbuchung. Bei einer Ausbuchung wird grundsätzlich die zum Zeitpunkt der Ausbuchung aktuelle Regelliste verwendet. Existiert für die Konstellation keine aktuelle Regel, greift als Fallback die Konfiguration, die zum Zeitpunkt der Einbuchung des betroffenen Bestands gültig war.

Wichtiger Hinweis: Eine Konsistenzprüfung der eingegebenen Konten findet nicht statt. Die buchhalterische Korrektheit der Kontenzuordnung liegt in der Verantwortung des konfigurierenden Anwenders.

Hat dies deine Frage beantwortet?