Skip to content

Doku Konfigurations Checkliste

Claudia Schreiber edited this page Mar 5, 2017 · 38 revisions

Status: In Erarbeitung

Inhaltsverzeichnis:

Einleitung

Abwesenheiten ja oder nein?

Preise sichtbar/relevant? (Produktepreise)

Preise editierbar oder nicht? (Produktepreise)

Preis pro Lieferung, Zielpreis und Admin-Anteil

Abotypen und Vertriebstypen

Einleitung

OpenOlitor ist nicht auf eine spezifische Form der regionalen Vertragslandwirtschaft oder der Direktvermarktung in Abonnementsform ausgerichtet, sondern hat zum Ziel, eine grosse Diversität von Initiativen administrativ abzubilden:

  • Verein oder andere Organisationform, der/die mit ProduzentInnen (bestehende Betriebe) und KonsumentInnen Verträge abschliesst.
  • Verein oder andere Organisationsform, der /die selbst eine Produktion von Lebensmitteln betreibt und mit KonsumentInnen Verträge über den Bezug von Lebensmitteln in Abonnementsform abschliesst.
  • Betrieb (bspw. Einzelunternehmen), der selbst eine Produktion von Lebensmitteln betreibt und mit KonsumentInnen Verträge über den Bezug von Lebensmitteln in Abonnementsform abschliesst.
  • usw.

Abwesenheiten, ja oder nein?

Fragestellungen:

  • Benötigt unsere Initiative die Funktion der Abwesenheiten?

Beschreibung:

AbonnentInnen können im Mitgliederportal diejenigen Lieferdaten auf "abwesend" setzen, an denen sie keinen Korb wünschen. OpenOlitor berücksichtigt diese Abwesenheiten bei der Zusammenstellung der Bestellungen und der Lieferdaten.

Praxisbeispiele:

  • Der Verein soliTerre schliesst Jahresverträge über 48 Lieferungen ab. Die AbonnentInnen können zwischen 48 und 52 Lieferungen beziehen. Wenn sie pro Geschäfsjahr 4 Lieferdaten auf "abwesend" setzen, ist der Saldo gleich Null. Wenn sie einen bis vier Körbe mehr beziehen als vertraglich vereinbart, dann erhalten sie für die mehr bezogenen Körbe eine Schlussabrechung.
  • Eine Initiative liefert nicht einzelne Körbe, sondern Gemüse in Gebinden in den Depots, die AbonnentInnen nehmen die vorgesehenen Mengen selbst. Die Initiative kennt zwar keine vertraglich geregelten Abwesenheiten (d.h. jeder Abonnent organisiert sich selbst, wenn er den Korb nicht abholen kann). Damit aber nicht zu viel Gemüse in die Depots geliefert wird, können die AbonnentInnen Abwesenheiten eingeben, wenn sie niemanden gefunden haben, der das Gemüse an ihrer Stelle holt. OpenOlitor berücksichtigt diese Abwesenheiten beim Zusammenstellen der Liefermengen pro Depot und bei der Lieferliste (AbonnentInnen pro Depot pro Liefertag).
  • Eine Gemüseabonnement wird nicht als Jahresvertrag ausgestaltet, sondern als Abonnement über eine gewisse Anzahl von Lieferungen. Wird ein Liefertag auf "abwesend" gesetzt vom Mitglied, wird ein zusätzlicher Liefertag am Ende des Abozeitraums angehängt.

Fazit:

Die Abwesenheiten können einerseits dazu dienen, auf Basis einzelner Körbe individuelle Abwesenheiten zu erfassen und zu verarbeiten. Andererseits können sie der Mengensteuerung dienen, auch wenn nicht einzelne Körbe ausgeliefert werden, sondern Gemüse in grösseren Gebinden in Depots gebracht werden.

Preise sichtbar / relevant? (Produktepreise)

Fragestellungen:

  • Benötigt unsere Initiative Produktepreise?

Beschreibung:

Initiativen können OpenOlitor mit oder ohne Produktepreise verwenden. Werden die Preise in der Konfiguration (Einstellungen, Projekt) deaktiviert, findet die Planung der Lieferungen ohne Preise statt. Die Produkte werden dann nur mengenmässig quantifiziert. Diese Einstellung erfolgt auf Ebene "Initiative" bzw. "Projekt".

Praxisbeispiele:

  • Eine Initiative ordnet den Produkten keine Preise zu, weil die gesamte Ernte an die AbonnentInnen verteilt wird. Gleichwohl soll eine Lieferplanung stattfinden, damit die Mengen für die Verteilorte in Abhängigkeit der Anzahl Abonnemente pro Verteilort gesteuert werden können.
  • Eine Initiative ordnet den eigenen Produkten zwar keine Preise zu, möchte aber die "Türe" für Zukäufe von Gemüse von befreundeten Betrieben offen halten. Entsprechend werden die Produktepreise nicht deaktiviert. Aber den eigenen Produkten wird der Preis 0.00 zugewiesen. Erst wenn Zukäufe von Dritten stattfinden, werden diesen Produkten Preise zugeordnet. In diesem Fall wird ein Produkte zweimal aufgeführt, einmal mit Preis 0.00 und einmal mit dem verhandelten Preis Zukauf.
  • Der Verein soliTerre in Bern arbeitet einerseits mit Produktepreisen und andererseits mit Flächen- und Tierpauschalen. Gewisse Produkte werden pro Fläche (Produktionskosten) eingekauft, unabhängig vom Ertrag. Der ganze Ertrag der Pauschale wird dann an den Verein geliefert. Die Flächen- und Tierpauschalen-Produkte haben den Preis 0.00. Die Ausgaben für die Flächen- und Tierpauschalen werden bei der Berechung des Korb-Zielpreises für jeden Abotyp separat berücksichtigt. Die Berechnungsgrundlagen sind beim Verein soliterre einsehbar (info@soliterre.ch).
  • Der Produktepreis kann auch zweckentfremdet werden, bspw. indem statt eines Produktepreises bspw. ein Aquivalent für anderen Wert von Produkten eingegeben wird (bspw. Arbeitskraftstunden pro Kilo Kartoffeln).

Fazit:

Die Produktepreise sind dann nötig, wenn Bestellungen von Gemüse für die Abonnements entweder für den eigenen Betrieb oder für Produzenten in Franken oder Euro quantifiziert werden sollen. Das Feld lässt sich auch für andere Zwecke nutzen.

Preise editierbar (Produktepreise)?

Fragestellungen:

  • Soll bei der einzelnen Lieferplanung der Preis von Produkten modifizierbar sein oder nicht?

Beschreibung:

In OpenOlitor gibt es potentiell zwei Orte, an denen die Preise von Produkten verändert werden können. Einerseits in den Stammdaten im Untermenu "Produkte". Andererseits in der konkreten Lieferplanung von Körben. Wenn in der Konfiguration (Ebene Projekt) die Preise auf "nicht editierbar" eingestellt sind, kann in der Lieferplanung der Preis nicht abgeändert werden. Wenn die Preise auf editierbar eingestellt sind, hingegen schon.

Praxisbeispiele:

  • Der Verein soliTerre arbeitet mit Jahrespreisen. In der OpenOlitor-Konfiguration wurden die Preise auf nicht-editierbar gesetzt, damit in der Lieferplanung keine Fehler passieren. Produktepreise werden verhandelt und nach Genehmigung durch die Mitgliederversammlung im den Stammdaten, im Untermenu Produkte, geändert. Wenn, was selten vorkommt, ein Preise eines Produktes in einer bestimmten Lieferplanung geändert werden muss, ohne dass der Preis des Produktes ändert, wird ein "Sonderprodukt" eingesetzt (Rettungsreifen-Symbol neben der Produkteliste in der Lieferplanung).
  • Andere Initiativen übernehmen wöchtentlich oder zweiwöchentlich publizierten Produkte-Preise, das heisst, der Preis der Produkte ändert sich laufend. In solchen Situationen muss der Preis in der Konfiguration auf "editierbar" gestellt werden.

Fazit:

Diese Einstellung bezieht sich auf Produktepreise und konkret auf die Editierbarkeit der Produkte in der konkreten Lieferplanung. In den Stammdaten können die Produktepreise jederzeit und unabhängig von dieser Einstellung geändert werden.

Preis pro Lieferung, Zielpreis. Admin-Anteil

Fragestellungen:

  • Wie hoch ist unser Preis pro Lieferung bei einem bestimmten Abotyp?
  • Wie hoch ist unser Zielpreis pro Lieferung bei einem bestimmten Abotyp?
  • Wie hoch ist der Admin-Anteil (der Produzenten) bei einem bestimmten Abotyp?
  • Wie hängen diese drei Parameter zusammen?

Beschreibung:

OpenOlitor kann den Abzug von Adminstrationsanteilen von Mitgliedern (AbonnentInnen) und ProduzentInnen abbilden. Unter dem Preis pro Lieferung wird der Preis verstanden, der den AbonnentInnen in Rechnung gestellt wird. Diese Zahl dient dazu, bei der batchweisen, abonnementstyp-übergreifenden Erstellung von Rechnungen den Rechnungsbetrag durch OpenOlitor berechnen zu lassen. Wenn die Abotypen keinen festen Preis haben, können Rechnungen auch mit leerem Betragsfeld erstellt werden.

Die Kosten der Administration werden von den AbonnentInnen und/oder von den ProduzentInnen getragen. Der Anteil der AbonnentInnen wird über den Zielpreis festgelegt: Der Zielpreis ist der Preis, der im Durchschnitt pro Geschäftsjahr pro Abotyp erreicht werden soll. OpenOlitor errechnet mit jeder Lieferplanung diesen Durchschnittspreis mit. So kann sichergestellt werden, dass in Initiativen mit Einkauf von Produkten nicht mehr Wert in die Körbe gelangt als über die Abonnentsbeiträge eingenommen wird. Entsprechend ist der Zielpreis um den Wert des Admin-Anteils der AbonnetInnen tiefer als der Preis pro Lieferung.

Der Administrationsanteil der Produzenten wird über den Wert "Admin-Anteil" in Prozent festgelegt. Er errechnet sich vom Zielpreis. Der Admin-Anteil wird bei der Erstellung der Abrechnung für die Produzenten von OpenOlitor abgezogen (vor allfälligem Zuschlag für Mehrwertsteuer bzw. WUST.

Praxisbeispiel:

  • Der kleine Korb Vegi hat einen Preis pro Lieferung von 20 Franken. Die AbonnentInnnen bezahlen 10% davon an die Administrationskosten der Initiative. Der Zielpreis liegt folglich für dieses Abonnement bei 18 Franken. Bezahlen die Produzenten davon nochmals 10 Prozent, liegt ihr Erlös pro Korb bei 16.20 Franken. Insgesamt weist der Admin-Anteil der Produzenten und AbonnentInnen 19% auf.

Fazit:

OpenOlitor kann die Admin-Anteile von Produzenten und AbonnentInnen pro Abotyp separat ausweisen.

Abotypen und Vertriebstypen

Fragestellungen:

  • Welche und wieviel Abonnements-Typen benötigt unsere Initiative?

Beschreibung:

Ein Abotyp in OpenOlitor zeichnet sich dadurch aus, dass alle Körbe denselben Preis pro Lieferung aufweisen, denselben Namen tragen (klein Vegi beispielsweise), denselben Lieferrhythmus, dieselbe Laufzeit, Kündigungsfrist und denselben Guthaben Mindestbestand aufweisen. Auch Anzahl Soll-Abwesenheiten, Farbcode, Zielpreis und Admin-Anteil der Produzenten sind bei einem Abotyp identisch.

Innerhalb eines Abotyps können aber verschiedenen Vertriebe festgelegt werden. Da die Lieferplanungen pro Vertrieb pro Abotyp durchgeführt werden, müssen Liefertag und Liefertermine nicht pro Abotyp, sondern nur pro Vertrieb innerhalb eines Abotyps übereinstimmen. Innerhalb eines Vertriebs können gleichzeitig verschiedene Depotorte und Arten der Auslieferung (Postlieferung, Hauslieferung, Depotlieferung) kombiniert werden.

Praxisbeispiele:

  • Eine Initiative hat einen grosses Abo und zwei kleine Abos. Das grosse Abo wird wöchtentlich am Mittwoch ausgeliefert in 2 Depots. Die beiden kleinen Abos heissen fast gleich: "Abo klein Dienstag" und "Abo klein Freitag". Die Hälfte der kleinen Abos wird am Dienstag der ungeraden Wochen, die andere Hälfte der kleinen Abos am Freitag der geraden Wochen ausgeliefert. Am Dienstag werden nur 3 Depots beliefert, am Freitag 6 Depots. Da die Ernte am Montag der ungeraden Wochen und Donnerstag der geraden Wochen unterschiedlich ausfällt, müssen die beiden kleinen Abos je separat geplant werden. Die Umsetzung in OpenOlitor sieht so aus: Es werden zwei Abotypen erstellt. Das grosse Abo erhält einen Vertrieb: Mittwoch, ZUordnung der beiden Depots. Das kleine Abo erhält zwei Vertriebe, damit die zeitversetzte Lieferung je an einem anderen Tag in verschiedene Depots umgesetzt werden kann.
  • Eine Initiative hat ein grosses und ein kleines Abonnement mit identischen Vertrieben, also gleicher Tag, gleiche Depots, etc.). Allerdings sind die Erntemengen manchmal zu klein und können nicht in vernünftigen Mengen auf alle kleinen Körbe oder alle grosse Körbe verteilt werden. Es muss innerhalb der Abotypen eine weitere Unterteilung stattfinden, damit auch Kleinstmengen in die Körbe zugeteilt werden können. Die Körbe desselben Abotyps sind dann nicht immer identisch bezüglich Inhalt. Umsetzung in OpenOlitor: Pro Abotyp werden mittels Anlegen von mehreren (identischen) Vertrieben "Korbgruppen" angelegt, die separat geplant werden können. Wenn sie gleichen Inhalt haben, kann in der Lieferplanung der ganze Korb mittels Drag und Drop kopiert werden. Es entsteht also kaum zusätzlicher Aufwand.

Fazit:

OpenOlitor weist eine ausgeklügelte Struktur auf was Abotypen und Vertriebe angeht.

Dokumentation

OpenOlitor-Versionen

Doku nach Menupunkten

Doku nach Masken

Doku nach Abläufen

Doku globale Bedienungselemente

Doku Konfigurations-Checkliste

Technische Dokumentation

Documentation (fr)

[Docu selon rubriques de menu]

[Docu selon masques]

Docu en fonction des processus de travail

[Docu des éléments globaux d'utilisation]

Docu check-list de configuration

[Docu des composantes du serveur]

[Docu des composantes Web]

Documentation (en)

Technical documentation

Clone this wiki locally