Category Archives: release 3.1

kivitendo 3.0 ubuntu 10.04 -> kivitendo 3.1 ubuntu 12.04

Als Ergänzung zum letzten Post, hier nochmal eine aktuellere Anleitung, da debian in der Tat schhon etwas intelligenter ist, als ich ;-).

Problem: kivi 3.0 mit Erweiterungen im eigenen Branch (Druckvorlagen, DATEV.pm, Defaulthaken in Berichten).

Als erstes “verheiraten” wir den branch mit der aktuellen Version. Die für uns am Besten geeignete Methode (Dank an Geoff, der das damals auf der 2011er-Schulung kurz erklärt hat), ist hier “rebasing”:

$ git checkout master
$ git pull
$ git checkout kundenbranch
$ git status -uno
$ git rebase master

Git Status -uno ist auch sehr schön, um direkt zu sehen, ob man Arbeitsverzeichnis “sauber” ist, d.h. es liegen keine nicht eingecheckten Änderungen “herum”.
So, es gibt einen Konflikt in der DATEV.pm, weil hier in Abstimmung mit dem Steuerberater ein Standard-DATEV-Feld als Personenkonto-Nummer umgewandelt wurde. Bei diesem Kunden (wie eigentlich auch bei den meisten Kunden) haben wir den gutartigen Fall: Kunden / Lieferantennummer == Personenkontonummer.

$ git mergetool
$ git add SL/DATEV.pm
$ git rebase –continue

Da die locale/de/all nervig zum “Rebasen” ist, wenn man hier viele Änderungen hat, deswegen hier noch mein Trick:
alle Änderungen, welche die all betreffen ignorieren (skip) und dann am Schluss nur die vier fehlenden Felder:

$ git checkout master — locale/de/all
$ git commit -m “wirkliche revision”

Damit ist das soweit abgehakt und das DB-Upgrade für den eigentlichen Mandanten kann durchgeführt werden. Ah, ok, es gibt eine Rose Client.Auth-Objekt Fehlermeldung wenn ich mich anmelde. Hier war ich etwas schlampig. wahrscheinlich fehlen Module für die 3.1

$ scripts/installation_check.pl -v
$ apt-get install libfile-copy-recursive-perl

Ok, leider fehlt noch rose-db in einer neueren Version, da hilft nur ein ubuntu-Upgrade und hier die Ergänzung zum vorherigen Post: Ja, ubuntu kann automagisch und sicher das Postgres-Cluster aktualisieren:

$ do-release-upgrade
$ pg_dropcluster –stop 9.1 main # 9.1 wieder deinstallieren
$ pg_upgradecluster
Starting target cluster on the original port… Success. Please check that the upgraded cluster works. If it does, you can remove the old cluster with pg_dropcluster 8.4 main

Sehr schön, damit ist alles erledigt. Ein Hoch auf das stressfreie Debian / Ubuntu

kivitendo 3.1 mit ubuntu 12.04 LTS -> upgrade 14.04

Als letzte gute Prüfung für die 3.1beta einmal das darunterliegende ubuntu auf die derzeitige 14.04 LTS alpha hochgezogen:
Ubuntu denkt hier schon eine Menge mit:

$ do-release-upgrade

Das läuft soweit sauber durch, bis auf die Tatsache, dass postgresql die Biege macht:

postgresql hängt ab von postgresql-9.3; aber:
Paket postgresql-9.3 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes postgresql (–configure):
Abhängigkeitsprobleme – verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
postgresql-client-9.3
postgresql-client
postgresql-9.3
postgresql-contrib-9.3
postgresql-contrib
postgresql

Er startet allerdings noch in der alten 9.1 Version.
Zumindestens hiermit hab ich dann beide Versionen am Laufen:

root@sprint:~# update-alternatives –remove postmaster.1.gz /usr/share/postgresql/9.1/man/man1/postmaster.1.gz
root@sprint:~# apt-get install postgresql-9.3

Und kann damit dann einen Dump von 9.1 in die 9.3 einspielen.
Ok.

Allerdings musste ich folgende Änderung in der Apache-Konfiguration vornehmen:

Bugsprint 2014 kivitendo 3.1

Für die kivitendo Version 3.1 gab es, wie in der Vergangenheit auch einen gemeinschaftlichen Bugsprint mit vielen Projektbeteiligten. Das war eine sehr effiziente Aktion, insgesamt wurden 227 Einträge im Bugtracker bearbeitet.

Konzentrierte Stille beim “Bugsprinten”, anbei Beweisvideo I und II:

webdav dokumenten-management in kivitendo 3.1

Ein “neues” Feature was mir sehr gut gefällt, ist das Speichern der Verkaufsbelege im Webdav-Ordner. Das ist ein sehr schönes Beispiel, wie man aus einer Schwäche des Programms eine Stärke entwickeln kann.

Problem: Belege sind nicht digital revisionssicher, da die PDF-Generierung immer dynamisch ist und hierbei die aktuellen Stammdaten des Kunden / Lieferanten und die aktuellste Version der Druckvorlage ausgewählt wird.

Das letztere Problem kann man durch Anlegen eines neuen Druckvorlagensatz umgehen oder man setzt in der vorhandenen Druckvorlage eine entsprechende Variable die dann eine Weiche über das Belegdatum zu Verfügung stellt (s.a. grüner Kreis in Abb. unten)

So richtig sinnvoll fand ich damalige Lösung nicht. Aus einem Kundenprojekt heraus (der Kunde betreibt das DMS alfresco und kivitendo parallel) ist dann die Idee entstanden Ausgangs-Belege über den Webdav-Ordner zu synchronisieren.

Dadurch ist dann wieder klassischerweise aus einer Kundenerweiterung ein im Standard konfigurierbares Features geworden.

Diese Funktion lässt sich unter Mandantenkonfiguration wie folgt aktivieren:

Dadurch wird jetzt bei jedem Druck eines Belegs geprüft, ob dieser aktualisiert werden sollte (hier wird “nur” verglichen, ob der zuletzt gespeicherte Beleg in der Dateigröße mit dem aktuellen Beleg abweicht).

Soweit hat man die Belege jetzt auf dem Server liegen und jetzt wird es so langsam interessant.

Ich hab für die Steigmann Werft, dieses Feature aktiviert und auf diesem Server befindet sich noch parallel ein Alfresco Community 4.2c, dies kann man dann mit diese Google-Code Plugin: Bulk-Filesystem-Import erweitern und dann hat man folgendes Szenario:
Somit kann man jetzt per Cronjob oder noch sinnvoller per integrierten Task-Server die Ausgangsbelege in Alfresco einspielen und diese dann Volltext-Indiziert suchen.

Alfresco und die Möglichkeiten hatte ich ja auf der FrOsCon 2013 vorgestellt und hierfür auch die entsprechenden Erweiterungsmöglichkeiten evaluiert. Mittlerweile hat sich diese Idee technologisch überholt, da es sehr viel sinnvoller ist, Belege über die vorhandene CMIS-API von Alfresco zu synchronisieren.

Neue Features seit 3.0

FF

Es hat sich seit der 3.0.0 vor Allem viel unter der Haube getan, es wird immer
einfacher neue Module zu schreiben bzw. vorhandene Module neu und effizienter
zu implementieren. An der Oberfläche werden auch immer mehr Bereiche per
Javascript und jQuery komfortabler gemacht.

Da ich mir nie so sicher bin, welche Features es noch nicht in der 3.0.0 gibt,
da ich meistens in der Unstable oder Kundeninstallationen unterwegs bin, habe ich eine (unvollständige) Liste der neuen Features zusammengestellt:

  • verknüpfte Belege (!)
  • Projekte überarbeitet mit Anzeige aller Projektbelege
  • Kunden- und Lieferantenmasken auf Controller umgestellt
  • Partpicker für Lagereingang mit Kurzhistorie
  • Mandantenkonfiguration mit Verwaltung im Adminbereich
    * Ein Login für mehrere Mandanten möglich
    * WebDAV jetzt pro Mandant möglich
  • Auftragsimport
  • Automatisches Auslagern einstellbar
  • eigenes Recht für Debitoren- und Kreditorenbuchungen
  • Ansprechpersonensuche
  • Lieferplan und Projekte mit get_models umgesetzt
  • Steuernamen übersetzbar gemacht
  • Zukunftsbuchungen können verhindert werden
  • neues Recht um Artikel nur anzuzeigen, nicht zu bearbeiten