Category Archives: Unstable

aktuelle Entwicklerversion von kivitendo installieren

Wer schon einmal die aktuelle Entwicklung in seiner Umgebung ausprobieren möchte, installiert am Besten eine Version mittels git wie folgt:

Bildschirmfoto vom 2017-03-21 08-11-31

Danach einfach die Schritte wie in der Installationsanleitung beschrieben durchführen.

Wer schon eine bestehende git-Installation hat, kann diese einfach kopieren und dann im Apache als weitere Installation konfigurieren, bspw.


$ cp -a kivitendo/ kivitendo-devel/
$ cd kivitendo-devel/
$ git branch # zeigt die aktuellen zweige
$ git checkout master
$ git pull
$ vim config/kivitendo.conf # !!! die auth-db ändern, damit nicht das Echtsystem hochgezogen wird!
- db = kivitendo_auth
+ db = kivitendo_auth_devel
$ service apache2 restart

Den Rest dann in der apache.conf einstellen, wie in der Anleitung beschrieben.
Ich hab in der Regel ein kleines Synchronisationsskript um Echtdaten direkt in eine Test-DB zu analysieren, in etwa so:

#!/bin/bash
pg_dump -U postgres -h 127.0.0.1 kivi > /tmp/kivi.sql
psql -U postgres -h 127.0.0.1 template1 < drop-create-devel.sql
psql -U postgres -h 127.0.0.1 kivi-devel < /tmp/kivi.sql

$ cat drop-create-devel.sql

DROP DATABASE kivi-devel;
CREATE DATABASE kivi-devel;

kivitendo mit E-Mail-Journal

Das hat mich heute sehr gefreut, diesen Commit auf der Projektliste zu sehen:

commit 72f19f83681b222d1606d75c90ceedc43bb545f9
Author: Moritz Bunkus <m.bunkus@linet-services.de>
Date: Thu Sep 24 11:42:15 2015 +0200

E-Mail-Journal: Journal anzeigen, Eintrag anzeigen, Anhänge herunterladen

In unseren Projekten empfehlen wir immer möglichst viel über die E-Mail-Funktion des Systems zu versenden, da dies dann im internen Bemerkungsfeld der Belege entsprechend mitprotokolliert wird. Blöderweise kann man hierüber keine direkte Auswertung sehen.
Das ändert sich ab heute in der devel-Version von kivitendo und in einigen Monaten dann im nächsten Release.

Wenn jetzt E-Mails verschickt werden, werden zusätzlich noch der Status (erfolgreich versendet) und der Zeitpunkt in einem extra Bericht mitprotokolliert:

In der Detailansicht der Mail wird dann auch nochmal die gesamte E-Mail inkl. Dokumentanhang dargestellt. Somit ist dies zusätzlich zu der WebDAV-Archivierung der Belege eine richtig sinnvolle Archivfunktion, um wirklich nachzuvollziehen, was an den Empfänger in welchen Zeitraum geschickt wurde. Ferner ist dann auch die Darstellung der Mail etwas klarer, weil hier alle E-Mail-Teile nochmal angezeigt werden:

Da zwei sehr schöne Features in der aktuellen Devel-Version vorhanden sind und außer wirklichen Bugfixes seit dem Release nichts weiter passiert ist, lohnt sich vielleicht schon jetzt ein Upgrade auf die heutige Version.

Administratoren, die aus dem git heraus installiert haben und lokale Änderungen im eigenen Branch verwalten (s.a. Vortragsfolien git und kivitendo bzw. Video) können heute bedenkenlos (insofern 3.3 im Einsatz):


$ git checkout master
$ git pull
$ git checkout mein_eigener_branch
$ git rebase master
$ service apache2 restart

durchführen …

Schnellwachsende Südfrüchte – Massenkonvertieren von Lieferscheinen nach Rechnungen

Kaum ist die 3.3 zwei Wochen in Umlauf, geht es mit der Entwicklerversion in Windeseile weiter.
Aktuell haben wir die sehr gute Situation, dass einige Shopschnittstellen mit hohem Durchsatz an kivitendo angebunden werden.
Für diese Kundengruppe geht es vor allem um eins:

Geschwindigkeit und Einfachheit!

kivitendo muss hier möglichst mit einem Klick sehr viel lästige Kleinarbeit erledigen.
Aus einem dieser Projekte stammt die gerade eingefügte Erweiterung (git commit 4edb3a6f7d23140ec7ca67).
Der Prozess ist wie folgt: Waren werden gepackt und mit Lieferschein und Rechnung verschickt.
Durch eine geschickte Kombination von Hintergrund-Job und Objekt-Konvertierung kommen wir hier (auf unserem Testsystem) auf einen Durchsatz von 440 Lieferscheinen konvertiert zu Rechnungen und an den Netzwerkdrucker übergeben in 7 Minuten. Innerhalb einer Sekunde wird ein Lieferschein gewandelt und zum Drucker geschickt.

Trotzdem hat kivitendo noch Zeit, den aktuellen Status des Prozesses an den Nutzer zu melden und paralleles Weiterarbeiten ist nicht nur möglich, sondern erwünscht ;-).

Der nächste Optimierungs-Schritt wäre hier dann beim Durchsatz, indem man den Ausdruck parallelisiert, aber da warten wir lieber, bis ein begeisterter kivi-Fan in diese Problem-Dimension kommt.

Die obigen Ergebnisse kann man prinzipiell mit einer Server-Client-Lösung im Web (neudeutsch: Cloud) erzielen, allerdings knickt die Performanz auch bei der 10-fachen Menge (4400 Lieferscheine) nicht wesentlich ein und liefert annähernd konstant denselben Durchsatz-Wert (4400 Lieferscheine in kleiner 2h)
Das Druckdokument hat eine Größe von 43 MB mit mehr als 5000 Seiten. In der Kette ist  der Speicher des Netzwerkdruckers dann das nächste Nadelöhr, das kann man aber kivi-seitig auch noch optimieren, indem man einen maximalen Größenwert definiert und die Übergabe an den Drucker bei Erreichen dieses Wertes portioniert.

Ich bin zufrieden ;-).

Langtexteditor

Im Zuge der Pflichtenhefterweiterung in der derzeitigen Unstable wurde durch LINET auch ein kleiner Onlineeditor für die Langtextbeschreibung von Artikeln eingeführt.

Anbei zwei Screenshots von der Artikelbearbeitung und einem PDF-Ausdruck einer LaTeX-Vorlage.

Upgrade auf die aktuelle Unstable – ein kleiner Erfahrungsbericht

W

Mit dem ersten Kunden sind wir vor zwei Wochen auf die aktuelle Unstable von kivitendo migriert, da endlich die Mandantenfähigkeit benutzt werden sollte.

Abgesehen vom Rebase für die kundenspezifischen Anpassungen gab es ein paar Hürden zu meistern:

Die neue Version setzt eine neuere Rose-Version voraus, hierfür mußte die Ubuntu Installation auf die Version 12.04 hochgezogen werden, womit sich auch gleich PostgreSQL von Version 8.4 auf 9.1 verbessert hat.

Mit diesem Update müssen ab sofort alle Artikelnummern eindeutig sein. Man kann nicht mehr z.B. einen Artikel und eine Dienstleistung beide mit der Nummer 1 haben. Im Laufe des Updateprozesses wird dies geprüft, und bei doppelten Artikeln erhält man die Möglichkeit, diese entsprechend zu ändern.

Aus dem Freitextfeld für Standardlagerplatz in der Artikelverwaltung werden nun zwei Dropdownfelder, wo man bestehende Lager und Lagerplätze auswählen kann. Dies ermöglicht es Lieferscheine bei entsprechend vorhandener Menge mit einem Knopfdruck komplett auszulagern, sofern für alle Artikel der hinterlegte Standardlagerplatz benutzt werden soll. Das Upgradeskript versucht hier das Freitextfeld vorhandenen Lagerplätzen automatisch zuzuweisen, bei Nichteindeutigkeit hat man aber noch die Chance, manuell auszuwählen.

Einige der Upgradeskripte laufen bei großen Datenbanken sehr lange, das hat bei mir auch schon mal 15 Minuten pro Mandant gedauert. Man sollte insbesondere bei Verwendung von fcgi darauf achten, daß die Timeouts entsprechend lang genug konfiguriert sind, sonst bricht das Upgrade zwischendurch ab. Bei mir war das der Parameter FcgidIOTimeout in der fcgid.conf.

Nach der Installation sind relativ schnell neue Fehler entdeckt worden, schließlich ist das ja noch eine kundenangepasste Unstableversion.

Insbesondere die Kundenanpassungen im Kundenbereich mußten umgeschrieben werden, da hier der Unterbau komplett ausgetauscht worden ist. Die Neuerungen machen dies aber insgesamt einfacher als vorher.

Es wurden auch gleich ein paar Bugs im Standard gefixed, siehe Tickets 2386, 2384 und 2381.

Bei der neuen Mandantenfähigkeit gab es dann noch eine Enttäuschung, und zwar sind die Benutzereinstellungen noch nicht mandantenfähig. Hat man dem Benutzer Schmitz den Mandanten FirmaA und FirmaB zugeordnet ist es noch nicht möglich, dem Benutzer in den beiden Mandanten unterschiedliche E-Mailadressen oder Signaturen zu geben.

Insgesamt überwiegt aber der positive Eindruck, die neue Einlagerungsfunktionalität mit Partpicker ist sehr schick, und auch die verküpften Belege sind eine feine Sache.

Mit der Mandantenfähigkeit kann jetzt auch endlich die WebDAV-Funktionalität mit unterschiedlichen Mandanten innerhalb einer Installation umgehen.

Wer nicht die Möglichkeit hat, schnell auf auftauchende Bugs zu reagieren, sollte jetzt zwar noch nicht unbedingt auf die Unstable migrieren, möglich ist es aber.

Die oben genannten Punkte gilt es aber spätestens bei der nächsten Stableversion zu beachten und sind hiermit schonmal als kleiner Erfahrungsbericht dokumentiert.

Auf jeden Fall sollte man das Upgrade erst in einer Testumgebung durchführen, und hierfür auch die lxerp_auth sichern.

Ich habe das Update auch in zwei Schritten durchgeführt, erst Ubuntu mit Postgres, und erst zwei Wochen später das kivitendo Update.