Doku nach Masken
Status/Version 1: In Erarbeitung
Diese Dokumentation beschreibt die einzelnen Masken von OpenOlitor:
Übersicht zu Menus, Submenus und deren Masken
Das Hauptmenu ist wie folgt aufgebaut:
-
Menu Kunden:
Niveau 1: Maske Übersicht Kunden, Spalten erweiterbar (kundenoverview.html)
Niveau 2: Maske Kunde erstellen (kundendetail.html)
Niveau 2: Maske Detailansicht Kunde (kundendetail.html)
-
Menu Kunden, Submenu Personen:
Niveau 1: Maske Übersicht Personen, Spalten erweiterbar (personenoverview.html)
-
Menu Abos:
Niveau 1: Maske Übersicht Abonnements, Spalten erweiterbar (abosoverview.html)
Niveau 2: Maske Detailansicht Abonnement via Pfeil (abosdetail.html)
Niveau 3: Maske Guthaben anpassen (abosdetail-guthaben-anpassen.html)
Niveau 3: Maske Vertriebsart anpassen (abosdetail-vertriebsart-anpassen.html)
Niveau 3: Maske Manuelle Rechnung erstellen (rechnungendetail.html)
-
Menu Pendenzen
Niveau 1: Maske Übersicht Pendenzen (pendenzenoverview.html)
-
Menu Lieferanten
Niveau 1: keine Maske
-
Menu Lieferanten: Submenu Lieferplanung (Korbplanung)
Niveau 1: Maske Übersicht Lieferplanungen (lieferplanungoverview.html)
-
Submenu Abrechnung (Produzenten)
Niveau 1: Maske Übersicht Lieferantenabrechnungen (lieferantenabrechnungenoverview.html)
Niveau 2: Maske Detailansicht Lieferung via Pfeil (lieferungen.html)
-
Menu Auslieferungen
Niveau 1: keine Maske
-
Menu Auslieferungen, Submenu Depotauslieferungen
Niveau 1: Maske Übersicht Depotauslieferungen (depotauslieferungenoverview.html)
-
Menu Auslieferungen, Submenu Tourenauslieferungen
Niveau 1: Maske Übersicht Tourenauslieferungen (tourenauslieferungenoverview.html)
-
Menu Auslieferungen, Submenu Postauslieferungen
Niveau 1: Maske Übersicht Postauslieferungen (postauslieferungenoverview.html)
-
Menu Buchhaltung
Niveau 1: keine Maske
-
Menu Buchhaltung, Submenu Rechnungen
Niveau 1: Maske Übersicht Rechnungen (rechnungenoverview.html)
Niveau 2: Maske Detailansicht Manuelle Rechnung erstellen (rechnungendetail.html)
-
Menu Buchhaltung, Submenu Zahlungsimports
Niveau 1: Maske Übersicht Zahlungsimports (zahlungsimportsoverview.html)
Niveau 2: Maske Detailansicht Zahlungsimport (zahlungsimports.html)
-
Menu Buchhaltung, Submenu Einkauf: existiert noch nicht
-
Menu Stammdaten
-
Menu Stammdaten, Submenu Depots
-
Menu Stammdaten, Submenu Touren
-
Menu Stammdaten, Submenu Abotypen
-
Menu Stammdaten, Submenu Produzenten
-
Menu Stammdaten, Submenu Produkte
-
Menu Reports
-
Menu Einstellungen
-
Menu Einstellungen, Submenu Projekt
-
Menu Einstellungen, Submenu Vorlagen
-
Menu Sysadmin
-
Menu Sysadmin, Submenu Logs
Dieses Dokument wird ständig ergänzt und erweitert. Um den aktuellen Status innerhalb von einzelnen Abschnitten genauer sichtbar zu machen, verwenden wir diese Symbole:
- 🍏 Folgt in einer späteren Version.
- 🍎 Folgt noch in der aktuellen Version.
- 🍋 Ist umgesetzt, muss aber noch (besser) dokumentiert werden.
OpenOlitor erfasst in diesem Menupunkt alle TeilnehmerInnen einer Initiative: Abonnentinnen, Gönnerinnen, Genossenschafterinnen, usw. Es wird unterschieden zwischen einem Adressblock (der Anbindung ist für die Abonnemente) und den einzelnen Ansprechpartnerinnen pro Adressblock. Ziel dieser Struktur ist es, möglichst viele an den Abos beteiligte Personen erfassen zu können.
Kategorisiert werden die Ansprechpersonen via den Adressblock mittels Flags. Die Flags (Kundentypen-Kategorien) werden pro Teilnehmer- oder Teilnehmergruppe, also pro Eintrag als Kunde hinterlegt. Dies bedeutet, dass in gewissen Situationen Personen doppelt erfasst werden müssen. Beispiel: Frau A ist Gönnerin-Mitglied der Initiative, hat aber selbst kein Abo. Sie ist aber als Nicht-Vertragspartnerin im Abo von Frau B beteiligt. Entsprechend wird Frau als Ansprechperson beim Eintrag/Adressblock (Aboanbindung) von Frau B als Ansprechperson hinterlegt. Gleichzeitig erhält sie einen eigenen Adressblock/Eintrag mit dem Flag "Gönnerin". Siehe auch "Konfiguration, Kundentypen".
In dieser Ansicht unterhalb hat eine Einzelperson ein oder mehrere Abos gelöst:
In dieser Ansicht unterhalb haben mehrere Personen (oder ein Verein oder eine Firma) ein oder mehrere Abos gelöst. Sobald eine zweite Ansprechperson angelegt wird, gibt es ein neues Feld im Adressblock namens "Anschrift". Dort wird die gemeinsame Anschrift der Ansprechpersonen hinterlegt, also beispielsweise "Verein XY", "WG AA", Familie BB" oder "Anna Muster & Thomas Beispiel".
In der Ansicht oben sind bei mehreren Ansprechpersonen die weiteren Angaben pro Person versteckt, auf Mausklick können die Daten zur Ansprechperson ausgeklappt werden:
Es gibt für den Adressblock und für jede Ansprechperson ein Bemerkungsfeld. Im Bemerkungsfeld der Ansprechperson kann bspw. vermerkt werden, ob diese Person den Abo-Vertrag unterzeichnet hat oder ob sie in anderer Form am Abo beteiligt ist. Das Bemerkungsfeld ist nicht zu verwechseln mit der Pendenzen- bzw. History-Funktion.
Zusätzlich kann pro Adressblock eine Zusatzinfo zur Lieferung erfasst werden. Dies ist bei Hauslieferung relevant, wenn bspw. ein Korb an einen bestimmten Ort an der Adressse hinterlegt werden soll (bspw. "Keller, zweite Türe links"). Falls Rechnungsadresse und Lieferadresse abweichen, kann eine Lieferadresse erfasst werden, die dann in der Tourenplanung die Rechnungsadresse ersetzt. Die Lieferadresse ist bei der Depotlieferung nicht relevant, sie betrifft nur die Haus- und Postlieferung.
Bei den Projekteinstellungen (unter "Einstellungen" in der Navigation links) werden einerseits Stammdaten zur Initiative die OpenOlitor benutzt, eingegeben. Andererseits sind Vorlagen von Serienbriefen, Etiketten und weitere Templates hinterlegt.
In den Stammdaten zur Initiative hinterlegt sind die Koordinaten, das Logo, die verwendete Währung sowie der Start des Geschäftsjahrs der Initiative. Auf das jeweilige Geschäftsjahr beziehen sich bspw. die Zielpreis-Berechnungen in der Lieferplanung. Bevor Änderungen vorgenommen werden können, muss das Editieren aktiviert werden.
In den Projekteinstellungen ist auch eine Konfiguration enthalten. Dort kann zum einen die verwendete Sprache festgelegt werden. Weiter kann festgelegt werden, ob die Preise von Produkten im Tool eine Rolle spielen sollen oder nicht. Wenn mit Produktpreisen gearbeitet wird, kann zusätzlich festgelegt werden, ob diese Preise in der Produkteliste fix hinterlegt werden (und damit auch in der Korbplanung so übernommen werden) oder ob die Preise editierbar sein sollen. Editierbar bezieht sich dabei auf die Veränderung der Preise in der Ansicht "Lieferplanung" (Korbplanung). In der Produkteliste sind die Preise immer veränderbar (sofern die Preise in den Projekteinstellungen als relevant hinterlegt wurden). Fixe Preise sind in RVL-Initiativen verbreitet, es gibt aber auch Formen der Vertragslandwirtschaft oder der Direktvermarktung im Abosystem, wo Tages-, Wochen- oder Monatspreise zum Einsatz kommen. Derzeit werden diese wechselnden Preis in der Lieferplanung manuell eingegeben bzw. verändert. :green_apple: Im Rahmen der weiteren Entwicklung von OpenOlitor besteht die Möglichkeit, veröffentlichte Preislisten zu importieren. Ebenfalls in den Konfigurationen hinterlegt ist, ob der Eintrag einer Emailadresse bei den TeilnemerInnen obligatorisch ist.
In der Konfiguration können zusätzlich Eigenschaften (Flags) konfiguriert werden, die den einzelnen TeilnehmerInnen ("Kunden") zugeordnet werden können (einfache oder mehrfache Zuteilung). Hat eine Initiative beispielsweise die Flags "Abonnentin", "Gönnerin", "Interessierte" und "Genossenschafterin" definiert, können diese den einzelnen Teilnehmerinnen zugeordnet werden, was ein späteres Filtern, beispielsweise für die Erstellung von Rechnungen, Serienbriefen oder Serienmails für einzelne der Gruppen, die durch Flags definiert wurden, aus OpenOlitor ermöglicht:
Zusätzlich können in den Projekteinstellungen Produktekategorien erfasst werden. Diese Kategorien helfen bei der Eingabe von zusätzlichen Produkten in der Produkteliste, indem nach den erfassten und zugeordneten Kategorien gefiltert werden kann:
In den Einstellungen finden sich auch die projektspezifisch hinterlegten Vorlagen (Templates).
In den Stammdaten werden Depots und Touren, Abotypen, ProduzentInnen und Produkte erfasst. Nicht zu den Stammdaten gehören die TeilnehmerInnen (Kunden).
In den Stammdaten Depot können beliebig viele Depots eingerichtet werden:
Die Basisdaten der einzelnen Depot enthalten die Anschrift (Bezeichnung, Adresse, PLZ und Ort) sowie ein Kurzzeichen (für Etiketten und andere Anwendungszwecke, bei denen nicht die volle Bezeichnung des Depots sichtbar gemacht werden soll) und die Information, ob das Depot überhaupt aktiv ist. Ein nicht aktives Depot kann bei der Einrichtung von Abotypen (und folglich auch bei der Erstellung von Abonnements) nicht oder nicht mehr angewählt werden. Depots, die nicht mehr verwendet werden, werden nicht gelöscht, sondern auf inaktiv gesetzt. Bei den Zusatzdaten der Depots kann festgelegt werden, ob eine Maximalzahl von Körben für das Depot besteht (falls ja, kann in diesem Feld eine Zahl eingegeben werden). Ebenso kann ein Farbcode pro Depot hinterlegt werden. Das bewährt sich bei der Verteilung: Mit Etiketten in unterschiedlichen Depot-Farben kann einfach visuell kontrolliert werden, ob nicht versehentlich ein Korb im falschen Depot ausgeladen wurde. Ebenfalls in den Zusatzinformationen können die Öffnungszeiten des Depots hinterlegt werden. In den Kontodaten wird die Bankverbindung des Depots hinterlegt, falls Zahlungen an Depots ausgeführt werden sollen. Weiter ist zu jedem Depot eine Ansprechperson erforderlich: Dies ist die Person, die seitens der Depotstelle den Kontakt zur Initiative pflegt. Die verantwortliche Person ist die Person, die sich seitens der Initiative um diese Depotstelle kümmert und mit der Ansprechperson der Depotstelle Kontakte pflegt.
Bei den Stammdaten Touren werden die einzelnen Liefertouren festgehalten. Weil bei der Hauslieferung die Wohnadresse und die Lieferadresse abweichen kann, kann bei der Erfassung von AbonnentInnen neben der Wohnadresse auch eine allenfalls abweichende Lieferadresse erfasst werden, siehe Beschreibung zu TeilnehmerInnen (Kunden).
Bei den Stammdaten Abotypen werden bei den Basisdaten die Bezeichnung des Abotyps festgelegt (bspw. Gross Vegi) und eine Beschreibung des jeweiligen Abotyps. Es wird zudem festgelegt, wann dieser Abotyp zeitlich aktiv ist. Ein Abotyp kann über längere Zeit verfügbar sein (bspw. Jahresabo Klein Vegi mit Aktivzeit über mehrere Jahre) oder auch nur kurz (Abonnement für frischen Most, verfügbar während 4 Wochen). Ist ein Abotyp aktiv, kann ein solches Abonnement einem Abonnenten (Teilnehmer, Kunde) zugeordnet werden.
Zusätzlich wird der Lieferrhythmus festgelegt: Wöchentlich, monatlich, zweiwöchtentlich oder unregelmässig. Die regelmässigen Lieferrhytmen werden hier festgelegt, damit bei der Erstellung der Lieferdaten automatische Lieferdatenberechnungen vorgeschlagen werden können. Wird unregelmässig gewählt, müssen die Lieferdaten vollständig manuell angelegt werden.
Der ebenfalls in den Stammdaten Abotypen festgehaltene Preis entspricht dem Verkaufspreis des jeweiligen Abotyps (inkl. einer allfällige MWST).
Bei der Laufzeit geht es einerseits darum, die Abwesenheiten und andererseits die Erneuerung von Abo steuern zu können. In der Laufzeit unbeschränkte Abotypen erneuern sich automatisch, sofern sie nicht gekündigt werden. Bei den in der Laufzeit begrenzten Abotypen (begrenzt nach Anzahl Monate oder Anzahl Lieferungen) müssen die einzelnen Abonnements für die Vertragserneuerung aktiv erneuert werden (neues Abonnement). Bei der Begrenzung nach Anzahl Lieferungen, besteht die Möglichkeiten, Abwesenheiten einzugeben (also Lieferungen auszusetzen), und zwar so, dass die ausgesetzten Lieferungen das Abonnement jeweils um eine Lieferung verlängern.
Die Kündigungsfrist wird hier eingetragen, der nächste Kündigungstermin und die entsprechende Kündigungsfrist von OpenOlitor errechnet und in der Aboverwaltung und im Kundenportal hinterlegt werden kann.
Mit dem Guthaben-Mindestbestand kann den in den Stammdaten "Abotypen" festgelegt werden, um wieviel Lieferung der Abonnent im Vergleich zu den Zahlungen im Rückstand ist. Dies erlaubt einerseits eine Inkassokontrolle und automatische Einstellung von Lieferungen, wenn der Saldo-Minestbestand überschritten wird, andererseits können so auch Schlussabrechnungen für zuviel bezogene Körbe erstellt werden (bspw. wenn ein Jahresabo über 52 Kalenderwochen nur 48 Lieferungen enthält, und die vier Körbe abbestellt oder bezogen werden können).
Bei den Zusatzdaten können weitere Einstellungen vorgenommen werden: Wenn "wird standardmässig geplant" aktiviert wird, erscheint dieser Abotyp in der Lieferungsplanung (also der Planung der Körbe und muss nicht manuell aufgerufen werden). Bei der Anzahl Soll-Abwesenheiten kann eingetragen werden, wieviele Lieferungen (Körbe) die AbonnentInnen abbestellen müssen, um nicht eine Schlussabrechnung zu erhalten. Bei einem Jahresabonnement, das 48 Lieferungen beinhaltet, können so beispielsweise 4 Lieferungen (Differenz zu 52 Kalenderwochen) als Soll-Abwesenheiten hinterlegt werden. Der Farbcode erlaubt es, die Abotypen farblich kennzuzeichnen (in OpenOlitor, aber auch auf den mittels Dokumentvorlagen erzeugten Dokumenten bspw. den Ettiketten). Der Zielpreis und der Administrationsanteil dienen dazu, die Anteile der AbonnentInnen und der ProduzentInnen an den Adminstrationskosten feszulegen, falls benötigt. Der Administrationsteil der AbonnentInnen wird über den Zielpreis festgelegt. Beläuft sich beispielsweise der Abopreis des Abotyps "Klein Vegi" auf 20 Franken, so kann über den Zielpreis (also den Preis, der über alle Lieferungen im Schnitt über das Geschäftsjahr angestrebt wird) festgelegt werden, in welcher Höhe die AbonnentInnen effektiv Lebensmittel erhalten. In Initiativen, die nicht mit Preisen pro Produkt arbeiten, kann dieser Teil der Konfiguration ausgelassen werden. Die Zielpreisberechnung ist in den Fällen etwas komplizierter, wenn Flächenpauschalen zum Einsatz kommen, wenn also eine gewisse Summe bei den Abotypen abgezogen wird, weil diese Produkte nicht pro Menge geerntete Lebensmittel, sondern pro angebaute Fläche pauschal entschädigt werden. Wenn zusätzlich Vegane oder Vegetarische Abotypen bestehen, kann mit der Zielpreisberechnungen auch eine Eier-Tierpauschale berücksichtigt werden, also eine Pauschale, die nicht bei allen Abotypen angerechnet wird. Die Zielpreisberechnungen selbst wird ausserhalb des Tools erstellt. Wir werden hier eine Beispielberechnungen zur Verfügung stellen. Während der Administrationsanteil der AbonnentInnen über die Zielpreis berücksichtigt wird, wird der Administrations-Anteil der Produzenten hingegen direkt in Prozent abgerechnet. von 100% werden über den Zielpreis also beispielsweise 10% Admin-Anteil der AbonnentInnen abgezogen (ein Korb à 20 Franken hat dann einen Zielpreis von 18 Franken), die Produkte werden für diesen Zielpreis auf die Körbe verteilt und bei der Produzentenabrechnung wird dann vom Totalpreis der Administrationsanteil von 15 Prozent abgezogen. Die Anzahl aktiver Abonnemente schliesslich zeigt, wieviele Abonnements diesem Abotyp effektiv zugeordnet sind.
Ebenfalls beim jeweiligen Abotyp werden auch die Art der Lieferung und die Lieferdaten festgelegt. Bei der Vertriebsart stehen die Depotlieferung (an Sammelstellen), die Heimlieferung (einzeln an bestimmte Adressen, wobei die Rechnungs- und die Lieferadresse abweichen können). Die Postlieferung kann als Dritte Variante angewählt werden.
Bei der Heimlieferung wird eine Liefertour ausgewählt (zuvor konfiguriert in den Tour-Stammdaten), bei der Depotlieferung ein Depot (vorher konfiguriert in den Depot-Stammdaten). Die Postlieferung erfordert keine zusätzliche Konfiguration, da die Aboadresse bzw. Lieferadresse bei den Teilnehmerdaten (Kundendaten) bereits hinterlegt ist.
Dann werden pro Abotyp ein Liefertag ausgewählt und diesem Liefertag werden Depots, Touren und/oder Postlieferung als Vertriebsarten zugeteilt. Pro Abo und Liefertag werden die Lieferdaten eingegeben (die Lieferdaten können als Vorschlag errechnet oder ganz manuell eingegeben werden, es können nach der Berechnung auch einzelne Lieferdaten wieder gelöscht werden). Ein Abotyp kann also einen Liefertag und mehrere Vertriebsarten umfassenn. Bei der Zuweisung des Abotyps zum Abonnenten wird dann unter den hier erstellten Varianten ausgewählt.
Wichtig: In der Lieferplanung werden die einzelnen Abotypen gesamthaft zusammengestellt, also unabhängig von der Vertriebsart. Liefert eine Initiative beispielsweise den Abotyp "Klein Vegi" am Mittwoch an 10 Depots, 4 Touren und 5 Körbe als Postlieferung, und ist der Korbinhalt immer derselbe, muss nur ein Abotyop erfasst werden. Gibt es dagegen den kleinen Vegi-Korb einmal am Donnerstag in ein Depot, am Freitag nach Hause und am Samstag per Post, müssen drei Abotypen erfasst werden.
Bei den Stammdaten Produzenten werden alle Angaben (Adresse, Telefonnummer, Mail, Bankkoordinaten, MWST-Details) derjenigen Betriebe oder Produzentinnen und Produzenten erfasst, die in die Initiative liefern bzw. für die Initiative produzieren. Diese Daten bilden die Grundlage für die automatisierte Rechnungserstellung für die Produzenten. Das heisst, in OpenOlitor werden Rechnungen für Guthaben erstellt, welche die Produzentinnen und Produzenten von der Initiative erhalten. Dabei wird die eine eventuelle MWST-Pflicht der Produzenten berücksichtigt: Sofern ein Produzent MWST-pflichtig ist oder für die MWST optiert hat, kann seine MWST-Nummer und der MWST-Satz erfasst werden. Diese Daten fliessen wiederum in die Rechnungen ein.
In den Stammdaten Produkte kann eine Liste von Produkten erfasst werden, die dann in der Lieferplanung (Korbplanung) als Auswahlliste zur Verfügung steht. Je nachdem, ob in den Projekt-Voreinstellungen für Preise optiert wurde (Preise sichtbar / relevant) und ob die Preise als editierbar bezeichnet wurden, erscheinen in der Produkteliste die Preise oder nicht. Bei den nicht editierbaren Preisen gelten bei der Lieferplanung (Korbplanung) die in der Produkteliste hinterlegten Preise als fix (Preise nicht editierbar) oder als veränderbar bei der Lieferplanung (Korbplanung). Wenn die Preise als "nicht editierbar" hinterlegt wurden, werden sie in der Produkteliste verändert. Die Bezeichnung der Produkte enthält den Namen des Lebensmittels. Diese Bezeichnung wird auch in den Listen "aktueller Korb" und in den Auswertungen verwendet. Entsprechend empfiehlt es sich, eine gewisse Systematik anzuwenden und die Lebensmittel so zu bezeichnen, dass auch Laien verstehen, was gemeint ist. Beim Verein soliTerre werden beispielsweise Bezeichnungen, die nicht allgemein verständlich sind, mit einem Typ-Präfix eingetragen: Statt "Ochsenherz" heisst es dann: "Tomaten, Ochsenherz". Artbezeichnungen werden bei soliTerre tel quel eingetragen: Schwarzer Rettich und Winterrettich. Verschiedene Sorten oder Zubereitungsarten hingegen werden in der Tendenz mit Komma getrennt: "Randen, gekocht" vs. "Randen, Chioggia Pro Specia Rara". Oder "Karotten, rot" und "Karotten, violett". Da nach Buchstabenabfolgen gefiltert werden kann, müssen nicht alle Kohlarten mit "Kohl..." beginnen. Die Von-Bis-Felder haben zur Zeit reinen Informationscharakter, sie legen fest, wann ein Lebensmittel zeitlich zur Verfügung stehen kann. Der Preis bezieht sich immer auf 1 Einheit der unter Einheit festgesetzten Werte: Also 1 Franken pro 1 kg, pro 1 Liter, pro 1 Gramm, pro 1 Stück oder pro 1 Bund. Die Standardmenge dient der Lieferplanung (Korbplanung). Wird ein Standardwert von bspw. 300 g bei Produkt "Karotten, rot" eingegeben, erscheint dieser Wert beim den "Karotten, rot" in der Korbplanung automatisch. Wenn dann 350 g geplant werden, kann der Wert korrigiert werden (und muss nicht vollständig neu eingegeben werden).
Übersichten und Berichte werden in OpenOlitor in zwei Kategorien unterteilt: Berichte und Auswertungen, die im Admin-Alltag laufend benötigt werden, werden direkt in OpenOlitor angezeigt und sind über den Export-Knopf auf der jeweiligen Seite exportierbar (CSV-Datei). Weitere Berichte, die nur alle paar Monate oder wenige Male pro Jahr benötigt werden, zeigt OpenOlitor nicht an, macht sie jedoch im CSV-Format exportierbar. Unter Reports in der Navigation links unten stehen diese Berichte und Auswertungen zum Download bereit (Formate: CSV, PDF, LibreOffice-Textdateien). Diese Berichte sind zu einem grosse Teil vor-konfiguriert (basierend auf den Abfrage und Berichten des "alten Admin-Tools des Vereins soliTerre), zusätzliche Berichte von den OpenOlitor-Nutzern zusätzlich erstellt werden bzw. über den Verein OpenOlitor als Vorschlag eingebracht werden. Bereits in OpenOlitor integriert sind die Berichte für den Etiketten-Ausdruck (Etiketten, die auf Körbe geklebt werden, falls die Körbe namentlich angschrieben werden), für verschiedene Serienbriefe sowie verschiedene Auswertungen (gelieferte Produkte total, gelieferte Produkte pro Produzent total, alle Lieferungen in der Übersicht, etc.).
Zum Workflow siehe [Zusammenstellung der Lieferungen] (https://github.com/OpenOlitor/OpenOlitor/wiki/Zusammenstellung-der-Lieferungen).
Eine Lieferplanung besteht aus einer oder mehreren Korbplanungen. Die Korbplanung erfolgt pro Abotyp und Vertrieb.
Generell wird bei der Erstellung von Rechnungen jeder einzelnen Rechnung eine Referenznummer und eine ESR-Nummer automatisch zugeteilt. So können Einzahlungsscheine erstellt werden, die anschliessend eine automatisierter Verarbeitung den eingegangenen Zahlungen ebenfalls in OpenOlitor ermöglicht. Die Rechnungen können entweder als PDF (oder LibreOffice-Datei) exportiert und per Mail direkt aus OpenOlitor versendet werden oder als PDF oder LibreOffice erstellt und anschliessend ausgedruckt werden.
Rechnungen können derzeit nur für AbonnentInnen erstellt werden. Sind andere TeilnehmerInnen erfasst (bspw. GönnerInnen oder GenossenschafterInnen ohne Abonnement), müssen Serienbriefe mithilfe eines Datenexports ausserhalb des Tools erstellt werden. Alternativ könnte ein "Fake"-Abotyp erstellt werden. Rechnungen an AbonnentInnen können entweder einzeln erfasst werden oder für eine Auswahl von AbonnentInnen.
Die Auswahl erfolgt über den Einsatz von Filtern. Gefiltert werden kann nach Abonnement-Nummer und Abonnement-Typ. Es können für eine Anzahl Lieferungen oder bis zu einem gewissen Zielguthaben (für eine Schlussabrechnung über eine bestimmte Anzahl Guthaben, wenn mehr Körbe bezogen werden können als vertraglich vereinbart) Rechnungen erstellt werden:
Bei der manuellen Erstellung von einzelnen Rechnungen können ausser der Kundennummer, die nach Auswahl des Abonnenten zugewiesen wird, und der ESR- und Referenznummer, die automatisch erstellt wird, alle Felder manuell verändert bzw. editiert werden. Einzelne Rechnungen können über das Menu Abos (Auswahl eines einzigen Abos) oder das Menu Kunden erstellt werden.
Zugang über die Kundenansicht einzeln:
Anhand des Rechnungsdatums wird der Status der einzelnen Rechnung automatisch festgelegt: 30 Tage nach Rechnungsdatum wird auf Mahnungsstatus gewechselt. Im Statutsfeld können Rechnungen auch storniert werden.
Die manuelle Erstellung von Rechnungen und die Inkassokontrolle durchlaufen folgenden Workflow:
- Eine Rechnung wird manuell erstellt (in der Kunden-Detailansicht): Die Rechnung wird einem Abo zugewiesen. Es wird ein Titel und die Anzahl der in Rechnunge gestellten Lieferungen hinterlegt. Es wird ein Rechnungsbetrag hinterlegt. Das Rechnungsdatum und das Fälligkeitsdatum werden hinterlegt.
- Bis zum Speichern hat die Rechnung den Status "Neu"
- Mit "Speichern" wird die Rechnung erstellt.
- Die Rechnung kann nun noch gelöscht werden.
Für die folgenden Schritte ist zu Unterscheiden, ob Rechnung gemailt oder ausgedruckt und versendet wird:
-
VARIANTE MAIL: Die Rechnung wird verschickt per Mail.
- Der Status der Rechnung ist "Verschickt"
- Es können ESR-Nummer importiert und verarbeitet werden.
- Die Rechnung kann nicht mehr gelöscht werden.
-
VARIANTE MAIL: Die Rechnung kann storniert werden
- Die Rechnung hat neu den Status storniert.
-
VARIANTE MAIL: Es kann eine Mahnung verschickt werden
- Status neu "Mahnungverschickt"
- kein Löschen/Stornieren mehr möglich
-
VARIANTE MAIL: Es kann ein Zahlungsimport erfolgen oder die Rechnung kann manuell auf "Bezahlt" gesetzt werden
- Status neu "Bezahlt"
- kein Löschen/Stornieren mehr möglich
-
VARIANTE DRUCK: Die Rechnung wird gedruckt.
- Der Status der Rechnung ist immer noch "Erstellt"
- Die Rechnung kann noch gelöscht werden.
[...]
Für die Inkassokontrolle werden bei der Bank die sogenannten "ESR-Dateien" heruntergeladen und in OpenOlitor eingespiesen (Zahlungsimports). Beim Import zeigt ein Inkasso-Verarbeitungsfenster an, ob mit einer Rechnung, die bezahlt wurde, alles in Ordnung ist (Status "OK") oder ob Fehler aufgetreten sind. Wenn der einbezahlte Betrag nicht stimmt, meldet OpenOlitor im Fenster "nicht erledigte Zahlungseingänge" unter "Status" "Betrag falsch", wenn diese Referenznummer bereits verwendet wurde, heisst es "Bereits verarbeitet", wenn die ESR-Nummer nicht lesbar war, heisst es "ESR nicht erkannt", und so weiter. Im Inkasso-Verarbeitungsfenster können diese Fehler (die es leider regelämssig gibt), bearbeitet werden und gelöste Fälle können mit einem "OK" und einer Bemerkung versehen werden. Danach werden diese Zahlungseingänge in die "erledigten Zahlungseingänge" verschoben.
Bei den Guthaben werden drei Typen unterschieden: Das Guthaben in Rechnung umfasst die Anzahl der in Rechnung gestellten Körbe. Das Guthaben vertraglich umfasst die Anzahl Körbe, die vertraglich zur Lieferung vereinbart wurden. Das Guthaben setzt sich aus diesen beiden Positionen zusammen:
Die Pendenzen/History-Verwaltung wird in der Navigation als Hauptmenupunkt angezeigt. Erfasst werden diese Pendenzen entweder manuell oder durch die Software.
Bei der manuellen Hinterlegung von Pendenzen wird im Menu "Kunden" (Teilnehmer) in die Detailansicht des Teilnehmers navigiert. Dort befindet sich an 2. Stelle die Pendenzen /History-Übersicht. Dort kann mit dem Button "Neue Pendenz" eine neuer Eintrag erstellt werden. Standardmässig wird als Erfassungsdatum das aktuelle Datum eingegeben, das Datum kann jedoch auch manuell eingegeben werden Es gibt derzeit drei Art von Pendenzen: Die "ausstehende", die "erledigt" und die "nicht-erledigt" (d.h. kann nicht erledigt werden derzeit im Gegensatz zur ausstehenden Pendenz).
OpenOlitor fügt derzeit in zwei Fällen ohne Zutun des Nutzers Pendenzen ein: Wenn für ein Abo die Vertriebsart oder das Depot verändert wird, und wenn das Guthaben manuell verändert wird.
In der Pendenzenübersicht im Hauptmenu in der Navigation links sind alle Pendenzen ersichtlich und können auch nach Status gefiltert werden, zur Detailansicht gelangt man, indem man auf den Kundenlink klickt:
🍏 In künftigen Versionen von OpenOlitor könnte die Pendenzenfunktion zur einer systematischen History ausgebaut werden, sofern entsprechender Bedarf geäussert wird.
Hier werden einige, häufig auftauchende Geschäftsfälle beschrieben.
- Änderungen an einem bestehenden Abo vornehmen: Häufige Änderungen am Abo eines Teilnehmers sind Änderungen des Depotortes oder der Vertriebsart, wobei der Abotyp derselbe bleibt. Diese Änderung wird am schnellsten über das Menu "Abos" erledigt, dort auf das betroffene Abo klicken. (Zum Abo kann man auch via die Kundenansicht gelangen.) Dann öffnet sich die Detailansicht des Abos. Auf den Pfeil neben dem Button "Speichern" klicken und "Vertriebsart anpassen" auswählen:
Sogleich öffnet sich das Fenster "Vertriebsart anpassen", dort die nötigen Anpassungen vornehmen. Zur Auswahl stehen alle in den Stammdaten hinterlegten Vertriebsvarianten für dieses Abo. Das Bemerkungsfeld muss ausfüllt werden. Geeignet ist hier der Hinweis bspw. auf das Email, mit dem der Teilnehmer den Wechsel gewünscht hat. Nach dem Speichern wird der Wechsel ohne weiteres Zutun in der Pendenzenliste/History abgespeichert.
-
Abotyptyp wechseln: Bei jedem Abowechsel wird das alte Abo auf inaktiv gesetzt und das neue Abo gestartet. Hier gibt es zwei Möglichkeiten: Entweder das neue Abo erhält alle Eigenschaften des alten Abos (Startdatum, Anzahl Abwesenheiten, etc.) oder das alte Abo wird abgeschlossen inkl. einer allfälligen Schlussabrechnung und das neue startet mit einem eigenen Startdatum, das dann auch neue Kündigungstermine auslöst. Im ersten Fall kann über die Veränderung des Guthabens den bereits bezogenen Abwesenheiten Rechnung getragen werden. Ein rückwirkende Eintragung von Abwesenheiten für bereits gelieferte Körbe ist nicht möglich.
-
Guthaben anpassen: Guthaben müssen dann manuell angepasst werden können, wenn beispielsweise Abwesenheiten fehlerhaft eingetragen worden sind. Diese Änderung wird am schnellsten über das Menu "Abos" erledigt, dort auf das betroffene Abo klicken. (Zum Abo kann man auch via die Kundenansicht gelangen.) Dann öffnet sich die Detailansicht des Abos. Auf den Pfeil neben dem Button "Speichern" klicken und "Guthaben anpassen" auswählen. Sogleich öffnet das entsprechende Dialog-Fenster:
Das Bemerkungsfeld muss ausfüllt werden. Geeignet ist hier der Hinweis darauf, weshalb das Guthaben verändert wurde. Nach dem Speichern wird der Wechsel ohne weiteres Zutun in der Pendenzenliste/History abgespeichert.
- Neue Kundentypen erfassen: In das Feld "Kundentyp Name..." die Bezeichnung des neuen Kundentyps eintragen und auf den Button "Erstellen" klicken.
Anschliessend das Bemerkungsfeld ausfüllen (fakultativ) und auf den Button "Speichern" klicken. Das Bemerkungsfeld kann auch nachträglich bearbeitet werden.
- Ich kann keine Abwesenheiten eintragen, es erscheint kein Datumsfeld: Abwesenheiten können nur dann eingetragen werden, wenn Lieferdaten zur Verfügung stehen. Es gilt also zu prüfen, ob für den betreffenden Abotyp Lieferdaten vorhanden sind.