G. Richardson [Thu, 30 Jul 2015 11:52:36 +0000 (13:52 +0200)]
Überarbeitung Speichern von Buchungsgruppen
analog zum Verhalten von Steuerzonen: beim Speichern bessere Prüfung und
gegebenenfalls Fehlermeldungen und Rollback, wenn Speichern fehlschlägt.
Verhindert, daß "unfertige" Buchungsgruppen gespeichert werden, wo die
TaxzoneCharts fehlen.
G. Richardson [Thu, 30 Jul 2015 10:21:26 +0000 (12:21 +0200)]
Steuerzonen und Buchungsgruppen bearbeiten: displayable_name für Konten
Die description-Variable in TaxzoneChart enthält nun den
displayable_name für die Konten.
Für die Anzeige der Kontennamen beim Bearbeiten von Steuerzonen und
Buchungsgruppen, wo die Konten nicht bearbeitet werden können sondern
nur angezeigt werden sollen. Kein "--" mehr.
G. Richardson [Thu, 30 Jul 2015 04:36:03 +0000 (06:36 +0200)]
Steuerzonen überarbeitet - Prüfung und Löschen
Nicht benutzte Steuerzonen können jetzt gelöscht werden, sowie deren
Kontenzuordnungen geändert werden (wie bei Buchungsgruppen). Siehe
Feature #70.
Schlägt die Speicherung neuer Steuerzonen fehl, weil z.B. die
Buchungsgruppenkonten fehlen, gibt es nun einen Rollback und eine
ordentliche Fehlermeldung, siehe Fehler #68.
Die 3.1er Erweiterung des Lieferplans ist mittlerweile in einem eigenen Bericht (Lieferwertbericht)
und muss nicht extra in den defaults konfiguriert werden.
Ferner Mandantenkonfiguration etwas besser beschrieben:
Die letzte noch erhaltene Option wirkt sich auch nur auf den Lieferwertbericht und nicht den Lieferplan aus.
Jan Büren [Tue, 28 Jul 2015 11:53:04 +0000 (13:53 +0200)]
RB als Standard Druckvorlage gesetzt - Pflichtenheft übernmommen
Da der Pfad Standard in einigen Dateien (DB-Upgrade-Skript) hart-kodiert wurde,
insbesondere um die Pflichtenheft-Druckvorlagen nachträglich in benutzdefinierte
Vorlagenverzeichnissse zu packen, ist dies entsprechend auf Pfadebene abgebildet.
S.a. #69
G. Richardson [Wed, 15 Jul 2015 14:32:05 +0000 (16:32 +0200)]
Sammelaufträge - fehlerhaftes Verhalten
Standardmäßig wird der Sammelauftrag, zusammen mit den Positionen, per
RecordLinks verlinkt. Eine Ausnahme besteht wenn der Sammelauftrag aus
genau einem Auftrag entstanden ist, in dem Fall wird angenommen, daß
"als neu speichern" gemeint ist, und es gibt keine Verlinkung.
Dies entspricht dem eigentlich gewünschten Verhalten aus Commit d40a8e2 .
G. Richardson [Wed, 1 Jul 2015 09:28:27 +0000 (11:28 +0200)]
Belegpositionen nicht mehr mit ordnumber, transdate, cusordnumber speichern
stattdessen für das Drucktemplate der Rechnung ordnumber_oe, transdate_oe und
cusordnumber_oe aus Recordlinks auslesen, und auch entsprechende
Druckvariablen für Angebot und Lieferschein bereitstellen.
Diese Informationen sollen in Zukunft nur noch aus record_links bestimmt
werden, aus Kompatibilitätsgründen werden die alten Werte aber vorerst
noch in der DB belassen, aber eben nicht mehr bei neuen Aufträgen oder
Lieferscheinen gespeichert. Dadurch werden sie auch nicht mehr im Rahmen
des Workflows weitergereicht.
Ursprünglich wurden diese Datenbankfelder wahrscheinlich für
Sammelaufträge konzipiert, d.h. sie sollten nur befüllt werden, wenn man
einen neuen Auftrag aus mehreren bestehenden Aufträgen erstellt hat.
Das passt insofern, als daß diese Felder beim initialen Speichern eines
Auftrags nicht gefüllt wurden. Allerdings wurden die Felder schon
gefüllt, wenn man einen Auftrag zum zweiten Mal gespeichert hat, es war
also nicht allein auf das Zusammenfügen von Aufträgen beschränkt.
Außerdem wurden diese Felder im Rahmen des Workflows von Auftrag zu
Lieferschein oder Auftrag zu Rechnung dann in delivery_order_items oder
invoice gefüllt.
Bei "als neu speichern" eine Auftrags wurde auch noch die alte
Auftragsnummer in die neue Position übernommen.
Weiterhin wurde nicht berücksichtigt, daß man mittlerweile auch aus
mehreren Lieferscheinen eine Rechnung erstellen kann, die auch
unterschiedliche Aufträge haben können.
Für das Rückverfolgen der ursprünglichen Belege ist generell nun
record_links eine gute Möglichkeit, die Rückverfolgung von Positionen zu
ermöglichen. Das Verhalten, daß die Variablen nur dann gefüllt sind,
wenn sie aus Sammelaufträgen stammen, ist nun nicht mehr vorgesehen (und
hat vorher auch nicht richtig funktioniert).
In der Druckvorlage gibt es für Rechnungspositionen nun auch neue
Druckvariablen, nämlich die Angebotsnummer, Angebotsdatum,
Lieferscheinnummer und Lieferscheindatum für die Belege, aus denen die
Positionen im Rahmen des Workflows ursprünglich stammten. Siehe Doku.
G. Richardson [Mon, 29 Jun 2015 09:37:22 +0000 (11:37 +0200)]
record Aliase für Items
damit man von DeliveryOrderItem, OrderItem und InvoiceItem direkt auf
das entsprechende ar/ap/do/oe Objekte verweisen kann.
Beispiel in console:
die erste Position aus der ersten Rechnung:
my $item = SL::DB::Manager::Invoice->get_first()->items->[0];
alle dorthin verknüpften Items (wenn aus Angebot, Auftrag und Lieferschein generiert)
my $linkeditems = $item->linked_records( direction => 'from', recursive => 1 );
in was für records befinden sich diese verknüpften Positionen:
foreach ( @$linkeditems ) { print $_->record->type, "\n" };
sales_quotation
sales_order
sales_delivery_order
Moritz Bunkus [Fri, 17 Jul 2015 07:29:35 +0000 (09:29 +0200)]
kivi.js: Support für jQueryUI-ToolTips wegen ToolTipster entfernt
Siehe Commit c0713b6. Damit nur ein ToolTip-System genutzt wird, und da
jQueryUI-ToolTip bisher nirgends in Templates verwendet wird, fliegt nun
der Support aus kivi.js. Grund ist auch, dass jQueryUI-ToolTip kein HTML
in ToolTips kann.
Moritz Bunkus [Fri, 17 Jul 2015 07:21:29 +0000 (09:21 +0200)]
wzToolTip durch jQuery ToolTipster ersetzt
wzToolTip hat ein uraltes, ist in der Benutzung ausgesprochen
unkomfortabel und unflexibel und muss zwingend in jedem benutzenden
Template manuell _nach_ dem <body>-Tag eingebunden werden. Dadurch kann
es z.B. nicht im Layout mit ausgegeben werden.
Moritz Bunkus [Thu, 16 Jul 2015 15:04:54 +0000 (17:04 +0200)]
SL::DB::CustomVariable->value für Typ Nummer auch wirklich Nummer zurückgeben
Da die Spalte number_value in der DB vom Typ numeric() ist, wird das von
Rose als String eingelesen. Das bedeutet, dass ->number_value z.B. der
Wert '0.00000' liefert, was im Booleschen Kontext trueish ist – nicht
das, was der Programmierer erwarten würde.
Statt dessen erwartet der Programmierer, dass !$zahl für den Wert 0 auch
wirklich zutrifft.
Daher sollte ->value für CVars vom Typ Nummer auch wirklich eine Zahl
zurückgeben, was durch ein * 1 erzwungen wird. Ausnahme: undef, was
weiterhin undef bleibt.
G. Richardson [Wed, 15 Jul 2015 10:24:29 +0000 (12:24 +0200)]
Projektliste in Detailsanzeige bei Angeboten, Aufträgen und VK-Rechnungen füllen (v2)
oe und is speichern die Projekt-Dropdowns, die im jeweiligen form_header
zusammengebaut werden, in $TMPL_VAR{ALL_PROJECTS}.
Das Projekt-Dropdown in io.pl für die Detailsanzeige (zweite
Positionszeile) greift hingegen für alle Belege auf
$form->{ALL_PROJECTS} zu, daher werden die Elemente nochmal gesondert in
$form gespeichert.
Moritz Bunkus [Fri, 3 Jul 2015 08:23:14 +0000 (10:23 +0200)]
GetModels: Disablen von Plugins auch für undef
Die Dokumentation sagt Folgendes zum Deaktivieren von Plugins:
> Configuration for plugins. If the option for any plugin is omitted,
> it defaults to enabled and is configured by default. Giving a
> falsish value as first argument will disable the plugin.
Das bisherige Verhalten war aber, dass bei Übergabe von
undef (z.B. »paginated => undef«) die Standardeinstellungen gegriffen
haben.
projects / kivitendo-erp.git / log