ODOO EINRICHTUNG / NEUAUFSATZ - Teil 2
Tipps zur Odoo-Einrichtung

4) Modulkonfiguration

Kommen wir zum nächsten Meilenstein im Aufsatz, zur Nachjustierung der installierten Module.

Dabei gehen wir am besten die wichtigsten und meist verwendeten Konfigurationsoptionen pro Hauptmodul durch. Das heißt allerdings nicht, dass alle weiteren Optionen unwichtig sind. Die Anzahl der Konfigurationen, Bedeutungen und Kombinationsmöglichkeiten ist jedoch so groß, dass die Besprechung aller Features jeden Rahmen sprengen würde.

CRM

Wenn man den Prozess betrachtet, gibt es hier eine wichtige Erweiterung, nämlich das Arbeiten mit „Leads“ oder Interessenten. Dabei handelt es sich um eine Vorqualifizierung, d.h. z.B. um das Abrufen von Anfragen an eine Info-Mailadresse, Kontaktanfragen über die Webseite oder um den Import von unqualifizierten Adressen. Sollte dieses Feature aktiviert sein, erscheint eine weitere Option, in der man eine eingehende Mailadresse konfigurieren kann. Darüber hinaus wird Odoo später einen separaten Menüpunkt „Interessenten“ anzeigen, in dem die Bereinigung und Vorqualifizierung durch eine Konvertierung in eine „Verkaufschance“ erfolgen kann.

Sales

Dies ist das erste Modul mit einer sehr umfangreichen Konfiguration. Zum Glück gibt es einige sehr sprechende Optionen oder Punkte, die kleine Zusatzfunktionen freischalten. Aus diesem Grunde gehen wir hier nur auf das Wesentlichste ein.

Varianten

Hiermit kann die Variantenverwaltung von Odoo aktiviert werden. Hier sollte man jedoch etwas vorsichtig sein. Nur weil intern oft von Varianten gesprochen wird, hat man auch gleich ein „Varianten-Problem“. Daher die Frage: Wann sollte man diese Option überhaupt aktivieren?“

Um das zu beantworten, müssen wir uns die Frage stellen, wofür diese Funktion bestimmt ist. Schauen wir uns an, was sich hinter den Szenen abspielt:

Ob aktiviert oder nicht, ist die Produktanlage in Odoo im Kern aufgeteilt in eine Produktvorlage und das Produkt oder den Artikel selbst. In allen Belegen ist nicht die Produktvorlage verknüpft, sondern der Artikel. In der Oberfläche wird im Menü suggeriert, dass hier ein Produkt angelegt wird, doch technisch legt der Nutzer lediglich eine Vorlage an. Dies wiederum bewirkt, dass dazu umgehend ein tatsächliches Produkt generiert wird.

Doch der Übergang ist an sich so fließend, dass man keinen Unterschied merkt, auch wenn keine Varianten aktiviert sind, obwohl die Datenstruktur bereits in der Form vorhanden ist. Mit anderen Worten, auch ohne die Aktivierung der Varianten wird eine Variante verkauft, geliefert, bestellt und verrechnet.

Durch die Aktivierung wird diese Struktur jedoch sicht- und konfigurierbar. D.h., es lassen sich Attribute und Werte definieren, die wiederum die Anlage der Artikel übernehmen. Dabei wird auch die Benennung der Artikel automatisiert.

Ein zweiter wesentlicher Aspekt ist die Integration in das eCommerce Modul. Denn dort werden natürlich nicht die einzelnen Varianten/Produkte angezeigt, sondern die Produktvorlagen, so dass ein Benutzer bei der Suche im Shop nur den gesuchten Artikel findet und seine Suche nicht mit allen Ausprägungen unnötig geflutet wird. Klickt er dann den Artikel an, kann er auf der Detailseite alle Attribute einsehen und sich bequem die gewünschte Variante auswählen.

Fazit

Fassen wir also zusammen: Varianten helfen bei der Produktpflege und bei der Produktsuche. Doch zwingend notwendig ist dieses Feature nicht unbedingt. Werden Produkte z.B. extern über ein PIM gepflegt (wenn es nicht viele Ausprägungen gibt oder kein Shop vorhanden ist), sollte man genau überlegen, ob man es aktiviert, denn damit wird eine Komplexität geladen, die nicht unbedingt wünschenswert ist. Der Export und Import von Odoo ist, wenn man ihn versteht, sehr leistungsstark und lässt Massenupdates und die Pflege in externen Listen gut zu.

Denn wie wir in vielen Blogartikeln bereits deutlich machen wollten, gilt in der IT ein Leitsatz ganz besonders: Weniger ist mehr! Das System bleibt so einfach stabiler, man behält die Übersicht und somit die Kontrolle.

Units of Measure

Auf dieses Feature sind wir bereits in vorherigen und auch im ersten Teil dieses Artikels eingegangen. Es sollte auch nur dann aktiviert werden, wenn eine Übersetzung zwischen unterschiedlichen Einkaufseinheiten zum Verkauf existiert. Rein zur Anzeige der Einheit ist es nicht notwendig.

Price lists

Dies ist eine recht mächtige Funktion von Odoo. Ich kenne aktuell keinen Aufsatz, der ohne ausgekommen ist, was allerdings nicht heißt, dass es ihn nicht gibt. In einem Satz dargestellt geht es bei diesem Punkt darum, den Standardverkaufspreis eines Produkts für Kunden oder Vertriebskanäle anzupassen. Die Funktion gibt es in 2 Varianten, einmal in einer etwas einfacheren Darstellung und Pflege, in der einfach Produkte und deren Preis gesetzt werden. Dabei kann noch mit dem Zeitraum der Gültigkeit gespielt werden. In der etwas erweiterten Variante können Preisregeln angelegt werden, die eintreffen müssen, bevor ein Preis, Discount oder eine Formel zur Berechnung eines Preises greift.

Seitdem ich mit Odoo arbeite, also seit 2007 (als Odoo noch TinyERP 4.2 hieß) gibt es diese Funktion und zwar über sehr viele Jahre nur in der (wie sie heute heißt) „Advanced Version“. Erst mit dem eCommerce Modul hat eine vereinfachte Variante Einzug gehalten. Doch im Kern ist die Berechnung und Komplexität immer gleich, sie wird nur – abhängig von der gewählten Option – einfacher oder komplizierter dargestellt.

Und da ich es seit jeher nicht anders gewohnt bin, fühle ich mich in der Advanced Version zu Hause und installiere auch nur diese.

Abgesehen davon, dass Preislisten, in Kombination mit der Mehrwährungsoption in den Finanzen, auch die Steuerung der Währung zum Kunden übernehmen, können hier Regeln definiert werden, die dann das Setzen eines Festpreises erlauben. So kann man damit z.B. den Preis innerhalb einer anderen Währung bestimmen, um nicht durch einen Wechselkurs einen seltsam erscheinenden Wert zu erhalten, die Eingabe eines Rabattsatzes erlauben oder über eine Berechnung Rabatte, Zuschläge und Auf- und Abrundungen kombinieren.

Als Basiswerte für die Regelsetzung dienen Warengruppen, Hauptartikel (wir haben oben die technische Bezeichnung „Vorlageartikel“ genutzt), Varianten, die dann kombinierbar mit bestellter Menge und einem Gültigkeitszeitraum sind.

Dies lässt sich also auch sehr gut als „preisliche Rahmenbedingung zum Kunden“ nutzen, egal, ob es sich dabei um ein Handelsunternehmen, einen Fertiger oder Dienstleister handelt.

Customer Addresses

Generell ist es möglich, zu Unternehmen und/oder Kontakten untergeordnete Adressen oder Ansprechpartner anzulegen bzw. zu pflegen und diese in Rechnungs- oder Lieferadressen auch zu unterscheiden. Doch bei der Angebots- bzw. Auftragsanlage hat man nicht viel Kontrolle darüber, da nur ein Feld „Kunde“ angezeigt wird und ggf. abweichende Adressen im Hintergrund geladen und verwendet werden.

Wird es also immer maximal eine abweichende Rechnungs- oder Lieferadresse geben – oder vielleicht nur abweichende Rechnungs-, aber keine Lieferadressen, da es sich um eine Dienstleistungsbranche handelt und die Lieferadresse auch im Kommentarfeld des Angebotes hinterlegt werden kann, dann lebt es sich ohne den Haken an dieser Option deutlich einfacher. Andernfalls sollte das Feature unbedingt aktiviert werden.

Sales Warnings

Eine kleine Funktion mit großer Wirkung. Oft wird gefragt, wie kann ich in Odoo z.B. einen Lieferstopp realisieren? Die Antwort ist: mit dieser Funktion.

Denn darüber kann man für einen Kontakt eine Nachricht vom Typ „Warning“ oder „Blocking“ hinterlegen. Die erste Option bewirkt, dass direkt ein Pop-up Fenster mit einem an der Nachricht hinterlegten Text erscheint, sobald ein Angebot für diesen Kunden angelegt wird. Wählt man eine blockierende Nachricht, so erscheint wieder ein vorab konfigurierter Text, doch danach kann kein Angebot erfasst werden.

Diese Funktion ist ebenfalls für Einkauf, Lieferungen, Rechnungen und für Produkte aktivierbar.

Pro-Forma Invoice

Eigentlich muss diese Funktion nicht erklärt werden, da die Benennung mehr als sprechend ist. Proforma-Rechnungen sind Belege, die nicht zur Zahlung auffordern und ein beliebtes Mittel zum Nachweis von Warenwerten für den Zoll, kostenlosen Mustersendungen, Warenaustausch, Ersatzlieferungen und natürlich Vorkassen.

Da es jedoch immer noch Odoo 8 Benutzer gibt, hier eine kurze Erläuterung. In Odoo 8 gab es einen Rechnungs-Workflow über den pro Auftrag festgelegt werden konnte, ob eine Rechnung vor oder nach der Lieferung erstellt werden sollte. Beides hat eine Rechnung generiert. Ein großer Nachteil, denn wenn der Kunde nicht bezahlt hat, musste die Rechnung auch noch ausgebucht werden. Da Workflows ab Odoo 9 abgeschafft wurden, hat man hier zu einem Standardmittel gegriffen.

Dabei wird Angeboten und Aufträgen ein weiterer Belegtyp „Proforma“ hinzugefügt, der unabhängig vom Status jederzeit gedruckt werden kann.

Dazu eine Anmerkung zum Schluss: Sollte hierzu eine Zahlung erfolgen und verbucht werden, wird Odoo direkt nach der Erstellung der Kaufmannsrechnung die nicht ausgeglichene Zahlung erkennen und direkt auf der Rechnung anzeigen, so dass beide Transaktionen schnell und einfach miteinander ausgeglichen werden können und der Vorgang abgeschlossen ist.

Invoicing Policy

Dies ist eine recht wichtige Option, die pro Produkt konfigurierbar ist, so dass Odoo automatisch abrechenbare Auftragspositionen identifizieren kann. Die Einstellung hier setzt lediglich den Standardwert, der bei Neuanlage eines Produktes berücksichtigt werden soll.

Purchase

Auch wenn es hier bei weitem nicht so viele Einstellungsoptionen gibt, wie z.B. im Verkauf, Lager oder den Finanzen, möchte ich nicht auf jeden Punkt eingehen, sondern mich auf die Funktionen fokussieren, zu denen es die meisten Diskussionen gibt und die wir als wesentlich betrachten.

Purchase oder Approval

Sollte nicht jeder bestellen dürfen, es ein 4-Augenprinzip oder Freigabestufen im Einkauf geben, dann wäre dieser Punkt zu aktivieren. Da gerade Freigabestufen kein einfaches Thema sind, bietet Odoo lediglich die Eingabe eines Wertes an, ab dem eine zusätzliche Freigabe einer Managerrolle notwendig ist, um die Bestellanfrage/RfQ in eine Bestellung umzuwandeln.

Dabei stellt sich natürlich zum einen die Frage, was man eingibt, wenn nur die Angabe eines Wertes möglich ist. Und zum anderen, wie bildet man Freigabestufen ohne zusätzliche Programmierung – sprich im Standard – ab?

Zur ersten Frage: Was gebe ich ein, wenn ich mehrere Stufen umsetzen möchte?

Antwort: hier ist natürlich der niedrigste Wert einzugeben, denn ansonsten kann schon darunter direkt bestellt werden, was ja nicht erreicht werden soll.

Im Prinzip sollten die Stufen, wer wann was freigeben darf, nicht ganz unbekannt sein und sollten somit nicht zwangsweise technisch gelöst werden müssen. Die technische Lösung ist also der unterste Schwellenwert, der einen administrativen Benutzer oder eine Managerrolle benötigt. Die Verständigung darüber kann sehr transparent über interne Notizen erfolgen, in dem eine Notiz an einen Manager adressiert wird. (Wie dies im Standard im Detail erfolgen kann, werden wir noch in einem separaten Blog veröffentlichen.) Sollte das Bestellvolumen die Freigabegrenze der Rolle übersteigen, so kann dies über eine weitere Notiz an den nächsten Benutzer weitergegeben werden.

Obwohl dies sehr transparent und nachvollziehbar pro Vorgang dargestellt wird, kann man natürlich hier Bedenken haben. Das Problem lässt sich jedoch dann nur durch eine Programmierung lösen. Allerdings raten wir hier, eine Lösung mit Bedacht zu definieren, denn Technik kann nicht vor Missbrauch schützen, egal in welchem Bereich eines Unternehmens man sich befindet.

Purchase Agreements

Hier handelt es sich wohl um die stärkste und umfangreichste Erweiterung im Einkaufsmodul. Die Lösung ist sehr flexibel und deckt deutlich mehr mögliche Geschäftsvorfälle ab, als man vom Namen her vermuten sollte.

Was genau alles damit gelöst werden kann und für welche Anwendungsfälle das Feature gedacht ist, darauf werden wir noch separat eingehen. Doch bevor wir in ein paar Details gehen, um einen Eindruck zu schaffen, was mit diesem Mittel alles abgedeckt werden kann, schauen wir uns doch einmal die Einstellungsoptionen an, die ein Administrator hat, wenn er Kaufvertragsarten anlegt:


Kaufverträge sind die Klammer von Bestellanfragen (RfQ) und Bestellungen (Purchase Order). Die wesentliche Basis bilden 3 miteinander kombinierbare Optionen, die das Verhalten der Kaufverträge bei der Anlage der Verträge, aber auch bei der Anlage und Zuordnung der Bestellanfragen und Bestellungen steuern.

Auswahltyp

Im „Exklusiven“ Modus können mehrere Bestellanfragen (RfQ) für einen Vertrag generiert werden. Sobald jedoch die erste bestätigt und somit zur Bestellung (Purchase Order) wird, werden alle anderen zugehörigen Anfragen automatisch abgebrochen. Wählt man als Typ die 2. Option, bleiben sie natürlich offen und können ebenfalls bestätigt oder müssen manuell abgebrochen werden.

Zeilen

Wählt man die Option „Vereinbarungspositionen verwenden“, werden die Positionen des Kaufvertrages in die Bestellung übernommen, d.h. Produkt, Produkt-beschreibung und Einzelpreis. Andernfalls startet man leer, und die Bestellpositionen müssen manuell angelegt werden. Dies bedeutet übrigens nicht, dass nicht nachträglich manuell Produkte einer Bestellung hinzugefügt werden können, die nicht Bestandteil des Vertrages waren. Das ist natürlich der Fall.

Mengen

Sollte die Auswahl auf „Vereinbarungsmenge verwenden“ gesetzt worden sein, dann wird entweder in Verbindung mit dem vorherigen Punkt auch automatisch die im Vertrag gesetzte Menge für das Produkt übernommen oder, sobald beim Hinzufügen einer neuen Bestellposition ein Produkt aus dem Vertrag gewählt wird, die jeweilige Menge entsprechend als Standardwert gesetzt.

Falls hier die Option „Menge manuell setzen“ festgelegt wurde, ist der Standardwert bei einem Vertragsprodukt 0 und muss vom Einkäufer selbständig gesetzt werden.

Wenn man nun diese Optionen kombiniert, so kann man nahezu jeden denkbaren Anwendungsfall damit abdecken, wie z.B.

1) Ausschreibung

Ganz simplifiziert läuft eine Ausschreibung nach folgendem Muster ab: ein oder mehrere Produkte müssen beschafft werden. Das Volumen ist groß, demnach werden die Produkte und benötigten Mengen gelistet und an unterschiedliche Kandidaten geschickt. Die Rückmeldungen werden entsprechend erfasst und ausgewertet – ein Kandidat erhält den Zuschlag.

Hierzu legt man eine Kaufvertragsart „Ausschreibung“ an, wählt die Optionen „Exklusiv“, „Vertragspositionen“ und „Menge“ verwenden. Da Verträge ebenfalls eine Freigabe haben, wird die Ausschreibung über die Produkte, deren Beschreibung und Menge zusammengestellt. Theoretisch spricht nichts dagegen, hier sogar schon Werte für Preise zu erfassen, um ein internes Bild über den Umfang der Ausschreibung abzubilden. Diese werden so oder so nicht an die Lieferanten kommuniziert und können somit als Orientierungen genutzt werden.

Wichtig ist, dass natürlich der Lieferant auf dem Kaufvertrag leer bleibt, da dieser aktuell noch nicht feststeht. Nachdem der Kaufvertrag (also die Ausschreibung) von einer Managerrolle freigegeben wurde, erscheint ein Knopf „Anfrage erstellen“. Hierüber werden neue Einkaufsanfragen erstellt, auf denen sämtliche Positionen und deren Menge übernommen werden. Das Feld des Lieferanten bleibt leer, was auch Sinn und Zweck der Übung ist, denn hier ist der neue Kandidat einzutragen.

Die Kommunikation erfolgt somit belegbezogen pro Lieferant getrennt. Vergleiche können über die Pivotansicht ausgewertet werden. Sobald die Bestellanfrage des „Gewinners“ bestätigt wird, werden alle weiteren Anfragen abgebrochen.

Offen ist natürlich, ob es sich hierbei tatsächlich um eine oder mehrere Bestellung(en) handelt oder ob es um eine Ausschreibung oder um einen neuen Rahmenvertrag geht. Der Prozess kann gegebenenfalls leicht angepasst werden.

2) Rahmenvertrag

Standardeinkaufspreise mit Lieferanten sowie die dazugehörigen Staffelungen werden direkt am Produkt gepflegt. Der erste Eintrag in der Liste ist mein bevorzugter Lieferant bzw. meine bevorzugte Staffelung bei meinem Vorzugslieferanten. Doch abhängig von der Größe des Volumens wird zum Standard-EK ein abweichender Einkaufspreis vereinbart. Dies könnte man natürlich ebenfalls am Produkt pflegen, doch dann ist es a) schwer zu unterscheiden, was ist der Standardpreis und was der verhandelte, und b) basiert der Preis auf einer vereinbarte Abnahmemenge, deren Erfüllung ebenfalls auswertbar sein sollte.

Hierzu kann man eine neue Kaufvertragsart anlegen. Entsprechend erlaubt man „multiple Anfragen“, dass weder Positionen noch Mengen übernommen werden sollen.

Wichtig ist natürlich, dass nun – im Gegensatz zur Ausschreibung – im neu angelegten Vertrag der Lieferant gesetzt wird.

Demnach werden Produkte und Mengen nach Bedarf gesetzt oder hinzugefügt. Es können, wie gesagt, natürlich auch nicht im Vertrag gelistete Produkte in die Bestellung aufgenommen werden.

Im Vertrag kann man die bereits bestellte Menge separat zur vereinbarten Vertragsmenge sehen und somit vergleichen.

3) Abrufvertrag

Die Abgrenzung zum Rahmenvertrag ist natürlich schwer, da ein Abrufvertrag nicht viel anders ist als ein Rahmenvertrag. Der wesentliche Unterschied ist jedoch, dass es datumsabhängige Abrufe gibt, die meist sogar recht konkret festgelegt sind.

Hierzu legt man eine neue Kaufvertragsart an, die Einstellungen sollten „multiple Anfragen“ sein und diesmal verwenden wir natürlich die  Positionen. Wenn immer die gleichen Mengen abgerufen werden, sollte man auch die Mengen verwenden, andernfalls macht es mehr Sinn, diese auf manuelle Angabe zu belassen.

Wenn nun ein Vertrag von diesem Typ angelegt wird – auch hier muss natürlich der Lieferant gesetzt werden – kann man direkt über „neue Bestellung“ eine komplette Kopie vom Vertrag als Bestellanfrage anlegen. Hier wird das Datum des Abrufs hinterlegt und die Mengen entsprechend angepasst.

4) Wartungsvertrag

Hier ist nicht ein Wartungsvertrag mit einem Kunden gemeint, sondern man selbst bezieht eine Wartung. Ob dies wirklich als Kaufvertrag angelegt werden muss, ist vielleicht fraglich. Doch wenn es sich um einen wiederkehrenden Beleg handelt, bei dem es durchaus vorkommen kann, dass eine Leistung noch einmal geprüft werden muss, dann kann es durchaus Sinn machen, hierzu einen Kaufvertrag anzulegen. Der Bezug einer Hausmeisterdienstleistung könnte z.B. als Wartungsvertrag angelegt werden. Dabei erlaubt man wieder multiple Anfragen, ver-wendet Position und Menge. Danach legt man für jeden Abrechnungszyklus eine Anfrage an und bestätigt diese.

Nun kommen zwei alternative Prozesse in Frage:

Variante 1)

Es werden dazu gleich schon die Entwurfsrechnungen angelegt. Mit der Buchhaltung kann nun vereinbart werden, dass eine Entwurfsrechnung bestätigt und bezahlt werden kann, wenn sie für den jeweiligen Monat vorliegt. Ist man mit der Leistung des Hausmeisters nicht zufrieden, werden die Entwurfsrechnungen gelöscht.

Variante 2)

Dabei werden Entwurfsrechnungen nicht gleich generiert, sondern erst, wenn die monatliche Rechnung des Hausmeisters eingeht. Mit anderen Worten, ist man mit der Leistung des Hausmeisters nicht zufrieden, muss die Bestellung abgebrochen werden. Somit kann die Buchhaltung bei der Erfassung die Eingangsrechnung keiner Bestellung zuordnen, und es ist klar, dass es ein Problem gibt.

Natürlich ist der Hausmeister nur ein Beispiel, und die Frage, welche Variante die bessere ist, kann nur situationsbedingt beantwortet werden.

Und dies sind nur wenige Beispiele von tatsächlich vielen. Die hier beschriebenen Anwendungsfälle können abhängig von der Situation jedoch leicht abweichend konfiguriert werden, da der Prozess individuell läuft. Dazu darf man nicht vergessen, dass das interne Wording und somit das Verständnis von dem von Odoo abweichen kann. Wie so oft beschrieben, ist dies bei jeder Einführung kein zu unterschätzendes Thema und sicherlich auch komplett system-unabhängig. Dabei muss man jedoch sagen, dass nie ein auf jede Situation passender Begriff gefunden werden kann. Am Ende des Tages zählen schließlich nur die Funktion und das zu erreichende Ergebnis, nicht der Begriff selbst. An diesen kann man sich gewöhnen und ihn in den internen Sprachgebrauch übernehmen.

Drop Shipping / Streckengeschäft

Dies ist zum Glück wieder eine Erweiterung, die recht schnell erklärt ist, wenn dies überhaupt notwendig ist, da die Bezeichnung für sich selbst sprechen sollte.

Hier erlaubt Odoo einen weiteren Belegtyp im Lager, nämlich das Streckengeschäft, das die Lieferung vom Lieferanten direkt an den Kunden symbolisiert. Dabei wird allerdings der Prozess ein wenig abgewandelt.

Normalerweise wird nach Bestätigung eines Angebots die Auslieferung angelegt und terminiert, so dass der Vorgang in die Bedarfsermittlung einfließen kann. Die Aktivierung des Streckengeschäfts erfolgt entweder pauschal am Produkt oder pro Auftragsposition. Für jedes Produkt oder jede Auftragsposition wird nun eine Bestellanfrage an den jeweiligen Lieferanten erstellt. Erst wenn diese bestätigt und damit zur Bestellung wird, wird ein Streckenlieferschein generiert, der dann auch am Auftrag sichtbar bzw. von diesem aus zugänglich ist.

Im Falle von Handelsunternehmen aktiviere ich dieses Feature grundsätzlich, da es in den meisten Fällen zumindest als Ausnahme vorkommt.

8 Juni, 2020
artikel teilen
kategorien
Bearbeiten
Archiv
Anmelden to leave a comment
MEHRWERTSTEUER-ÄNDERUNG IN ODOO
“Eilblog” – ein kleines How-To
Top