Auch in diesem Jahr sind wir wieder auf der als Aussteller, Referent und Sponsor vertreten. Nachdem wir im letzten Jahr einenSchnellübersicht über kivitendo dort präsentiert haben, zeigen wir in diesem Jahr: Linux only! FiBu – Online Banking – Geschäftsbelege. Alles in einer Firma: Client, wie auch serverseitig machbar und skalierbar.
Auf der FrOSCon 2014 hatte ich ja hierzu einen Vortrag gehalten, s.a.:älterer Blog-Eintrag
In dem Vortrag hatte ich einige Checkboxen geändert.
Im aktuellen Kundenprojekt ist mir jetzt ein noch bessere Anwendungsfall aufgetaucht:
Individualisierter Verkaufsbericht!
Der ursprüngliche Auftraggeber braucht hier mehrere Sichtweisen je nach Bearbeitertyp.
$ cp templates/webpages/vk/search_invoice.html templates/webpages/vk/search_invoices_Karsten.html
Ein vimdiff der beiden Templates sieht wie folgt aus:
Das Template ist ja komplett unkritisch da wir dies mit
$ git add templates/webpages/vk/search_invoices_Karsten.html
hinzufügen. Die zwei Zeilen in der vk.pl können wir sicher als Weiche dann immer “krisensicher” rebasen:
Zu guter Letzt noch der Hinweis, wie ich zwei Repos auf demselben Server aktuell halte, weil ich das ja auch immer selber “nachgoogle”:
$ git remote add dev-lokal /usr/local/lib/lx-office-erp-devel
$ git fetch dev-lokal
$ git cherry-pick 805b11a
Auch in diesem Jahr waren wir wieder auf der FrOSCon präsent und ich hab einen kurzen Vortrag zu git und kivitendo gehalten.
Die Vortragsfolien, sowie das Video zu kivitendo mit git und Erstellung von Projekterweiterungen sind hier zu finden. Der Vortrag basiert zum Teil auf diesen Blog-Eintrag
Interessanterweise gibt es ein sehr innovatives Unternehmen, das in demselben Geschäftsbereich wie wir aktiv ist, und sich in räumlicher Nähe zu uns befindet.
Netterweise laden die alle Interessenten kostenfrei in das Kameha Grand Hotel ein.
Super, dann bin ich mal ein neugieriger Interessent!
Super Buffet im Kameha - Jan in der Schlange hinten in lila
Die Aufmachung und das Catering ist schon mal sehr nett, insgesamt gefällt mir das Produkt und die Ideen dahinter auch.
Anbei der Link zu dieser Veranstaltung.
Ich bin eigentlich hier um neue Ideen zu bekommen, bzw. um mal kivitendo zu vergleichen.
Insbesondere mit der Integration von DMS in kivitendo befasse ich mich seit letzten Jahr auch (wieder) intensiver. Vorab schon mal ein Bildschirmfoto des aktuellen Entwicklungsstandes:
CMIS Integration kivitendo Alfresco alle Metadaten inkl. Thumbnail Preview
Ich hab die letzten Wochen mich nochmal genauer “technisch” hingeschaut, so wie sich deren DMS (Team) in Scope integriert, so scheint das auch mit Alfresco und kivitendo zu funktionieren.
Wenn man genau hinschaut benutzen beide Systeme auch das gleiche Verfahren zur Hash-Generierung:
Hash-Wert ScopeDMS: 7c6368a5-caf3-49a3-934e-4dc0fbb5ddf7
Hash-Wert Alfresco: 00a705c3-f21d-4e65-801e-5ad961931a11
Mir gefällt das Produkt echt gut, dass ist eine gut durchdachte “Business-Suite”.
Ferner gefällt mir der Gründer Jörg Haas, der einen inspirierenden und visionären Vortrag hielt.
Was er beschreibt, deckt sich 100%ig mit unserer Projekterfahrung und zunächst einmal die FiBu-Komponente rund zu bauen und daraufhin dann weiteres oben drauf zu setzen ist pragmatisch genau richtig!
Ein paar Punkte haben mich noch beeindruckt, deren DMS-Lösung ist zusätzlich noch konsequent auf Handheld-Devices ausgerichtet.
Ferner wird ein digitaler Eingangsstempel auf die eingescannten Belege gedruckt, das könnte man mit nachbauen. Vielleicht hat Alfresco auch schon vorgedacht.
Cool fand ich auch, dass der E-Mail Verkehr zu einem Vorgang komplett zu Verfügung steht, das lässt sich auch soweit mit Alfresco und den beiden Workflow-Möglichkeiten abbilden.
Wer weiss, vielleicht halte ich nächstes Jahr selber einen Vortrag dort (zumindestens könnte man einfach einen anmelden), ich denke nicht, dass wir als ernsthafte Konkurrenz angesehen werden und den Vergleich brauchen wir hier nicht zu scheuen (zumal unsere drei größeren Referenzen für sich selbst sprechen).
Manchmal ist es sehr erfrischend eine Rückmeldung zu bekommen von Personen die gar nicht kivi vorbelastet sind und das Projekt nicht mit der “Vergangenheits”-Brille begutachten.
Hier eine Rückmeldung aus einem ganz anderem OpenSource-Projekt:
Ich habe mir aber die Seiten von kivitendo im Internet angeschaut. Sieht lecker und gesund aus – und klingt wirklich gut.
Ich habe hier schon mal die Werbetrommel gerührt, wir müssen nur noch einen passenden Anwendungsfall finden.
Sehr schön.
Exemplarisch mal ein Beispiel für ein sehr sinnvolles Einsatzfeld, nämlich immer dann, wenn die Skalierung entscheidend ist und der Standard nicht mehr ausreicht, ist der Einsatz von OpenSource Software gekoppelt mit einem flexiblen Dienstleister Gold wert …
In diesem Fall war die Anforderung, dass innerhalb eines Rahmenvertrags mit dem Kunden die Datenübermittlung per EDI erfolgt. Relativ zeitnah stellte sich heraus, dass die Datenmenge den Einsatz von dem sogenannten WebEDI, sprich die Aufträge werden per Webinterface händisch abgeholt, nicht sinnvoll ist.
Ferner sollten dann auch die Ausgangsrechnungen direkt elektronisch in das System des Kunden übertragen werden, sodass eine komplette elektronische Abbildung des Prozess sinnvoll erschien:
Soweit so gut, jetzt wird die automatische Übertragung der Aufträge noch elektronisch per E-Mail protokolliert und damit ist diese Anforderung soweit erfüllt.
Das ist theoretisch alles nichts Neues, aber je einfacher man den Prozess gestaltet und implementiert, desto besser funktioniert es dann auch in der Praxis, insbesondere wenn der Handlungsbedarf auf Grundlage der Datenmenge sinnvoll ist. Das klingt zwar lustig, aber wenn der Kunde von alleine darauf kommt, dass hier etwas zu tun ist und wir ihm dabei unterstützen können ist der Prozesserfolg dann umso sicherer ;-).
Das ist ferner auch ein sehr schönes Beispiel, wie man mit einfachen OpenSource “Basis-Komponenten” und “etwas” kivi-Perl-Kleber einen Unternehmensprozess abbilden und verbessern kann. Genau an dieser Stelle, setzt ja unsere Geschäftsidee an und dies ist ja genau die Nische die sinnvoll ist, s.a.
Weil mich am Samstag die internen Code-Qualität von kivitendo begeistert hat, hab ich noch das Bedürfnis dieses auch mal ins Internet zu verkünden …
Kundenanforderung: Wir arbeiten mit der Löschen-Funktion in allen Verkaufsbereichen und mögen keine “Lücken” im Nummernkreisen. Präventiv haben wir uns hier schon den Kopf zerbrochen, wie man diese Anforderung umsetzen kann und das auch noch möglichst “allgemeingültig”.
Pragmatischerweise setz ich den Nummernkreis einfach wieder auf den Vorgänger und dann wird ja die Lücke bei der nächsten Nummernvergabe wieder aufgefüllt.
Ich hab mir einmal den Nummernkreis des Kunden angeschaut und der ist soweit “gutartig”, sprich wir haben keine Präfix (A2014-$IRGENDWAS), also kann ich hier unkritisch eine Projekterweiterung durchführen.
Jetzt ist aber hier die Programmierung mittlerweile schon viel intelligenter und es wird überprüft, ob es sich um eine Nummer die schon in Benutzung ist handelt UND: Ob es eine Prefix gibt!
$ perldoc SL/PrefixedNumber.pm
Ich bin begeistert!
Im Kern der Software stecken so manche kleine bis größere Juwelen drin.
Insofern brauch ich in diese Modul nur noch für meinen Anwendungsfall erweitern und die Kunden-Erweiterung ist durch …
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
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:
Weil die Frage schon öfters mal auftaucht und teilweise kontrovers diskutiert wird:
kivitendo ist erstmal eine frei konfigurierbare doppelte Buchhaltung mit der Möglichkeiten einen Kontorahmen von Grund auf aufzubauen. Insofern kann man diesen flexibel an Landesbedürfnisse anpassen. Für die Schweiz gibt es auch einen eigenen Kontenrahmen, der allerdings nur in Anlehnung eines "Käfer"-Kontenrahmens erstellt wurde und in diesem müssen auch noch nachträgliche Einstellungen gemacht werden (bspw. Steuersätze anpassen). Falls man kivitendo als gleichwertigen Ersatz, nur mit dem Kostenvorteil OpenSource evaluiert, macht dies in der Regel keinen Sinn,da ist man bei einem FiBu-Produkte von der Massenstange (sage oder lexware) besser aufgehoben. Wir nutzen LexWare selber um die DATEV-konformität zu überprüfen. Falls man Spass und Freude daran hat, sich selber in die doppelte Buchführung reinzufuchsen und einen Kontenrahmen selber zu gestalten, dann ist man hier genau richtig. Ansätze für die Schweiz gibt es beispielsweise auch hier. Falls man eine größere und komplexere Struktur abbilden möchte (Betrieb ab 10 Mitarbeiter), würden wir uns dann als Implementierungs- partner selber empfehlen, da wir kivitendo für unsere Kunden in verschiedenen Ländern im Einsatz haben, allerdings ist der Stammsitz immer in Deutschland. Hier kann man sich am Besten über die aktuellen Referenzen ein Bild machen, ob man in diese Kategorie fällt oder nicht.