PriceRule: Bei Mengen statt "<", ">" die ">=" und "<=" anbieten.

PriceRule: Name der Quelle auf Singular geändert

PriceRule: filter reset sollte auch dropdowns resetten

PriceRule: Überschriften mit Einkauf und Verkauf

PriceRule: Priorität auf 2 Werte einschränken

PriceRule: nach gültig/ungültig filtern

PriceRule: gültig korrekt editierbar machen

PriceRule: Waren auch im Einkauf zulassen.

PriceRule: Nicht Fehler werfen wenn _garkeine_ Regel zutrifft

PriceRule: Vergleiche waren falsch herum

PriceRule: bessere Validierung und Lokalisierung

PriceRule: Filter nach Ware implementiert

PriceRule: Korrektes Matching von Nulls

PriceRule: Löschen von Preisregeln

PriceRule: Fehler vermeiden wenn noch keine Preisregeln angelegt sind.

PriceRule: price_from_rule für Festpreise gefixt.

PriceRule: Erste Version

PriceSource: Spalte vor Preis und Rabatt anzeigen.

PriceSource: record objekte im Einkauf korrekt bauen

PriceSource: Keine Fehler werfen wenn best_price nicht existiert

PriecSource: Numerische Vergleiche im Template stinken

PriceSource: Rabattbehandlung

PriceSource: Einkaufsrechnungen brauchen einen Typ

PriceSource: credit_notes auch im Popup unterstützen

PriceSource: Fehler, wenn noch keine Quellen disabled sind, behoben.

PriceSource: Konfiguration

PriceSource: Nur den Namen des Moduls anzeigen, nicht den vollen Namen

PriceSource: 0,0000 Preise nicht als best_price erlauben

Auch wenn es im Einzelfall valide Preise sein können, sollte das
Standardverhalten keine Umsonstpreise vorschlagen.

PriceSource: Bei Lieferscheinen best_price nicht nachrechnen

PriceSource: numerische felder in record_item korrekt parsen

PriceSource: Gutschriften berücksichtigen

PriceSource: bei Rechnungen mitspeichern

PriceSource: changelog

PriceSource: Preisselektion auf Popup umgestellt.

- Logik für geänderte Preise implementiert
- Visualisierung verbessert
- fix für emptied rows
- nachricht wenn invalid und missing
- benachrichtigung für höher/niedriger
- js ausgelagert
- best price benachrichtigung

noch offene bugs:
- preise mit mehr als 2 stellen werden abgeschnitten
- interaktive preise noch nicht möglich
- symbol für "besser preis" ist nicht schön
- beide make_record_item implementierungen sind leicht unterschiedlich
- pricesource controller grösstenteils ungetestet
- performance ist im moment mies

PriceSource: db upgrade erst nach 3.1.0 einspielen

PriceSource: depends_on entfernt

PriceSource: Dokumentation

PriceSource: pricegroup migration

PriceSource: Featureabdeckung

- Einkaufs/Verkauf abgedeckt
- Klarere Regeln für price_from_source, available_prices und best_price
- makemodels unterstützung
- bugfixes für Rechnungen und neue Belege
- best_price jetzt getestet
- Verkäuferabhängigkeit von makemodels und pricegroup implementiert und getestet

PriceSource: Mehr Informationen an Preise übergeben

record + record_item verfügbar gemacht
best_price für pricegroups
Price: spec/source entzerrt

PriceSource: Erste Version

- Preisgruppen und Stammdaten sind implementiert
- Persistenz in allen Belegen funktioniert
- Rudimentäre Visualisierung funktioniert
- Klassen sind alle da

- Doku fehlt
- Verkauf/Einkaufweiche fehlt
- best_price ungetestet
- Preisgruppen hängen noch nicht von Verkäufer ab
- dependancy system fehlt
- verhalten bei fehlerhaften sources
- pricegroup -> active_source migration

PriceTaxCalculator: Doku-Fix

Typos in Filtered Doku

Typos in LinkedRecords Dokumentation

CSS: Klassen für interaktive text <a> mit javascript.

DBUtils: selectall_ids

displayable_name für business, partsgroup, pricegroup

PTC-Doku um API-Beispielsaufruf ergänzt

Verwaiste Einträge aus all entfernt

Aktuell werden diese zwei Übersetzungszeichenketten nicht mehr im
Programm verwendet.

PriceTaxCalculator: für Items berechnete flüchtige Werte zurückgeben Teil 3

Die items können nicht als Hash-Referenz gespeichert werden, weil das
kaputt geht, wenn die Items noch nicht gespeichert wurden und damit noch
keine ID besitzen. Daher Umstellung auf Array-Speicherung.

Außerdem Anpassung des Testcases.

PriceTaxCalculator: für Items berechnete flüchtige Werte zurückgeben Teil 2

PriceTaxCalculator: für Items berechnete flüchtige Werte in %data zurückgeben

Webdav: Typo

orderitems persistent teil III
IMMER die orderitems_id in sub poso löschen, nicht nur in
der if-bedingung
Angebot -> Auftrag i.O.
Auftrag - > Angebot i.O.
Kundenauftrag -> Lieferantenauftrag i.O.

CsvImport: Makemodels auch auf instabilen Datenbanken in der richtigen Reihenfolge speichern

Löschen von Angeboten/Aufträgen protokollieren

Berücksichtigt jetzt auch Angebote in history_erp.

Webdav: Framework um Dokumente im Webdav zu behandeln

Soll auf lange Sicht die Funktionen in Common ablösen.

SL/DB/Invoice->abbreviation prüft jetzt invoice_type

USTVA - Position 67 richtig berechnen

console - shortcut for purchase_invoice

redundante actions / orderitems delete in oe.pl gelöscht

nur einmal in sub poso alle orderitems_id löschen. ferner doppelte
dispatch actions entfernt

orderitems persistent machen.
bei vorlage als und position löschen entsprechend die ids löschen, sodass
diese beim speichern des neuen beleges, bzw. beim neu erstellen der positionen
erzeugt werden.
Folgende Szenarien geprüft:
Von Angebot:
-> erneuern                       i.O.
-> mittlere Position löschen      i.O.
-> als neu speichern              i.O.
-> Speichern, Löschen, neue Pos   i.O.
-> Angebot -> Auftrag             i.O.
Rücksprünge von:
-> Auftrag -> Angebot (quotation in io.pl!) i.O.
-> Lieferantenauftrag -> Verkaufsauftrag    i.O.
-> Lieferantenauftrag -> Lieferantenanfrage i.O.
-> Verkaufs-Rechnung -> Auftrag (keine orderitems vorhanden) i.O.

CustomerVendorPicker: ref($value) nur prüfen, wenn es tatsächlich ein Objekt ist

…und nicht schlicht die ID eines Objektes.

SL::DB::{Invoice,DeliveryOrder}: Items mit neg. qty beim Wandeln optional weglassen

Auth: nicht auskommentieren, sondern richtig dokumentieren

RecordLinks: credit_notes verlinken, und Typ von Rechnungen anzeigen

Layout: entfernte locales

Auth - experimentell: $::auth dbh wieder cachen.

Layout: Tests schlagen fehl, weil Top auf $::dispatcher zugreift

Layout Aufräumaktion:

- Admin und V3 Menü entflochten. Benutzen jetzt beide das neue CssMenu
  als sub_layout
- Top-Klone aus V3 und Javascript herausoperiert und als sub_layout
  eingebunden
- Neues Layout AdminLogin für die Loginmaske im Adminbereich (d'oh)
- Inputfelder im frame_header kleiner gemacht, Frickelfox ignoriert mal
  wieder css Vorgaben und inheritet font-size nicht.
- Beschreibung in Placeholder verschoben. Ja das ist html5. Benutz halt
  nicht IE6.
- javascript für Ansprechpartnersuche gefixt und ausgelagert.
- Login, Classic und V3 sind top level Layouts und brauchen nicht
  sub_layoutbar sein. Macht den Code einfacher.

LxERP.t8 ist kein filter.

analog zu Commit 445c84a3593

no lexical postif in DeliveryPlan.pm

test ausführen, nicht vergessen!!! @myself

HTML Templates für Buchungstab vergessen

LxERP.t8 ist kein filter.

Auth.pm: Rechte nur dann laden, wenn User & Client gesetzt sind

Seit f6ed86e wird im Menü-Template-Code auf Rechte
getestet (AUTH.assert(…)). Im User-Bereich ist das kein Problem, weil
die Menü-Templates nur dann benutzt werden, wenn tatsächlich ein User
angemeldet ist.

Im Admin-Bereich allerdings wird ebenfalls Menü-Code verwendet,
allerdings gibt es in dem Moment weder einen Client noch einen User. Der
Auth-Code muss damit klarkommen und in dem Fall schlicht »nicht
berechtigt« zurückliefern.

Auth.pm cosmetics: Entfernen von $::lxdebug->enter_sub/leave_sub

Tabreiter-Titel für Buchungsliste angepasst

damit der Übersetzungsparser damit zurechtkommt.

WebDAV Reiter - title als class statt h1

Buchungen in ar/ap/is/ir in eigenem Tabreiter anzeigen

Neuer Reiter "Buchungen", wo zu einer Rechnung/Buchung die Buchungen
laut acc_trans angezeigt werden.

In einer Tabelle "Buchungen" werden alle Buchungen laut acc_trans
angezeigt.

In einer Tabelle "Salden" werden die aktuellen Salden der bebuchten
Konten angezeigt, ausgeglichene Konten werden herausgefiltert.

Nicht für Dialogbuchungen umgesetzt.

Es wird auf das FiBu-Recht (general_ledger) geprüft, ansonsten wird der
Reiter nicht angezeigt

Typos in Doku/perlpod

Datum Schnelleingabe - changelog Eintrag

setTimeOut für schnelle Datumseinsgabe bei set_duedate

Die jquery-Abfrage des Datumsfeldes in set_duedate (Fälligkeitsdatum)
wird mit setTimeOut erst nach Ersetzen des Datums per schneller
Datumseingabe durchführen

Schnelle Datumseingabe ohne Trenner

Buchhalter sind es gewohnt, das Datum im Nummernblock ohne Punkte
eingeben zu können, z.B. wird aus
01122014 -> 01.12.2014

Mit diesem Patch wird im Datumsfeld noch vor der Prüfung auf ein gültiges
Datumsformat per Javascript geprüft, ob
* die Eingabe nur aus Zahlen besteht
* das Datumsformat dd.mm.yy, dd-mm-yy oder mm-dd-yy ist

Trifft dies zu, werden am Beispiel für den Fall dd.mm.yy folgende
Umwandlungen durchgeführt:

 8 Zahlen:   31122014  -> 31.12.2014
 6 Zahlen:   311214    -> 31.12.2014
 4 Zahlen:   3112      -> 31.12.2014   aktuelles Jahr wird angenommen
 1-2 Zahlen: 12        -> 31.10.2014   aktueller Monat wird angenommen
             7         -> 07.10.2014   aktueller Monat wird angenommen

Nach der Umwandlung findet wie bisher eine (simple) Plausibilitätsprüfung des
Datums per Javascript statt. Sollte das Datumsfeld andere Datumsfelder
beeinflussen, wie z.B. das Rechnungsdatum das Fälligkeitsdatum im Ein-
und Verkauf durch ein onChange, muß hier eventuell mit einem setTimeOut
gearbeitet werden, da ansonsten der Wert vor der Umwandlung genommen
wird.

FiBu Schellsuche in Headerzeile

neues Ajax Autocompletefeld im Header für Benutzer mit FiBu-Rechten,
welches Rechnungsnummern und Kunden-/Lieferantennamen durchsucht. Durch
die Auswahl im Dropdown gelangt man direkt zu dem Beleg.

Löschen von orderitems beim speichern von OE korrigiert.

Lieferplan: all_businesses in init-methode ausgelagert

<gorash> kurzes feedback zum lieferplan:
<gorash> in der action alle business laden: der ganze punkt an den init_* sachen ist, dass mand as laden von nötigen daten aus der action rauskriegt

Benutzerdefinierte Variablen via Trigger löschen Bugfix 2

Die Triggerfunktion selber sollte aus Performancegründen nicht »DELETE …
WHERE … IN (SELECT…)« nutzen, da dies bei PostgreSQL sehr langsam ist.

CVars-Lösch-Queries deutlich effizienter gestaltet

PostgreSQL kann Queries à la »DELETE … WHERE … IN (SELECT…)« nicht gut
optimieren und erzeugt dafür exponentielle Laufzeit. Viel schneller ist,
eine Vorselektierung mit normalen JOINs zu nutzen und nachher beim
DELETE ein WHERE EXIST (…) mit Bezug auf die zu löschende Tabelle
einzusetzen.

SL::CTI::sanitize_number: nur Ziffern zurückliefern

Syntax Typo in all

Übersetzungsspalte verbessert und Berechnungsfuntkion für stocked_qty in Lieferberichte

Übersetzungen für Lieferwertbericht

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

Lieferplan / Lieferwertbericht um Filter Bearbeiter erweitert

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

CustomerVendor: CVars bei Wechsel von Ansprechpersonen richtig befüllen

Lieferplan: Filter für Projektnummer und Kundentyp

Conflicts:

SL/Controller/DeliveryPlan.pm

CustomerVendor-Controller: Daten in Neu-Anzeige bei Fehler beibehalten

RDBO hat das Verhalten, dass bei einem neuen, noch nicht gespeicherten
Objekt die Methoden zum Hinzufügen von Relationship-Objekten (z.B. in
1:n-Beziehnungen wie $customer->add_contacts(…)) beim danach erfolgenden
Auslesen der Beziehung nicht zurückliefert. Das heißt, dass Folgendes
der Fall ist:

my $customer = SL::DB::Customer->new;
$customer->add_contacts(SL::DB::Contacts->new);
print scalar(@{ $customer->contacts || [] }); # Das hier gibt 0 aus

Existiert das Objekt hingegen schon, dann klappt das normal. Das Problem
kann man umgehen, indem man beim Anlegen des neuen Objektes die
Beziehungen explizit auf eine leere Array-Referenz setzt, damit der in
RDBO enthaltene Check an der Stelle greift.

Das betrifft den Workflow, wenn man Daten in den benutzerdefinierten
Variablen eingibt, auf Speichern drückt und kivitendo dann wegen eines
fehlgeschlagenen Checks die Maske erneut anzeigt.

Kunden/Lieferanten sind nicht verwaist, wenn es Lieferscheine gibt.

CustomerVendor-Presenter: croaken, wenn Parameter fehlen oder falsch sind