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 drei alternative Vorlagensätze mit:
Standard
f-tex
RB
Im Administrationsbereich lässt sich bei einem Benutzer/Mandanten einer dieser Vorlagensätze als Basis für die zu - druckenden Dokumente auswählen. Rufen Sie dazu die auf.
Wählen Sie dort einen Benutzer aus oder legen Sie einen neuen an. In der Benutzerbearbeiten-Maske müssen Sie zwei Dinge - angeben:
- Name: Der Verzeichnisname für den neuen Vorlagensatz. Dieser kann im Rahmen der üblichen
- Bedingungen für Verzeichnisnamen frei gewählt werden.
- Vorlagen auswählen: Wählen Sie hier den Vorlagensatz aus, der kopiert werden soll
- (Standard, f-tex oder RB.)
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 Verfügung stellt.
Keine Redundanz. Es wird ein- und dieselbe LaTeX-Vorlage für alle briefartigen Dokumente verwendet. Also - Angebot, Rechnung, Performarechnung, Lieferschein, aber eben nicht für Paketaufkleber etc..
Leichte Anpassung an das Firmen-Layout durch verwendung eines Hintergrund-PDF. Dieses kann leicht mit dem - eigenen Lieblingsprogramm erstellt werden (Openoffice, Inkscape, Gimp, Adobe*)
Hintergrund-PDF umschaltbar auf "nur erste Seite" (Standard) oder "alle Seiten" (Option
- "bgPdfFirstPageOnly" in Datei letter.lco)
Hintergrund-PDF für Ausdruck auf bereits bedrucktem Briefpapier abschaltbar. Es wird dann nur bei per E-Mail
- versendeten Dokumenten eingebunden (Option "bgPdfEmailOnly" in Datei
- letter.lco).
Nutzung der Layout-Funktionen von LaTeX für Seitenumbruch, Wiederholung von Kopfzeilen, Zwischensummen - etc. (danke an Kai-Martin Knaak für die Vorarbeit)
Anzeige des Empfängerlandes im Adressfeld nur, wenn es vom Land des eigenen Unternehmens abweicht (also die - Rechnung das Land verlässt).
Multisprachfähig leicht um weitere Sprachen zu erweitern, alle Ãbersetzungen in der Datei
- translatinos.tex.
Auflistung von Bruttopreisen für Endverbraucher.
Vorlagenverzeichnis mit Option f-tex anlegen, siehe: Vorlagenverzeichnis anlegen. Das - Vorlagensystem funktioniert jetzt schon, hat allerdings noch einen Beispiel-Briefkopf.
Erstelle eine pdf-Hintergrund Datei und verlinke sie nach ./letter_head.pdf.
Editiere den Bereich "settings" in der datei letter.lco.
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 Hintergrund-PDF 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 Hintergrund-PDF 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 LaTeX-Vorlage verwendet, welche über Codeweichen die - Besonderheiten der jeweiligen Dokumente Berücksichtigt. -
Tabellen mit oder ohne Preis
Sprache der Tabellenüberschriften etc.
Anpassung der Bezugs-Zeile (z.B. Rechnungsnummer versus Angebotsnummer)
Darstellung von Brutto oder Netto-Preisen in der Auflistung (Endverbraucher versus Gewerblicher - Kunde)
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.
Der auszuweisende Bruttopreis wird innerhalb der LaTeX-Umgebung berechnet. Es gibt zwar ein Feld, um bei Aufträgen "alle - Preise Brutto" auszuwählen, aber:
hierfür müssen die Preise auch in Brutto in der Datenbank stehen (ja - das lässt sich über die Preisgruppen und die - Zuordung einer Default-Preisgruppe handhaben)
man darf beim Anlegen des Vorgangs nicht vergessen Dieses Häkchen zu setzen. (das ist in der Praxis wenn man sowohl - Endverbraucher- wie Gewerbekunden beliefert der eigentliche Knackpunkt)
- 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:
Die Entscheidung, ob Netopreise ausgewiesen werden, ist nicht mehr fix mit einer Preisliste Verbunden.
Die Default-Zahlart kann im Kundendatensatz hinterlegt werden, und man muss nicht mehr daran denken, "alle Preise - Netto" auszuwählen.
Die Entscheidung, ob Netto- oder Bruttopreise ausgewiesen werden, kann direkt beim Drucken reviediert werden, - ohne dass sich der Auftragswert ändert.
In Lieferscheinen kommen shipto*-Variablen im Adressfeld zum Einsatz. Wenn die
- shipto*-Variable leer ist, wird die entsprechende Adressvariable eingesetzt. Wenn also die Lieferadresse in
- StraÃe, Hausnummer und Ort abweicht, müssen auch nur diese Felder in der Lieferadresse ausgefüllt werden. Für den Firmenname wird
- der Wert der Hauptadresse angezeigt.
-
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:... 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 +