Jan Büren [Thu, 12 May 2016 11:10:59 +0000 (13:10 +0200)]
SelfTest: Überbuchte Bank-Transaktion finden
Es ist möglich, mehrere Rechnungen auf einen Schlag einer Bankbewegungen
zuzuordnen. Aktuell wird an der Oberfläche der Anwendung hier keine
Warnmeldung/Rückmeldung ausgegeben. Eine überbuchte Bankbewegung ist
aber auf jeden Fall nicht buchungskonform und muss entsprechend in der
Datenbank korrigiert werden.
Entsprechend einen Test hierfür geschrieben.
Wenn sich das Script beendet, so kann es sein, dass der Webserver
bereits den nächsten Request zum Script geschickt hat. Ist das der Fall,
kommt es zu einem internal server error für den User.
Statt dessen kann sich das Script selber ausführen. Dadurch werden die
Kommunikationskanäle zwischen Webserver und Script (STDIN, STDOUT,
STDERR) aufrechterhalten.
Moritz Bunkus [Mon, 2 May 2016 12:37:47 +0000 (14:37 +0200)]
Dispatcher: Restart bei hohem Memory-Verbrauch via exec anstelle von exit
Wenn sich das Script im Fall von zu hohem Speicherverbrauch beendet, so
kann es sein, dass der Webserver bereits den nächsten Request zum Script
geschickt hat. Ist das der Fall, kommt es zu einem internal server
error für den User.
Statt dessen kann sich das Script selber ausführen. Dadurch werden die
Kommunikationskanäle zwischen Webserver und Script (STDIN, STDOUT,
STDERR) aufrechterhalten.
Sven Schöling [Mon, 2 May 2016 14:25:58 +0000 (16:25 +0200)]
select styling in lx-office-erp.css
Irgendwer bei Firefox 46 scheint was geraucht zu haben. Das Stylesheet
hatte alle anderen windowmanager decorations überschrieben, aber FF
hat seit 32 select appearance ignoriert. Angeblich aus
Sicherheitsgründen. Das haben sie glücklicherweise gerade rechzeitig
gefixt, weil sie nun das unity7 Theme nochmal kaputter gemacht haben.
Ansonsten wäre das unbenutzbar.
Moritz Bunkus [Wed, 27 Apr 2016 12:45:46 +0000 (14:45 +0200)]
Request handling: bei zu hohem Speicherverbrauch erst flushen, dann beenden
Wenn sich das Script sofort beendet, dann werden Daten nicht an den
Webserverprozess geschickt und der wiederum schickt eine unschönen
Internal Server Error an den Client.
Daher zuerst den Request vollständig an den Server schicken und damit
den laufenden Request abschließen, bevor sich der Prozess beendet.
Die Perioden beginnen nicht mehr immer nur am 1. des Monats, sondern an
dem Tag, der über das Vertragsstartdatum angegeben ist. Daher müssen
auch die Variablen <%period_start_date%> und <%period_end_date%> anhand
des Vertragsstartdatums gesetzt und dürfen nicht auf den Monatsbeginn
beschnitten werden.
Sven Schöling [Thu, 21 Apr 2016 11:10:28 +0000 (13:10 +0200)]
Keine Default Exporte mehr in den main:: space
Ich hoffe ich habe alle erwischt. Dieser Commit, macht folgendes:
Exports in den main:: space passieren immer, wenn ein bin/mozilla/
script ein Modul einbindet, das @EXPORT setzt.
Laut meiner ack/grep Magie sind das SL::MoreCommon und SL::Helper::Flash
gewesen.
In beiden Fällen waren das importe, wo die eigentlichen Funktionen
vorher im main:: space gelegen haben und dann nachträglich in ein Modul
verschoben wurden.
Ich habe also:
1. Im script selber die Exportliste exakt auf die Funktionen gesetzt die
das script selber benutzt, gefunden mit dem oneliner:
Das waren in Flash: flash und in MoreCommon: save_form und restore_form.
2. Für den Fall, dass andere scripte im main:: Space diese Funktionen
benutzen alle anderen bin/mozilla Scripte nach diesen Funktionen
durchsucht, und für den Fall dass sie _nicht_ selber ein require
b/m/common.pl machen die entsprechenden imports hinzugefügt.
Nein, das war kein Fix für http://trac.kivitendo.de/ticket/2232
Implementiert wurde (imho):
a) Wenn es eine gültige Einheit gibt
b) Dann nimm das erstbeste Einzelteil einer Erzeugnis-Ware
c) und konvertiere die ausgewählte Einheit des Erzeugnis in die Einheit
der erstbesten Erzeugnis-Ware.
Jan Büren [Tue, 19 Apr 2016 13:10:52 +0000 (15:10 +0200)]
Erzeugnis fertigen verbessert
Transfertyp assembled hinzugefügt
Bei gefertigten Erzeugnissen sowie bei verbrauchten Waren
das tagesaktuelle Datum gesetzt (vorher wurde gar keins gesetzt).
Moritz Bunkus [Mon, 18 Apr 2016 13:19:37 +0000 (15:19 +0200)]
SL::DB::Printer: »Dokument an Drucker schicken« zentralisiert
Die neue Funktion print_document übernimmt das Spawnen des externen
Prozesses und schickt das Dokument an den Drucker. Das Dokument kann
entweder direkt als Inhalt oder als zu sendender Dateiname übergeben
werden.
Die gelieferte Menge pro Position wird über die Recordlinks der Items
zwischen Auftrag und Lieferschein(en) ermittelt.
So werden auch gleiche Artikel auf unterschiedlichen Positionen getrennt behandelt.
Ebenso ob ein Auftrag 'delivered' ist, d.h. ob alle Mengen vollständig in Lieferscheinen erfasst sind.
Für nachträglich hinzugefügte Lieferscheine oder Lieferscheine ohne Item-Recodlinks wird ein
Fallback-Verfahren durchgeführt, das beginnend von der ersten Auftragsposition
versucht die Artikel in den Lieferscheinen zuzuordnen.
Sven Schöling [Fri, 15 Apr 2016 17:18:58 +0000 (19:18 +0200)]
Menu: Fehlerchecks beim yaml einlesen
2 häufige Fehler abfangen:
- wenn ids in einer datei doppelt vorkommen (passiert beim editieren)
- wenn YAML selber Fehler wirft gab es bisher ein HTTP 500
Moritz Bunkus [Wed, 6 Apr 2016 14:45:50 +0000 (16:45 +0200)]
SL::Controller->send_file: trueish zurückgeben
send_file meldet Fehler (z.B. »kann Datei nicht öffnen«) durch
croak(). Im Erfolgsfall sollte die Funktion aber regulär einen wahren
Wert zurückgeben, um ordentlich in eval{} benutzt werden zu können.
Individuelle Lieferadressen werden nur von shipto.trans_id zu ar.id
verlinkt, nicht aber in ar.shipto_id. Die Implementation ist analog zu
SL::DB::DeliveryOrder->new_from.
Moritz Bunkus [Wed, 6 Apr 2016 11:59:31 +0000 (13:59 +0200)]
DeliveryOrder->new_from: kein $custom_shipto-Objekt zurückgeben
Falls das Quellobjekt eine individuelle Lieferadresse besaß, wurden bei
new_from() zwei Objekte zurückgegeben: das neue Lieferscheinobjekt und
ein Clone der individuellen Lieferadresse. Diese waren nicht verknüpft.
Der Aufrufer musste daher zuerst das Lieferscheinobjekt speichern,
dessen ID beim gecloneten Lieferadressenobjekt hinterlegen und das
anschließend speichern.
Dies ist umständlich und fehlerträchtig. So hat z.B. der einzige
bisherige Nutzer dieses Interfaces,
SL::DB::Order->convert_to_delivery_order, das bereits falsch gemacht und
vergessen, beim Lieferadressenobjekt die ID des neuen
Lieferscheinobjektes einzutragen. Somit wurden Lieferadressen erzeugt,
die keinerlei Verknüpfung hatten.
Das geänderte Interface hinterlegt das Objekt für die individuelle
Lieferadresse schlicht in $new_delivery_order->custom_shipto. Dort wird
das Objekt gespeichert, wenn der Lieferschein selber gespeichert wird.
PDF::Table - fehlerhafte Headerbearbeitung ab Seite 2
ab Seite 2 werden die benötigten Weiten der Spalten um die Zahl der Headerzeilen
nach hinten verschoben. Dann kommt es zu fehlenden Zeilenumbrüchen in manchen Zellen
Da Pushen von leerem Array führt zu diesem Fehler, d.h. es wird doppelt gepushed.
Dieser Fehler war schon in der alten PDF::Table