Preisfatkoren implementiert.
Kosmetik: trailing whitespace entfernt.
Bugfix Rabattberechnung: Berechnung so umgestellt, dass der Rabatt von der Zeilensumme genommen wird und nicht vom Einzelpreis (Rundung). Fix für Bug 325.Bugfix Zwischensummen: Bei Belegen aus OE.pm (Angebote, Aufträge, Anfragen) wurde die Variable <%runningnumber%> innerhalb eines Zwischensummenblocks nicht "1.1, 1.2, 1.3" etc hochgezählt, sondern normal "1, 2, 3" etc....
Kosmetik/Vereinfachung
Kosmetikmerge aus Revisionen 5187, 5191, 5193, 5194, 5218, 5219, 5222, 5228, 5229
Kosmetik.
Debugcode entfernt.
Group_BY muss conditional sein
Kosmetikmerge aus r5130
Ein fehlender Platzhalter beim Speichern von neuen Mahnungsleveln.
Bugfix: Warengruppe => sql fehler
Kosmetik, merge aus -r5105,5106,5118,5120,5124
Die Variable $form->{error_function} konnte dazu benutzt werden, die Authentifizierung komplett zu umgehen, indem sie z.B. auf header gesetzt und der HTTP_USER_AGENT vom Client leer gelassen wird. Analog zum SQL-Ledger-Problem, das in CVE-2007-1437 beschrieben wird.
Neues Warenberichte Backend.
Von Grund auf neu geschrieben, unter Beruecksichtigung der folgenden Grundsaetze:+ ein Query fuer alles+ Query wird aus Tokens gebaut -> weniger anfaellig fuer SQL Fehler+ Kombinationen die vorher nicht erlaubt waren und per Blacklist gefiltert wurden produzieren jetzt ein Ergebnis, dass in vielen Faellen sogar interpretiert werden kann....
Storno Bugfix. paid wurde unter bestimmten Bedingungen nicht richtig gesetzt.
subtotal ist eine Boolean-Spalte; ältere DBI-Versionen mögen's nicht, wenn man ihnen dort Integer unterschiebt.
Generischer USTVA Report für alle Kontenrahmen ausser Germany
pos_ustva ist vom Typ Text, nicht Integer
Fehler in der Datenbankabfrage fuer Lieferungen bei Kundenstammdaten, Ansicht erweitert umVerkaufspreis
Diverse Bugs im Zusammenhang mit Steuerautomatiken, mit chart_id=0 oder mit rate=0.Beides sollte jedoch moeglich sein fuer Konten wie 'steuerfrei'.
Zahlungskonditionen: Zahlenwerte auf zwei Stellen gerundet ausgeben.
Zahlungskonditionen:1. Neue Variablen <%invtotal_wo_skonto%> und <%total_wo_skonto%> hinzugefügt, die die Belegsumme bzw. die noch offene Summe abzüglich des Skontobetrags beinhalten.2. Die Variablen <%total%> und <%invtotal%> waren nur bei Rechnungen gefüllt, nicht aber bei Angeboten und Aufträgen.
Umstellung der Kontenübersicht auf die Verwendung von "Template".
Umstellung der Steuerbearbeitungsfunktion auf das "Template"-Modul.
Steuern: Anzeige und Eingabe des Steuersatzes mit formatierten Zahlen. Auch Nachkommastellen bei Steuern zulassen. Kosmetik.
Korrekturen zu r2737: Speichern von Steuern funktionierte nicht, taxnumber mitspeichern, Layout Titel
Neues Modul 'Steuern Bearbeiten'. Mit diesem Modul ist es moeglich, die Eintraege der Tabelle tax, bzw. _tax anpassen zu koennen.
Form::redirect muss auch Zahlen in Scriptnamen zulassen, weil ansonsten z.B. menuv3.pl nicht ausgeführt wird.
Aus Debuggründen war's noch auskommentiert.
Beim Versenden per Email eine anständige Überschrift anzeigen und nicht "email oe".
Beim Versenden von Emails wird der Text etc wieder in intnotes gespeichert. Fix für Bug 713.
Verhindern, dass durch Manipulation von $form->{callback} beliebiger Code ausgeführt werden kann.
Pfadkomponenten entfernen, bevor exec aufgerufen wird, damit nicht beliebige Perlscripte ausgeführt werden können.
Ganz böse Verwechselung mit 't' und 'f' bzw. '1' und '0', die zur Verwechslung von Angeboten und Aufträgen geführt hat. Kam aus rev 2698.
Das nächste Release ist 2.4.3.
Webdav: Die Links werden nicht mehr wortwörtlich angezeigt, sondern der Typ (Datei oder Verzeichnis) wird ausgegeben und als Link hinterlegt.
Webdav: Wenn eine Pfadkomponente Leerzeichen enthielt (z.B. "Storno zu ..."), dann wurden komplett falsche Links erzeugt.
$form->get_standard_dbh() benutzen für verbesserte Geschwindigkeit
Bei Einkaufsrechnungen muss das Rechnungsdatum als Anhaltspunkt für die zu verwendenden Steuerschlüssel und -sätze benutzt werden. Fix für Bug 710.
Verkaufsrechnungen: Beim Stornieren den absoluten Ertrag negativ speichern.
Rechnungsliste: Unterscheidung zwischen Stornorechnung und stornierter Rechnung wieder gefixt.
Beim Stornieren von Einkaufs- und Verkaufsrechnung auch die storno_id mit speichern (analog zu AR.pm/AP.pm), damit später eine Unterscheidung zwischen Stornorechnung und stornierter Rechnung möglich ist.
Bei boolean-Spalten lieber 't' und 'f' als 1 und 0 übergeben, weil wohl einige DBD::Pg-Versionen damit Probleme haben. Außerdem einige Integerwerte mit 0 initialisieren. Hoffentlich ein Bugfix für 703.
Umwandlung von Angebot nach Auftrag hat nach Fehler verursacht, da gleiches Modul
Bei der Umwandlung eines Auftrags in eine Rechnung wurde die individuelle Lieferadresse nichtgespeichert
Mahnungen: Die Konfiguration so umgestellt, dass jetzt nicht mehr global entschieden wird, ob automatisch Rechnungen für die Mahngebühren und Zinsen erzeugt werden, sondern pro Mahnlevel. Die Dokumentation um die von Lx-Office erzeugten Namen für die Mahnungsvorlagen (auch für die Rechnung) erweitert.
update_business und update_defaults: Bei sehr langen Zahlenkomponenten wurden die erzeugten Nummern leider auf -0000000...001 gesetzt. Grund ist, dass der Formatierer '%d' für sprintf auf 32bit-Systemen nun mal nur mit 32bit-Zahlen umgehen kann. Geriet die Zahlenkomponente größer als 2147483647, so erhielt man einen Überlauf.
Bei Template-Vorlagen per Default nicht vorne und hinten die Zeilen bereinigen -- ist zum Debuggen einfacher.
ReportGenerator: Man kann jetzt die Standardanordnung (align) in den Spalten angegeben werden.
Mehr perldoc
ReportGenerator: Wenn keine Datensätze hinzugefügt wurden, dann wird eine entsprechende Meldung anstelle der Spaltenüberschriften ausgegeben. Die Export-Buttons werden in diesem Fall ebenfalls nicht angezeigt.
Kosmetik
Waren-/Dienstleistungs-/Erzeugnisberichte auf die Verwendung von ReportGenerator umgestellt.
Wenn ein Hash namens %main::debug_options existiert, dann werden all seine Variablen 'key' in HTML-Vorlagen als DEBUG_KEY zur Verfügung gestellt. Wird bisher nur bei Mahnungsvorlagen benutzt. Und ist nur für Entwickler gedacht.
Debugmeldung entfernt
Beim Drucken von Mahnungen stand die Kundennummer nicht zur Verfuegung
Kunden- und Liferantenstammdatenliste auf die Verwendung von ReportGenerator umgestellt.
Mahnungen: Neuer Variable für jede Rechnung: <%dn_linetotal%> als für diese Rechnung zu zahlender Betrag (offener Betrag zuzüglich Mahngebühren und Zinsen).
Einführung des Modules "Template" als schnellere Alternative (Faktor 9) zu "HTML::Template". Wird via $form->parse_html_template2() aufgerufen. Umstellung der von ReportGenerator verwendeten Vorlage auf die Verwendung von "Template".
Erweiterung um Anzeige des Ertrages im Verkauf
Buchungsliste:1. $form->{sort} nicht ohne Überprüfung in einem SQL-Query benutzen.2. Nur dann mehrere Zeilen zusammenfassen, wenn auch ihre ID übereinstimmen (was vermutlich nie der Fall sein wird, aber anders ist es schlicht falsch, weil dann Buchungen zusammengefasst werden können, die zu unterschiedlichen Belegen gehören).
ReportGenerator: Möglichkeit zum Einfügen einer "leeren" Zeile, die die ganze Tabellenbreite einnimmt.
ReportGenerator: Die Spaltendatenfelder 'data' und 'link' können jetzt auch Array-Referenzen sein, die in der Zelle zeilenweise ausgegeben werden.
Konvertierung von lokalisierten HTML-Seiten in den als $dbcharset angegebenen Zeichensatz.
ReportGenerator: Unix-Zeilenenden als Standard aktiviert. Grund ist, dass Excel nicht damit zurecht kommt, wenn Zelleninhalte mit \r\n umgebrochen werden, wohl aber, wenn die ganze Datei nur mit Unix-Zeilenenden formatiert ist.
Beim CSV-Export Zeilenumbrüche in Zellendaten durch das ausgewählte Format ersetzen.
Durch das Verschieben der Headerausgabe beim PDF-Export wurde der Name des Attachments nicht richtig gesetzt (jeweils nur '.pdf'). Fix für Bug 681.
Stornierte Rechnnung muss auf storno = true haben
Stornomechanismus mal auf Dialogbuchen ausgeweitet
storno fix: acc_trans query muessen nach oid sortieren
1. $form->{title} wird nicht mehr zwangsweise umgeschrieben und nach $form->header() wiederhergestellt.2. Kosmetik: lokale Variable $form anstelle von $self->{form}.
Storno Fix nr. 29283574983745
Es werden beim Storno jetzt nur noch die urspruenglichen acc_trans Eintraege storniert,nachtraegliche Zahlungseingaenge bleiben unberuehrt.
Paket 'List::Util' wird nun benutzt (sollte aber eh zu jeder Standard-Perl-Installation gehören). Die Teile der URLs entfernt, die spezifische Versionsnummern der Pakete enthalten.
Reportgenerator: Beim Listenexport als PDF kann das PDF auch direkt ausgedruckt werden.
Zahlungseingang:Das Buchungskonto wird nicht benutzt, und wird deshalb nicht mehr angezeigt.Die Backendfunktion holt sich das benoetigte Konto sowieso aus den Rechnungen.
Ausserdem ein Bugfix:currency ist bei alten Rechnungen auf '' gesetzt, bei neuen auf NULL (nach sql-injection fix)...
Debugmodi umgeschrieben auf das viel schoenere shiftingformat.Neuer Debugmodus "DEVEL", der genau das enthaelt was man ueblicherweise zum debuggen braucht,ohne den overhead von ALL.
Beim Laden von Dialogbuchungen wurde das Belegfeld nicht mitgeladen
und das ganze nochmal für Kreditorenbuchungen und deren Stornos
bin/mozilla/ar.pl auf use strict standard gebracht.
Debitoren storno umgeschrieben und Bug gefixt.
Etwas mehr Übersicht.
Reportgenerator: Man kann jetzt auch Trennzeilen einfügen, die in der HTML-Ausgabe als horizontale Linie über die gesamte Tabellenbreite realisiert sind.
Berichtsklasse:1. Commit der vorher vergessenen HTML-Templates für die Berichte und die Exportoptionen.2. HTML-Berichte: Zeilenumbrüche mit "\n" werden in "<br>" umgewandelt.3. CSV-Export: Richtiger MIME-Type; Download der Datei forcieren; Option für die Spaltenüberschriften gefixt.
Eine Report-Klasse geschrieben, der die Ergebnisse von Datenbankabfragen übergeben werden. Diese Klasse kann daraus dann entweder die bekannten Listenansichten oder auch CSV- und PDF-Exporte erzeugen. Dazu werden entsprechende Buttons eingeblendet.Dazu werden einige neue Perl-Module (Text::CSV_XS und IO::Wrap) sowie zwei weitere Hilfsprogramme (html2ps und Ghostscript) benötigt, deren Pfade über die lx-erp.conf eingestellt werden müssen.
Webdav-Feature: Pfadtrennzeichen aus den Nummern (Angebotsnummer, Rechnungsnummer etc) entfernen.
In der Kürze liegt die Würze.
Eingangsrechnungen: Wirklich das Datum der zuletzt erstellten Rechnung benutzen, nicht das maximale Datum.
Eingangsrechnung: Als Rechnungsdatum wird das Datum der letzten Eingangsrechnung vorausgewählt. Zusätzlich wird das Fälligkeitsdatum in Abhängigkeit von den beim Lieferanten ausgewählten Zahlungsbedingungen gesetzt.
Zur Überwachung von $form-Variablen können jetzt mehrere gleichzeitig ein- oder ausgeschaltet werden. Syntax: $form->{"Watchdog::var1,var2,var3"} = 1;
Der letzte Einkauspreis wurde nicht geladen und daher auch keine MArgenberechnung
Mahnwesen:1. Beim Erzeugen neuer Mahnungen wurden unter Umständen überall die falschen nächsten Mahnstufen vorausgewählt.2. Rechnungen, die bereits auf der höchsten Mahnstufe waren, wurden nicht mehr angezeigt.
Probleme mit mehreren Währungen und Wechselkursen behoben.
"Als bezahlt markieren" Button-Funktion in die common.pl verlegt.
neuen button und Funktion für "als bezahlt markieren" eingeführt.
Buchungen wurden nicht korrekt angezeigt, wenn gleiche Referenz aber unterschiedlicheBeschreibung
Der benannte Parameter $copy_accnos wird ansonsten nicht verwendet.
ic.pl auf use strict umgeschrieben (experimentell)ic.pl generate_reports konsistenzchecks umgeschirben, und kommentiert, wird im weiteren mit verbesserter datenbanklogikverwendet.SL/IC.pm: kosmetik
Eine neue Funktion eingebaut, mit der eine einzelne Datenbankverbindung zum Abholen verschiedener Funktionen genutzt werden kann. Diese Datenbankverbindung wird erst beim Ende der Lebenszeit von $form wieder geschlossen. Momentan bauen fast alle Backendfunktionen eine eigene Datenbankverbindung auf. Hiermit ist das teilweise überflüssig.
Die Funktion "Zahlung buchen" bei Kreditorenrechnungen komplett umgeschrieben. Sie verlässt sich nun nicht mehr auf die aktuellen Daten in $form, um die alten Einträge in acc_trans zu löschen, sondern lädt den vorherigen Stand aus der Datenbank, entfernt darauf basierend die Einträge in acc_trans und lässt AP->post_transaction() selber die Zahlungen eintragen....
Ein Fehler an dieser Stelle ist nicht schlimm, da er auch dadurch zustande gekommen sein kann, dass die Tabelle 'schema_info' noch nicht existiert. Das passiert z.B., wenn man eine pre-2.4.0.0-Datenbank im Admin-Menü aktualisieren möchte.
Mehrere Fehler in der Kontenuebersicht behoben