MÜNCHEN: Je enger die Margen bei Handelsgeschäften werden, desto genauer müssen die Instrumente sein, mit denen IT-Händler die wirklichen Deckungsbeiträge pro Geschäftsvorfall ermitteln. Josef Böck* zeigt auf, womit viele Warenwirtschaftssysteme, die im IT-Handel zum Einsatz kommen, Schwierigkeiten haben.Viele Warenwirtschaftssysteme tun sich schwer, Lagerwertausgleiche, nachträgliche Gutschriften oder einfach fehlerhaft eingebuchte Lieferantenrechnungen kaufmännisch richtig auf die Artikel umzulegen. Die Auswirkungen sind manchmal dramatisch - gerade im Projektgeschäft.
Drei Beispiele verdeutlichen die Mängel:
Beispiel 1: Computerhändler F. hat im Januar 20 PCs vom Hersteller gekauft, von denen 18 für einen Auftrag bestimmt waren. Zwei hat er sich wegen des guten Preis-Leistungs-Verhältnisses auf Lager gelegt. Die Rechnung kam fast zeitgleich mit der Lieferung und wurde in das System eingebucht. Zwei Wochen später kündigte der Hersteller das Modell ab und gewährte allen Händlern, die dieses Modell noch auf Lager hatten, einen Lagerwertausgleich. Händler F. bekam also eine Gutschrift, nachdem er die zwei Stück gemeldet hatte. Das Problem: In seiner Warenwirtschaft konnte er die neuen Einkaufspreise den beiden Artikeln nicht mehr zuordnen. Sein Deckungsbeitrag im Falle des Verkaufs wird deshalb nicht mehr stimmen, denn das Artikelkonto enthält keinerlei Informationen über den nachträglichen Einkaufsvorteil.
Lieferanten schicken falsche Rechnungen
Beispiel 2: Computerhändler L. ist im Projektgeschäft tätig. Er kauft kundenbezogen immer große Lose, beispielsweise von Laptops, legt sie in seinem Lager an ganz bestimmte Plätze, weil jedes Los für jedes einzelne Projekt Sonderpreise enthält und für den jeweiligen Kunden reserviert ist. Mit den Projektpreisen kommen auch die Hersteller und Lieferanten immer wieder durcheinander und schicken deshalb bis zirka 50 Prozent der Rechnungen im ersten Anlauf mit falschen Preisen. 80 Prozent der Fehler werden von Einkauf oder Buchhaltung von L. entdeckt. 20 Prozent werden mit den falschen Preisen eingebucht. Da die Preise fast immer zu hoch sind, wird sein mit jedem Projekt erzielter Deckungsbeitrag damit nicht richtig errechnet - eventuell weist ein Auftrag sogar einen negativen Deckungsbeitrag auf. Nach Entdecken der Fehler in den übrigen Rechnungen erhält L. in der Regel eine Gutschrift, die er jetzt aber auf die PCs des betroffenen Projektes buchen muß, um seine korrekten Zahlen zu haben. Nur wenn sich alle Beteiligten daran erinnern, in welchem Projekt wann welche Preise bekannt und eingebucht wurden, wird ein Projekt realistisch nachkalkulierbar sein.
Beispiel 3: Systemhaus C. hat am Ende des Geschäftsjahres unter anderem noch fünf PCs und zehn Drucker auf Lager, die inzwischen nicht mehr zum Anschaffungspreis verkauft werden können, weil die Herstellerpreise gesunken sind, ohne daß es einen Lagerwertausgleich dafür gegeben hätte. Der Verantwortliche bei C. muß die Geräte abwerten und Einkauf wie Verkauf an den neuen Wert angleichen, sonst werden seine deckungsbeitragsbezogen bezahlten Vertriebsleute die PCs nicht ohne weiteres verkaufen. Kaufmännisch richtig müßte sich die Abwertung auf genau diese 15 Geräte beziehen. Später eingetroffene Produkte vom selben Modell dürften nicht betroffen sein, weil die ja schon zum neuen Preis eingekauft wurden. Ohne rückwirkende Korrektur des Einkaufspreises nur für die 15 Geräte bei gleichzeitiger Buchung der Wertdifferenz zum Beispiel auf ein Lagerverbrauchskonto bliebe das "Verschwinden" von Wert aus dem Lager nicht nachvollziehbar.
Ohne Korrekturen nur grobe Aussagen möglich
In allen drei Fällen ensteht das gleiche Problem: Das jeweils eingesetzte Warenwirtschaftssystem sollte in der Lage sein, den Einkaufspreis für solche Sonderfälle zu korrigieren, um ab dem Zeitpunkt der Änderungen mit den faktischen oder, wie in Beispiel 3, mit den aktuellen Einkaufspreisen kalkulieren zu können. Die nachträgliche Korrektur sollte nachvollziehbar und ausweisbar sein. Viele Lösungen, die vom IT-Handel eingesetzt werden, haben aber mit diesem Punkt Probleme, obwohl solche Korrekturen in der IT-Branche häufig vorkommen. Ein System, das zum Beispiel nur mit durchschnittlichen Einkaufspreisen rechnet, läßt solche Korrekturen nicht zu. Durch ein Ausweisen der Veränderungen auf Sachkonten bekommt man zwar die Veränderungen in seine Erfolgsrechnung, nicht aber in Abhängigkeit vom Artikel. Je größer also die Stückzahlen, die nachträglich korrigiert werden, desto größer die Ungenauigkeit.
Eine mögliche Lösung wäre eine entsprechende Funktionalität im Warenwirtschaftssystem. Diese "Wertberichtigung" würde Korrekturen wie die oben aufgeführten artikelbezogen vornehmen. Händler, die regelmäßig von einem der drei Fälle betroffen sind, sollten in ihrem System eine weitestgehende Automatisierung anstreben, damit sie nicht das ganz Jahr über mit sehr groben Aussagen über ihre Projekte leben müssen.
*Josef Böck ist Geschäftsführer der Singhammer IT Consulting GmbH
in München.
"Viele Warenwirtschafssysteme tun sich mit Lagerwertausgleich schwer."