Author Archives: Jan

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 ;-).

kivitendo 3.3 unterwegs …

In den nächsten Wochen wird kivitendo in der Version 3.3 veröffentlicht. Der Fokus der Veröffentlichung liegt auf dem Kontoauszugs-Import, der hier im Wiki sehr gut beschrieben ist: http://redmine.kivitendo-premium.de/projects/forum/wiki/Bankerweiterung

Inspiriert ist diese Erweiterung aus einem Kundenprojekt, welches dort 2013 initiiert wurde. Sie hat folgende Eckpunkte:

  • Kontoauszüge importieren (für MT940 wird aqbanking-cli benötigt)
  • anhand der Kontoauszüge Zahlungen verbuchen
  • die FiBu-Buchungen auf die Bankkonten mit den importieren Auszügen abgleichen

Aktuell haben wir die Volksbank und die Sparkasse hiermit getestet.

Wer es vorab ausprobieren möchte, bitte exakt die Anweisung befolgen. Der Import erfolgt in 2 Schritten:

  1. Konvertierung MT940 → CSV (per Linux-Programm aqbanking)
  2. Import CSV → kivitendo (deswegen hier das Importprofil entsprechend auf aqbanking abstimmen (Amerikanisches Zahlenformat etc).

Hier die wichtigste Info auf den Punkt (steht aber auch genauso im Wiki):

  1. Das Bankkonto (IBAN / BIC) muss ohne Leerzeichen erfasst sein.
  2. Das Profil MT940 ist Case sensitiv (alles groß schreiben)
  3. Import-Profil genau wie in der Doku erfassen
  4. Debugging-Abschnitt beachten

Details der weiteren Features gibt es wie immer im Changelog und an dieser Stelle auch nochmal der Status von heute:

Bankerweiterung und Skontobehandlung

Bei der Bankerweiterung kann man

  • Kontoauszüge importieren (für MT940 wird aqbanking-cli benötigt)
  • anhand der Kontoauszüge Zahlungen verbuchen
  • die FiBu-Buchungen auf die Bankkonten mit den importieren Auszügen
  • abgleichen

__Es wurde ein neues Recht “Bankbewegungen” eingeführt.

Beim Verbuchen der Zahlungen werden Rechnungsvorschläge gemacht, die anhand
eines internen Punktesystems bewertet werden.

Es wurde eine Skontobehandlung bei der Zahlung der Rechnungen implementiert,
und zwar nach der Bruttomethode. D.h. es wird der skontierte Betrag auf
erhaltene oder gewährte Skonti gebucht. Allerdings gibt es hier keine
Steuerautomatik, d.h. man muss am Monatsende die Salden noch manuell umbuchen.

Die zu buchenden Skontokonten müssen unter System → Steuern konfiguriert
werden.

Die Skontobehandlung wurde beim Verbuchen der Skontobelege und beim
SEPA-Einzug bzw. der SEPA-Überweisung implementiert.
Beim Bezahlen von Rechnungen kann man auswählen ob man die Zahlung

  • ohne Skonto
  • mit Skonto laut Zahlungsbedingungen
  • die Differenz als Skonto

buchen möchte. Es wird je nach Zahlungsbetrag und Zahlungsdatum ein sinnvoller
Vorschlag gemacht.

Kleinere neue Features und Detailverbesserungen:

  • Briefe werden auch im WebDAV archiviert. Ferner bessere Fehlerbehandlung und
    E-Mail-Funktion aktiviert.
  • Mehrfachauswahl und Mengeneingabe für Artikel:
    Wenn in den Belegmasken die Artikeleingabe nicht eindeutig ist, erscheint
    eine Maske zur Artikelauswahl. Hierzu kann jetzt in den Benutzereinstellungen
    eingestellt werden, dass in dieser Maske mehrere Artikel mit Mengen ausgewählt
    werden können.
  • Stammdaten → Berichte → Waren: Nach Shopartikel filtern und anzeigen können.
  • Auftrags-/Angebotsbericht: Erfassungszeit als letzte Sortierung verwenden,
    damit die Einträge nach Eingabezeitpunkt sortiert sind, wenn es
    gleichrangige Einträge in der aktuellen Sortierung gibt.
  • Bei Eingabe nicht eindeutiger Artikel in den Belegmasken bleibt jetzt auch die
    Mengeneingabe über die Auswahlmaske hinweg bestehen. Damit kann man die Menge
    auch schon vorher eingeben: Nicht eindeutiger Artikel, TAB, TAB, Menge, ENTER
  • In den Berichten zu Aufträgen, VK-Lieferscheinen, Warenstammdaten, Kunden-/
    Lieferntenstammdaten kann das Erfassungsdatum angezeigt und danach gefiltert
    werden.
  • Filtern/Anzeigen von benutzerdefinierten Variablen bei Kunden-/Lieferanten in
    den Berichten Angebot/Aufträge und Verkaufsrechnungen
  • Filtern nach Kunden-/Lieferantentyp bei Lieferschein-Berichten.
  • Preisgruppe bei Stammdaten → Berichte → Kunden anzeigen lassen können.

Bugfixes:

  • Bugfix #54 Fehlermeldung im Mahnlauf bei automatischer Rechnung über Mahngebühren
  • Bugfix #50 Kundentyp-Rabatt wird falsch übernommen

 

kivitendo 3.2.1 veröffentlicht

Schon etwas länger ist die 3.2.1 veröffentlicht, deswegen wird es höchste Zeit, ein paar Zeilen dazu zu schreiben, denn für den einen oder anderen lohnt sich sicherlich schon ein Blick darauf …

Die Motivation, eine 3.2.1 zu veröffentlichen ist überwiegend einiger kleinerer Bugfixes zu verdanken, die kurz nach der 3.2 hochgekommen sind.
Dadurch sind u.a. nebenbei zwei neue Features dazugekommen – zum einen die Verkaufsbrieffunktion und zum anderen ein simples automatisches Auslagern beim Buchen von Verkaufsrechnungen.

Somit sind wir im Warenverwaltungswesen ;-) mittlerweile wieder bei der Version 2.2 angekommen, die nur ein simples Bestandslager zu Verfügung gestellt hatte, allerdings mit dem riesigen Vorteil, dass auch komplexere Lagersysteme (ab 2.6 dazugekommen) abgebildet werden können.

Die Brieffunktion lohnt sich vor allen Dingen für diejenigen, die sowieso und gerne mit LaTeX ihre Druckvorlagen erstellen und diese dann auch simpel mit kivitendo direkt verwalten wollen.

Verkaufs-Brieffunktion
Simple Brieffunktion in kivitendo

Wer die Dokumentenarchivierung aktiviert hat, kann sich im nächsten Release darauf freuen, dass auch die Briefe automatisch mitarchiviert werden.

Hier der komplette Changelog mit ein paar Screenshots der Veränderungen:

Kleinere neue Features und Detailverbesserungen:

  • Das Verkaufsmenü wurde um eine Brieffunktion (Entwurf und finale) erweitert.
    Hierfür muss entsprechend eine neue Druckvorlage (letter.tex) erstellt werden.
    Eine erste Vorlage hierfür befindet sich im Standard-Druckvorlagen-Satz

  • Automatisches Auslagern beim Buchen einer Verkaufsrechnung: In der Mandanten-Konfiguration lässt sich im Reiter “Lager” auswählen, ob Artikel beim Buchen einer Verkaufsrechnung automatisch von den Standardlagerplätzen ausgelagert werden sollen. Dabei werden die Einstellungen für das Auslagern über Standardlagerplätze berücksichtigt.

  • HTML-Editor jetzt auch im Bemerkungsfeld von Einkaufs/Verkaufsbelegen eingebaut
  • %::myconfig wird nun auch dem JavaScript Client zur Verfügung gestellt

 

  • Preisregeln können priorisiert werden

  • Beim Anlegen von Lieferscheinen wird jetzt auch der Preis kurz versteckt
    ermittelt und mitgespeichert, damit beim Umwandeln in Rechnungen keine
    Überraschungen passieren. (Feature #41). Dies ist nützlich, wenn man den
    Workflow nicht mit Angebot oder Auftrag sondern mit einem Lieferschein
    beginnt.

Bugfixes:

  • Bugfix #51 Stammdaten → Waren → Preisinformationen → Blättern defekt
  • Bugfix #49 / trac 2848 Langtext-Popup erscheint nicht immer
  • Bugfix #48 ‘#’ wird nicht bei Artikelnummer in LaTeX-Templates ausgedruckt
  • Bugfix #47 Nicht mehr benötigte Trigger entfernt (check_inventory)
  • CSS für PartPicker repariert
  • Bug beim Parsen von benutzerdefinierten Variablen behoben (Commit 2b9e50ba72)

 

kivitendo auf der CeBIT 2015

Dieses Jahr haben wir uns entschieden auf dem “Open Source Business Alliance”-Stand Dienstags bis Donnerstags vormittag präsent zu sein.

Wir haben eine sehr nette Referenzgeschichte mit an Bord, die aktuelle 3.2 und am Donnerstag um 13:15h halte ich noch einen Überzeugungsvortrag in diesem Sinne: “Mit der Open Source Warenwirtschaft kivitendo, sowie die Integration von OpenSource und freien Standards lassen sich auch alle betriebswirtschaftlichen Anforderungen nach deutschem Recht elegant und flexibel abbilden”.
Wenn vielleicht ein Linux-Admin mit seinem skeptischen Chef über die CeBIT läuft ist er hier am Donnerstag gut aufgehoben ;-)

Das komplette Vortragsprogramm

Verwaiste Verkäufer bei Kunden löschen …

Heute bei einem Kunden umgesetzt. Über die Jahre ist doch einige Mitarbeiter-Fluktuation zu verzeichnen.
Mitarbeiter werden ja prinzipiell nicht gelöscht, damit die ehemaligen verknüpften Belege erhalten bleiben, allerdings möchte man die Verknüpfung bei Kunden entfernen.

Übersicht über alle Kunden mit verwaisten Verkäufern:

select id from customer where salesman_id in (select id from employee where deleted = true);

Und Entfernen aller verwaisten Verkäufer:

update customer set salesman_id=NULL where id in (select id from customer where salesman_id in (select id from employee where deleted = true));

kivitendo Druckvorlagen-Verhalten shipto (Lieferschein)

Weil ich gerade darüber gestolpert bin, hier einmal für a) mich selber als Zukunftserinnerung (google) und b) alle anderen die auch danach googlen.

In der bald erscheinenden 3.2 wird der Präfix shipto für Lieferscheine nicht mehr automatisch mit der Rechnungsadresse befüllt, falls es für den Lieferschein keine abweichende Lieferadresse gibt.
Somit muss für bestehende Druckvorlagen bspw. folgende Anpassung gemacht werden:

Hintergrund:

Das neue Verhalten ist wie folgt:

– Weder die shipto_id (die Drop-Down-Box in den Belegmasken) noch die
individuellen shipto*-Felder werden weder beim Neuanlegen eines
Beleges noch bei Wechsel des Kunden aus den Datenbanken belegt.

– Beim Ausdruck werden die shipto*-Felder nicht mehr aus der
Mandantenkonfiguration vorbelegt, wenn keine Lieferadresse gesetzt
ist.

– Beim Ausdruck werden die shipto*-Felder mit den Daten aus den
Kundenstammdaten belegt, wenn die shipto_id (die Drop-Down-Box in den
Belegmasken) gesetzt ist.

Die ursprüngliche Intention war, möglichst viele Fälle abzudecken. Ganz
ursprünglich war es nämlich in den Druckvorlagen gar nicht möglich,
Kontrollstrukturen zu benutzen und damit die Ausgabe konditional zu
steuern. Es konnte also rein in den Druckvorlagen nicht unterschieden
werden zwischen »der Benutzer hat keine Lieferadresse eingegeben« und
»der Benutzer hat eine eingegeben oder ausgewählt«.

Daher wurde die ganze Logik immer im Perl-Code abgehandelt.

Das macht aber erhebliche Probleme für den Benutzer, für den es absolut
intransparent ist, wann welche Lieferadresse wie vorbelegt wird. Hinzu
kommt, dass in den Belegmasken nicht ersichtlich ist, dass eine
individuelle Lieferadresse eingetragen wurde.

Hinzu kommt, dass die Druckvorlagen inzwischen verschiedene Mechanismen
zur Verfügung haben, um Fallunterscheidungen zu treffen (z.B. die
kivitendo-Mechanismen <%if shipto…%> oder die LaTeX-eigenen
\IfThenElse{\equal{<%shipto…%>}{…}}}…). Leider war es mit dem vorherigen
Code für die Druckvorlagen nicht mehr möglich festzustellen, ob der
Benutzer nun eine Lieferadresse eingegeben hat oder nicht.

Die neue Situation ist recht einfach:

Steht in »shiptoname« oder »shiptostreet« ein nicht leerer Wert, so ist
eine Lieferadresse vorhanden, ansonsten nicht.

Für die »nicht«-Fall kann dann jede Vorlage selber entscheiden, was zu
tun ist. Für Vorlagen im Verkaufsbereich sinnvollerweise gar keine
Lieferadresse ausgeben (oder einfach die Lieferadresse aus den
Kundenrechnungsdaten), für Vorlagen im Einkaufsbereich ebenfalls keine
Lieferadresse oder die Adresse aus der Mandantenkonfiguration.

Anbei noch mein Beispiel-Code (aus den aktuellen RB Druckvorlagen-Satz):

\ifthenelse{\equal{<%shiptoname%>}{}}{ % KEINE ABWEICHENDE LIEFERADRESSE

<%name%>

<%street%>

~

<%zipcode%> <%city%>

<%country%>

}{ % ABWEICHENDE LIEFERADRESSE (Aus Stammdaten oder Beleg)

<%shiptoname%>

<%shiptostreet%>

~

<%shiptozipcode%> <%shiptocity%>

<%shiptocountry%>
} % ende ifthenelse LIEFERADRESSE

kivitendo auf der OpenRheinRuhr 2014

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.

kivitendo eigene Erweiterung mit git pflegen

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

2. Cloud-Unternehmenstag scopevisio 17.1.2014

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 (Bild von http://www.cloud-unternehmertag.de)

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).