In Anlehnung an den letzten Eintrag wird jetzt auch kurz die neue Skontobehandlung in der aktuellen Unstable anhand eines Beispiels im Wiki vorgestellt:
http://redmine.kivitendo-premium.de/projects/forum/wiki/Skontobehandlung
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:
So schick die Datenbankabfragen per Rose sind, will man doch ab und an schauen, was da im Hintergrund auf Datenbankebene passiert, also welche SQL-Queries eigentlich generiert werden.
Während man beim alten Code in der kivitendo.conf unter [debug] per
global_level = QUERY
noch alle SQL-Abfragen in der Logdatei protokollieren konnte, muß man bei Rose nun
dbix_log4perl = 1
einstellen, um die von Rose generierten Queries zu sehen. Das produziert dort auch immer unheimlich viel Ouput.
In der Console kann man bei Manager-Methoden einen debug-Parameter übergeben, wo das generierte SQL ebenfalls angezeigt wird:
my $invoices = SL::DB::Manager::Invoice->get_all( where => [ id => 962 ], debug => 1);
SELECT
t1.amount,
t1.cp_id,
t1.currency_id,
< ... snip ... >
t1.type
FROM
ar t1
WHERE
t1.id = ? (962)
Man kann aber auch das Logging explizit für alle Anfragen in der console Session (oder sogar beim Entwickeln von Test-Skripts) anstellen:
$Rose::DB::Object::Manager::Debug = 1;
$Rose::DB::Object::Debug = 1;
Ab dann sieht man direkt in der console, welche SQL-Abfragen im Hintergrund passieren, z.B. bei der Benutzung eines Filters:
SL::DB::Manager::Invoice->get_all(where => [ SL::DB::Manager::Invoice->type_filter('invoice') ]);
SELECT
t1.amount,
t1.cp_id,
t1.currency_id,
< … snip … >
t1.type
FROM
ar t1
WHERE
(
(
t1.storno = ? OR
t1.storno IS NULL
) AND
t1.amount >= ? AND
t1.invoice = ?
) (0, 0, 1)
Ein paar Beispiele zum selber Ausprobieren:
Schnell schauen, welche Abfragen mit with_objects oder require_objects generiert werden:
Alle Artikel, mit LEFT OUTER JOIN auf die Tabelle partsgroup
my $parts = SL::DB::Manager::Part->get_all( with_objects => [ 'partsgroup' ] );
Nur die Waren, die eine Warengruppe haben:
my $parts = SL::DB::Manager::Part->get_all( require_objects => [ 'partsgroup' ] );
Oder der Unterschied in der Abfrage, ob man einen Artikel per
my $part = SL::DB::Part->new( id => 962 )->load;
oder per
my $part = SL::DB::Manager::Part->find_by( id => 962 );
ausliest.
Ich war ein paar Tage unterwegs und wollte jetzt die Reisekosten in kivitendo verbuchen.
In unserem Demo-Mandanten, der Steigmann-Werft, gibt es für diesen Fall noch kein Beispiel, deshalb will ich das hier nochmal dokumentieren.
Der Mehrwertsteuersatz für Übernachtung und Frühstück unterscheidet sich ja mittlerweile, und es gilt auch den Verpflegungsmehraufwand zu verbuchen.
Als Beispiel nehme ich den Angestellten Herr Müller, der für die Übernachtung 30€ inkl. Frühstück bezahlt, wobei 27€ auf die Übernachtung und 3€ auf das Frühstück entfallen, es geht um insgesamt 5 Übernachtungen und einem An- und Abreisetag.
In SKR04 gibt es dafür die Konten 6660 Reisekosten Arbeitnehmer Übernachtungsaufwand für das Zimmer und 6650 Reisekosten Arbeitnehmer für das Frühstück. Und da Herr Müller gerne alles vor Ort in bar bezahlt, und hinterher die Belege einreicht, haben wir für ihn auch in kivitendo ein eigenes Verbindlichkeitskonto 3638 Verbindlichkeiten Müller eingerichtet, damit die Firma immer weiß, wieviel sie ihm noch zurückzahlen muß.
In kivitendo würde man das als Dialogbuchung wie folgt erfassen:
Beim Verpflegungsaufwand setzt man 12€ pro Tag für normale Arbeitstage mit mehr als 8 Stunden oder Anreisetage an, und 24€ pro Tag bei Abwesenheit von 24h.
Herr Müller ist am Freitag angereist, hatte vier volle Tage vor Ort, und ist am Mittwoch wieder abgereist. Das macht 12 + 4*24 + 12 = 120€.
Bezahlt die Firma allerdings Herrn Müller vor Ort einige der Mahlzeiten, so gibt es Abzüge von dieser Pauschale, und zwar 20% für das Frühstück und jeweils 40% für Mittagessen und Abendessen, bezogen auf die Pauschale für 24h. Das macht beim Frühstück also einen Abzug von 4,80€ und Mittagessen und Abendessen von jeweils 9,60€.
Da die Firma nur das Frühstück bezahlt hat müssen von den 120€ also noch 5*4,80€ abgezogen werden, das macht dann insgesamt 96€. Das betreffende Konto heißt 6664 Reisekosten Arbeitnehmer Verpflegungsmehraufwand und wird wieder gegen das Verbindlichkeitskonto von Herr Müller verbucht.
Den aktuellen Saldo vom Verbindlichkeitskonto von Herrn Müller kann man sich jederzeit im Buchungsjournal, in der Bilanz oder in der SuSa anschauen. Den Ausgleich bucht man wieder per Dialogbuchung. In der Dialogbuchungsmaske wird der aktuelle Saldo des Kontos ebenfalls angezeigt, mit dem praktischen Hinweis, ob der Saldo im Soll oder Haben ist. In diesem Fall beträgt der Saldo von Konto 3638 246€ im Haben, so daß ich das Konto im Soll verbuchen muß, um das Konto zu “leeren”. Das Gegenkonto ist das Bankkonto, von dem aus ich überweise.
Ist Herr Müller mit der Bahn gefahren bucht man die Fahrkarten nach dem gleichen Schema wie oben, das Konto ist 6663 Reisekosten Arbeitnehmer, Fahrtkosten
.
Update: Die gesetzliche Regelung für den Verpflegungsmehraufwand findet sich übrigens in §9 Absatz 4a EStG.
Die Chemnitzer Linuxtage haben am kommenden Wochenende wieder ein sehr schönes Vortragsprogramm zusammengestellt.
Ich bin mir gar nicht sicher, wie lange es her ist, aber auf jeden Fall über 10 Jahre, daß ich das letzte Mal die CLT besucht habe. Dieses Jahr ist es wieder soweit, wenn auch “nur” als Besucher.
Für alle kivi-Fans aus der Gegend, denen es zum Anwendertreffen am 16.4. zu weit ist, biete ich aber gerne an, sich am Samstag oder Sonntag zu verabreden, am Besten einfach vorab eine Mail schreiben, dann können wir das organisieren.
Oder sprecht mich einfach spontan an, ich bin dann der mit dem kivitendo T-Shirt.
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 😉
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.
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));
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