Generell können generierte Dokumente nur alle den gleichen Namen haben.
Beim Umbennen wird ggf. auch die Version mitgeschickt. Diese muss aus de rID herausgefiltert werden
Angebote|Preisanfrage werden immer geschlossen, falls
es ein Auftrag oder Lieferantenauftrag daraus generiert wird.
Die ursprüngliche Funktion in OE.pm kann als Quelle noch
mehrere Belege haben, dies ist im aktuellen Workflow nur eine
1:1 Beziehungen. TODO: Testfall.
Auftrags-Controller: Beleg vor drucken und E-mailen speichern.
Das nur bei "speichern" auch gespeichert wird, ist vielleicht konsequent, aber
im Alltag eher unpraktisch. Viele Anwender hatten damit ein Problem, dass die
verschickte oder gedruckte Version des Belegs anders ist, als die gespeicherte,
weil oft nicht daran gedacht wurde, nach der letzten Änderung und nach dem
Drucken/versenden nochmals zu speichern.
Deshalb wird jetzt beim Drucken und E-Mailen immer gespeichert.
Auftrags-Controller: Wiederkehrende Rechnungen. Konfig nicht mit neuer id …
… speichern, wenn diese schon vorhanden ist, sondern die vorhandene mit
den neuen Attributen versehen.
Wenn sich die id ändert, lässt sich nicht mehr feststellen, ob für diese Konfig
bzw. diesen Auftrag schon wiederkehrende Rechnungen erzeugt wurden und es werden
evtl. alle nochmal erzeugt.
Bevor es den Customer-Picker gab, bestand die Möglichkeit
über einen Klick auf ein Fragezeichen den Kunden/Lieferanten
rauszusuchen. Die Funktion war noch ein bisschen erweitert,
da der Ansprechpartner noch separat angezeigt wurde (toter Projektcode im
Standard ?), die zusätzlich Auswahl-Funktion hatte keine weitere
Auswirkung. Die aktuelle einzige Stelle, wo der Code noch geladen
wurde ist im Letter-Controller. Das Deaktivieren des js-Codes
zeigt, wie erwartet, keine Unterschiede im Verhalten =>
Alles mittlerweile komplett überflüssig, inkl. edit_part.js (?) in Letter.pm
Werner Hahn [Tue, 25 Sep 2018 10:14:05 +0000 (12:14 +0200)]
TopQuickSearch für den Benutzer konfigurierbar gemacht.
Über UserPreferences, allerdings wird die Mandantenkonfiguration (quick_search_modules) nicht
berücksichtigt. Der Benutzer hat alle Schnellsuchen zur Verfügung.
Das L.multiselect2side macht Probleme deswegen auskommeniert. Wenn aktiv wird das
Emailsignaturfeld m Tab "Persönliche Einstellungen" doppelt angezeigt,
beide Felder und Links (Signatur bearbeiten und volle Signatur prüfen) sind sichtbar.
Auftrags-Controller: Verkäufer aus Benutzer vorbelegen, wenn nicht beim Kunden
Beim Anlegen eines Angebots/Auftrags wird der Verkäufer mit dem Verkäufer aus
den Kundenstamdaten gefüllt. Ist hier keiner gestezt, so wird der Verkäufer mit
dem aktuellen Benutzer vorbelegt.
Jan Büren [Mon, 10 Sep 2018 19:28:52 +0000 (21:28 +0200)]
Kontoauszug verbuchen: Skonto-Option auch über Rechnung suchen anbieten
Historisch bedingt kann das automatische Skonto bei Zahlungen nur
benutzt werden, wenn die Bankbewegung in der Spalte Vorschläge
per ajax Klick hin- oder herbewegt wird. Alle Rechnungen die auch
oder zusätzlich oder gar besser passen, aber über die Funktion
Rechnung suchen gewählt werden, wurden bisher nicht berücksichtigt.
Dieser simpler Aufruf in TT bereinigt die Inkosistenz (s.a. POD
zum Commit vorher).
Falls es kein Skonto-Datum gibt, d.h. der Beleg hat überhaupt keine
Skonto-Option, dann auch dem Benutzer erst gar nicht die Auswahl
anbieten.
Prinzipiell die Auswahl anzeigen ist sinnvoll, damit das Verhalten
durchgängig ist und dem Anwender visuell klarer ist, was gebucht werden wird.
Jan Büren [Mon, 10 Sep 2018 19:23:04 +0000 (21:23 +0200)]
SEPA-Export: Überweisungen via SEPA - Feature Überweisungsdatum vorbelegen
Muss aktiv in der Mandantenkonfiguration (Feature -> SEPA) aktiviert werden.
Entweder wird ein vorhandenes Skontoziel als Ausführungsdatum an
die Bank/Export übergeben oder die Netto-Fälligkeit.
Skonto geht vor Netto. Bei beiden Verfahren wird ein Puffer
in Tagen (Standard 0) abgezogen.
Jan Büren [Mon, 3 Sep 2018 13:34:15 +0000 (15:34 +0200)]
Kreditorenbuchungen: Warnung bei vorhandener Rechnungsnummer für diesen Kreditor
Vorbedingung:
AP.js erweitert, sodass der Prüfcode entsprechende Inputs von IR oder AP prüft.
Erweiterungen:
Einkaufsrechnung (IR) mit derselben Prüfung wie Kreditorenbeleg beim Speichern versehen
Prüffunktion auf schon vorhandene Belegnummer zu diesem Kreditor bei
Einkaufs- oder Kreditorenbeleg implementiert.
Generischen Controller für JS-Prüfung (SalesPurchase.pm) mit einer
Funktion hinzugefügt, sowie entsprechend Changelog und locales.
Bernd Bleßmann [Sat, 25 Aug 2018 14:12:58 +0000 (16:12 +0200)]
CustomerVendor-Picker: 'type' nicht als html-Attribut setzen
Die Parameter des Picker-Aufrufs werden an das Input-Tag weitergeben und so
wurde das type-Attribut mit dem Typ (customer/vendor) des Pickers
überschrieben.
Bernd Bleßmann [Fri, 3 Aug 2018 13:08:31 +0000 (15:08 +0200)]
Auftrags-Controller: nur neue Maske/Links hierhin, wenn experimentelle Features an
- in Menüs Verkauf/Einkauf: Links zu Angebot u. Auftrag)
- in Berichten Angebot/Auftrag und Lieferscheine: Links zu Angeboten und Auträgen
- im Presenter (und damit in der Liste der verknüpfte Belege)
- Todo-Liste
Bernd Bleßmann [Fri, 10 Aug 2018 11:01:57 +0000 (13:01 +0200)]
Auftrags-Controller: kein Unterstrich vor privaten Funktionen
In einem Controller wird den von aussen zugänglichen Funktionen "action_"
vorangestellt, deshalb ist zur Unterscheidung das Voranstellen eines
Unterstrichs unnötig und verschlechtert die Lesbarkeit.
Auftrags-Controller: Null-Werte in Eingabezeile von leer unterscheiden.
Die Idee war, bei einem leeren Wert in der Eingabezeile ein default zu
nehmen (Menge => 1, Preis => "bester" Preis, Rabatt => "bester" Rabatt).
Bisher wurde aber nicht zwischen leer und 0 bzw. 0,00 unterschieden, so dass
dann auch die default-Werte genommen wurden.
Das wird jetzt unterschieden.
projects / kivitendo-erp.git / log