Moritz Bunkus [Mon, 27 Dec 2010 12:12:35 +0000 (13:12 +0100)]
Vor dem Ausführen von (pdf)latex das HOME auf das users-Verzeichnis setzen
Es gibt Situationen, in denen (pdf)latex Fontdateien für bestimmte
Schriftgrößen on the fly erzeugen muss. Diese werden in ~/.texmf-var
gespeichert. Deshalb muss das Verzeichnis, das (pdf)latex für HOME
hält, vom Webserver schreibbar sein.
Verhält sich analog zur Situation mit Umwandlung von
OpenDocument-Vorlagen nach PDF; da muss OpenOffice nach
~/.openoffice.org schreiben.
Sven Schöling [Mon, 27 Dec 2010 11:37:06 +0000 (12:37 +0100)]
Lagerbewegungen auch für Dienstleistungen friegeben.
Fix für Bug 1383.
Da sich Lagerbewegungen sowieso nicht komplett aus den Dienstleistungen
raushalten ließen, und es überzeugende Argumente dafür gibt Dienstleistungen
auch einlagern zu können, entfernt dieser Patch die Beschränkung, dass nur Waren
eingelagert werden dürfen.
Jan Büren [Sat, 18 Dec 2010 13:13:07 +0000 (14:13 +0100)]
Standard-Auswahl für Umlaufvermögenskonto (Bank) mandantenweit setzen. Ferner yearend aus AM.pm entfernt und schliessende </options> für selectAP_paid Array hinzugefügt
Jan Büren [Fri, 10 Dec 2010 10:54:02 +0000 (11:54 +0100)]
Zahlungsverkehr: Bei der Suche nach offenen Rechnungen auch eine Suche nach Rechnungsnummer zulassen. HINWEIS: Es wird nur der erste Treffer (falls vorhanden) angezeigt
G. Richardson [Thu, 9 Dec 2010 18:12:36 +0000 (19:12 +0100)]
cogs-Bug behoben
price_factor wurde bei Warenbestandsbuchung nicht berücksichtigt. Wurde die
Ware z.B. mit "pro 100" eingekauft war die Bestandsbuchung um das 100fache zu
groß.
Ist das basefactor noch nötig?
Sven Donath [Wed, 8 Dec 2010 15:04:16 +0000 (16:04 +0100)]
Übersetzungen in Sprache de_DE eingepflegt
Für die Module:
* SEPA Lastschrift
* Verkaufsbericht
"Überschriften" sind "headings", nicht "headers".
Eigentlich müssten templates/webpages/vk/search_invoice.html und bin/mozilla/vk.pl
dahingehend überarbeitet werden.
Bitte interne Variablen und Bezeichner möglichst in englischer Sprache verwenden.
(Kann es sein, dass der "Überschriften"-Hanken in templates/webpages/vk/search_invoice.html
nicht funktioniert?)
Weitere kleinere Reparaturen durchgeführt.
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.