Das Drucksystem von kivitendo benutzt von Haus aus LaTeX Vorlagen.
- Um drucken zu können, braucht der Server ein geeignetes LaTeX System. Am
- einfachsten ist dazu eine texlive Installation. Unter
- Debianoiden Betriebssystemen installiert man die Pakete mit:
-
aptitude install \ - texlive-base-bin \ -texlive-latex-recommended \ -texlive-fonts-recommended \ -texlive-latex-extra \ -texlive-lang-german \ -texlive-generic-extra -
-
TODO: rpm Pakete.
kivitendo bringt 3 alternative Vorlagensätze mit:
Bei einem neuen Benutzer/Mandanten lässt sich einer dieser Vorlagensätze - als Basis für die zu druckenden Dokumente auswählen:
-
unter: -Administration -> Benutzerverwaltung -> [ein Benutzer] - Erzeuge Vorlagen, Name: [Name für das neue Vorlagenverzeichnis] - Vorlagen auswählen: [Default, f-tex oder RB] - -> Speichern -
-
der gleiche Vorlagensatz kann, wenn er mal angelegt ist, bei mehreren Benutzern verwendet werden.
Die Abhängigkeiten kann man prüfen mit:
-
/scripts/installation_check.pl -l
-
Der standard Vorlagensatz von Kivitendo. Wie unter - http://demo.kivitendo.org zu sehen.
Ein Vorlagensatz, der in Wenigen Minuten alle Dokumente zur stellt.
./letter_head.pdf
oder etwas Detaillierter:
- Es wird eine Datei sample.lco erstellt und diese nach letter.lco verlinkt. - Eigentlich ist dies die Datei die für die Firmenspezifischen Anpassungen - gedacht ist. Da die Einstiegshürde in LaTeX nicht ganz niedrig ist, wird in - dieser Datei auf ein Hintergrundpdf verwiesen. Ich empfehle über dieses pdf - die persönlichen Layoutanpassungen vorzunehmen und sample.lco unverändert zu - lassen. Die die Anpassung über eine *.lco Datei die letztlich auf letter.lco - verlinkt ist ist aber auch möglich. +
Informationen über die Einrichtung der Benutzerauthentifizierung, + über die Verwaltung von Gruppen und weitere Einstellungen
kivitendo verwaltet die Benutzerinformationen in einer + Datenbank, die im folgenden âAuthentifizierungsdatenbankâ genannt + wird. Für jeden Benutzer kann dort eine eigene Datenbank für die + eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken + können, müssen aber nicht unterschiedlich sein.
Im einfachsten Fall gibt es für kivitendo nur eine einzige + Datenbank, in der sowohl die Benutzerinformationen als auch die Daten + abgelegt werden.
Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter gegen verschiedene Authentifizierungsmethoden geprüft + werden. Dazu zählen die Authentifizierungsdatenbank, LDAP-Server sowie verschiedene Arten von HTTP-Header-basierten Methoden.
Welche Art der Passwortüberprüfung kivitendo benutzt und wie
+ kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der
+ Konfigurationsdatei config/kivitendo.conf
+ festgelegt. Diese muss bei der Installation und bei einem Upgrade von
+ einer Version vor v2.6.0 angelegt werden. Eine
+ Beispielkonfigurationsdatei
+ config/kivitendo.conf.default existiert, die als
+ Vorlage benutzt werden kann.
Das Passwort, das zum Zugriff auf das Administrationsinterface
+ von kivitendo benutzt wird, wird ebenfalls in dieser Datei
+ gespeichert. Es kann auch nur dort und nicht mehr im
+ Administrationsinterface selber geändert werden. Der Parameter dazu
+ heiÃt admin_password im Abschnitt
+ [authentication].
Die Verbindung zur Authentifizierungsdatenbank wird mit den
+ Parametern in [authentication/database]
+ konfiguriert. Hier sind die folgenden Parameter anzugeben:
host
+ Der Rechnername oder die IP-Adresse des + Datenbankservers
port
+ Die Portnummer des Datenbankservers, meist 5432
db
+ Der Name der Authentifizierungsdatenbank
user
+ Der Benutzername, mit dem sich kivitendo beim
+ Datenbankserver anmeldet (z.B.
+ "postgres")
password
+ Das Passwort für den Datenbankbenutzer
Die Datenbank muss noch nicht existieren. kivitendo kann sie + automatisch anlegen (mehr dazu siehe unten).
kivitendo unterstützt verschiedene Module für die Passwortüberprüfung. Welche benutzt wird, regelt der Parameter
+ module im Abschnitt [authentication].
Dieser Parameter listet die zu verwendenden Authentifizierungsmodule auf. Es muss mindestens ein Modul angegeben werden, es + können aber auch mehrere angegeben werden. Weiterhin ist es möglich, das LDAP-Modul mehrfach zu verwenden und für jede Verwendung + eine unterschiedliche Konfiguration zu nutzen, z.B. um einen Fallback-Server anzugeben, der benutzt wird, sofern der Hauptserver + nicht erreichbar ist.
Verfügbare Module sind:
+ DB: in Authentifizierungsdatenbank integrierte Benutzerverwaltung
+ ldap: Bind mit User-Objekten gegen einen oder mehrere LDAP-Server
+ http_headers: überlässt Authenfizierung vorgelagerten Proxy-Servern übernimmt Usernamen
+ aus mitgeschickten HTTP-Headern
Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank geprüft werden, so muss der Parameter
+ module das Modul DB enthalten. Sofern das Modul in der Liste enthalten ist, egal an welcher
+ Position, können sowohl der Administrator als auch die Benutzer selber ihre Passwörter in kivitendo ändern.
Wenn Passwörter gegen einen oder mehrere externe LDAP- oder Active-Directory-Server geprüft werden, so muss der Parameter
+ module den Wert LDAP enthalten. In diesem Fall müssen zusätzliche Informationen über den
+ LDAP-Server im Abschnitt [authentication/ldap] angegeben werden. Das Modul kann auch mehrfach angegeben werden,
+ wobei jedes Modul eine eigene Konfiguration bekommen sollte. Der Name der Konfiguration wird dabei mit einem Doppelpunkt getrennt an
+ den Modulnamen angehängt (LDAP:Name-der-Konfiguration). Der entsprechende Abschnitt in der Konfigurationsdatei
+ lautet dann [authentication/Name-der-Konfiguration].
Die verfügbaren Parameter für die LDAP-Konfiguration lauten:
host
+ Der Rechnername oder die IP-Adresse des LDAP- oder + Active-Directory-Servers. Diese Angabe ist zwingend + erforderlich.
port
+ Die Portnummer des LDAP-Servers; meist 389.
tls
+ Wenn Verbindungsverschlüsselung gewünscht ist, so diesen
+ Wert auf â1â setzen, andernfalls auf
+ â0â belassen
verify
+ Wenn Verbindungsverschlüsselung gewünscht und der Parameter tls gesetzt ist, so gibt dieser
+ Parameter an, ob das Serverzertifikat auf Gültigkeit geprüft wird. Mögliche Werte sind require (Zertifikat
+ wird überprüft und muss gültig sei; dies ist der Standard) und none (Zertifikat wird nicht
+ überpfüft).
attribute
+ Das LDAP-Attribut, in dem der Benutzername steht, den der
+ Benutzer eingegeben hat. Für Active-Directory-Server ist dies
+ meist âsAMAccountNameâ, für andere
+ LDAP-Server hingegen âuidâ. Diese Angabe ist
+ zwingend erforderlich.
base_dn
+ Der Abschnitt des LDAP-Baumes, der durchsucht werden soll. + Diese Angabe ist zwingend erforderlich.
filter
+ Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort
+ <%login%>, so wird dieses durch den vom
+ Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird
+ der LDAP-Baum nach einem Element durchsucht, bei dem das oben
+ angegebene Attribut mit dem Benutzernamen identisch ist.
bind_dn und
+ bind_password
+ Wenn der LDAP-Server eine Anmeldung erfordert, bevor er
+ durchsucht werden kann (z.B. ist dies bei
+ Active-Directory-Servern der Fall), so kann diese hier angegeben
+ werden. Für Active-Directory-Server kann als
+ âbind_dnâ entweder eine komplette LDAP-DN wie
+ z.B. âcn=Martin
+ Mustermann,cn=Users,dc=firmendomainâ auch nur der
+ volle Name des Benutzers eingegeben werden; in diesem Beispiel
+ also âMartin Mustermannâ.
timeout
+ Timeout beim Verbindungsversuch, bevor der Server als nicht erreichbar gilt; Standardwert: 10
+ Diese Methode der Authentifizierung überlässt einem vorgelagerten Webserver oder Proxyserver die Authentifizierung. Dazu können + SSO-Systeme wie z.B. Authelia oder Authentik zum Einsatz kommen. Die vorgelagerten Server übermitteln dann den Usernamen der + authentifizierten Person in einem speziellen HTTP-Header, der an kivitendo durchgereicht wird. Damit kivitendo nicht von + beliebigen Quellen aus mit so einem Usernamen aufgerufen werden kann, verlangt kivitendo weiterhin, dass in einem weiteren + Header ein Shared Secret übertragen wird. Dieses Secret wird vom Administrator vergeben und sollte nicht weitergegeben werden.
- Es wird eine Datei sample_head.pdf mit ausgeliefert, diese wird nach - letter_head.pdf verlinkt. Damit gibt es schon mal eine Funktionsfähige - Vorlage. Schau Dir nach Abschluss der Installation die Datei sample_haed.pdf - an und erstelle ein entsprechendes pdf passend zum Briefkopf Deiner Firma, - diese dann im Template Verzeichniss ablegen und statt sample_head.pdf nach - letter_head.pdf verlinken. + Ãber einen weiteren Header wird wiederum gesteuert, an welchem Mandanten die Anmeldung erfolgt. Dies geschieht über die + Datenbank-ID des Mandanten.
- letzlich muss ./letter_head.pdf auf das passende Hintergrundpdf verweisen, - welches gewünschten Briefkopf enthält. Bei Updates oder nach erneutem -
- Es wird eine Datei mydata.tex.example ausgeliefert die nach mytdata.tex - verlinkt ist. Bei verwendetem Hintergrundpdf wird nur der Eintrag für das - Land verwendet die Datei muss also nicht angefasst werden. Die Anderen Werte - sind für das Modul lp (Label Print in erp - zur Zeit nicht im - öffentlichen Zweig). -
- Alle Anpassungen zum Briefkopf, Fusszeilen, Firmenlogos, etc. - sollten über die Hintergrund pdf datei oder die *.lco Datei erfolgen. -
- Das Konzept von kivitendo sieht vor, für jedes Dokument - (Auftragsbestätigung, Lieferschein, Rechnung, etc.) eine - Latex-Vorlage vorzuhalten, dies ist sehr Wartungsunfreundlich. Auch - das Einlesen einer einheitlichen Quelle für den Briefkopf bringt nur - bedingte Vorteile, da hier leicht die Pflege der Artikel-Tabellen aus - dem Ruder läuft. Bei dem vorliegenden Ansatz wird für alle - Briefartigen Dokumente mit Artikel-Tabellen eine einheitliche - Latexvorlage verwendet, welche über Codeweichen die Besonderheiten - der jeweiligen Dokumente Berücksichtigt -
Nachteil:
- Latex hat ohnehin eine sehr steile Lehrnkurve. Die Datei letter.tex - ist sehr komplex und verstärkt damit diesen Effekt noch einmal erheblich. - Wer Latex-Erfahrung hat, oder geübt ist Scriptsparachen nachzuvollziehen kann - natürlich auch innerhalb der Tabellendarstellung gut persönliche Anpassungen - vornehmen. Aber man kann sich hier bei Veränderungen sehr schnell häftig in - den Fuss schiessen. -
Wer nicht so tief in die Materie einsteigen will oder leicht zu - frustrieren ist, sollte sein Hintergrund PDF auf Basis der mitglieferten - Datei sample_head.pdf erstellen, und sich an der Form der dargestellten Tabellen - wie sie ausgeliefert werden, erfreuen. -
Kleiner Tipp: - Nicht zu viel auf einmal wollen, lieber kleine kontinuierliche - Schritte gehen. -
Bruttopreise für Endvorbraucher
Der auszuweisende Bruttopreis wird innerhalb der LaTeX - Umgebung berechnet. es gibt zwar ein Feld um bei Aufträgen "alle Preise - Brutto" auszuwählen, aber:
- Es gibt mit f-tex eine weitere Alternative. Die Information ob Brutto oder - Nettorechnung wird mit den Zahlarten verknüpft. Zahlarten bei denen - Rechnungen, Angebote, etc, in Brutto ausgegeben werden sollen enden mit "_E" - (für Endverbraucher) Falls identische Zahlarten für Gewerbekunden und - Endverbraucher vorhanden sind legt man diese einfach doppelt an (einmal mit - der Namensendung "_E"). Gewinn:
Lieferadressen
In den allermeisten Installationen sollte drucken jetzt schon - funktionieren. Sollte ein Fehler auftreten wirft TeX sehr lange - Fehlerbeschreibungen, der eigentliche Fehler ist immer die erste Zeite - die mit einem Ausrufezeichen anfängt. Häufig auftretende Fehler sind zum - Beispiel:
! LaTeX Error: File `eurosym.sty' not found. Die entsprechende - LaTeX-Bibliothek wurde nicht gefunden. Das tritt vor allem bei - Vorlagen aus der Community auf. Installieren Sie die entsprechenden - Pakete.
! Package inputenc Error: Unicode char \u8:æ¡ not set up for - use with LaTeX. Dieser Fehler tritt auf, wenn sie versuchen mit - einer Standardinstallation exotische utf8 Zeichen zu drucken. - TeXLive unterstützt von Haus nur romanische Schriften und muss mit - diversen Tricks dazu gebracht werden andere Zeichen zu akzeptieren. - Adere TeX Systeme wie XeTeX schaffen hier Abhilfe.
Wird garkein Fehler angezeigt sondern nur der Name des Templates,
- heiÃt das normalerweise, dass das LaTeX Binary nicht gefunden wurde.
- Prüfen Sie den Namen in der Konfiguration (Standard:
- pdflatex), und stellen Sie sicher, dass pdflatex
- (oder das von Ihnen verwendete System) vom Webserver ausgeführt werden
- darf.
Wenn sich das Problem nicht auf Grund der ausgabe im Webbrowser verifizieren lässt:
editiere [kivitendo-home]/config/kivitendo.conf und ändere "keep_tmp_files" auf 1
-
keep_temp_files = 1;
-
bei fastcgi oder mod_perl den Webserver neu Starten
Nochmal einen Druckversuch im Webfrontend auslösen
wechsele in das users Verzeichnis von kivitendo
-
cd [kivitendo-home]/users
-
LaTeX Suchpfad anpassen:
-
export TEXINPUTS=".:[kivitendo-home]/templates/[aktuelles_template_verzeichniss]:"
-
Finde herraus welche Datei kivitendo beim letzten Durchlauf erstellt hat
-
ls -lahtr ./1*.tex
-
Es sollte die letzte Datei ganz unten sein
für besseren Hinweis auf Fehler texdatei nochmals übersetzen
-
pdflatex ./1*.tex
-
in der *.tex datei nach dem Fehler suchen.
HTTPHeaders gestellt werden. Zusätzlich
+ muss im Abschnitt authentication/http_headers der Parameter enabled=1 und im Abschnitt
+ authentication/http_basic der Parameter enabled=0 gesetzt werden. Die folgenden Parameter
+ müssen anschlieÃend im Abschnitt authentication/http_headers konfiguriert werden:
+ client_id_header
+ Name des Headers, in dem das vorgelagerte System die Datenbank-ID des Mandanten überträgt.
user_header
+ Name des Headers, in dem das vorgelagerte System den Namen des authentifizierten Users überträgt.
secret_header
+ Name des Headers, in dem das vorgelagerte System das Shared Secret.
secret
+ Wert des Shared Secrets selber, der vom vorgelagerten System übertragen werden muss, damit die Werte als gültig + angesehen werden.
+ Diese Methode der Authentifizierung überlässt dem Webserver (meist Apache) die Authentifizierung mittels der standardisierten + HTTP Basic Authentication (RFC 7617). Dazu muss der Webserver so konfiguriert werden, dass er für alle kivitendo-Requests vom + Webbrowser Authentifizierung verlangt. Zusätzlich muss er veranlasst werden, den angegebenen Usernamen auch an kivitendo zu + übermitteln. Dies könnte beispielhaft wie folgt aussehen: +
<Directory /path/to/kivitendo-erp> + AllowOverride All + Options ExecCGI Includes FollowSymlinks + + # Require authentication from local user file: + AuthType Basic + AuthName "kivitendo" + AuthUserFile /etc/apache2/htpasswd.kivitendo + Require valid-user + + # Pass name of authorized user to kivitendo: + SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 +</Directory>
+ Um diese Methode zu aktivieren, muss das Authentifizierungsmodul auf HTTPHeaders gestellt werden. Zusätzlich
+ muss im Abschnitt authentication/http_basic der Parameter enabled=1 und im Abschnitt
+ authentication/http_headers der Parameter enabled=0 gesetzt werden.
+
Sollen auf einem Server mehrere kivitendo-Installationen
+ aufgesetzt werden, so müssen die Namen der Session-Cookies für alle
+ Installationen unterschiedlich sein. Der Name des Cookies wird mit dem
+ Parameter cookie_name im Abschnitt
+ [authentication]gesetzt.
Diese Angabe ist optional, wenn nur eine Installation auf dem + Server existiert.
Nachdem alle Einstellungen in
+ config/kivitendo.conf vorgenommen wurden, muss
+ kivitendo die Authentifizierungsdatenbank anlegen. Dieses geschieht
+ automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter
+ der folgenden URL erreichbar sein sollte:
+ http://localhost/kivitendo-erp/controller.pl?action=Admin/login +