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

Beleg Schnellsuche in der 3.2

Eines meiner kivitendo Lieblingsfeatures für die tägliche Arbeit aus der neuen Version 3.2 ist die Beleg Schnellsuche für Debitorenrechnungen, Kreditorenrechnungen und Dialogbuchungen, insbesondere wenn man für die Buchhaltung bei kivitendo zuständig ist. In der Kopfzeile gibt es nun ein interaktives Eingabefeld, wo man nach Rechnungsnummern, Kunden- oder Lieferantennamen oder Belegbeschreibungen suchen kann. Hat man z.B. einen Papierbeleg vor sich kann man von jeder Seite aus direkt zu dem gebuchten Beleg gelangen.

Das Eingabefeld basiert auf jQuery autocomplete, und man muß mindestens 3 Zeichen eingeben, bevor die Suche aktiviert wird. Dargestellt werden maximal 40 Ergebnisse pro Belegtyp, und die Ergebnisse werden zeitlich sortiert. Mit den Pfeiltasten oder der Maus kann man dann einen Beleg aus dem Dropdown auswählen, und im Idealfall gibt es nur einen Treffer, so daß man mit der Enter-Taste direkt zum Beleg springen kann. Im Dropdown wird dabei eine Kurzzusammenfassung des Beleges angezeigt, bestehend aus Abkürzung Belegtyp, Rechnungsnummer, Name, Betrag und Rechnungsdatum.

Das Feature ist für die Buchhaltung gedacht und daher braucht der Benutzer auch das Gruppenrecht “Dialogbuchen, Debitorenrechnungen, Kreditorenrechnungen” aus dem Bereich “Finanzbuchhaltung und Zahlungsverkehr”.

Die Schnellsuche wurde letztes Jahr in vereinfachter Form als Programmierbeispiel in der Entwicklerschulung vorgestellt, und findet sich nun auch im Standard.

Ausprobieren kann man das Feature wie immer in der offiziellen Demo.

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

Steuerfilter

Bei der Dialogbuchung war es früher so, daß wenn man ein Buchungskonto auswählte, prinzipiell alle Steuervarianten (Umsatzsteuer 7/19%, Vorsteuer 7/19%) zur Verfügung standen. Hatte das Konto eine Steuerautomatik wurde der richtige Eintrag vorausgewählt, aber man konnte dies nach belieben ändern.
Es kam allerdings immer wieder vor, daß Anwender nicht genau hingeschaut haben und beim manuellen Zuweisen z.B. Vorsteuer statt Umsatzsteuer ausgewählt haben. Daher wurde mit der Version 3.1. ein Filter eingeführt, wo man einstellen kann, bei welchen Kontenarten welche Steuerarten angezeigt werden können.
Dies geschieht unter “System”->”Steuern”, wo man für jeden Steuerschlüssel festlegen kann, für welche der Kontenarten diese Steuer auswählbar sein soll.

Die Standardeinstellung ist z.B., daß Steuerschlüssel 3 (Umsatzsteuer 19%) nur bei Erlöskonten angezeigt wird, nicht bei Aufwandskonsten oder Aktiva/Passivakonten. Sobald man ein Erlöskonto auswählt stehen für die Steuerautomatik also auch nur Umsatzsteuerkonten und keine Vorsteuerkonten zur Verfügung:

Jetzt hatten wir allerdings mit unserem Steuerberater einen Spezialfall, wo dieser ein Passiva-Konto (3272 Erhaltene Anzahlungen 19% USt) angelegt hat, und sich gewundert hat, warum er dieses Konto nicht mit Steuerautomatik buchen konnte, da nur die Varianten “keine Steuer” und “USt-frei” angezeigt wurden. Der Grund war natürlich genau dieser Filter. Für diesen Fall mußten wir also Steuerschlüssel 3 auch für Passivakonten freischalten:

Es gibt auch Fälle, wo solch ein Filter komplett unerwünscht ist. In dem Fall kann man das alte Verhalten wieder herstellen, indem man bei allen Steuern die Häkchen bei allen Kontenarten setzt. Auch während des Upgradeprozesses auf die 3.1. hat man einmalig die Möglichkeit, dies zu konfigurieren, bzw. die Voreinstellungen anzupassen.

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

Seitenumbruch in Druckvorlagen

Wir benutzen für die Positionstabellen in den Belegen generell die longtable Umgebung. Gerade wenn der Langtext länger wird kommt es immer wieder vor, daß auf dem ausgedruckten Beleg große leere Bereiche entstehen, v.A. auf der ersten Seite, so daß die Positionstabelle erst auf der zweiten Seite beginnt. Das sieht fast immer schlecht aus und erzeugt Unmut beim ästhetischen Belegersteller.

Dies liegt daran, daß LaTeX bei longtable nicht innerhalb einer Tabellenzeile umbrechen kann, und erst auf der zweiten Seite die Chance hat, die Position komplett unterzubringen. Wenn man nur eine Position hat kann man auch nicht durch manuelles Umsortieren der Positionen Abhilfe schaffen.

Bis zur Version 3.1 konnte man dies mit einem Trick umgehen, und zwar indem man \newline umdefinierte. Die Zeilenumbrüche aus der Langbeschreibung wurden in LaTeX nach \newline umgewandelt, und hierfür konnte man statt eines einfachen Zeilenumbruchs eine ganz neue Tabellenzeile generieren. Wenn sich z.B. die Langtextbeschreibung in der 3. Tabellenspalte befindet wie folgt:

\renewcommand{\newline}{ \\ & & }
\begin{longtable}{clp{10.2cm}crr}
...
\end{longtable}
\renewcommand{\newline}{\\ }

Dadurch kann LaTeX innerhalb des Langtextes nach Belieben die Seite umbrechen, da jede Langtextzeile einer Tabellenzeile entspricht. Das ist nicht wirklich elegant, funktioniert aber, solange in keine der anderen Spalten ein \newline vorkommt.

Mit dem neuen Langtexteditor wird der Langtext allerdings als HTML gespeichert, und statt einfacher Zeilenumbrüche wird nun alles in < pa r> Tags gesetzt.

In SL/Tempates/LaTeX.pm wird zudem das < /par > durch \n\n ersetzt, es gibt also kein \newline mehr und der Seitenumbruch funktioniert nicht mehr.

Um das alte Verhalten wiederherzustellen muß man dort das \n\n also durch ein \newline ersetzen.

Fehlermeldungen in LaTeX

Da ich auf der FrOSCon nicht dazu gekommen bin, mir einen der Vorträge anzuschauen, habe ich heute mal in eine der Aufzeichnungen hineingeschaut, Programmierung mit LaTeX

Fast nebenbei wird dort der \typeout Befehl erwähnt, mit dem man während des Kompilierens Ausgaben für den Benutzer erzeugen kann, und sich das damit auch zum Debuggen eignet.

Ein typischer Fehlerfall von kivitendo sind Sonderzeichen z.B. im Langtext von Artikeln, die durch Copy&Paste aus anderen Quellen, z.B. PDFs, eingefügt werden, und von LaTeX nicht verarbeitet werden können. Der Benutzer bekommt dann den Inhalt der .err-Datei angezeigt, kann damit in der Regel aber nicht viel anfangen, weil das betreffende Zeichen meist entstellt angezeigt wird und meist der Kontext fehlt.

Beispiel: ich füge die Zeichen 香港 in den Langtext von Position 2 ein, und erhalte:

! Package inputenc Error: Unicode char \u8:香 not set up for use with LaTeX.
l.188 & & \newline 香
港 \\

Der Benutzer hat keine Ahnung, um welches Zeichen es sich handelt und wo im Dokument es sich befindet, kann entweder durch raten oder gezieltes Löschen die Fehlerursache suchen, oder muß seinen Admin/Dienstleister anrufen.

Mit dem \typeout Befehl kann man aber z.B. in der Artikelschleife bei jeder Position kurz ausgeben, welche Artikelposition gerade ausgegeben wird, so daß man im Falle des Abbruchs zumindest schon mal sehen kann, bei welchem Artikel das Sonderzeichen ist.

<%foreach number%>
\typeout{Position <%runningnumber%> (Artikelnr <%number%>)}

In der .err-Datei, und damit an der Browserobefläche, taucht das dann folgendermaßen auf:

Position 1 (Artikelnr 1)
Position 2 (Artikelnr 1)

! Package inputenc Error: Unicode char \u8:香 not set up for use with LaTeX.

Jetzt weiß man zumindest schon mal, daß das kaputte Zeichen bei Position 2 liegt.

Das Gleiche könnte man auch für andere Eingabefelder, wie z.B. Transportmittel, machen.

Bei der Gelegenheit habe ich mich dann auch gewundert, warum mein 香港 eigentlich im Browser nicht richtig angezeigt wird, auf der Kommandozeile wurde das in der .err-Datei nämlich schön angezeigt. In der entsprechenden Codestelle (SL/Form.pm, sub cleanup) wurde die .err Datei nicht mit UTF-8 Encoding eingelesen, baut man das ein

} elsif (-f "$self->{tmpfile}.err") {
open(FH, "<:encoding(UTF-8)", "$self->{tmpfile}.err");

wird dann auch an der Oberfläche mein fehlerhaftes Zeichen korrekt angezeigt:

Position 1 (Artikelnr 1)
Position 2 (Artikelnr 1)

! Package inputenc Error: Unicode char \u8:香 not set up for use with LaTeX.

Für Unicode Zeichen hilft das dann zumindest schon mal.