In For.pm wird bei der Druckvorbereitung Customer-/Vendorname gesetzt.
Damit z.B. bei Massendruck oder neuen Controllern diese Variable auch
zur Verfügung stehen werden sie , falls die Objekte vorhanden in die Form geladen
G. Richardson [Tue, 7 Jun 2016 14:22:05 +0000 (16:22 +0200)]
BUG-Fix: Kreditorenbuchungen: Währung wird nicht übernommen
Es werden IMMER die Währungeinstellungen vom Lieferanten genommen.
Die Variable currency wird beim Holen der Lieferanten-Daten überschrieben.
Den Variablen-Wert vor dem Holen der Stammdaten sichern und danach
zurückschreiben.
Sven Schöling [Fri, 17 Jun 2016 17:10:17 +0000 (19:10 +0200)]
lx-office-erp.css: proportionale font-sizes
Firefox 47 ignoriert unter unity7 font-size in select komplett,
ausserdem haben wir seit ewigkeiten das problem dass td { font-size: 8pt
} alle spacings kaputtmacht. Das hier entfernt das experimentell.
Super Codierung und unsichtbar für alle anderen.
Punktevergabe wird jetzt offen angezeigt und mittels ToolTip
kann hier jeder sehen warum welche Zuordnungen passieren und selber
tüfteln (a la spamassassin rule set).
Falls in dem Datenmodell Drafts.pm, Dialogbuchungen vorhanden sind,
stürzt die Filterfunktion einfach ohne Rückmeldung ab und macht nichts weiter.
Sinnvollerweise nur Ergebnisse filtern, die auch eine vendor_id im Draft haben.
Bernd Bleßmann [Wed, 15 Jun 2016 14:31:41 +0000 (16:31 +0200)]
FlattenToForm: Information, ob das item ein Erzeugnis ist, berücksichtigen.
Damit klappt das Drucken mit Stücklisten-Information im neuen
Auftrags-Controller, beim Massenrechnungsdruck und beim autom. Drucken
wiederkehrender Rechnungen.
Jan Büren [Mon, 13 Jun 2016 14:39:51 +0000 (16:39 +0200)]
BankTransactions GUI Hotfix Verbesserung
Wenn man über die Liste aller Rechnung jetzt auch den
zu verbuchenden Betrag als Hilfestellung angezeigt bekommt, muss dieser
entsprechend konsequent auch bei dem einfachen AJAX-Anklicken
angezeigt werden.
Jan Büren [Mon, 13 Jun 2016 14:37:55 +0000 (16:37 +0200)]
Bankauszug verbuchen invoice_amount vor pay-invoice
Die Reihenfolge der Verarbeitung des Bankausszugs ist jetzt
wichtig. Vorher wurde einfach der Betrag der gesamten Rechnung
abgezogen, jetzt ist es nur noch der offene Betrag, der nach
der Zahlungsverbuchung dann auf 0 ist. Deshalb vorher ...
Wie in SL/IS.pm ( c0ed7d2fa ) werden hier die notes doppelt zurückgegeben.
fixup durch löschen von notes vor kopieren
Auch hier kann es passieren dass die notes von Dokumenten z.B. Rechnung durch die
notes des Lieferanten (Kunden) in den Forms-Variablen überschrieben werden,
dann beim Drucken der falsche Text in der (LateX) Rechnung landet.
Sven Schöling [Mon, 9 May 2016 08:06:23 +0000 (10:06 +0200)]
Partpicker styling
- Lupe jetzt inline
- Lupe in svg, kann also mitskalieren
- Inputfeld ist jetzt Model padding-box, size Angaben propagieren besser
auf die umliegenden Elemente
- getestet in lx-office-erp und kivitendo css
Moritz Bunkus [Wed, 8 Jun 2016 14:05:09 +0000 (16:05 +0200)]
generic_translations: DB-Upgrade in Perl geschrieben wg. Constraint-Namen
In alten PostgreSQL-Versionen hießen Foreign-Key-Constraints oft noch so
was wie »$1«. Da sich das Upgrade-Script also bzgl. des Namens nicht
sicher sein kann, gibt's momentan nur die Möglichkeit, einmal alle
Foreign-Keys zu einer Tabelle wegzuwerfen und diese neu anzulegen.
Dafür wiederum haben wir Support-Funktionen in SL::DBUpgrade2::Base, die
wie nutzen können. Also Umstellung des Scripts auf Perl.
Moritz Bunkus [Wed, 8 Jun 2016 12:29:08 +0000 (14:29 +0200)]
FlattenToForm: Zahlungsbedingungen des Kunden/Lieferanten nicht kopieren
Es haben die ZB des Beleges zu gelten, nicht die des
Kunden/Lieferanten. Die Variable »payment_terms« wird zwar später wieder
anhand von »payment_id« überschrieben (in »OE::order_details« und dann
»Form::set_payment_options«), aber nur dann, wenn im Beleg auch wirklich
Zahlungsbedingungen ausgewählt sind.
Sind keine ausgewählt, so würde das »payment_terms« von den Kunden-/
Lieferantenstammdaten gesetzt bleiben; das wäre schlicht inkorrekt.
Moritz Bunkus [Tue, 7 Jun 2016 11:30:46 +0000 (13:30 +0200)]
Zahlungsbedingungen: Unterscheidung zwischen Angeboten/Aufträgen und Rechnungen
Dies führt ein neues Attribut »payment_terms.description_long_invoice«
und dazugehörige Übersetzungen in »generic_translation« ein.
Die Druckvariable »payment_terms« wird nun in Abhängigkeit vom
auszudruckenden Beleg gesetzt:
1. Für Verkaufsrechnungen wird zuerst eine Übersetzung von
»description_long_invoice« für die ausgewählte Sprache gesucht. Falls
die leer ist oder keine Sprache ausgewählt, so wird die nicht
übersetzte »description_long_invoice« genommen. Ist auch die leer, so
erfolgt ein Fallback auf 2.
2. Für alle anderen Belege oder falls bei 1. nichts heraus gekommen ist,
wird wie vor dieser Änderung eine Übersetzung von »description_long«
für die ausgewählte Sprache gesucht. Falls die leer ist oder keine
Sprache ausgewählt, so wird die nicht übersetzte »description_long«
genommen.
Waldemar Toews [Thu, 28 May 2015 15:28:14 +0000 (17:28 +0200)]
BUG-Fix: Beim Stornieren einer Rechnungen wird der bezahlte Betrag verdoppelt.
Storniert man eine als bezahlt markierte Rechnung,
so wird der bezahlte Betrag ("paid") verdoppelt.
Im SQL wird, fälschlicherweise, amount zu paid dazu addiert. Soll aber nur zugewiesen werden.
Bücherkontrolle in Zahlungseingängen und Zahlungsausgängen fehlerhaft
- Erweiterung der Header und Footer Funktionen um das Buchungsdatum anhand der Bücherkontrolle zu prüfen
- Fällt Buchungsdatum ausserhalb des zulässigen Zeitraum der Bücherkontrolle so werden die betreffenden Einträge bei Zahlungsein-/ausgang deaktiviert
- Einbinden der Prüfung des maximal zukünftigen Buchungsdatums von Zahlungen ausgehend vom heutigen Datum
- Erweiterung der Prüfung bei Neueingabe von Zahlungsein-/ausgängen:
- Es werden nur noch die editierbaren Einträge geprüft
- Einträge ohne Zahlungen werden nicht geprüft und auch nicht gebucht