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
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.
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