Category Archives: Uncategorized

kivi roxx

“kivi roxx”, so der O-Ton von Michael Mendler Prokurist bei der Willenig Brandschutztechnik GmbH.

_MG_9725

Prokurist Michael Mendler erläutert die Prozesse innerhalb von kivitendo

Nach dem kivitendo bei der Willenig GmbH einige Jahre ohne vor-Ort Beratung durch einen Dienstleister eher ein Programm im Dornröschen-Schlaf war, scheint die Dame jetzt wach zu sein …

… aber lassen wir Michael Mendler selber Zwischenbilanz ziehen:

 

“Kivitendo kommt nun endlich in die Gänge.
Unsere Lageristin prüft jetzt bereits Eingangslieferscheine mittels Tablet und die Prozesse werden immer einfacher und gehen immer schneller von der Hand.
Ich bin nur im Dauerstress weil ich laufend neue Artikel für den Einkauf anlegen muss und auch neue Lieferanten ;)”

Das freut uns. Wichtigster Impuls von extern war die Umstellung von OpenOffice-Vorlagen auf PDF-Vorlagen und die klare Prozess-Gestaltung im Bereich der Einkaufs- und Verkaufsworkflows.

 

Partnertreffen, die Zweite!

Auch in diesem Jahr trafen sich die kivitendo Partner im Vorfeld der FrOSCon zu einem gemeinsamen Austausch.

Aufgebaut und einsatzbereit – Werner und Jan am Projektstand

Nach dieser sehr konstruktiven Zusammenkunft am Freitag folgten im Anschluß auf der FrOSCon auch Taten:

  • Das Projektmanagement-System redmine wurde auf den neusten Stand gebracht
  • Die Standarddruckvorlage ist in der kivi 4.0 XeLaTex-kompatibel (Danke an die Kollegin Marei Peschl vom TeX-Projektstand )
  • Die neue Auftragsmaske kann auch odt-Vorlagen verarbeiten.
  • Nebenbei hielt Jan noch einen Vortrag über Mailserver, sozusagen die  technische Weiterführung (Details hier) des Themas vom Treffen im April.
  • Weitere Verbesserungen des Redesign der Anwendung.

 

Marei Peschl von peiTeX migriert spontan die kivi-Druckvorlagen von LaTeX nach XeLaTeX

Unser Fazit: Das Partnertreffen hat sich bewährt. Ein gutes Gemeinschaftsergebnis wurde erzielt. → nächstes Jahr erneut!

 

faszinierte kivitendo Entwicklungspartner vom Design-Aufbau von Hans-Peter

 

 

kivitendo Zürich 12.Oktober

Auch in diesem Jahr lädt unser Partner die revamp-it zu einem lokalen kivitendo-Treffen nach Zürich ein, hier die Agenda des Vormittags und die Anmeldemöglichkeiten:

Ab 9.00 Begrüssung mit Kaffee / Tee

Wer sich für momentan in Entwicklung befindliche Features interessiert und am Kontakt mit Firmen interessiert ist, die kivitendo bereits nutzen, ist herzlich eingeladen, auch am Nachmittag beim kivitendo Community Treffen Schweiz dabei zu sein.

Das Community-Treffen startet um 12.00 mit einem gemeinsamen Mittagessen (auf eigene Kosten) im Restaurant Damas, Kyburgstr. 28. Alle Teilnehmenden an der kivitendo Präsentation sind herzlich zum Mittagessen eingeladen, unabhängig davon ob sie auch am Treffen am Nachmittag teilnehmen.

 

 

kivitendo 3.5.1 kommt mit dem Rentierschlitten

351

Wie versprochen vor dem Jahresende: Hier kommt kivitendo in der aktuellen Version 3.5.1 – saisonal passend diesmal im Rentierschlitten!

Diese Version beinhaltet eine Integrationsmöglichkeit von WebShops mittels einer generischen API im Kern von kivitendo selbst. Bei einem kivitendo-Partner ist sie für Shopware bereits seit längerem erfolgreich im Einsatz.

Ferner ist die DATEV-Schnittstelle erweitert worden, sodass das modernere CSV-Format der DATEV ab 2018 unterstützt wird.

In diesem Zuge wurde auch die schon länger gewünschte Überlagerung von Personen- anstatt Sammelkonten als Exportoption berücksichtigt.

Weitere Änderungen in diesem Release sind Bugfixes oder Detailänderungen, die den Anwender-Komfort erhöhen.

Somit ist kivitendo für 2018 – vor allem mit Blick auf die in Deutschland verwendeten FiBu-Schnittstellen nach DATEV oder den geforderten GoB-Export bei einer Betriebsprüfung – gut aufgestellt, ohne die kivi-eigene Kreativität in Bezug auf flexible Konfiguration und Anpassungen zu beschneiden.
Die Details hierzu liefert wie immer der Changelog. Für neue (oder alteingesessene) kivi-Fans hier noch der Hinweis auf die vollständige Installationsanleitung bzw. die Upgrade-Anleitung.

Wer kivitendo gar nicht kennt, sollte einen kurzen Blick auf unsere Demo-Instanz, die Steigmann Werft, werfen – hier ist exemplarisch ein komplettes Geschäftsjahr einer fiktiven Werft erfasst.

Die offizielle Pressemitteilung (pdf): kivitendo-pm-3-5-1

Demo-Mandant auf die Version 3.4.0 aktualisiert

Unsere offizielle kivitendo-Demo, die Steigmann Werft unter https://www.kivitendo.de, habe ich eben auf die Version 3.4.0 aktualisiert. Da in den Testsystemen schon lange alles aktualisiert war und ich die UPGRADE-Datei nicht gelesen habe, ist mir das natürlich direkt um die Ohren geflogen.

Was ich unter Ubuntu für unsere Installation nach dem git pull noch gemacht habe:

  • perl scripts/installation_check.pl
  • apt-get install libalgorithm-checkdigits-perl
  • in der Konfigurationsdatei den [task_server] Abschnitt auskommentiert
  • den Webserver neu gestartet
  • im Admin-Bereich angemeldet: /controller.pl?action=Admin/login
  • als Benutzer angemeldet

Alle Updates liefen mit unserem Testdatenbestand flott durch, damit steht die 3.4.0 jetzt offiziell online zum Ausprobieren bereit.

Buchungsgruppen optimieren

In der Regel fällt erst im laufenden Projekt auf, dass Konten anders zugeordnet gebucht werden sollen.

Unter der Haube, sprich in der Datenbank, lässt sich dies einfach ändern. Allerdings gibt es dann Konflikte, wenn man Gutschriften/Stornos zu Belegen generieren möchte, die auf andere Konten gebucht sind.

Was idiotensicher geht, ist das Ändern der Buchungsgruppe und nochmals bei allen Belegen auf Buchen klicken. Oder man wartet bis zum Geschäftsjahreswechsel mit der Buchungsgruppen-Änderung.

Anbei der SQL-Befehl, um bspw. alle Standard-19 %-Konten anzuzeigen:

select zon.description, chart.accno as income, c.accno as expense from taxzone_charts left join tax_zones zon on (zon.id=taxzone_id) left join chart on (chart.id = income_accno_id) left join chart c on (c.id = expense_accno_id) where buchungsgruppen_id=(select id from buchungsgruppen where description ='Standard 19%');

Jetzt braucht man “nur” die IDs der Konten anzupassen. Am besten unterteilt man Schritt für Schritt noch Aufwands- und Erfolgskonten.

select taxzone_charts.id, zon.description, c.accno as expense,expense_accno_id from taxzone_charts left join tax_zones zon on (zon.id=taxzone_id) left join chart on (chart.id = income_accno_id) left join chart c on (c.id = expense_accno_id) where buchungsgruppen_id=(select id from buchungsgruppen where description ='Standard 19%');

Und das Update:
update taxzone_charts set expense_accno_id=(select id from chart where accno='520000') where id=7;

Offene Forderungen importieren

Aus dem aktuellen kivi-Projekt hat sich die Anforderung ergeben, die Funktion “Kontoauszug verbuchen” direkt von Anfang an zu verwenden.

Hieraus enstand dann die Herausforderung, wie man mit Zahlungseingängen aus dem Vorjahr umgeht.

Hintergrund: Das alte ERP-System (SAP by design) wurde durch kivitendo abgelöst und man ist an einer schnellen Abschaltung interessiert, allein um den Vertrag bei SAP möglichst zeitnah zu kündigen.

SAP by design bietet eine OPOS-Liste mit folgender Struktur an:
offene-forderungen-opos-2015

Dabei kam die Idee auf, dass es doch besser ist, die Forderungen einzeln im System einzuspielen, damit man hier eine bessere Rückverfolgbarkeit der offenen Posten hat.

Ich habe die Gelegenheit genutzt, um den Prototyp Debitorenimport über CSV hierfür zu testen.

Der Debitorenimport kann alle kivitendo-Buchungsfälle abbilden. Allerdings muss hierfür der kivitendo-Administrator etwas kivitendo-/Buchhaltungs-Fachwissen mitbringen.
kivitendo teilt Transaktionen in Haupt- und Nebenbuch ein. Im Nebenbuch stehen die Metadaten des Belegs, die nicht direkt zur FiBu gehören und im Hauptbuch sind Soll und Haben sowie die Steuer ausgewiesen.

Für meinen Anwendungsfall brauche ich nur Netto-Werte, da SAP die Steuer nicht explizit bei der OPOS ausweist. Ferner besteht bei dieser kivitendo-Installation Abteilungspflicht und ich habe mir zusätzlich überlegt, dass man für diese Forderungen der Übersichtlichkeit halber ein eigenes Ertrags- und Forderungenkonto verwendet.

Somit sieht meine Debitorenbuchung an der Oberfläche wie folgt aus:
donut-spain

Die benötigte Struktur des Imports besteht aus einer Zeile mit Rechnungs-Metadaten und aus 2 bis 4 weiteren Zeilen (Sollkonto, Habenkonto, diverse Steuersätze):

Zeile 1: datatype,amount,invnumber,customernumber,customer,transdate,duedate,closed,netamount,invoice,department,employee_id

Zeile 2: datatype,amount,invnumber,chart_id,taxkey,transdate

Die chart_id findet man über die URL des Kontos unter System → Konten anzeigen heraus.

Diese Rechnungen sind geschlossen (closed == true), da sie wahrscheinlich schon vollständig geliefert und ferner keine Verkaufsrechnungen (invoice == false) sind.
Alle anderen Information sind in der OPOS-Liste enthalten, die ich per Skript einfach neu zusammenparse.

Somit ergibt sich für diese Debitorenbuchung folgender Datensatz:

Zeile 1:Rechnung,"1.220,00",RG508216,1215600,"Donut Spain S.A.",23.10.2014,22.11.2014,t,"1.220,00",f,"OPOS 2015",979

Zeile 2:AccTransaction,”-1.220,00″,RG508216,12533,0,23.10.2014

Zeile 3:AccTransaction,”1.220,00″,RG508216,12535,0,23.10.2014

Die einzelnen Zeilen werden etwas schlecht formatiert, deshalb hier nochmal als Screenshot:donuts sa

Inventur in kivitendo

Die Anpassung des Warenbestandes in kivitendo nach der Inventur ist über den CSV-Import sehr einfach. Unter System → CSV-Import → Lagerbewegungen/-bestände kann man hierfür eine Liste der frisch gezählten Bestände hochladen. Ein CSV-Liste aller zu zählende Waren exportiert man sich am besten unter Stammdaten → Berichte → Waren.

In diesem Beispiel gibt es die beiden Artikel “Heftzwecken” und “Büroklammern” mit den Artikelnummern 5 und 4, wobei hier nur die Artikelnummer wichtig ist, die Beschreibung wird ignoriert. Die Artikel liegen im Lager “lager1” auf Lagerplatz “Lagerplatz1”, die Inventur fand am 29.12.2015 statt und es wurden 53 Heftzwecken und 33 Büroklammern gezählt, was man jeweils als target_qty (Zielmenge) einträgt. Die Struktur der CSV-Datei sieht wie folgt aus:

partnumber,description,target_qty,shippingdate,warehouse,bin
5,Heftzwecken,53,29.12.2015,lager1,Lagerplatz1
4,Büroklammern,33,29.12.2015,lager1,Lagerplatz1

Beim Import kann man in der Vorschau sehen, was passieren wird:

CSV Import Einstellungen für Inventur

CSV Import Einstellungen für Inventur

Anhand der derzeitigen Menge laut Lagerbestand für das jeweilige Lager bestimmt der Importer, ob Artikel im Rahmen der Inventur eingelagert werden müssen, weil mehr als erwartet da sind, oder ob Artikel ausgelagert werden müssen, weil sich weniger auf Lager befinden. In dem Fall sieht man, daß kivitendo bei beiden Artikeln eine Mengen-Änderung von -7 Artikeln durchführen wird, um auf die vorgegebene Zielmenge zu kommen, da die Lagerbestände zu diesem Zeitpunkt 60 und 40 waren.

Damit der Standardkommentar angezeigt wird, muss man noch “Bei allen Lagerbewegungen ohne Kommentar setzen” einstellen. Der Kommentar ist derzeit auch die einzige Möglichkeit, die Lagerbewegung als Inventur- statt als einfache Korrektur zu markieren.

lager-inventur-umbuchungen

Zu beachten: bis Version 3.3 wurde in den Berichten als Datum immer das Erstellungsdatum verwendet, nicht das Lagerdatum – deshalb kann es hier zu Abweichungen kommen, wenn das Erstellungsdatum vom Lagerdatum abweicht.

 

DATEV-Export maximal nutzen

Das Standard-DATEV-Format bietet die Möglichkeit, zwei Kostenstellen mitzuexportieren.

Bisher wurde dieses Feld nicht befüllt, der DATEV-Standard sieht hier auch nur achstellige Nummern vor. Man muss also etwas überlegen, was man hier übergeben könnte.

Im aktuellen Kundenprojekt buchen zwei Mandanten in derselben kivi. Wir haben beim Steuerberater nachgefragt, ob er dies mit einer Trennung der Mandanten durch Buchungspflicht-Abteilungen und einem entsprechenden Filter beim Export abbilden kann.

Hier die Erweiterung des Exports aus Sicht des DATEV-Anwenders.
Die Kostenstelle ist in diesem Fall auf zwei Ebenen, da der Export nach dem ersten Namen gefiltert wird:

Struktur der Abteilungen:

  • wildwuchs ausbau → id 299
  • wildwuchs standard → id 300
  • wildwuchs internes → id 320
  • fuchswild ausbau → id 321
  • fuchswild standard → id 322
  • fuchswild internes → id 324

Filter für DATEV:
abteilungsfilter-datev

In Kostenstelle2 übergebe ich die Datenbank-ID der Abteilung. Somit ist diese eindeutig erfasst und der Steuerberater kann dieselben Abteilungsfilter abbilden (oder sogar noch bessere Auswertungen fahren), als in kivitendo.
Seine Sicht ist dann etwa so:

datev-mit-kostenstellen