G. Richardson [Tue, 22 Oct 2013 12:00:17 +0000 (14:00 +0200)]
L.pm um for_submit erweitert und in Kundenvorlage erweitert: #2386
Code von Sven übernommen. Ohne das for_submit wurde bei abgewählten
Checkboxen nichts übertragen (auch keine 0), so daß Rose die Spalte auch
nicht aktualisiert hat. Dies wurde durch das Hinfügen von Hiddens
umgangen.
Dies betraf die Checkboxen für Lastschrift und ungültig bei Kunden und
Lieferanten.
Die Checkboxen bei Notizen / notes auf der gleichen Seite wurden nicht
angepasst, da man hier nichts abwählen kann.
Sven Schöling [Mon, 9 Sep 2013 16:10:47 +0000 (18:10 +0200)]
SellPriceInformation: Layout nicht mit generieren.
Spart 10 Requests und umgeht einen interessanten Browserbug - Javascripte die aus ajax Request html eingelesen werden, werden vom Broweser mit einer zufälligen Nummer versehen um ein 304 zu vermeiden. Das hat gerade bei schwachen Leitungen zu massiv unnötigen Requests geführt.
G. Richardson [Wed, 4 Sep 2013 14:41:50 +0000 (16:41 +0200)]
Neue Verkaufsberichtvariante mit Umsatz-Sortierung
Es gibt einen neuen Menüeintrag "Verkaufsbericht Top", wo man nach den
gleichen Kategorien wie beim normalen Verkaufsbericht gruppieren kann,
aber wo man das Ergebnis nach Umsatz, Marge, Menge oder Gewicht
vorsortieren kann, was beim Standardverkaufsbericht nicht möglich war.
Dadurch kann man sich z.B. eine nach Umsatz sortierte Liste der Kunden
für einen Zeitraum anzeigen lassen. Es wird weiterhin nur auf Daten aus
"invoice" zurückgegriffen.
Es wird bei dieser Variante auf den gleichen Code zurückgegriffen,
allerdings wurde aus Gründen der Übersicht ein neuer Menüpunkt
eingeführt, in Zukunft könnte man dies vielleicht mit eigenen Reitern
besser machen.
Moritz Bunkus [Thu, 29 Aug 2013 11:19:52 +0000 (13:19 +0200)]
Einträge in employee aus User->login heraus aktualisieren
Vor der Mandanteneinführung war User->login bereits hierfür
verantwortlich. Dann wurde diese Funktionalität in den
Login-Controller verschoben. Allerdings kehrt die Ausführung in exakt
einem Fall nicht zum Logincontroller zurück: wenn noch
Datenbankupgrades eingespielt werden müssen.
In dem Fall werden die Updates eingespielt, dem User wird die
"Weiter"-Seite angezeigt, und von hier aus geht es direkt zum
company_logo.
User->login weiß daher als einzige Instanz, wann alle DB-Upgrades
User->installiert sind, und damit, wann RDBO-Instanzen sicher genutzt
User->werden können.
Daher die Funktionalität in die Employee-Manager-Klasse verschoben und
das Triggern der Funktion aus dem Login-Controller wieder zurück nach
User->login verschoben.
Moritz Bunkus [Thu, 29 Aug 2013 11:19:52 +0000 (13:19 +0200)]
Einträge in employee aus User->login heraus aktualisieren
Vor der Mandanteneinführung war User->login bereits hierfür
verantwortlich. Dann wurde diese Funktionalität in den
Login-Controller verschoben. Allerdings kehrt die Ausführung in exakt
einem Fall nicht zum Logincontroller zurück: wenn noch
Datenbankupgrades eingespielt werden müssen.
In dem Fall werden die Updates eingespielt, dem User wird die
"Weiter"-Seite angezeigt, und von hier aus geht es direkt zum
company_logo.
User->login weiß daher als einzige Instanz, wann alle DB-Upgrades
User->installiert sind, und damit, wann RDBO-Instanzen sicher genutzt
User->werden können.
Daher die Funktionalität in die Employee-Manager-Klasse verschoben und
das Triggern der Funktion aus dem Login-Controller wieder zurück nach
User->login verschoben.
Moritz Bunkus [Mon, 26 Aug 2013 13:57:39 +0000 (15:57 +0200)]
AM.pm::get_warehouse: keinen teuren Cross Join
Ein Cross Join wird nicht benötigt, weil nur die Existenz einer Zeile
in mind. einer der beiden relevanten Tabellen interessant ist. Das
auch entsprechend coden.
Moritz Bunkus [Tue, 6 Aug 2013 09:57:45 +0000 (11:57 +0200)]
Wiederkehrende Rechnungen: nicht '_email' in Vorlagendateinamen hinzufügenn
In Form::prepare_for_printing wurde '_email' immer an den Dateinamen
angehängt, sofern es ein solches Template gibt (also
z.B. 'invoice_email.tex') -- egal, wohin letztlich ausgegeben werden
soll (via 'media'). Nun wird das nur noch gemacht, wenn 'media' == 'email' ist.
Man konnte sich bisher, auch ohne das Recht zu besitzen, eine Liste
von Kreditoren-/Debitorenbelegen erstellen, indem man folgenden Link
aufgerufen hat:
ar.pl?action=search (dann auf weiter)
oder direkt:
ar.pl?action=ar_transactions
Die Ursache hierfür war, dass das Recht "Dialogbuchen, Debitoren-
rechnungen, Kreditorenrechnungen" ausreichte, um die oben ge-
nannten actions aufzurufen.
G. Richardson [Mon, 5 Aug 2013 08:29:52 +0000 (10:29 +0200)]
Neue Rechte für Anzeige der Debitoren- und Kreditorenbuchungen
Damit kann man in den Berichten für Einkaufs- und Verkaufsrechnungen die
Debitoren- und Kreditorenbuchungen herausfiltern, so daß z.B. die
Einkäufer nicht mehr Kreditorenbuchungen aus dem Fibu-Bereich sehen
können.
projects / kivitendo-erp.git / log