Einen sehr guten Eindruck macht Andreas Korte von der vitracom AG, als er auf der CeBIT über die Motivation seines Betriebes, kivitendo als Warenwirtschaft und SAP-Nachfolger einzusetzen, referiert.
Hier die bisher unveröffentlichten Votragsfolien: cebit-2016-kivitendo-sap_4
kivitendo
Ohne, dass wir google per adWords geschmiert haben. Allerdings haben wir das Sponsor-Paket: “Vortrag – ohne Call for Paper-Stress” der OSB Alliance erworben.
Hier mein Beweis-Screenshot:
Das passt super ins Konzept, denn auch bei meinem aktuellen Kundenprojekt werden alle kivitendo-Tipps in den sehr schönen Notizblock von SAP geschrieben …
Alles richtig gemacht!
Wir sehen uns auf der CeBIT!
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;
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:
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:
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:
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:
Filter für 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:
Durch das sehr gute neue E-Mail-Journal sind mir jetzt auch die automatischen SelfTests ins Auge gefallen.
Ursprünglich sind diese Tests als QS für Voll-Fibu-kivitendo Benutzer entwickelt worden, also solche Betriebe, die auch die Bilanz mit kivitendo selbst erstellen und zeichnen.
Allerdings lassen sich auch hiermit sehr gut Fehleingaben oder andere Problemchen entdecken, bevor sie sich symptomatisch über ein ganzes Geschäftsjahr hinziehen.
Standardmässig werden die SelfTests täglich ausgeführt (insofern konfiguriert) und beinhalten aktuell 17 Tests.
Die Tests geben die Ergebnisse zwar auf Englisch und leicht kryptisch aus, aber für ein geübtes Auge ist dies sicherlich verwertbar, bspw.:
Hier fällt der Test 12 negativ auf, da ar (accounts receivable) überbezahlt ist. Der Test gibt auch noch eine Rechnungsnummer als Hinweis mit aus. Mit dieser Info kann man dann simpel den Zahlungseingang korrigieren, der zwar korrekt ist, in diesem Fall aber der falschen Rechnung (allerdings dem richtigen Kunden) zugeordnet wurde:
Voraussetzung für die Selftests ist, dass es einen Login mit einer gültigen E-Mail-Adresse gibt.
Ferner muss der task_server für diesen Mandanten eingeschaltet sein.
Dann wird man mit folgender Einstellung nur im Fehlerfall benachrichtigt:
Das hat mich heute sehr gefreut, diesen Commit auf der Projektliste zu sehen:
commit 72f19f83681b222d1606d75c90ceedc43bb545f9
Author: Moritz Bunkus <m.bunkus@linet-services.de>
Date: Thu Sep 24 11:42:15 2015 +0200
E-Mail-Journal: Journal anzeigen, Eintrag anzeigen, Anhänge herunterladen
In unseren Projekten empfehlen wir immer möglichst viel über die E-Mail-Funktion des Systems zu versenden, da dies dann im internen Bemerkungsfeld der Belege entsprechend mitprotokolliert wird. Blöderweise kann man hierüber keine direkte Auswertung sehen.
Das ändert sich ab heute in der devel-Version von kivitendo und in einigen Monaten dann im nächsten Release.
Wenn jetzt E-Mails verschickt werden, werden zusätzlich noch der Status (erfolgreich versendet) und der Zeitpunkt in einem extra Bericht mitprotokolliert:
In der Detailansicht der Mail wird dann auch nochmal die gesamte E-Mail inkl. Dokumentanhang dargestellt. Somit ist dies zusätzlich zu der WebDAV-Archivierung der Belege eine richtig sinnvolle Archivfunktion, um wirklich nachzuvollziehen, was an den Empfänger in welchen Zeitraum geschickt wurde. Ferner ist dann auch die Darstellung der Mail etwas klarer, weil hier alle E-Mail-Teile nochmal angezeigt werden:
Da zwei sehr schöne Features in der aktuellen Devel-Version vorhanden sind und außer wirklichen Bugfixes seit dem Release nichts weiter passiert ist, lohnt sich vielleicht schon jetzt ein Upgrade auf die heutige Version.
Administratoren, die aus dem git heraus installiert haben und lokale Änderungen im eigenen Branch verwalten (s.a. Vortragsfolien git und kivitendo bzw. Video) können heute bedenkenlos (insofern 3.3 im Einsatz):
$ git checkout master
$ git pull
$ git checkout mein_eigener_branch
$ git rebase master
$ service apache2 restart
durchführen …
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 ;-).
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:
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:
Hier die wichtigste Info auf den Punkt (steht aber auch genauso im Wiki):
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
__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
buchen möchte. Es wird je nach Zahlungsbetrag und Zahlungsdatum ein sinnvoller
Vorschlag gemacht.
Kleinere neue Features und Detailverbesserungen:
Bugfixes:
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.
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:
Bugfixes: