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.
projects / kivitendo-erp.git / log