Jan Büren [Fri, 12 Oct 2012 15:32:20 +0000 (17:32 +0200)]
Strengere defaults für die config
Zahlung sind nicht änderbar nach dem Buchen.
Ferner die DATEV-Checks standardmässig einschalten
Kann auch gerne nochmal diskutiert werden, am Sinnvollsten wäre es die Konfiguration in die
Admin-Oberfläche zu verlagern
Ähnliche Fehler wie im Bug 2019 tauchten auch in der Detailansicht
einer Ware auf. Hier wurden EK-Preis und EK-Preis der Lieferanten
bei großen Zahlen mit Nachkommastellen nicht richtig angezeigt.
Moritz Bunkus [Wed, 10 Oct 2012 10:06:40 +0000 (12:06 +0200)]
Spaltenüberschriften mit grünem Background
Leider enthalten momentan gewisse Tabs noch <div
class="listheading">..., und die sind auf Überschriften
gestylt. Deshalb gab's Inkonsistenzen in den Tabellenlistheadings: mal
grauer Hintergrund, mal grün, wodurch weiße/schwarze Schrift oft
schwer lesbar war.
Im Workflow Auftrag-Lieferschein-Rechnung gab es Probleme mit dem
Lieferdatum. Beim Auftrag wurde bisher ein Lieferdatum verlangt,
was jetzt in Liefertermin umbenannt wurde, um echtes Lieferdatum
und Lieferfrist zu unterscheiden.
Der Liefertermin wird jetzt auch in der Ansicht vom Lieferschein
angezeigt. Das Lieferscheindatum und das Lieferdatum sind synonym.
Somit wird in der Rechnung als Lieferdatum das Datum vom Liefer-
schein angegeben.
Siehe auch Bug #1958. Dort wird allerdings noch zwischen einem
Lieferdatum und Lieferschein unterschieden, was dieser commit noch
nicht leistet.
Jan Büren [Mon, 24 Sep 2012 12:58:06 +0000 (14:58 +0200)]
DbUpgrade Templates für SKR04-3804-addition.pl kompatibel für Lx 2.7 gemacht
Hintergrund: In den Templates war keine ordentliche form definiert.
Früher wurde dann scheinbar einfach wieder standardmässig auf login.pl umgebogen, dass geht jetzt nicht mehr so.
Jan Büren [Thu, 20 Sep 2012 14:54:02 +0000 (16:54 +0200)]
Verkaufsrechnungen als Auftragsvorlage auch in geschlossenen Perioden erlauben
Hintergrund: Rechnungen können prinzipiell immer als neue Rechnungsvorlage verwendet werden, unabhängig ob sich die Rechnung in einer schon abgeschlossenen Buchungsperiode befindet oder nicht.
Entsprechendes sollte dann auch für die Funktion Verkaufsrechnung als Vorlage für Verkaufs-Auftrag gelten.
Wenn man Rechnungen (die Fremdwährungen nutzen) bezahlt hat, wurden
Gewinne/Verluste durch mögliche Kurswechsel bei Zahlungsbuchungen
nicht weiter berücksichtigt. Dadurch kam es zu Bilanzfehlern im
Buchungsjournal.
Das return bei payments_only wird jetzt erst nach den Wechselkurs-
buchungen ausgeführt.
In der Verkaufsrechnung traten noch einige Fehler auf, wenn man
ausländische Währungen angegeben hat. Wechselkurse wurden als Null
angezeigt und es gab kein Eingabefeld, wenn der Wechselkurs an einem
Datum noch nicht in der Datenbank vorhanden war. In Eingabefelder
eingegebene Werte wurden ignoriert.
In der Einkaufsrechnung traten ähnliche Fehler auf. Hier wurde nicht
einmal ein Wechselkurs angezeigt, obwohl Standardwährung und in der
Rechnung verwendete Währung nicht übereinstimmen.
In der Verkaufsrechnung traten noch einige Fehler auf, wenn man
ausländische Währungen angegeben hat. Wechselkurse wurden als Null
angezeigt und es gab kein Eingabefeld, wenn der Wechselkurs an einem
Datum noch nicht in der Datenbank vorhanden war. In Eingabefelder
eingegebene Werte wurden ignoriert.
In der Einkaufsrechnung traten ähnliche Fehler auf. Hier wurde nicht
einmal ein Wechselkurs angezeigt, obwohl Standardwährung und in der
Rechnung verwendete Währung nicht übereinstimmen.
Im Lieferplan wird jetzt noch zusätzlich zu der Gesamtliefermenge
und der schon gelieferten Menge auch noch die Differenz (also die
Menge, die noch nicht geliefert wurde) angezeigt.
Im Zahlungsverkehr-Zahlungseingang ist jetzt eine neue Filteroption
Kundennummer vorhanden. Bei Eingabe der Kundennummer wird die
Filterung für das Dropdown ausgeschaltet. Es funktioniert dann nur
noch die Filterung von Rechnungsnummer und Kundennummer.
Wenn diese wieder rein sollen, dann sollte der Debug-Level anders
gesetzt werden. Bei mir erscheinen die Ausgaben sonst immer.
($LXDebug::DEBUG1 ---> LXDebug->DEBUG1)?
Thomas Heck [Fri, 7 Sep 2012 11:46:36 +0000 (13:46 +0200)]
Lieferdatum u. Auftragsdatum beim 'als neu speichern' von Aufträgen neuberechnen
* Auftragsdatum wird aufs aktuelle Datum gesetzt
* Lieferdatum wird genau so wie beim Erstellen eines neuen Auftrags gesetzt. Das ist: Auftragsdatum (sprich aktuelles Datum in unserem Fall) + 1 Tag aufgerundet auf den nächsten Arbeitstag (Freitag -> Montag)
fixt #1959
Moritz Bunkus [Wed, 5 Sep 2012 07:18:45 +0000 (09:18 +0200)]
Sorted-Controller-Helper: Spaltentitle nicht direkt in make_sorted() übersetzen
Hintergrund ist der, dass ansonsten die Übersetzung nur einmal
passiert, nämlich dann, wenn das Modul compiliert wird. Für normales
CGI funktioniert das:
- Zuerst wird der Dispatcher geladen und ausgeführt. Der analysiert
zur Laufzeit die GET-/POST-Parameter und lädt erst dann den
erforderlichen Controller mittels "require".
- Sprich Dispatcher hat schon das für den Benutzer notwendige
$::locale-Objekt angelegt, und die Compilezeit des Controller-Moduls
liegt danach.
Für FastCGI würde das kaputt gehen:
- Zuerst wird der Dispatcher geladen und ausgeführt. Der analysiert
zur Laufzeit die GET-/POST-Parameter und lädt erst dann den
erforderlichen Controller mittels "require".
- Nach Beenden des Requests bleibt das Modul aber im Speicher.
- Beim nächsten Request auf denselben Controller wurde dieser bereits
compiliert, und die Titel wären bereits übersetzt -- in der Sprache
des Benutzers, der den Controller seit Start des FastCGI-Prozesses
das erste Mal aufgerufen hat.
In dem Verkaufsbericht gab es noch Probleme mit der Einheit in Bezug
auf den EK Preis. Dies hatte sich auch auf die Marge ausgewirkt. Beides
wird jetzt richtig berechnet.
In der Verkaufsrechnung gab es ähnliche Probleme. Hier wurde der
VK Preis nach Wechsel der Einheit umgerechnet, der EK Preis nicht.
Jetzt wird auch der EK Preis an die Einheit angepasst. Die Berechnung
war dadurch auch fehlerhaft durch unterschiedliche Einheiten
und wurde auch korrigiert.
Weiterhin wurde ein Problem mit dem Preisfaktor behoben. Wenn
ein Artikel in der Datenbank mit Preisfaktor hinterlegt war,
wurde der Preisfaktor bisher doppelt berechnet, jetzt nur
noch einmal.
projects / mfinanz.git / log