Jan Büren [Thu, 2 Oct 2014 06:22:37 +0000 (08:22 +0200)]
Angebotsgüligkeitsintervall Caveat
Svens Überlegung das Intervall vor der Berechnung zu nehmen, hatte ich auch. Aber dann würde ich eher
die gesamte Routine umschreiben und die Berechnung nicht über einen SQL-Befehl machen, sondern mit Hilfe
von SL/Locale.pm. Entsprechend nochmal den Hinweis in der Mandantenkonfiguration genauer gemacht.
Jan Büren [Wed, 1 Oct 2014 09:06:57 +0000 (11:06 +0200)]
Erinnerung für Transport- oder Versandkostenartikel bei Angebot / Auftrag implementiert
Erweiterung: Mandantenkonfiguration um einen Standardartikel der auf Vorhandensein
überprüft wird (oe). Falls nicht wird eine entsprechende Warnung ausgegeben.
Verbesserungsmöglichkei 1: Artikelnummer per partpicker auswählen
Verbesserungsmöglichkei 2: Erinnerung anolog zu Vorgangsbezeichnung vergeben implementieren
Moritz Bunkus [Tue, 30 Sep 2014 15:46:31 +0000 (17:46 +0200)]
Form::round_amount: Perls Wissen über Stringifizierung nutzen
Perl weiß am besten, wann eine nicht ganz exakte Fließkommazahl
eigentlich eine für Menschen sinnvoll lesbare Fließkommazahl ist (also
dass mit 143.19999999999998863132 eigentlich 143.2 gemeint ist, wenn ich
143.2 übergebe). Also nutzen wir diese Tatsache, machen aus der
Fließkommazahl einen String und teilen diesen dann am
Dezimaltrennzeichen auf.
Danach kann mit Integerarithmetik weiter gerechnet werden. Auf die
Nachkommastellen wird entsprechend addiert, sofern die relevante Stelle
>= 5 ist, und der dabei potenziell entstehende Übertrag wird in einer
zweiten Addition auf den Vorkommaanteil addiert.
Erst zum Schluss werden diese beiden Integerzahlen mit Hilfe eines
Strings zu einer Fließkommazahl zusammengesetzt.
Dabei muss beachtet werden, dass auf 32bit-Architekturen Perls
automatische Integer-Umwandlung von Strings bei Stringlängen von 9
bereits auf die wissenschaftliche Schreibweise wechselt. Das wird
verhindert, indem das Math::BigInt-Modul in dem Moment für die
Berechnung verwendet wird, aber aus Performancegründen nur dann, wenn's
wirklich nötig ist.
Jan Büren [Tue, 30 Sep 2014 09:28:18 +0000 (11:28 +0200)]
Konfigurierbares Angebotsgültigkeits-Intervall hinzugefügt
Standardmässig ist ein Verkaufsangebot bis zum nächsten Werktag gültig.
Dieses Intervall wird dann noch hinzugerechnet, bspw. nächster Werktag plus 14, 28 etc.
Falls das Intervall nicht gesetzt oder wir nicht den Typ sales_quotation haben, passiert nichts.
Der Datentyp ist Integer, Tippfehler werden bisher nur dort abgefangen (Wird wahrscheinlich
nur einmalig von einem Kunden gesetzt).
Jan Büren [Tue, 30 Sep 2014 06:49:43 +0000 (08:49 +0200)]
Beschriftung geändert: Lieferschein erstellt -> Lieferscheine(e) in kompletter Menge erstellt
Betrifft Status delivered in oe, dieser wird erst gesetzt wenn die Liefermenge komplett erreicht
ist. Somit ist Lieferschein erstellt, eine bessere Bezeichnung für "geliefert" (da ja
noch nicht ausgelagert), aber verwirrend wenn es schon einen Lieferschein gibt und der Haken,
zu Recht, noch nicht gesetzt ist.
Als Erläuterung paste ich schlicht den relevanten Teil des Kommentars,
der nun auch in der Funktion steht:
Trying to round with more precision first only shifts the problem to rarer
cases, which nevertheless exist.
Now we exploit the presentation rounding of Perl. Since it really tries hard
to recognize integers, we double $amount, and let Perl give us a representation.
If Perl recognizes it as a slightly too small integer, and rounds up to the
next odd integer, we follow suit and treat the fraction as .5 or greater.
Sven Schöling [Mon, 15 Sep 2014 13:18:51 +0000 (15:18 +0200)]
ParseFilter: with_objects merging bei Klassen mit Filtered Plugin
ParseFilter kennt 3 Quellen für with_objects Klauseln:
1. explizit übergebene
2. aus dem Filter inferierte
3. aus custom filtern gesetzte
Wenn nun ein Model das Custom Filter Plugin hat, muss bei jedem Filter
getestet werden, ob dieser Filter eigene with_objects setzt oder nicht.
Wenn der Filter aber auf eine normale Spalte zeigt, muss wie ohne Klasse
auch der Standardpfad als Include gesetzt werden. Das war aber nicht der
Fall.
Jan Büren [Thu, 4 Sep 2014 12:46:34 +0000 (14:46 +0200)]
all_parts um Namensoption des Kunden oder Lieferanten erweitert
Der Name wurde im Backend IC.pm schon richtig übergeben, es scheint
aber, dass dieser dann nicht mehr als Option angehakt war.
Entsprechend auch eine Flash-Warnung auch ausgegeben, falls überhaupt
keine Belegoption angewählt wurde.
Jan Büren [Thu, 4 Sep 2014 10:46:23 +0000 (12:46 +0200)]
hotfix für #10 Ansprechpartner auf ungültig setzen löst leeres Adressfeld beim Drucken aus
behebt (teilweise) #9 ggf. wäre es prinzipiell besser die customer_details
auf rose umzuschreiben
Jan Büren [Thu, 4 Sep 2014 07:07:29 +0000 (09:07 +0200)]
SuSa - Summe per und Saldo auch bei abweichenden Geschäftsjahr berechnen
Falls man eine Monats-SuSa zieht werden die Salden korrekt berechnet, allerdings
wurde nicht ein abweichendes Geschäftsjahr berücksichtigt. Jetzt wird
das Startdatum wie in der Bilanz genommen, dass ist schon mal besser, allerdings
ist hier der Fall Startdatum == closedto immer noch etwas unschön, s.a. Kommentar
in der Methode get_balance_startdate_method
G. Richardson [Wed, 3 Sep 2014 14:19:20 +0000 (16:19 +0200)]
netprice auf Anzahl von Nachkommastellen von sellprice runden
Es geht um die Anzeige der Einzelpreise von Positionen der
Druckvorlagen.
Bisher wurde netprice hart auf 2 Nachkommastellen gerundet, was zu
Problemen bei Subcentpreisen führte. Dies hatte den Effekt, daß z.B.
Menge 1000 und Sellprice 0.0036 eine linetotal von 3.6 ergab, und
netprice mit 3.6/1000 auf 2 Nachkommastellen gerundet zu 0 wurde. In der
Druckvorlage wurde dadurch der effektive Einzelpreis zu 0. Rundet man
auf die Anzahl der Nachkommastellen von sellprice (in diesem Beispiel
4), wird daraus wieder 0.0036 und kann in der Druckvorlage korrekt
angezeigt werden.
Jan Büren [Thu, 28 Aug 2014 12:14:32 +0000 (14:14 +0200)]
Überprüfung auf makemodel bei mehreren Artikeln verbessert
Aktuell wird nur auf Werte beim ersten Eintrag bei makemodel überprüft.
Falls es mehrere Werte und man den ersten Eintrag löschen will greift
die Überprüfung nicht mehr. Entsprechend die Prüfung erweitert.
Das behebt #7 Lieferanten-EK-Preise / Lieferantenartikelnummern verschwinden.
Moritz Bunkus [Tue, 26 Aug 2014 07:40:56 +0000 (09:40 +0200)]
Pflichtenheftaufträge: Pauschalpos. in Ang./Auftr. erstellen können
Pauschalpositionen haben die Menge 1, als Einheit die Einheit des
Artikels (und nicht »Stunden«) und als Preis den Gesamtpreis der
Aufwandsschätzung des dazugehörigen Abschnitts.
Moritz Bunkus [Mon, 25 Aug 2014 13:25:47 +0000 (15:25 +0200)]
Pflichtenheftaufträge: beliebige Artikel auswählen können
Zusätzlich werden dann Spalten angezeigt, die die Einheit und den im
Angebot/Auftrag verwendeten Positionstypen (Pauschalposition/
Auwandsposition) angeben.
Moritz Bunkus [Tue, 26 Aug 2014 12:00:33 +0000 (14:00 +0200)]
Form->parse_template: notes nicht immer aus invoicenotes kopieren
Wenn ein Beleg über Rose-Model-Code zum Drucken vorbereitet wird, dann
steht in $form->{notes} bereits der richtige Wert, und den
belegspezifische Wert $form->{invoicenotes} gibt es gar nicht. Also auch
notes damit nicht überschreiben.
Moritz Bunkus [Tue, 26 Aug 2014 11:29:59 +0000 (13:29 +0200)]
Finanzcontrollingbericht: wiedk. Rechnungen vom Enddatum immer bis heute
Das konfigurierte Enddatum ist nur dann relevant, wenn die
wiederkehrende Rechnung gekündigt wurde. Ansonsten wird sie automatisch
verlängert, sprich ein maximales Enddatum gibt es dabei nicht.
Das konfigurierte Enddatum ist nur dann relevant, wenn die
wiederkehrende Rechnung gekündigt wurde. Ansonsten wird sie automatisch
verlängert, sprich ein maximales Enddatum gibt es dabei nicht. Wir
nehmen der Einfachheit halber 100 Jahre.
Hiermit tauchen die Beträge der Aufträge im Finanzübersichtsbericht auch
richtig für jede Periode auf, nicht nur dann, wenn kein Enddatum in der
Konfiguration gesetzt ist.
Moritz Bunkus [Tue, 26 Aug 2014 11:03:40 +0000 (13:03 +0200)]
Form->prepare_for_printing: output_*-Variablen als Fallback auf %myconfig-Werte setzen
Wenn für eine Sprache kein Ausgabeformat für Datum und/oder Zahlen
festgelegt ist, so muss hier der Wert der angemeldeten Benutzerin
genommen werden, weil ansonsten die Werte falsch formatiert
werden. Außerdem kann es sein, dass die Vorlagen dann falsch rechnen,
wenn sie \numprint nutzen.
Behebt Formatierungsprobleme in wiederkehrenden Rechnungen, wenn der
Auftrag eine Sprache gewählt hat, in der die Ausgabeformate nicht
definiert sind.
Das Periodenenddatum wird am Anfang der sub bereits richtig als »der
letzte Tag innerhalb des Abrechnungszeitraumes« berechnet und darf
hinterher daher nicht mehr auf den Monat abgeschnitten werden.
Jan Büren [Mon, 25 Aug 2014 10:15:33 +0000 (12:15 +0200)]
abweichende Lieferadresse für Lieferschein bei RB-Druckvorlagen
analog zu dem Commit von gerade. Hier auch die abweichende Lieferadresse
beachten. erledigt #2
Jan Büren [Mon, 25 Aug 2014 09:47:35 +0000 (11:47 +0200)]
Bei Kundenauftrag -> Lieferantenauftrag Zahlungs- und Lieferbedingungen löschen
Zahlungs- und Lieferbedingungen aus dem Kundenauftrag zu übernehmen macht
i.d.R. keinen Sinn, da diese ja vom Lieferanten definiert werden.
S.a. Ticket 1 in Redmine und fixes #1
G. Richardson [Fri, 8 Aug 2014 11:50:23 +0000 (13:50 +0200)]
Steuerzone - neue Customer/Vendor-Objekte brauchen Steuerzone
Durch den not-NULL Constraint bei Kunden und Lieferanten muß
beim Anlegen eines neuen Objekts nun zwingend die Steuerzone mit
übergeben werden, ähnlich wie bei der Währung.
Dies wurde bei einigen automatischen Tests nachgeholt.
G. Richardson [Wed, 6 Aug 2014 10:32:23 +0000 (12:32 +0200)]
convert_taxzone - Fall keine Buchungsgruppen berücksichtigen
Für den Fall, daß in dem Mandanten gar keine Buchungsgruppen
konfiguriert sind (z.B. bei einem frischen Schweizer Kontenrahmen), wird
die Umwandlung der Buchungsgruppen übersprungen.
G. Richardson [Wed, 6 Aug 2014 09:01:42 +0000 (11:01 +0200)]
Steuerzone - Sortierreihenfolge bei Customer/Vendor
Sortierreihenfolge im Dropdown bei den Stammdaten einhalten.
Dadurch ist die Steuerzone mit der höchsten Sortierpriorität immer als
Defaults bei neuen Kunden/Lieferanten eingestellt (standardmäßig
Inland).
G. Richardson [Wed, 6 Aug 2014 08:07:46 +0000 (10:07 +0200)]
Steuerzone: in Upgrade-Datei customer/vendor angepasst
Macht man eigentlich nachträglich nicht, aber da das Update noch so
frisch ist...
Beim Umstellen von taxzone wurde vergessen, auch die Einträge der
Standardsteuerzone bei den Kunden und Lieferanten anzupassen. Im Zuge
der Umstellung, wo bei taxzone keine 0 mehr erlaubt ist, und diese auf 4
umgemapped wurde, müssen auch die hinterlegten Daten bei Kunden und
Lieferanten konvertiert werden.
In diesem Schritt wurden dann auch gleich Fremdschlüssel für die
Steuerzone bei Kunden und Lieferanten angelegt.
Ist das Update schon durchgelaufen und muß man manuell nachbessern wären
dies die Schritte (unter der Voraussetzung, daß id 0 auch zu id 4
geworden ist):
UPDATE customer SET taxzone_id=4 WHERE taxzone_id=0;
UPDATE vendor SET taxzone_id=4 WHERE taxzone_id=0;
ALTER TABLE customer ALTER COLUMN taxzone_id DROP default;
ALTER TABLE vendor ALTER COLUMN taxzone_id DROP default;
ALTER TABLE customer ADD FOREIGN KEY (taxzone_id) REFERENCES tax_zones (id);
ALTER TABLE vendor ADD FOREIGN KEY (taxzone_id) REFERENCES tax_zones (id);
G. Richardson [Mon, 4 Aug 2014 12:19:28 +0000 (14:19 +0200)]
CsvImport - Part : Anpassung für neue Steuerzonen
statt income/expense_accno_id_0 werden jetzt bei importierten
Waren/Dienstleistungen die Konten-IDs der Standardsteuerzone verwendet.
(Wobei die genau ID ja egal ist, wichtig ist, ob etwas gesetzt ist).
* neue BG: Konten-Dropdown mit Standardkonten vorausgewählt
* existierende BG nicht in Benutzung: Konten-Dropdown mit gespeicherten
Konten vorausgewählt
* existierende BG in Benutzung: gespeicherte Konten als Text anzeigen
G. Richardson [Sun, 3 Aug 2014 23:40:27 +0000 (01:40 +0200)]
DB Code für Buchungsgruppe und TaxzoneChart aufgeräumt
In SL::DB::Manager::Buchungsgruppe die Methoden inventory_accno und
inventory_accno_description entfernt, da hier einfach
inventory_account->accno und inventory_account->description benutzt
werden können.
G. Richardson [Sun, 3 Aug 2014 23:35:45 +0000 (01:35 +0200)]
Beim Erfassen von Steuerzonen Standardkonten verwenden
Vorauswahl von Erlös- und Aufwandskonten laut Mandantenkonfiguration.
Im Gegensatz zum Anlegen von Buchungsgruppen kann bei der Steuerzone
kein Bestandskonto konfiguriert werden, da dies nur von der
Buchungsgruppe abhängt.
G. Richardson [Wed, 30 Jul 2014 18:38:28 +0000 (20:38 +0200)]
Steuerzonen ungültig machen
jede Steuerzone kann man unter "System->Steuerzonen->auf Steuerzone klicken"
individuell auf ungültig (obsolete) setzen.
ungültig heißt:
* Steuerzone erscheint nicht in der großen Buchungsgruppenübersicht
* Steuerzone erscheint nicht im Drop-Down Menü für Steuerzonen bei neuen
Belegen (Angebot-Rechnung)
Bei alten Belegen, die erneut geöffnet werden, ist leider das Verhalten unterschiedlich:
* bei schon gebuchten EK/VK-Rechnungen (id) ist das Drop-Down ausgegraut und
disabled und es wird nur die ausgewählte Steuerzone angezeigt -> funktioniert
* bei schon gebuchten Angeboten/Aufträgen müssen immer alle Steuerzonen
angezeigt werden, da man die Steuerzone auch im Nachhinein ändern kann, aber
auch alle alten Belege mit mittlerweile ungültigen Steuerzonen korrekt
angezeigt werden müssen. Man kann also nicht einfach nach id fragen und
entsprechend nach ungültig filtern.
Bucht man also einen Auftrag mit einer bestimmten Steuerzone, setzt die
Steuerzone auf ungültig, und generiert dann aus dem Auftrag z.B. eine Rechnung,
würde die Steuerzone aus dem Auftrag nicht übernommen werden, sondern die erste
Steuerzone aus der Liste standardmäßig ausgewählt sein.