GENERELLE FEHLER IN DER STAMMDATENPFLEGE

Was man dazu wissen muss

Der Odoo Prozess funktioniert sehr effizient und sehr zuverlässig, wenn die Stammdaten gut angelegt und richtig gepflegt werden. Dies betrifft hauptsächlich Produkte und Partner (Partner können als Kunden und Lieferanten gekennzeichnet werden). Produkte sind zwar deutlich komplexer zu verwalten, dennoch ist dies hier tatsächlich einfacher, denn das Berechtigungs-Konzept sieht vor, dass nur bestimmte Benutzergruppen Artikel anlegen und ändern dürfen, der Rest darf sie nur lesen. Beim Partner sieht es schon anders aus, denn im Prinzip kann und muss jeder einen Partner (hauptsächlich einen Kunden) anlegen können.

Hier ein paar typische Beispiele:

Konvertierung eines Interessenten in eine Verkaufschance

Der Kunde stellt eine Anfrage per Email, Odoo holt diese Anfrage aus einer generischen Mailbox ab, beispielsweise info@, und wandelt sie in einen Lead um. Dabei sind die Daten flach hinterlegt. Beispiel von runbot.odoo.com mit Demodaten:


Hier wird nichts verlinkt dargestellt, da es keine Verknüpfung gibt. Dies macht in diesem Fall auch Sinn, da auf Info-Adressen gelegentlich SPAM geschickt werden.

Die Konvertierung des Interessenten zu einer Verkaufschance bietet die Anlage des Kontaktes an. Dies macht wiederum auch Sinn, denn die Anfrage wurde qualifiziert und der Kontakt sollte im Unternehmen bekannt sein. Im Zweifel meldet er sich bei einem anderen Mitarbeiter, der ihn und die Anfrage finden sollte, das Telefonat protokolliert und womöglich einen Hinweis an den Vertrieb hinterlassen möchte.

Hier die Optionen zur Qualifizierung:


Danach existiert der Kontakt, was an der Darstellung des Namens als Link erkennbar ist:


Nun haben wir bereits einen Partner angelegt, der als Kunde markiert wurde, und der nächste Schritt hin zu Angebot und Auftrag ist hoffentlich nicht mehr weit entfernt. Damit dieser Vorgang jedoch schnell und stufenlos vonstattengeht, muss der normale CRM- bzw. Vertriebs-Nutzer die Berechtigung haben, Partner bzw. Kunden direkt anlegen und natürlich auch verändern zu können.

Kontakt schreibt an den Helpdesk, jemand muss antworten

Hier geht es um fast das gleiche Problem wie im CRM: ein Kunde schreibt an ein Support Team, die Mail wird in ein Ticket umgewandelt. Dann wird der Kunde, wenn bekannt, zugewiesen oder, wenn nicht bekannt wie in unserem Beispiel, namentlich hinterlegt:


Doch nun möchte ich antworten:


Gemäß dem Benachrichtigungs-Prinzip muss nun der Empfänger als Follower am Vorgang hinterlegt werden. Dazu benötigt Odoo natürlich einen Partnerdatensatz und bittet mich, diesen entsprechend anzulegen:


Speichere ich, wird der „Kunde“ angelegt und die Nachricht verschickt. Und schon haben wir einen Datensatz mehr. Damit dies von einem normalen Benutzer durchgeführt werden kann, muss der Partner quick & dirty angelegt werden können, und das von jedem normalen Benutzer im Helpdesk.

Natürlich könnte man dies verhindern, aber hier sind wir genau in der Mitte zwischen Fluch und Segen!

Würde sich der Kontakt auf der anderen Seite telefonisch melden oder eine Anfrage per Email senden, wäre er bereits bekannt, die Verknüpfung würde automatisch generiert oder könnte generiert werden und die Verlinkung zum bereits erfolgten Support wäre sofort gegeben und transparent abrufbar. Wer möchte das verhindern?

Kontakt eines Unternehmens stellt eine Anfrage, ein Angebot muss erstellt werden

Ein Mitarbeiter eines Unternehmens, das bereits bekannt ist, ruft an oder bittet per Email um ein Angebot. Dies soll ohne weiteren Aufwand erfasst und versendet werden können. Dazu muss der Benutzer in der Lage sein, in einem neuen Angebot direkt einen neuen Kontakt innerhalb des Unternehmens anzulegen.

In alten Odoo Versionen waren Unternehmen und Kontakte getrennt gepflegt, hier wäre es möglich gewesen, unterschiedliche Berechtigungsstufen einzubauen. Doch da ein Kontakt ebenso wie ein Unternehmen ein Partner sein kann, der Kontakt jedoch dem Unternehmen zugeordnet wird, ist es schwer zu sagen, nicht jeder darf ein Unternehmen anlegen, einen Kontakt aber schon. Und was, wenn es eine Privatperson wäre, die ein Angebot anfragt?

Folglich sollte für jeden eine Neuanlage möglich sein.

Weitere denkbare Fälle

  • Ein neuer Kunde identifiziert sich über den Shop und generiert eine neue Bestellung → auch dieser Weg ist möglich, in diesem Fall muss der Gast sogar selbst in der Lage sein, sich anlegen zu können, ansonsten wäre nicht einmal ein Warenkorb möglich.
  • Im Rahmen einer Dienstleistung, deren Preise bekannt sind, soll eine Rechnung ohne einen Auftrag geschrieben werden.

Fazit

Fakt ist, das Odoo als Applikation die Intention hinter einer Datenerfassung nicht erkennen kann, daher muss eine Anlage generell erlaubt sein. Außerdem bietet dies den bereits beschriebenen Mehrwert, dass ein Kontakt dadurch schon recht früh erfasst wird und sich bei richtiger Anwendung schnell ein umfassendes Wissen über alle bekannten Vorgänge aufbaut.

Das Gefahrenpotential

Das hat natürlich seinen Preis, denn die schnelle Anlage erfolgt üblicherweise mit Standardwerten. Der Kunde stellt jedoch eine zentrale Information dar, egal, wo die Erstanlage erfolgt. Denn neben der Preisliste und der darin enthaltenen Vorgabe für die Währung, sind auch alle anderen buchhalterisch relevanten Vorgaben hinterlegt, wie die Steuerzuordnung, das Debitoren- oder ggf. das Kreditoren-Konto und die Zahlungsbedingung.

Die typischen Fehler

Im Folgenden finden Sie eine vermutlich bei Weitem nicht vollständige Liste an typischen Fehlern mit dann doch gravierenden Auswirkungen:

Rechnungsadresse

Es kommt sicher gelegentlich vor, dass es bei einem großen Unternehmen mit mehreren Tochtergesellschaften Verwirrung bei der Rechnungsadresse gibt. Wir erinnern uns an den Blog zum Thema Datev: Odoo arbeitet mit einem versteckten Feld „Commercial Partner“ bzw. „gewerbliche Einheit“.

Wird ein Unternehmen angelegt, so ist der Wert des Commercial Partners die eigene Datensatz ID. Legt der Benutzer einen Kontakt oder eine abweichende Adresse an, entspricht der eingetragene Wert der Datensatz ID der übergeordneten Information, in diesem Fall der Wert des Unternehmens. Unabhängig davon, dass dies natürlich auch in Berichten verwendet wird, hat es auch einen direkten funktionalen Aspekt, denn bei der Anlage einer Rechnung und der Zuweisung einer abweichenden Rechnungsadresse wird im Buchungssatz die Forderung genau diesem Commercial Partner zugewiesen, was übersetzt dann heißen würde: nicht der Kontakt ist der Debitor, sondern das Unternehmen.

Würde nun jemand die Rechnungsadresse einem anderen Unternehmen zuordnen, warnt Odoo:


Denn es geht nicht nur um die Rechnung. Die Vorgänge, die an einem Kontakt hängen, würden so einem anderen Unternehmen zugeordnet werden, was sicherlich mehr als fatal wäre! D.h., wie in der Meldung beschrieben, sollte der alte Kontakt deaktiviert und im neuen Unternehmen ein neuer angelegt werden.

Im Fall der Rechnung gäbe es sogar noch einen weiteren unangenehmen Aspekt. Denn würde der Benutzer dies tatsächlich so abspeichern, wäre die Rechnungsadresse nun einem neuen Unternehmen zugeordnet. Die Forderung jedoch wäre natürlich nicht „umgezogen“, da im Buchungssatz unverändert die Zuweisung an den vorherigen Commercial Partner erfolgt ist. Dies führt bei der Verbuchung einer Zahlung zu einer Fehlermeldung, die darüber informiert, dass die Konten nicht übereinstimmen. In diesem Fall ist gemeint, dass Odoo bei der Erfassung versucht, das Debitoren-Konto des neuen Unternehmens in den Buchungssatz der Zahlung zu schreiben und beim Ausgleich feststellt, dass das Debitoren-Konto der Forderung nicht mit der Zahlung übereinstimmt und somit ein Ausgleich unmöglich ist.

Dies lässt sich nur sehr schwer wieder lösen, da gebuchte Buchungen ebenfalls unantastbar sind.

Unternehmen im Unternehmen

Auch wenn die Maske zur Anlage und Pflege von Kontakten und Unternehmen auf den ersten Blick andeutet, dass nur zwei Ebenen erlaubt sind, würde die gewählte Struktur tatsächlich eine unendlich tiefe Verschachtelung erlauben, denn Odoo speichert in einem separaten Feld die Information des darüber liegenden Datensatzes.

Die Gründe dafür, warum dies eingeschränkt wurde, kann man zwar nur vermuten, liegen jedoch nahe:

Die Ermittlung würde so sehr schwierig und ggf. ist die Forderung auf der falschen Ebene hinterlegt. Man stelle sich zwei mögliche Konstrukte vor, die der Benutzer angelegt hat:

  1. Unternehmen, Abteilung, Kontakt
  2. Muttergesellschaft, Tochtergesellschaft, Kontakt

Theoretisch könnte man sich natürlich noch abweichende Adressen und Niederlassungen dazwischen denken, doch diese im Vergleich recht einfache Kette reicht schon, um die Schwierigkeit darzustellen. Denn in Variante 1 müsste die Commercial Partner ID auf Ebene 2 und 3 die von Ebene 1 sein, bei Variante 2 hingegen Ebene 2 und 3 den gleichen Commercial Partner haben und Ebene 1 in sich eigenständig sein und somit einen eigenen Commercial Partner darstellen. D.h. die Logik zum Erkennen der richtigen Logik wäre so komplex und abhängig von so vielen anderen Informationen, dass die Fehlerwahrscheinlichkeit sehr hoch wird, denn nichts ist fehlbarer als der Mensch.

Die richtige Adresse

Hinzu kommt, dass es nahezu unmöglich ist, ein richtiges Adress-Etikett zu drucken, wenn es unterschiedlich viele Ebenen gibt. Denn wenn wir uns die vorherigen beiden Beispiele anschauen, dann würde in Beispiel 1 Ebene 1 und danach Ebene 3 gedruckt werden müssen, in Beispiel 2 jedoch Ebene 2 und Ebene 3.

Auch hier würde der Programmcode so komplex werden, dass nach der Fertigstellung nur der Programmierer und Gott wissen, was passiert, und bei einer schlechten Dokumentation (die wohl die wahrscheinlichste Variante ist) nach kurzer Zeit auch der Programmierer nicht mehr zu den Wissensträgern gehört.

Steuerzuordnung

Die Steuerzuordnung ist ebenfalls eine zentrale Information in Odoo, denn der Steuersatz am Produkt und die Steuerzuordnung am Kunden werden als Standardsteuerzuordnung dem Angebot bzw. der Rechnung zugewiesen. Abhängig von der Konfiguration kann Odoo dies anhand des Landes in der Lieferadresse nachträglich ändern oder den Wert beibehalten. Doch innerhalb der Steuerzuordnung ist die Steuerkonsequenz definiert. Beispiel: ein Partner wurde als „Kunde EU mit USt-ID“ konfiguriert, da der Kunde in Frankreich ansässig ist und eine Lieferadresse beim Kunden vor Ort gewählt wurde. Für diesen Partner wird ein Angebot mit einem Produkt angelegt, das einen Steuersatz von 19% zugewiesen hat. Nun wandelt Odoo die 19% in „innergemeinschaftliche Lieferung“ um.

Nicht nur bei einem Unternehmen mit Niederlassungen im In- und Ausland und internationalen Kunden ist die Steuerzuordnung ein Thema, sondern auch für kleinere Szenarien. D.h. die Steuerzuordnung und die Konfiguration der Buchhaltung sollten gut abgestimmt sein. Da das Thema jedoch komplex ist, sollte man nicht alles der Maschine überlassen. Der Benutzer muss bereits bei der Angebotsanlage darauf achten, denn ein falscher Wert weißt die falschen Steuern aus und überträgt sich somit auch schnell auf die Rechnungserstellung.

Was also kann man tun?

Das Wichtigste ist auch hier: schulen und sensibilisieren. Bei richtiger Anwendung ergeben die Stammdaten einen guten Effizienzfaktor, bei falscher Anlage entsteht nicht nur Mehrarbeit durch die erforderliche Bereinigung, auch die Auswertungen stimmen nicht. Das System wird so schnell in Frage gestellt und erleidet einen Vertrauensverlust, obwohl es nur um einige wenige nicht beachtete Punkte geht. Falsche Stammdaten sollten ebenfalls umgehend bereinigt werden und nicht nur der Beleg, in dem die Fehler auftauchen.

Wir werden unsere Sammlung an einschlägigen Beispielen fortsetzen, sobald wir neue, typische und verzwickte Fälle entdecken.

9 April, 2019
artikel teilen
kategorien
Bearbeiten
Archiv
Anmelden to leave a comment
WIE DIE IT SO TICKT
oder die Frage, warum weniger mehr ist
Top