X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/bfcdd44a46b2347c59bed1765768ca318a0c324e..HEAD:/doc/html/ch02s09.html diff --git a/doc/html/ch02s09.html b/doc/html/ch02s09.html index 61b3dc806..2a385fae9 100644 --- a/doc/html/ch02s09.html +++ b/doc/html/ch02s09.html @@ -1,83 +1,89 @@
-Nach der Installation müssen Mandanten, Benutzer, Gruppen und - Datenbanken angelegt werden. Dieses geschieht im Administrationsmenü, - das Sie unter folgender URL finden:
- http://localhost/kivitendo-erp/controller.pl?action=Admin/login -
Verwenden Sie zur Anmeldung das Passwort, das Sie in der Datei
- config/kivitendo.conf eingetragen haben.
kivitendo verwaltet zwei Sets von Daten, die je nach Einrichtung - in einer oder zwei Datenbanken gespeichert werden.
Das erste Set besteht aus Anmeldeinformationen: welche Benutzer
- und Mandanten gibt es, welche Gruppen, welche BenutzerIn hat Zugriff
- auf welche Mandanten, und welche Gruppe verfügt über welche Rechte.
- Diese Informationen werden in der Authentifizierungsdatenbank
- gespeichert. Dies ist diejenige Datenbank, deren Verbindungsparameter
- in der Konfigurationsdatei config/kivitendo.conf
- gespeichert werden.
Das zweite Set besteht aus den eigentlichen Verkehrsdaten eines - Mandanten, wie beispielsweise die Stammdaten (Kunden, Lieferanten, - Waren) und Belege (Angebote, Lieferscheine, Rechnungen). Diese werden - in einer Mandantendatenbank gespeichert. Die Verbindungsinformationen - einer solchen Mandantendatenbank werden im Administrationsbereich - konfiguriert, indem man einen Mandanten anlegt und dort die Parameter - einträgt. Dabei hat jeder Mandant eine eigene Datenbank.
Aufgrund des Datenbankdesigns ist es für einfache Fälle möglich, - die Authentifizierungsdatenbank und eine der Mandantendatenbanken in - ein und derselben Datenbank zu speichern. Arbeitet man hingegen mit - mehr als einem Mandanten, wird empfohlen, für die - Authentifizierungsdatenbank eine eigene Datenbank zu verwenden, die - nicht gleichzeitig für einen Mandanten verwendet wird.
kivitendos Administration kennt Mandanten, Benutzer und Gruppen, - die sich frei zueinander zuordnen lassen.
kivitendo kann mehrere Mandaten aus einer Installation heraus - verwalten. Welcher Mandant benutzt wird, kann direkt beim Login - ausgewählt werden. Für jeden Mandanten wird ein eindeutiger Name - vergeben, der beim Login angezeigt wird. Weiterhin benötigt der - Mandant Datenbankverbindungsparameter für seine Mandantendatenbank. - Diese sollte über die Datenbankverwaltung - geschehen.
Ein Benutzer ist eine Person, die Zugriff auf kivitendo erhalten - soll. Sie erhält einen Loginnamen sowie ein Passwort. Weiterhin legt - der Administrator fest, an welchen Mandanten sich ein Benutzer - anmelden kann, was beim Login verifiziert wird.
Gruppen dienen dazu, Benutzern innerhalb eines Mandanten Zugriff - auf bestimmte Funktionen zu geben. Einer Gruppe werden dafür vom - Administrator gewisse Rechte zugeordnet. Weiterhin legt der - Administrator fest, für welche Mandanten eine Gruppe gilt, und welche - Benutzer Mitglieder in dieser Gruppe sind. Meldet sich ein Benutzer - dann an einem Mandanten an, so erhält er alle Rechte von allen - denjenigen Gruppen, die zum Einen dem Mandanten zugeordnet sind und in - denen der Benutzer zum Anderen Mitglied ist,
Die Reihenfolge, in der Datenbanken, Mandanten, Gruppen und - Benutzer angelegt werden, kann im Prinzip beliebig gewählt werden. Die - folgende Reihenfolge beinhaltet die wenigsten Arbeitsschritte:
Datenbank anlegen
Gruppen anlegen
Benutzer anlegen und Gruppen als Mitglied zuordnen
Mandanten anlegen und Gruppen sowie Benutzer zuweisen
Zuerst muss eine Datenbank angelegt werden. Verwenden Sie für
- den Datenbankzugriff den vorhin angelegten Benutzer (in unseren
- Beispielen ist dies âkivitendoâ).
Eine Gruppe wird in der Gruppenverwaltung angelegt. Ihr muss ein - Name gegeben werden, eine Beschreibung ist hingegen optional. Nach dem - Anlegen können Sie die verschiedenen Bereiche wählen, auf die - Mitglieder dieser Gruppe Zugriff haben sollen.
Benutzergruppen werden zwar in der Authentifizierungsdatenbank - gespeichert, gelten aber nicht automatisch für alle Mandanten. Der - Administrator legt vielmehr fest, für welche Mandanten eine Gruppe - gültig ist. Dies kann entweder beim Bearbeiten der Gruppe geschehen - ("diese Gruppe ist gültig für Mandanten X, Y und Z"), oder aber wenn - man einen Mandanten bearbeitet ("für diesen Mandanten sind die Gruppen - A, B und C gültig").
Wurden bereits Benutzer angelegt, so können hier die Mitglieder - dieser Gruppe festgelegt werden ("in dieser Gruppe sind die Benutzer - X, Y und Z Mitglieder"). Dies kann auch nachträglich beim Bearbeiten - eines Benutzers geschehen ("dieser Benutzer ist Mitglied in den - Gruppen A, B und C").
Beim Anlegen von Benutzern werden für viele Parameter - Standardeinstellungen vorgenommen, die den Gepflogenheiten des - deutschen Raumes entsprechen.
Zwingend anzugeben ist der Loginname. Wenn die - Passwortauthentifizierung über die Datenbank eingestellt ist, so kann - hier auch das Benutzerpasswort gesetzt bzw. geändert werden. Ist - hingegen die LDAP-Authentifizierung aktiv, so ist das Passwort-Feld - deaktiviert.
Hat man bereits Mandanten und Gruppen angelegt, so kann hier - auch konfiguriert werden, auf welche Mandanten der Benutzer Zugriff - hat bzw. in welchen Gruppen er Mitglied ist. Beide Zuweisungen können - sowohl beim Benutzer vorgenommen werden ("dieser Benutzer hat Zugriff - auf Mandanten X, Y, Z" bzw. "dieser Benutzer ist Mitglied in Gruppen - X, Y und Z") als auch beim Mandanten ("auf diesen Mandanten haben - Benutzer A, B und C Zugriff") bzw. bei der Gruppe ("in dieser Gruppe - sind Benutzer A, B und C Mitglieder").
Ein Mandant besteht aus Administrationssicht primär aus einem - eindeutigen Namen. Weiterhin wird hier hinterlegt, welche Datenbank - als Mandantendatenbank benutzt wird. Hier müssen die Zugriffsdaten - einer der eben angelegten Datenbanken eingetragen werden.
Hat man bereits Benutzer und Gruppen angelegt, so kann hier auch - konfiguriert werden, welche Benutzer Zugriff auf den Mandanten haben - bzw. welche Gruppen für den Mandanten gültig sind. Beide Zuweisungen - können sowohl beim Mandanten vorgenommen werden ("auf diesen Mandanten - haben Benutzer X, Y und Z Zugriff" bzw. "für diesen Mandanten sind die - Gruppen X, Y und Z gültig") als auch beim Benutzer ("dieser Benutzer - hat Zugriff auf Mandanten A, B und C") bzw. bei der Gruppe ("diese - Gruppe ist für Mandanten A, B und C gültig").
Hintergrund-Jobs werden über System -> Hintergrund-Jobs und Task-Server -> Aktuelle Hintergrund-Jobs anzeigen -> Aktions-Knopf 'erfassen' angelegt.
Nachdem wir über das Menü dort angelangt sind, legen wir hier unseren Hintergrund-Jobs an:
+ Aktiv: Hier ein 'Ja' auswählen
+ Ausführungsart: 'wiederholte Ausführung' auswählen
+ Paketname: Hintergrundjob auswählen
+ Ausführungszeitplan: Hier entsprechend Werte wie in der crontab eingeben.
Syntax:
* * * * * +⬠⬠⬠⬠⬠+â â â â â +â â â â âââââ Wochentag (0-7, Sonntag ist 0 oder 7) +â â â âââââââ Monat (1-12) +â â âââââââââ Tag (1-31) +â âââââââââââ Stunde (0-23) +âââââââââââââ Minute (0-59)
Die Sterne können folgende Werte haben:
+1 2 3 4 5 + +1 = Minute (0-59) +2 = Stunde (0-23) +3 = Tag (0-31) +4 = Monat (1-12) +5 = Wochentag (0-7, Sonntag ist 0 oder 7) +
Um die Ausführung auf eine Minute vor den Jahreswechsel zu setzen, müssen die folgenden Werte eingetragen werden:
59 23 31 12 *
+ Daten:In diesem Feld können optionale Parameter für den Hintergrund im YAML-Format gesetzt werden.
Der Hintergrund-Job SetNumberRange kann entweder jährlich oder monatlich/täglich den Nummernkreis verändern. Der Standardmodus 'jährlich' kodiert die nächste Jahreszahl in alle Nummernkreise und initialisiert diese von Beginn, bpsw. 202500001. Zusätzlich bleiben Präfixe in den Nummernkreis erhalten und es gibt drei konfigurierbare Parameter in diesem Modus:
Der jährliche Modus (default) akzeptiert im Feld Daten drei optionale Parameter, nämlich digit_year, multiplier so wie current_year.
+ digit_year kann zwei Werte haben entweder 2 oder 4, darüber wird gesteuert ob die Jahreszahl zwei oder vierstellig kodiert wird (für 2019, dann entweder 19 oder 2019). Der Standardwert ist vierstellig.
+ multiplier ist ein Vielfaches von 10, darüber wird die erste Nummer im Nummernkreis (die Anzahl der Stellen) wie folgt bestimmt:
+multiplier Nummernkreis 2020 +10 -> 20200 +100 -> 202000 +1000 -> 2020000 +
Falls der Parameter current_year bspw. so gesetzt ist:
+
current_year: 1
+ wird der Nummernkreis nicht um eins hochgezählt. Das ist sinnvoll wenn vom 31.12. auf den 01.01. sowieso keine Rechnungsläufe stattfinden und man die Nummernkreise dann am 01.01. des neuen Jahres automatisch hochsetzen möchte.
Wir gehen jetzt beispielhaft von einer letzten Rechnungsnummer von RE2019456 aus. Demnach sollte ab Januar 2020 die erste Nummer RE2020001 sein. Da der Task auch Präfixe berücksichtigt, kann dies mit folgenden JSON-kodierten Werten umgesetzt werden:
+ Daten:
+
multiplier: 100 +digits_year: 4
Dieser Job müsste dann zwingend vor Mitternacht des 31.12. ausgeführt werden.
+ Daten:
+
multiplier: 100 +digits_year: 4 +current_year: 1
Mit dieser Einstellung kann der Job auf 00:01h des 01.01. gesetzt werden.
Der (wahrscheinliche) monatliche Modus wird über den Parameter monthly gesteuert und erzeugt standardmäÃig folgende Nummernkreise JJ-MM-000, bspw. am 01.04.2025 25-04-000. Dieser Modus akzeptiert die zwei optionalen Parameter monthly_postfix für die Ãberlagerung am Ende der Zeichenkette und monthly_strftime für die beliebige Formatierung der strftime C-Methode, s.a. strftime-Patterns.
+Folgende Parameter erzeugen am 01.04.2025 folgenden Nummernkreis: 2025-04-01-A0001.
+
+ Daten:
+
+ +
+monthly: 1 +monthly_postfix: '-A0001' +monthly_strftime: '%Y-%m-%d' +
+ +
Der Hintergrund-Job ImportRecordEmails kann vollständig über das Feld Daten konfiguriert werden. Er benötigt folgende Variablen:
+ hostname: Hier wird der E-Mail-Server (IMAP) eingetragen
+ username: Benutzername, für den IMAP-Server (häufig die E-Mail-Adresse)
+ password: Passwort des Benutzers
+ folder: Hier wird der Ordner eingetragen, aus dem die E-Mails importert werden sollen, bspw. 'INBOX'
+ port: Port am E-Mail-Server. Default ist 993
+ ssl: Gibt an ob SSL verwendet werden soll. Default: 1
Optional können auÃerdem folgende Variablen verwendet werden:
+ email_import_ids_to_delete: Hier können IDs von Importen eingetragen werden, deren E-Mails aus dem E-Mail-Journal gelöscht werden sollen.
+ process_imported_emails: Wenn nach dem Import noch weitere Verarbeitung der angehangenen Dokumente erfolgen soll, müssen hier die jeweiligen Schritte eingetragen werden. Aktuell ist es möglich, dass angehangene ZUGFeRD-Rechnung direkt verbucht und mit der E-Mail verknüpft werden. Dazu muss hier 'zugferd' eingetragen werden.
+ processed_imap_flag: Das hier eingetragenen Flag wird nach dem Verarbeiten in der E-Mail auf den IMAP-Server gesetzt.
+ not_processed_imap_flag: Dieses Flag wird gesetzt, wenn die E-Mail nicht verarbeitet werden konnte.
+ record_type: Einträge im E-Mail-Journal können direkt einem Belegtypen zugeordnet werden. Wenn alle E-Mails, die mit einem Hintergrundjob importiert werden, den gleichen Belegtypen haben, kann man diesen hier festlegen und alle Einträge im E-Mail-Journal werden entsprechend zugeordnet. Für Eingangsrechnungen kann man hier bspw. 'ap_transaction' setzen.
Wie die IMAP Flags von den jeweiligen Clients angezeigt und eingerichtet werden, ist aktuell im Thunderbird (Version 115.8.0 und Version 115.8.1) und SoGo (Version 5.9.1) getestet:
In Thunderbird heiÃen die Flags Schlagwörter. In unseren beiden Testfälle, war das Verfahren unterschiedlich:
Thunderbird 115.8.0: Sie werden durchnummeriert mit dem Prefix "$label". Ãber die Einstellungen kann man Schlagwort und Farbe für den jeweiligen Tag setzen und berabeiten. Um die vordefenierten Tags in Thunderbird zu nutzen kann man $label1 - $label5 nutzen. Eigene Labels werden dann von thunderbird automatisch hochgezählt. Um das korrekte Tag für ein Label zu finden oder auch selbst ein Tag mit einer selbst gewählten Zahl zu definieren kann man in den Einstellunge ganz am Ende über den Button Konfiguration berabeiten... die Werte in der Kofiguration einsehen, ändern und berabeiten. Hier muss man nach mailnews.tags suchen.
Thunderbird 115.8.1: Einstellungen -> Schlagwörter -> hinzufügen. Das Schlagwort wird mit dem 'Label' 'name_mit_unterstrichen' zu Verfügung gestellt. Was wirklich passiert kann man dann ganz unten in den Einstellungen unter 'Konfiguration bearbeiten' und einer darauf folgenden Filtersuche nach 'mailnews.tag' erkennen.
In SoGo kann man unter Einstellungen -> Mail -> Labels beliebige Label mit $ als Prefix anlegen und Namen und Farbe zuweisen.
Eine beispielhafte Konfiguration im YAML-Format für das Feld 'Daten' im Hintergrund-Job könnte bspw. so aussehen: +
+record_type: ap_transaction +folder: INBOX/Eingangsrechnung +processed_imap_flag: zugferd_verarbeitet +not_processed_imap_flag: zugferd_geht_net +process_imported_emails: zugferd +hostname: www.meine-domaene.de +username: alpha39@meine-domaene.de +password: supipass8 +
+ +
Besteht die Anforderung, vor einer Inventur sämtliche Lagerplätze mittels Korrekturbuchungen auf Bestand 0 zu bringen, so kann dies mit dem Hintergrund-Job InventoryClearAll erledigt werden.
![]() | Anmerkung |
|---|---|
Damit diese Korrekturbuchungen nur einmalig auf Nutzerwunsch ausgeführt werden und nicht ausversehen periodisch das Lager leer räumen, muss die Variable correction_date auf das aktuelle Datum gesetzt sein. Die Korrekturbuchungen können nicht ohne Weiteres rückgängig gemacht werden.
+ Nachdem der Job im Menü System -> Hintergrund-Jobs und Task-Server -> Aktuelle Hintergrund-Jobs anzeigen erfasst wurde, kann er einmalig ausgeführt werden, indem beim Bearbeiten der Button Speichern und Ausführen gewählt wird. |
Im Feld Daten werden folgende Variablen akzeptiert:
+ correction_date: Das aktuelle Datum in der Form YYYY-MM-DD, sonst läuft der Job nicht
+ comment: (optional) Wird in den Korrekturbuchungen als Kommentar gesetzt. Falls kein Wert gegeben ist, wird der Kommentar vor Inventur gesetzt
+ dry_run: (optional) Falls dry_run: 1 gesetzt ist, werden keine Korrekturbuchungen ausgeführt, die notwenigen Korrekturbuchungen werden lediglich im Ergebnis des Jobs angezeigt
+ warehouse: (optional) Schränkt die Korrekturbuchungen auf ein bestimmtes Lager ein; andernfalls werden Korrekturbuchungen für alle Lager ausgeführt
Ein Konfigurationsbeispiel ist:
+correction_date: 2025-03-11 +comment: vor Inventur +dry_run: 1 +# warehouse: Stahllager Industriepark Gallin +
Gibt es viele alte offene Preisanfragen im Einkauf und Angebote im Verkauf, so können diese komfortabel mit dem Hintergrund-Job CloseQuotations geschlossen werden.
Im Feld Daten werden folgende Variablen akzeptiert:
+ dry_run: (optional) Falls dry_run: 1 gesetzt ist, werden keine Belege geschlossen, die Nummern der betroffenen Belege werden lediglich im Ergebnis des Jobs angezeigt
+ years: (optional) Anzahl der Jahre, die offene Preisanfragen und Angebote alt sein müssen, damit sie geschlossen werden. Standardwert: years: 1 (ein Jahr)
Ein Konfigurationsbeispiel ist:
+dry_run: 1 +years: 1 +