Rundungsfehler bei periodischen Rechnungen mit Einzelpreisen ...

... mit einer Nachkommastelle und Rabatt behoben.

siehe auch commit a22b8118e0bd68acac8a2d7b02a2d4f9fd0eaff1

Zudem einen Test dazu angelegt. Allerdings weicht die Art, wie der
PriceTaxCalculator und die Beleg-Masken rechnen, von einander ab.
Da müsste nochmal geprüft werden, was die richtige Art ist
(erst Rabatt abziehen und dann runden,
oder gerundeten Rabatt abziehen und wieder runden).
Auch beim Errechnen des Amounts gibt es unterschiede
(netamount * (1+Steuersatz),
oder aufsummieren).

FollowUp(Access)-Rose-Models: sinnvollere Namen für Relationships

rose_auto_create_model.pl: Relationship-Namen anhand der Spaltennamen mappen

Bisher wurde das Umbenennen der generierten Relationships anhand des von
Rose vergebenen Namens der Relationship vorgenommen. Das ist
problematisch, weil diese wiederum von der Reihenfolge abhängen, in der
die Fremdschlüsseldefinitionen von der Datenbank zurückgeliefert werden.

Konkretes Beispiel: Tabelle »follow_up_access« mit den Spalten »who« und
»what«, die beide Fremdschlüssel auf employee sind.

Rose benennt die erzeugten Relationships nach dem Klassennamen
derjenigen Tabelle, auf die die Schlüssel verweisen. Tabelle »employee«
→ Klasse »SL::DB::Employee« → Default-Relationshipname »employee«.

Die erste von der Datenbank gemeldete Fremdschlüsseldefinition bekommt
nun den Namen »employee«. Die zweite sollte diesen ebenfalls bekommen,
aber da der schon vergeben ist, bekommt sie das Suffix »_obj«, ergo
»employee_obj«. Soweit, so gut. Ändert sich nun aber die Reihenfolge, so
werden die Namen genau umgekehrt herum vergeben.

Die Umbenennung anhand des Tripels <Domäne, Tabelle, Spaltennamen>
hingegen ist immer eindeutig.

Kunden-/Lieferantenstammdaten: Maps-Link mit Firmenadresse als Routing-Ausgang

Spaltentyp Text anstelle von varchar() in diversen Tabellen Teil 3

Kunden-/Lieferantenstammdaten: Beschränkungen für Feldlängen entfernt

…da die Datenbankspalten inzwischen alle vom Typ TEXT und nicht mehr
VARCHAR sind.

Spaltentyp Text anstelle von varchar() in diversen Tabellen Teil 2

Tabelle »shipto«

Lieferantenauftrag → Kundenauftrag: Verkaufspreis als Einkaufspreis übernehmen

Der Preis, den ich beim Lieferanten zahlen musste (alte Maske:
sellprice_N) ist dann im weiteren Verkaufsprozess der
Einkaufspreis (neue Maske: lastcost_N).

Generische Unterstützung für CTI: Click-to-dial

ReportGenerator: class für Links angeben können

SL::MoreCommon: benutztes Encode auch usen

USTVA: Analog zu b0f569c auch Position 46 umdrehen.

Neuer Bericht »Liquiditätsvorschau«

Verkaufsbelege: optional nur Projekte des Kunden anbieten

Auch dieses Feature kann über die Mandantenkonfiguration eingeschaltet
werden.

Instance-Conf am Anfang jedes Requests laden

Angebote: neue Felder Auftragswahrscheinlichkeit, Voraus. Abrechnungsdatum

Einkaufs-/Verkaufsprozesse: optionale Einschränkungen für gewisse Aktionen

Über die Mandantenkonfiguration kann verboten werden, dass gewisse
Aktionen in den Einkaufs- und Verkaufsprozesse durchgeführt
werden. Diese sind:

- Direkte umwandlung von Verkaufsangeboten und -aufträgen in
  Verkaufsrechnungen (nur über den Weg der Lieferscheine)
- Direktes Anlegen neuer Einkaufslieferscheine und -rechnungen (nur
  durch Umwandlung bestehender Belege)

Offene Transaktionen vor DB-Upgrades comitten

Hintergrund ist, dass Locks potenziell vorhanden sein können. Einfaches
Beispiel: $::instance_conf wird geladen (dadurch implizites
ACCESS-SHARE-Lock auf »defaults«), Upgrade will Schema von »defaults«
verändern, was dann hängt, weil dafür ACCESS-EXCLUSIVE benötigt wird –
das mit ACCESS-SHARE kollidiert.

CSV-Helfer-Test: In-Memory-Streams mit richtigem Encoding initlisieren

Einkauf/Verkauf: Vorgangsbezeichnung in Suche default an…

…sofern in der Mandantenkonfiguration das Erzwingen der Eingabe der
Vorgangsbezeichnung eingeschaltet ist.

Einkauf/Verkauf: Eingabe der Vorgangsbezeichnung optional erzwingen

Wird über eine Option in der Mandantenkonfiguration eingeschaltet.

Auftragsmaske: JavaScript-Checks für Speichern aktiver per. Rechnungen nach kivi.SalesPurchase verschoben

Lieferscheinmaske: JavaScript-Checks für Lagermenge nach kivi.SalesPurchase verschoben

DB-Schema-Anpassungen für »Spaltentyp Text anstelle von varchar() in diversen Tabellen«

Projektliste: kein Filterkriterium für Status == alle

…und nicht »nie benutzt«

Kundenauswahl bei Summen-/Saldenliste

Vor E-Mail-Versand prüfen, ob Empfänger+Betreff+Body vorhanden

Angebote/Aufträge drucken: auch das Order-Objekt ausliefern

Im Druck auch den Typ von Artikeln mit ausliefern

special_chars: U+00A0 NO-BREAK SPACE in latex erkennen und korrekt rendern.

Das Zeichen passiert oft, wenn Artikelbeschreibungen von Webseiten von
Lieferanten copy&pasted wird.  Webseiten padden ihre Daten gerne mit &nbsp; das
dann als U+00A0 gerendert wird, und landet so in der Datenbank.

SL::DB::Invoice: Verknüpfung auf die Buchungsobjekte

print_html_template auch mit scalarrefs als file aufrufbar gemacht

Ausserdem die Fehlermeldung bei nicht korrektem aufruf mit header angeben.

print_form optional ohne redirect

Form->error: confess anstelle von STDERR bei Fehlern von der Console aus benutzen

Locales: fehlende Übersetzungen aus CRM-Menü-Datei ergänzt

locales.pl: Task-Server-Fehlschlags-E-Mail-Template ignorieren

Spaltentyp Text anstelle von varchar() in diversen Tabellen

console: shortcuts für die häufigsten Belegtypen, nützlich beim debuggen

Term::ReadLine::Perl::Bind in Console nicht nutzen

Fixt zwar unter RXVT, macht aber unter anderen Emulatoren die Bindings
ziemlich kaputt.

Task-Server: vor jedem Job mehr Variablen re-initialisieren

Besonders wichtig: $::request, da sie zum Cachen genutzt wird und die
Garantie vom Cache ist, dass er nach jedem »Request« (beim Task-Server:
nach jedem Job) geleert wird.

SL::DB::Part,Helper::PriceTaxCalculator: agressiveres Caching

Damit wird für ziemlich jeden Objekttyp nur noch ein einziges Query
abgesetzt.

SL::DB::Object: generische Methoden zum Cachen von RDBO-Instanzen

SL::DB::Part: Cachen von Objekten gefixt Teil 2

get_active_taxkey hat vorher ganz einfach nicht gecachet.

SL::DB::Part: Cachen von Objekten gefixt

Über Steuerzonen erhaltene Informationen müssen pro Part-ID gecachet
werden, weil diese natürlich Artikel-spezifisch sind.

Locale: Warnungen

CVars: spelling: dependant -> dependent (wir haben uns irgendwann mal auf AE geeinigt)

PeriodicInvoices: korrekter Fallback, wenn kein email Template gesetzt ist.

PeriodicInvoices: Rechnugnen nicht einen Tag zu früh erstellen, das gibt massig Probleme

SL::DB::CustomVariable::{value,value_as_text}: Verwendung von $::request->cache()

Partpicker: Benutzerdefinierte Variablen mitschicken

SL::DB::Unit::base_factor: Verwendung von $::request->cache()

SL::DB::{Chart,Part}: Verwendung von $::request->cache()

SL::Request: Funktion zum Cachen von Objekten für Dauer des Requests

PriceTaxCalculator: chart->taxkey lookup vorberechnen

PartPicker: keine AJAJ-Requests nach Fat-Data ohne item.id schicken

LXDebug: Zeitstempel mit Millisekunden-Auflösung ausgeben

SL::Helper::CreatePDF: gewisse Variablen nicht mit Variablen überschreiben lassen

Tab Persistenz in allen masken ausser customer_vendor

War beim Umschreiben auf jquery-ui kaputtgegangen, weil der div.tabwidget eine
id braucht. CustomerVendor hatte das beim neuschreiben schon korrekt mit id
versehen.

SL::Controller::Base->send_file: neuer Parameter unlink zum Löschen nach Senden

Dispatcher: Requests auf controller.pl ohne action auf Loginseite redirecten

Ist hilfreich, wenn man aus der Browserhistory einen Link wie
http://…/kivitendo/controller.pl aufruft. Bisher wurde nur eine böse
Fehlerseite angezeigt.

RecordLinks: frühzeitig abbrechen, wenn keine links gefunden wurden.

Hintergrundjobhistorie: Status für Fehlschlag richtig benennen

CVars: Einträge beim Löschen dazugehöriger Belege automatisch löschen

CVars: beim Autovivifien gültigen Wert für selects forçieren

Kunden-/Lieferantenbericht: auch im Nicht-Union-Fall nach Typ sortieren können.

Kunden-/Lieferantenbericht: Zahlungsbegingungen anzeigen können.

CustomerVendor-Picker: keine ungültigen, wenn $::form->{obsolete} nicht gesetzt ist

Template-Pfad vor regex quoten.

zu commit 6348bffb3ca90327f8dd042bfd0a89802b269b79
(Template-Pfad aus Pfad-Namen anderer Tex-Dateien richtig entfernen.)

CustomVariable: typo - from_kivi -> from_kivitendo

Rose-Model-Generator: Foreign-Key-Namens-Mapping auf Datenbank beziehen

Rose-Model-Generator: --db für nur eine Datenbank bei --all

Siehe auch Commit »Rose-Model-Generator: prinzipielle Unterstützung
verschiedener Datenbanken«.

Rose-Model-Generator: auf Duplikate in Blacklist/Paketnamenshash prüfen

RDBO Invoice->new_from: Fälligkeitsdatum und Zahlungsbedingungen gefixt

1. Konvertierung von Order-Objekten: Hier wurde das Fälligkeitsdatum
   zwar richtig übernommen, nicht aber die Zahlungsbedingungen.

2. Konvertierung von DeliveryOrder-Objekten: Lieferscheine haben gar
   keinen Fremdschlüssel auf die Zahlungsbedingungen. Daher wurden hier
   weder das Fälligkeitsdatum noch die Zahlungsbedingungen übernommen.

Was jetzt gemacht wird, ist die Zahlungsbedingungen vom Quellobjekt zu
nehmen, wenn dort welche existieren, und ansonsten vom dazugehörigen
Kunden. Wurden Zahlungsbedingungen gefunden, so wird das
Fälligkeitsdatum daraus berechnet und ansonsten auf »Rechnungsdatum + 1
Tag« gesetzt.

RDBO Customer, Vendor: Alias payment_terms auf payment

…für API-Analogie mit Order, DeliveryOrder, Invoice.

RDBO {Invoice,DeliveryOrder}->new_from Attribute nachträglich zuweisen

Macht man die Vermischung ->new(%args, %attributes), so ist die
Reihenfolge, wann welche aus %args und welche aus %attributes genommen
werden, aufgrund von Perls beliebiger Hash-Reihenfolge nicht
garantiert. Also zuerst nur die berechneten aus %args zuweisen und
danach die vom Caller bereitgestellten in %attributes.

Template-Pfad aus Pfad-Namen anderer Tex-Dateien richtig entfernen.

Behebt #2483.

RecordLinks: Anzeige etwas verbessert

Task server: Fehlgeschlagene Jobs optional per E-Mail melden

RDBO BackgroundJob(History): Refactoring von Status-Strings

Test-BackgroundJob: Möglichkeiten, das Ergebnis zu steuern

Rose-Attr-Helfer: _as_timestamp

…mit verschiedenen Präzisionsstufen und Tests!

Locale::parse_date_to_object: Unterstützung für volle Timestamps & explizite Formate

…und dafür Tests.

Locale::format_date_object: explizites Setzen der Formate; Millisekunden als neues Format

…und dazu Tests.

Verknüpfte Belege: Standardmässig rekursive Belege finden

SL::DB::Helper::LinkedRecords: rekursive Suche in linked_records

Merge branch 'master' of github.com:kivitendo/kivitendo-erp

Rose-Model-Generator: prinzipielle Unterstützung verschiedener Datenbanken

Um Models für andere Datenbanken zu erstellen, müssen dann noch SL::DB,
SL::DB::Helper::Mappings und SL::DB::Object entsprechend angepasst
werden, damit die Verbindung richtig aufgebaut werden.

LinkedRecords: bidi Verhalten den docs angepasst und direction Parameter optional gemacht

warnings: uninitialized in eq

Mal wieder ein paar lexicals in post if.

t/structure/globals: Lexikalische Variablen sind schwer exportierbar.

t/test.pl: Neuere Tests kommen sich bei multicore in die Quere. Vorerst ausschalten

t/test.pl: File::Find macht nur dann lstat wenn follow oder follow_fast als option gesetzt ist

LinkedRecords: Test und Doku Update

CsvImport: Feldlängen aus den Metadaten auslesen, nicht fest codieren.

Dispatcher: Pro-Request-Initialisierung in eigene Sub verschoben

Weiterhin optionale Initialisierung von Client und User in besagter Sub.
Erleichert die Verwendung die Initialisierung vom Dispatcher in eigenen
Scripten (z.B. der console oder rose_auto_generate_models.pl, auch wenn
die noch nicht umgestellt sind), weil dann nicht in jedem Script der
Initialiserungspfad nachgebaut werden muss.

Beispiel ($client_id_or_name und $login können z.B. vorher aus einer
Konfigurationsdatei gelesen werden):

use SL::Dispatcher;
use SL::DB::Customer;

our $dispatcher = SL::Dispatcher->new('CGI');
$dispatcher->pre_startup;
$dispatcher->pre_request_initialization(
  client => $client_id_or_name,
  login  => $login,
);

print join("\n", map { $_->id . ":" . $_->name } @{ SL::DB::Manager::Customer->get_all(limit => 5) }), "\n";

Unbekannte config values beim Speichern d. Benutzereinstellungen nicht löschen

scripts/dbupgrade2_tool.pl: bei --create --type pl auch package stub anlegen

Modul List::UtilsBy in Abhängigkeiten und als Fallback aufgenommen

$::request auch in dbupgrade2_tool initialisieren