Artikel-Klassifizierung: Neue Option "Preis separat ausweisen"
- neuer boolcher Wert in der Tabelle parts_classification: "report_separate"
- editierbar unter Artikelklassifikation
- In Aufträgen und Rechnungen werden die Zwischensummen LaTeX zur Verfügung gestellt.
- <%separate_XXX_subtotal%> wobei XXX die Abkürzung der Klassifikation ist.
- <%non_separate_subtotal%> der Rest der Positionen, z.B. reiner Warenwert.
Hintergrund:
Preise von Artikeln wie "Verpackung" oder "Transport" müssen
oftmals separat ausgewiesen werden, genau so wie der reine Warenwert.
Die ursprünglich als "Artikeltyp" bezeichnete Klassifizierung von Artikeln
Sie dient einer weiteren Gliederung um zum Beispiel den Einkauf vom Verkauf zu trennen, etc.
Gekennzeichnet durch eine Beschreibung (z.B. "Einkauf") und ein Kürzel (z.B. "E")
Flexibel änderbar und erweiterbar.
- Neue Datenbanktablle und Rose-Objekte, sowie Controller zum Bearbeiten der Tabelle
- Zwei-Zeichen Abkürzung:
Der Typ des Artikel und die Klassifizierung werden durch zwei Buchstaben dargestellt.
Der erste Buchstabe ist eine Lokalisierung des Typs des Artikel ('P','A','S') ,
deutch 'W', 'E', und 'D' für Ware Erzeugnis oder Dienstleistung, ggf. weitere Typen.
Der zweite Buchstabe ist eine Lokalisierung der Klassifizierungsabkürzung (abbreviation).
Die Abkürzungen sind aus dem Part Presenter abholbar:
- SL::Presenter::Part->type_abbreviation($part_type)
- SL::Presenter::Part->classification_abbreviation($classification_id)
Wenn im ERP-Dokument nach einer Artikelnummer oder Beschreibung gesucht wird,
diese in den Stammdaten vorhanden ist,
aber der Artikeltyp leer oder falsch ist, bzw im Typ for_purchase bzw for_sale nicht gesetzt ist,
wird die Fehlermeldung "Gesuchter Artikel ist nicht für den Einkauf bzw Verkauf" gemeldet
Anpassung des CSV Import,
nun wird alternativ zur 'type'-Spalte die 'pclass'-Spalte mit zwei Buchstaben geparsed und entsprechend
classification_id,assembly sowie inventory_accno_id gesetzt (oder type_id falls neue Implementierung eingebaut).
G. Richardson [Thu, 28 Jul 2016 16:14:15 +0000 (18:14 +0200)]
Ware/Erzeugnis/Dienstleistung per parts.part_type unterscheiden
Neuen ENUM-Typ eingeführt, der auf die Werte "part", "service" und
"assembly" beschränkt ist.
Da man enums nicht innerhalb von Transaktionen hinzufügen kann, was der
Default für den kivitendo Upgrade Mechanismus ist, wird hier auch schon
das Sortiment vorbereitet.
Jan Büren [Fri, 18 Nov 2016 14:36:20 +0000 (15:36 +0100)]
optionales Feature für SEPA Überweisungen
Nach der Rechnungsnummer im Verwendungszweck zusätzlich Kunden- oder Lieferantennummer angeben.
Optional konfigurierbar in der Mandatenkonfiguration und übersetzbar für alle verfügbaren Sprachen.
Moritz Bunkus [Tue, 8 Nov 2016 11:58:44 +0000 (12:58 +0100)]
Startup: Include-Pfade mittels FindBin ermitteln
Neue Perl-Versionen werden das aktuelle Verzeichnis '.' aus dem
Standard-Include-Pfad @INC entfernen. Das bedeutet für uns, dass wir
nicht mehr einfach »use SL::Dispatcher;« und ähnliche Konstrukte machen
können.
Daher stellt dieser Commit all diejenigen Perl-Dateien, die als externe
Einstiegsquelle dienen, auf die Verwendung von FindBin um. Es werden
nicht nur die Verzeichnisse »modules/override« und »modules/fallback«
behandelt, sondern auch das Installationsverzeichins selber mit in @INC
aufgenommen, um für die Entfernung von '.' gewappnet zu sein.
Zusätzlich wurden die meisten Scripte so modifiziert, dass sie nicht
mehr direkt aus dem kivitendo-Installationsverzeichnis heraus aufgerufen
werden müssen sondern aus beliebigen Verzeichnissen heraus aufgerufen
werden können. Sie wechseln schlicht zu allererst das aktuelle
Verzeichnis ins kivitendo-Installationsverzeichnis.
Perl-Module, die nicht direkt Scripte sind und den Pfad zum
Installationsverzeichnis benötigen (also z.B. SL/DBUpgrade2.pm), dürfen
allerdings FindBin nicht benutzen, weil $FindBin::Bin das Verzeichnis
zum aufgerufenen Perl-Script enthält, und das kann mal dispatcher.pl
sein, mal scripts/dbupgrade2.pl. Für diese Module gibt es weiterhin
SL::System::Process->exe_dir, die das kivitendo-Installationsverzeichnis
zuverlässig ermittelt.
Leider ist es nicht möglich, nur SL::System::Process->exe_dir anstelle
von $FindBin::Bin zu nutzen, da zuerst SL::System::Process eingebunden
werden muss, und um das zu tun, muss das Installationsverzeichnis ja
bereits im Include-Pfad vorhanden sein — typical case of catch 22.
Moritz Bunkus [Tue, 8 Nov 2016 12:47:41 +0000 (13:47 +0100)]
systemd Service: Abhängigkeiten gefixt; User ergänzt; ProtectXZY ergänzt
• Requires & After: falscher Abschnitt, gehören nach [Unit]
• User: der Task-Server sollte als der User laufen, unter dem auch der
Webserver läuft.
• ProtectSystem, ProtectHome, PrivateTmp: diverse Sicherheitsmechanismen
von systemd nutzen; siehe »man systemd.exec«
Moritz Bunkus [Tue, 8 Nov 2016 12:36:25 +0000 (13:36 +0100)]
scripts: nicht mehr benötigte/funktionierende Scripte entfernt
• create_tags_file.pl: das alte tags-Format wird eigentlich nicht mehr
verwendet; wenn dann etags oder GNU global.
• spawn_oo.pl: lange veraltet; soffice heißt das Programm schon lange
nicht mehr; funktioniert nicht; unzulänglicher Test, ob Prozess läuft
• templ2t8.pl: Konvertierung vom alten Template-System wird schon lange
nicht mehr benötigt
• pl2tmpl.pl: dito
Moritz Bunkus [Wed, 7 Sep 2016 11:32:35 +0000 (13:32 +0200)]
Pflichtenhefte: Faktor für Verkaufspreis in Abschnitten & »Kostenschätzung« umbenannt
Aktuell haben wir nur einen Verkaufsbasispreis im Pflichtenheft: den
Stundensatz in den Grundeinstellungen. Dies ist allerdings der
Stundensatz, der Kunden gegenüber in Rechnung gestellt wird, und damit
ein Verkaufspreis und kein Kostenfaktor. Die Kosten anhand des
Verkaufspreises abzuschätzen ist aber unsinnig.
Daher ist es sinnvoller, erst mal von »Zeit- und Preisschätzung«
anstelle von »Zeit- und Kostenschätzung«.
Der neu eingeführte Faktor, der an Abschnitten angegeben werden kann,
ist dann ein Multiplikator für die Verkaufspreisschätzung. Er kann
z.B. benutzt werden, um geplante Wochenendarbeiten höher zu bepreisen.
Eine Einführung von echter Kostenschätzungen würde etwas mehr Arbeit
erfordern.
Automatisches Löschen von Flashanzeige unterdrückbar
Bei jedem ClientJS call wird bisher vor Ausführung der Antwortdaten in Javascript
die Info/Warnung/Fehleranzeige gelöscht.
Bei periodischen ClientJS call kann das zu unerwünschten Effekten führen,
z.B. eine Fehlermeldung wird so schnell gelöscht, dass sie nicht erkannt werden kann.
Nun kann optional dies per $self->js->no_flash_clear abgeschaltet werden
Generell werden die SEPA Export-Items aus der Punktebewertung herausgenommn,
dafür wird eine exaktere Prüfung auch mittels des Transaktionstyps ermittelt.
Dadurch werden auch Sammellastschriften/Überweisungen erkannt.
Setzen von Skontotyp, kein Prüfen der Sepaitems mehr in >get_agreement_with_invoice
In einer Rechnung wird beim Erzeugen aus der Vorlage der gezahlte Wert nun
richtig ausgefüllt.
Wie in create_invoice.html negative Werte frisch formatieren (commit 15b2640059)
projects / kivitendo-erp.git / log