Lieferplan-Bericht um Berichts-Feld "ausgelagerte Menge" erweitert

Der Lieferplan berechnet aktuell die "verschickte" Menge der Waren
aus der Menge der generierten Lieferschein, beachtet aber nicht den
tatsächlichen Status des Lieferscheins (ausgelagert oder nicht).
Entsprechend ein Extra-Feld in dem Bericht hinzugefügt, dass diese
Untermenge der Lieferscheine (Status ausgelagert) berücksichtigt.
Nur teilweise ausgelagerte Lieferscheine werden NICHT berücksichtigt.
 -> technischer Hintergrund: keine Verknüpfung mit inventory
Die "große" UNION-Query (sub delivery_plan_query) musste nicht angefasst werden,
da der Filter über "offene Verkaufsaufträge" geht. Verkaufsaufträge werden aber
erst dann geschlossen wenn alle Menge in der Verkaufsrechnung verbucht
worden sind und NICHT wenn alle Mengen in den Lieferscheinen (unabhängig
 vom Status 'ausgelagert') verbucht / geschrieben wurden.
Merge branch 'master' of github.com:kivitendo/kivitendo-erp
Erweiterung Lieferplan Belege wirklich ausgelagert und Warenverkaufswert (default: aus)

Erweiterung Mandantenkonfiguration im Bereich Lager zum Einschalten von
a) Warenverkaufswert
Falls aktiviert erscheint eine neue Spalte im Lieferplan, die den Wert der
ausgeliefert Waren angibt. Berechnungen mit sellprice sind in der kivi immer
hakelig. Hier die getesten Fälle:
 - Rabatt       i.O.
 - Preisfaktor  i.O.
 - Steuer im Preis inbegriffen (eine Warnung wird generiert).

b) Lieferplan berücksichtigt die tatsächlich ausgelagerten Lieferscheine
Falls der Firmenprozess zwei Rollen vorgibt (Lieferschein-Ersteller und
Lieferschein-Auslagerer), konnte dies mit dem vorhanden Bericht nicht klar
eingesehen werden. Entsprechend werden bei dieser Funktion nur die tatsächlich
ausgelagerten Lieferscheine berücksichtigt. Achtung: Teilausgelagerte Belege
werden nicht berücksichtigt (keine verknüpfung mit tabelle inventory)
Hintergrundjob: Link zum Verlauf anzeigen
Einkaufs-Lieferplan

Lieferplan für noch nicht vollständig gelieferte Einkaufsaufträge.
Merge branch 'master' of github.com:kivitendo/kivitendo-erp
Verbesserungen Einkaufs-Lieferplan

a) keinen Fallunterschied für $vc im Template, sondern ein einfaches hidden flag vc
b) kein copy & paste von action_list(_ap), sondern parameter in erp.ini
c) performanteres grep, statt foreach in OrderItem (Details s.a. devel-liste)
d) my $vc nicht als statische Klassenvariable gesetzt
e) CSV-Export für beide Fälle richtig (filter vc übergeben)
DeliveryPlan - kleinere Details verbesert
a) SQL-sanitize $vc param
b) Syntaxfehler in Template
c) SELF.vc leicht sinnvoller als nur $vc
d) Column defs mit visible an- und ausschalten, bzw. hotfix für heute
JavaScript & Templates in UTF-8 speichern

…und nicht in ISO-8859-*
locales.pl: nur auf .js oder .html endende Files nach JavaScript-t8() scannen

Ansonsten werden alle Dateien in den js-Unterverzeichnis gescannt, und
hier liegen u.a. Bilder (JPGs), Stylesheets etc.
locales.pl: Quelldateien mit Encoding UTF-8 lesen

Das erlaubt die Verwendung von Unicode in HTML-Templates,
Perl-/JavaScript- und Menü-Dateien, sodass die auch vom Locale-System
richtig durchgereicht werden.
Rundung bei Debitorenbuchung, Kreditorenbuchung und Dialogbuchung

Zwei neue Hilfsfunktionen für Form eingeführt die von ap/ar/gl genutzt
werden:

* calculate_tax wird zur Berechnung der Steuer bei
** update in ar, ap und gl
** post_transaction in AR.pm und AP.pm innerhalb von calculate_arap

* calculate_arap berechnet netamount, amount und totaltax anhand einer
vorhandenen $form in ar/ap, und formatiert und rundet die amount_$i and
tax_$i in der $form.

Das Ziel war es, daß diese drei Belege mit den gleichen Formeln zur
Steuerberechnung bei Steuer inkl./exkl. arbeiten. Ein Vorteil im
Vergleich zur Einkaufs- und Verkaufsrechnung ist, daß es hier keine
Positionen/Mengen/Rabatte/etc gibt, sondern direkt Werte auf Konten
bebucht werden, man muß nur Währungskurse berücksichtigen und beim
Schreiben in die Datenbank auf die Vorzeichen achten. Einkaufs- und
Verkaufsrechnungen werden hiervon nicht beeinflußt.

Vor allem bei der Einstellung "MwSt. inkl" wird die Steuer nun immer auf
zwei Stellen gerundet in die Datenbank geschrieben, und nicht (wie
bisher in manchen Fällen) mit 5 Nachkommastellen, was zu mehreren Bugs
geführt hat.

Es gibt einen neuen Test t/form/arap.t der die Berechnungen dieser
beiden Funktionen testet, nicht aber das eigentliche Buchen der Belege.

Mit diesem Commit sollten für zukünftige Buchungen folgende Bugs behoben
sein:

1691 - Rundung bei Berichten bei Buchungen mit MwSt inkl.
2029 - Rundungsfehler bei Dialogbuchung
2033 - Unterschiede in Rundungen durch taxincluded
2094 - Rundungsprobleme in Kreditorenbuchungen: Cent "kippt" bei Zahlungseinbuchung
2435 - Rundungsfehler in Kreditorenbuchungen (Netto vs. Brutto)

Dieser Commit greift in die Eingeweide von Uraltcode ein, wo die
diversen Stellen alle mal mit copy&paste entstanden und dann langsam
divergiert sind, hat also hohes Fehlerpotential. Es lohnt sich, den
DATEV-Check anzuschalten.
Bei Fehler LaTeX Tempfiles als UTF8 einlesen

Dadurch können Unicode-Zeichen, die in der .tex Datei Fehler
verursachen, dem Benutzer an der Oberfläche besser angezeigt werden.
Standard-Auslager-Verfahren verbessert (Dienstleistungen)

a) Falls Dienstleistungen nicht per Standardverfahren
   ein- oder ausgelagert werden sollen, entsprechend NICHT auslagern.
  Meine erste Idee, einfach die Menge auf 0 zu setzen funktioniert nur dann,
  wenn auch ein Standardlagerplatz für die Dienstleistung oder Mandanten gesetzt ist.
  Ferner wird dann eine Lagerbewegung mit der Menge 0 noch in inventory gemacht.
  Folgende Ergänzungen: a) Menge auf 0, b) delete für Prüfung auf "Mengen-Hash" (qty)
  c) ein undef Element in dem Array all_requests hinzugefügt, sodass DO.pm (unpack_stock_info)
  in demselben Format die Daten empfängt wie beim manuellen Auslagern, wenn eine Position nicht
  per Fragezeichen ausgelagert wird.
b) Ergänzung ob beim Einlagern per Standard-Einlagern ein Standard-Lagerplatz für
  die Ware / Dienstleistung gesetzt ist, anstatt der Ausgabe eines SQL-Fehlers

Testfälle für a)

Notwendige Bedingung: Auslagern über Standardlagerplatz aktiviert

                          Verkauf      |    Einkauf
A Dienstleistung                       |
NICHT automatisch            i.O.      |      i.O.
ein- oder auslagern                    |
-------------------------------------------------------------
B Leere Position (QTY == 0)  i.O.      |      i.O.
Verbesserung Standardauslagern für den Fall Dienstleistung ist nicht lagerbar

Kein undef an SL/DO.pm übergeben, sondern die richtigen Position zum
Einlagern durch eine "schlauere" Schleife machen.
Falls eine Position die NICHT ein-, bzw. ausgelagert werden soll, schon
belegt wurde (per Benutzereingabe). Diese auch dann löschen, da ansonsten
Beleg ne Lager (Hinweis von Sven)
Doppelte if-Abfrage entfernt

zum Commit von gerade: unnötig zweimal auf $qty zu prüfen
Verbesserung Standard-Auslagern

a) Überprüfung auf negative Eingabe des Benutzers (hier wird beim
    manuellen Auslagern keine Lager-Bewegung durchgeführt).

b) Löschen von bisher eingetragenene Mengen innerhalb der einzelnen
  Positionen (für den Fall Dienstleistung nicht ein- oder auslagern).
  Falls das ein Benutzer so eingibt
Pflichtenhefte: Funktion Abschnitte/Funktionsblöcke neu nummerieren
Pflichtenhefte vordef Textblöcke: überflüssige Tags entfernt
Pflichtenhefte vordef Textblöcke: Verwaltung Flags »benutzbar für…«