Category Archives: kivitendo development

Aktuelle Entwicklerversion von kivitendo installieren

Wer schon einmal die aktuelle Entwicklung in seiner Umgebung ausprobieren möchte, installiert am besten eine Version mittels git wie folgt:

Bildschirmfoto vom 2017-03-21 08-11-31

Danach einfach die Schritte, wie in der Installationsanleitung beschrieben, durchführen.

Wer schon eine bestehende git-Installation hat, kann diese einfach kopieren und dann im Apache als weitere Installation konfigurieren, bspw.


$ cp -a kivitendo/ kivitendo-devel/
$ cd kivitendo-devel/
$ git branch # zeigt die aktuellen zweige
$ git checkout master
$ git pull
$ vim config/kivitendo.conf # !!! die auth-db ändern, damit nicht das Echtsystem hochgezogen wird!
- db = kivitendo_auth
+ db = kivitendo_auth_devel
$ service apache2 restart

Den Rest dann in der apache.conf einstellen, wie in der Anleitung beschrieben.
Ich hab in der Regel ein kleines Synchronisationsskript um Echtdaten direkt in eine Test-DB zu analysieren, in etwa so:

#!/bin/bash
pg_dump -U postgres -h 127.0.0.1 kivi > /tmp/kivi.sql
psql -U postgres -h 127.0.0.1 template1 < drop-create-devel.sql
psql -U postgres -h 127.0.0.1 kivi-devel < /tmp/kivi.sql

$ cat drop-create-devel.sql

DROP DATABASE kivi-devel;
CREATE DATABASE kivi-devel;

kivitendo bei den Chemnitzer Linux-Tagen

Unsere Partner Neumann Medien IT, V-SOLUTION und die kivitec GmbH sind dieses Wochenende mit einem eigenen Stand bei den Chemnitzer Linux-Tagen. Wer sich über kivitendo und seine Einsatzmöglichkeiten informieren will, bekommt hier die beste Möglichkeit dazu. Dazu gibt es noch einen Vorgucker auf die bald erscheinende kivitendo-Version 3.5.

Wer nicht so recht weiß, was ihn in Chemnitz erwartet, kann HIER mal einen Blick aufs Vorjahr werfen.

Wem Termin oder Ort nicht zusagen, der sollte sich auf jeden Fall das jährliche kivitendo-Treffen vom  27. bis 28. April 2017 in Bonn vormerken. Weitere Infos dazu folgen in Kürze.


Chemnitzer Linux-Tage Logo

kivitendo goes Schwiiz – “Modus Schweiz” in kivitendo 3.4.1

Gastbeitrag von Andreas Rudin (revamp-it)

Mit dem Release 3.4.1 steht kivitendo nun auch produktiv für einen Einsatz in der Schweiz zur Verfügung. Ein Umstand, der einige spezifische Erweiterungen erforderte und einige Zeit in Anspruch genommen hat. Realisiert wurde der Modus Schweiz von revamp-it aus Zürich, dem Schweizer Entwicklungspartner von kivitendo. Dieser Gastbeitrag von Andreas Rudin gibt einen Überblick über den Modus Schweiz.

Nach der Installation von kivitendo wird in der Konfiguration einmalig der neu vorhandene default manager auf “swiss” gestellt. Anschließend werden beim Erstellen einer neuen Datenbank automatisch die für die Schweiz typischen Grundeinstellungen vorausgewählt:

  • Schweizer Franken als Währung
  • KMU-Kontenplan mit den aktuellen gesetzlichen Anforderungen
  • Hochkomma als Tausender Trennzeichen
  • automatische Rundung von Verkaufsbelegen auf 5 Rappen inkl. Verbuchen der Rundungsdifferenzen
  • Erfolgsrechnung statt GUV
  • Ausblenden von UStVa und DATEV
  • Sollversteuerung, Aufwandsmethode, Bilanzierung

Diese Vorauswahl kann manuell an individuelle Bedürfnisse angepasst werden.

Neben dem Kontenplan für mehrwertsteuerpflichtige Firmen steht ein weiterer Kontenplan für Betriebe und Institutionen zur Verfügung, die nicht mehrwertsteuerpflichtig sind.

Die Erfolgsrechnung, in der alle Aufwands- und Ertragskonten einzeln aufgelistet werden, kann auch beim Einsatz von anderen Kontenplänen (SKR3 oder SKR4) in der Mandantenkonfiguration freigeschaltet werden.

Beim Einsatz von OpenDocument-Vorlagen besteht mittels eines Makros die Möglichkeit, Verkaufs-Rechnungen oder Aufträge mit Schweizer Einzahlungsscheinen mit Referenzzeile direkt aus kivitendo heraus erzeugen und verschicken zu können.

Eine ausführliche Beschreibung aller Modus-Schweiz-Features findet sich in der Online-Dokumentation zu kivitendo.

 

kivitendo-Version 3.4.1 im Orbit angekommen

Die Juno-Sonde ist im Jupiter-Orbit angekommen und kivitendo in der Version 3.4.1 veröffentlicht. Ein perfekter Tag also – sowohl für die Nasa als auch das kivitendo-Team. Während Juno geschlagene fünf Jahre unterwegs war, hat kivitendo sich nur rund drei Monate Zeit gelassen.

Wie immer präsentieren wir das bis dato stabilste kivitendo. Das sieht man
auch daran, dass bei den mittlerweile 49 Komponenten-Tests 32.000 automatisierte
Datenvarianten geprüft werden, bevor eine Version offiziell veröffentlicht wird.

Neues Release mit vielen Detailverbesserungen

Passend zu ihrer Versionsnummer bringt die 3.4.1 viel Liebe zum Detail mit:

Die Brieffunktion wartet jetzt mit Formatierungsmöglichkeiten auf und gleichzeitig ist es möglich, Briefe per Mail zu verschicken. Dazu wurden Schwachstellen wie die Weiterleitung nach dem Löschen von Briefen, das direkte Drucken auf Drucker und die Auswahl einer Ansprechperson gefixt.

Beim CSV-Import ist es ab sofort möglich, die Spalten der jeweils hochgeladenen Datei frei zuzuordnen und die entsprechende Zuordnung auch im Profil zu speichern. Die Schnellsuchen im Header wurden – designed auf schnellen Zugriff – nochmal erweitert und sind pro Mandant konfigurierbar.

Weiteres Tuning erhielt der neue Code im Bereich der Auftragsmaske – mit vielen Positionen ist mit der neuen Version ein schneller Zugriff möglich. Diese Funktion ist momentan noch experimentell geflaggt, ist aber bereits im Programm und kann getestet werden.

Neben diversen weiteren Detailverbesserungen, die bei Interesse im Changelog zu lesen sind, bekam auch der Schweizer Modus einige entscheidende Verbesserungen spendiert:

Die 3.4.1 bringt einen neuen Kontenrahmen, die Erfolgrechnung, das 1‘000.00 Zahlenformat und die Fünf-Rappen-Rundung mit. Unter anderem besteht auch die Möglichkeit, Rundungserträge und –verluste aus der Fünf-Rappen-Rundung zu verbuchen.

Wer sich die neue kivitendo-Version live anschauen möchte – wie gehabt sind wir am 20. und 21. August mit Stand und Vortrag auf der → FrOSCon 2016 zu finden. Dazu mehr in Kürze.

Neue Auftragsmaske in kivitendo

Das aufwändigste neue Feature in der Version 3.4.0, das wahrscheinlich auch den größten Einfluss auf die weitere Entwicklung von kivitendo haben wird, ist der neue Auftragscontroller. Ziel dabei ist es, die alte durch eine neue Auftragsmaske zu ersetzen.
Da die neue Maske aber noch nicht alle Features ihres Vorgängers beherrscht, ist dieses Feature im Menü noch als “experimentell” markiert, und kann parallel zu der alten Auftragsmaske verwendet werden. Jeder kann testen, ob die Funktionalität der neuen Maske schon für den eigenen Einsatz ausreicht. Bei einigen Kundenprojekten von uns ist die Auftragsmaske bereits produktiv im Einsatz.

Langfristig soll die neue Maske auch die technische Grundlage für neue Lieferschein- und Rechnungsmasken bilden.

Neue Auftragsmaske in kivitendo

Die alten Belegmasken haben u. a. zwei große Probleme. Zum einen ist das generell sehr alter Code, der schlecht wartbar ist und es nicht einfach macht, die modernen und benutzerfreundlichen Features von kivitendo, z.B. Kundenpicker, Partpicker, Projektpicker etc., in einzubauen.

Zum anderen wird die alte Maske ab einer gewissen Zahl von Artikeln einfach sehr langsam. Beim Hinzufügen eines neuen Artikels wird die Seite jedes Mal komplett neu aufgebaut  – das dauert mit einer steigenden Anzahl von Auftragspositionen immer länger, so wird das effiziente Bearbeiten irgendwann schlicht unmöglich.

Bei der neuen Maske wurde von Anfang an auf eine schnelle und effiziente Eingabe geachtet. Die Seite wird beim Hinzufügen neuer Artikel nicht mehr jedes Mal neu aufgebaut, sondern dynamisch erweitert und die Gesamtsummen laufend aktualisiert.
Hierfür gibt es oberhalb der Artikelliste eine zentrale Eingabezeile, in der man neue Artikel zu der wachsenden Liste hinzufügt.

Alle Eingabefelder bei denen man aus einer Liste auswählen kann, also z.B. Kunde und Projekt, sind nun über Picker realisiert. Der Kundenpicker reagiert sowohl auf Kundennummer als auch Kundenname und zeigt bei Auswahl auch beides an.

Was die neue Maske im Vergleich zur alten noch nicht kann:

  • es gibt keine Detailszeile mit z.B. Ertrags- und EK-Preis-Informationen
  • Kundendetails anzeigen
  • Kreditlimit-Warnung
  • individuelle Lieferadressen
  • wiederkehrende Rechnungen konfigurieren
  • Preisfaktor ist noch nicht gut getestet
  • Sprache und Währung auswählen
  • die meisten der Workflow-Schritte, z.B. kann man bisher nur einen Lieferschein, nicht aber eine Rechnung oder einen Lieferantenauftrag  aus dem aktuellen Auftrag erstellen

Für viele Anwendungsfälle ist die neue Maske aber dennoch schon geeignet und ausprobieren kann man sie auch in unserer Demo unter “Verkauf  Auftrag erfassen (experimentell)“. Unter “Verkauf → Berichte → Aufträge” kann man auch auswählen, ob man bestehende Aufträge mit der alten oder der neuen Maske öffnet.

kivitendo mit E-Mail-Journal

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 …

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)

 

Rose Debugging in der console

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.