Holger Lindemann [Sat, 27 Nov 2010 01:22:45 +0000 (02:22 +0100)]
Benutzer und Password vom Schalter Vertreter unabhängig sichtbar.
Es waren diverse Anfragen für die Pfleger dieser Daten, z.B. für Kundenportale,
und auch die zentrale Verwaltung von Zugangsdaten bei Lieferanten macht Sinn.
Sven Schöling [Fri, 26 Nov 2010 13:09:58 +0000 (14:09 +0100)]
users/partshead.csv aus dem Repo entfernt.
Die Datei sollte nur vom User angelegt werden, und verhindert Artikel Importe
solange sie so im Repo drin ist.
Im Gegensatz zu meinem Gespräch mit Holger habe ich sie nicht in eine .default
oder ähnlich umbenannt, weil es keinerlei Dokumentation dafür gegeben hätte.
Ich habe in der Hilfe wenigstens einen Satz eingefügt der erwähnt, dass es die
Möglichkeit gibt, aber auch nicht mehr.
Wenn jemand die Doku komplett machen möchte, dann kann da auch wieder eine
Beispieldatei mit dazugepackt werden.
G. Richardson [Wed, 14 Apr 2010 08:24:45 +0000 (10:24 +0200)]
Neuer Bericht "Verkaufsbericht" unter Verkauf->Berichte
Vor allem interessant für Wiederverkäufer, die ihre Margen anzeigen wollen und EK-Preis pflegen.
Neue Dateien bin/mozilla/vk.pl und SL/VK.pm, sowie template unter templates/webpages/vk
* Auflistung aller verkauften Artikel mit VK-Preis, EK-Preis und Margen
* Sortiert nach Kunden und Artikeln oder Artikeln und Kunden
* Preisfaktor (Preis pro 100) bei Gesamtbetrag berücksichtigt
* Anzahl der Dezimalstellen einstellbar (für bestimmte Spalten)
* Einheit als Anzeigeoption (aber keine Umrechnung, z.B. kg->g)
Stornos und stornierte Rechnung aus VK-Bericht herausgefiltert
1) für Auswertungen gar nicht nötig
2) bei Storno wird in invoice marge_total und marge_percent nicht gesetzt
deshalb dynamisch für VK-Bericht berechnet, auch wenn es jetzt nicht mehr angezeigt wird
Macht es überhaupt Sinn bei Stornos dann invoice mit Margenwerten zu befüllen?
Nicht berücksichtigt:
* Einkauf
Noch Fehlerhaft:
* Abwechselndes grau/beige in Ansicht unregelmäßig, generelle Formatierung der Ausgabe (z.T. noch farbig)
Die ganze Funktion ist leicht Mist und reagiert allergisch darauf, wenn
Variablennamen mit einem der Stichwörter "if", "foreach" oder "end"
anfangen. Leider enthält sie anscheinend weiterhin den Bug, dass nicht
auf "foreach" sondern auf "for" getestet wird, und das ist nun mal bei
"FORmat_info" am Anfang enthalten.
Jan Büren [Thu, 18 Nov 2010 09:13:58 +0000 (10:13 +0100)]
Sobald ein alter Zahlungseingang in einem abgeschlossen Zeitraum fällt und man
einen neuen buchen möchte erhält man, dass die Buchung nicht möglich ist. Entsprechend in Bug 1502 dokumentiert und weiterführende Ideen kommentiert
Joachim Zach [Wed, 3 Nov 2010 11:03:11 +0000 (12:03 +0100)]
Wechselkurs wird falsch ausgelesen
Es hat sich herausgestellt, dass der Fehler nicht in der Formatierung lag. Das
Procedere ist wie folgt: Bei post_invoice wird geprüft, ob ein
Wechselkurseintrag für das fragliche Datum existiert:
Ja -> diese Zahl wird genommen.
Nein -> $form->{exchangerate} wird als lokalisierter Eingabestring
interpretiert und in eine Zahl konvertiert.
Fehlerhaft war die Abfrage: Es wurde $form->{transdate} statt $form->{invdate}
genommen. $form->{transdate} wird vom Aufrufer (in is.pl) aber vor dem Aufruf
nicht gesetzt, weshalb die Abfrage immer den "Nein"-Fall produzierte.
Sven Donath [Mon, 1 Nov 2010 09:37:14 +0000 (10:37 +0100)]
Teil 2.1 von: Usability und Lokalisierung, Administration, Gruppen
Einen "Zurück"-Button mit absoluter Rücksprung Adresse versehen statt in der Historie
einen Schritt zurück zu gehen.
Auf Gruppenrechte-Seite die Buttons "Zurück" und "Speichern" vertauscht.
Delete-Confirm-Message so umgebaut, dass der Gruppenname am Anfang der Frage steht
und zusätzlich in der Überschrift.
Fehlermeldungen durch generic/error.html so verändert, dass die Fehlerursache
mit in der CSS-class="message_error" steht. Der "Zurück"-Button befindet sich darunter.
Es gibt Fälle, wo der "Zurück"-Button keine Funktion hat. Mir ist es bisher im Pop-Up "Details"
für Kunden und Lieferanten z.B. in der Rechnungsmaske aufgefallen. In Pop-Up-Fehlermeldungen
sollte der "Zurück"-Button ein "Schließen"- oder "OK"-Button werden.
Das werde ich mit einer Anpassung der Bedingung IF SHOW_BACK_BUTTON realisieren.
Sven Schöling [Fri, 22 Oct 2010 12:14:45 +0000 (14:14 +0200)]
multibox part 2.
Jetzt komplett PROCESS fähig, die einzelnen Variablen werden
zwischengespeichert unter einem Pseudonamespace, und garantiert überschrieben
beim Folgeaufruf.
Sven Schöling [Thu, 21 Oct 2010 12:48:39 +0000 (14:48 +0200)]
Multibox: Keine Variablen in den rows speichern
2 Gründe:
1. Die rows können Objekte sein, und sobald die entweder nicht auf Hashref
basieren, oder per AUTOLOAD ihre methoden sauber prüfen gibt das Chaos.
2. Wenn keine Daten da reingespeichert werden, bruachen die multiboxes nicht
mit INCLUDE aufgerufen werden, sondern können mit PROCESS den stack clone
umgehen.
Sven Schöling [Thu, 21 Oct 2010 09:33:20 +0000 (11:33 +0200)]
Attribute nicht doppelt anlegen
setup führt ein frühes initialize durch, und wenn es danach nochmal manuell
passiert wurden die auto_attr_helper nochmla angelegt, was zu redefines geführt
hat. Das hier behebt das.
Sven Donath [Thu, 21 Oct 2010 00:24:33 +0000 (02:24 +0200)]
Teil 2 von: Usability und Lokalisierung, Administrations-Interface
* Admin User-Liste Spalten geändert
- Spalte "Driver" ausgeblendet, in list_users.html die Spalte Driver / Pg
auskommentiert. Ist die nicht unnütz?
- Reihenfolge der Spalten geändert
- Neue Spalten hinzugefügt: Vorlagen, Drucken, Sprache
- Den Bedienhinweis hellgelb hinterlegt
* Gruppen-Administration aufgeräumt und etwas logischer gemacht.
* Zurück-Knöpfe repariert und optimiert. (sind möglichst an der gleichen Stelle)
* Strings "eingedeutscht", <br>-Tags entfernt
* Reihenfolge der Seitensegmente logischer gemacht
* An verschiedenen Stellen table-tr-td-Tags entfernt
* die inline-Styles kommen später ins CSS
* Das Nachrichten-System ist etwas verbessert. Messages wurden von Users übersehen.
Meldungen werden per CSS farblich hervorgehoben. Vier CSS-Klassen,
message_ok, message_error, message_hint, message_error_login
Ok = grün, Fehler = rot, Hinweis = gelb, Fehler beim Login ist altes CSS, neuer Name
Der CSS-Code für die Messages ist in allen drei CSSs (noch) identisch.
Im nächsten Teil geht es mit $form->{saved_message} weiter, damit diese Nachrichten
ebenfalls berücksichtigt werden.
Sven Donath [Thu, 14 Oct 2010 14:16:13 +0000 (16:16 +0200)]
Input, Textarea und Select = Yellow überarbeitet
Holgers gute Idee estwas verfeinert.
Dabei sind die :focus Klassen hinter die As gewandert und eine
Menge Leerzeichen und Tabs "verloren gegangen".
Durch das CSS sind die Login-Screen Inputs auch yellow.
Auf Android scheint das nicht zu funktionieren.
Sven Donath [Wed, 13 Oct 2010 21:05:33 +0000 (23:05 +0200)]
Vorgabe für den Datenbankbenutzer auf 'lxoffice' gesetzt, da
das bei der .deb-Installation bzw. der Nutzung der scripts/inst_postgres.sh
der Standard ist. (Für den Adminbereich hatte ich das in Commit 4b937 gemacht.)
In einer späteren Änderung soll der dbuser aus der config/authentication.pl
gelesen werden.
Das wäre der Hardcodierung vorzuziehen. Aktuell bekomme ich $cfg->{user}
aus der Auth.pm (sub _read_auth_config) nicht in die admin.pl. :-|
Vielleicht ist das auch der falsche Weg.
Sven Donath [Wed, 13 Oct 2010 20:08:18 +0000 (22:08 +0200)]
Vorgaben bei Neuinstallation auf sinnvollere Werte geändert.
Das sind:
* "Stck" statt "mg" an erste Stelle. Alle anderen von groß nach klein sortiert
* "EUR:USD" als Vorgabe für Währungen.
* "Standard 16%/19%" Buchungsgruppe an erste Stelle gesetzt
Alle Änderungen sollen den Start nach der Neuinstallation vereinfachen und
bei Updates nichts verändern.
Jan Büren [Wed, 13 Oct 2010 11:05:35 +0000 (13:05 +0200)]
Warum nicht wieder das Buchungsjournal für einzelne Konten aktivieren? Ist doch alles seit 2005 im Backend dafür vorhanden ... FiBu -> Bericht um Suchfeld Kontonummer erweitert
Jan Büren [Wed, 13 Oct 2010 10:19:45 +0000 (12:19 +0200)]
Der Filter für Kontennummer im Buchungsjournal sollte seit 2005 nicht MEHR funktionieren. Buchungsjournal könnte man auch noch tiefer überarbeiten. Erstmal nur Kommentar
Jan Büren [Tue, 12 Oct 2010 14:01:12 +0000 (16:01 +0200)]
Currencies nochmal besser kommentiert und fehlerhaften Array wieder rausgenommen. Die callback-Funktion um currency erweitert (@sven donath: muh=kuh hatte ich mal extra dringelassen ...). Ferner ist die Antwort zu department klar: Abteilungen werden bei Rechnungen oder FiBu-Buchungen angegeben und sollten nicht per Zahlungsein- oder -ausgang geändert werden. Entsprechend aus cp.pl und CP.pm entfernt.
Jan Büren [Mon, 11 Oct 2010 10:41:58 +0000 (12:41 +0200)]
Neu-Aufbau Lx-Office Bildschirm
Nach einer erfolgreichen Buchung erscheint die Meldung: 'Zahlung gebucht.' und
die Startseite wird angezeigt. Wünschenwert wäre es, wenn man in
Zahlungsverkehr bleiben würde, optimalerweise mit vorbelegten Feldern. Letzter Commit für Bugfix 1484. Bildschirm wird neu aufgebaut und zumindestens das Konto wird als Vorbelegung übernommen
Jan Büren [Fri, 8 Oct 2010 11:36:12 +0000 (13:36 +0200)]
Das Ankreuzfeld 'alle' hat keine Funktion wenn man einen Auswahlliste (multibox) an Lieferanten hat
Es wird trotzdem nach der Auswahlliste gefiltert und die Option 'alle' wird
ignoriert auch wenn man auf Erneuern klickt.
2.)
Das Eingabefeld 'Betrag' im oberen Teil der Maske hat in Lx-Office meiner
Meinung nach keinen Sinn mehr, da nur noch über die Auswahl der offenen
Kreditorenposten ein Zahlungsausgang veranlasst wird. Entsprechend als Info-Textfeld angelegt. Teilfix für Bug 1484
Jan Büren [Fri, 8 Oct 2010 11:04:22 +0000 (13:04 +0200)]
Zahlungsein- und ausgänge. Die Prüfung, ob negative oder leere Werte eingetragen wurden vom CP.pm auf cp.pl verlagert. Genauere Fehlermeldung, falls kein Eintrag gewählt wurde. Die Überprüfung auf ->{amount} rausgenommen, sodass man ohne Erneuern direkt nach Auswahl der Überweisung buchen kann. Teilfix für Bug: 1484
Moritz Bunkus [Thu, 7 Oct 2010 10:24:44 +0000 (12:24 +0200)]
Nicht versuchen, Strings als Hashes zu benutzen
Wenn man aus einen Beleg heraus einen neuen Artikel anlegt, so ist
$form->{CVAR_CONFIGS} mit einem Hash gefüllt. Alle $form-Variablen
werden dann in Hiddens mitgeschliffen, aber halt nicht richtig
gedumpt. Beim nächsten Aufruf von _update_custom_variables steht
deshalb in $form->{CVAR_CONFIGS} ein String 'HASH(0x987387123)', der
natürlich kein Hash ist.
Sven Donath [Wed, 6 Oct 2010 21:50:46 +0000 (23:50 +0200)]
Einheit-Vorgabe gefixt
Für neue(s/r) Angebot, Auftrag, Rechnung etc. war die Vorgabe in der neuen Position
immer "kg". Nun ist es die Einheit, die unter System ganz oben steht.
Sven Donath [Mon, 4 Oct 2010 19:24:02 +0000 (21:24 +0200)]
Sicherheitsproblem! Datei xtcom/info.php gelöscht
Wird offenbar von keinem anderen Script benötigt.
Stellt aber ein Sicherheitsproblem dar, da man durch
Aufruf von <lx-office-server>/lx-office-erp/xtcom/info.php Informationen
über den Kernel, Webserverpfade und einiges mehr abfragen konnte.