Revert "added roundings for periodic invoices"

This reverts commit 64b3d19a8012187c3c01717b91d59df2b2753ee3.

stricter filtering of posititions at erfolgsrechnung

added roundings for periodic invoices

Vergessene neue html-Dateien zu letztem Commit

Dokumentation-Erweiterung und -Anpasung CH-Modus, OpenDocument-Vorlagen

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

Rundung in den Verkaufsbelegen des Vorlagensatzes rev-odt ergänzt

BUG-Fix: FiBu/Dialogbuchungen: Steuerschlüssel nach Öffnen falsch

Nachdem eine Dialogbuchung mit dem Steuerschlüssel "USt-frei 0%" gebucht und geschlossen wurde,
wird nach dem öffnen derselben Buchung der Steuerschlüssel auf "Keine Steuer 0%" gesetzt.

Zum Einen wird hier nach den Schlüsseln gesucht, sondern 0 als Schlüssel angenommen.
Wie 2013 in Commit 0f8092f8 begonnen, ist die tax_id nicht zwingend 0.
Ebenso mus die txa_id für "USt-frei 0%"  berücksichtigt werden sowie auch die EU.
Also nur dort berechnen wo Rate != 0 , derzeit bei taxkey 0,1,10 und 11

Zudem war bei der Vorauswahl der Steuer, die steuerfreien Namen nur mit zwei statt 5 Stellen hinter dem Komma,
d.h. es wurde keine Steuer vorselektiert, also dann der erste Eintrag "Keine Steuer 0%"

Vendor/Customer Name in FlattenToForm setzen

In For.pm wird bei der Druckvorbereitung Customer-/Vendorname gesetzt.
Damit z.B. bei Massendruck oder neuen Controllern diese Variable auch
zur Verfügung stehen werden sie , falls die Objekte vorhanden in die Form geladen

Sprachanpassungen Erfolgsrechnung, GUV und BWA

BankTransaction: Filter aus letztem Commit auch nicht vorbelegen

BankTransactions: Lieferantenfilter nicht benutzen, wenn...

kein fremder Konteninhaber existiert. Ansonsten wird da einfach nach
einem zufälligen Vendor gefiltert der kein Konto hat.

BUG-Fix: Kreditorenbuchungen: Steuer inklusive wird nicht übernommen

Debitoren- und Kreditorenbuchungen in Fremdwährung öffnen

Bisher wurde zwar der Buchungsbetrag anhand des Wechselkurse
umgerechnet, nicht aber die Steuer (sofern vorhanden), hierfür mußte man
erst erneuern.

BUG-Fix: Kreditorenbuchungen: Währung wird nicht übernommen

Es werden IMMER die Währungeinstellungen vom Lieferanten genommen.
Die Variable currency wird beim Holen der Lieferanten-Daten überschrieben.
Den Variablen-Wert vor dem Holen der Stammdaten sichern und danach
zurückschreiben.

Bugfix #182: Auftrag aus Rechnung erstellen

Ticket #182 behoben, + Kommentare.

am: fehlendes include für Historiensuche

Finanzübersicht: Neue Spalte »Kosten« analog zu BWA-Kosten

Anpassungen im CH-Kontenplan und CH-Kontenzuordnung

.mailmap update - Martin mag multiple Mailadressen.

Farben für Kontoauszug verbuchen auch im lx-office-erp.css

Alles trist und grau. Schade, schade, schade ...
Nun nicht mehr, auch für andere kivi-Freunde gibt es jetzt
Kontovorschläge in grün und orange!

lx-office-erp.css: proportionale font-sizes

Firefox 47 ignoriert unter unity7 font-size in select komplett,
ausserdem haben wir seit ewigkeiten das problem dass td { font-size: 8pt
} alle spacings kaputtmacht. Das hier entfernt das experimentell.

Kontoauszug verbuchen - Punktesystem sichtbar machen

Super Codierung und unsichtbar für alle anderen.
Punktevergabe wird jetzt offen angezeigt und mittels ToolTip
kann hier jeder sehen warum welche Zuordnungen passieren und selber
tüfteln (a la spamassassin rule set).

Nur die eigene Rechnungsnummer mit höheren Punkten versehen ...

... bei Lieferantenrechnungen weniger Punkte vergeben, aber mit
derselben Unschärfe wie bei Verkaufsrechnungen arbeiten.

Conflicts:
SL/DB/BankTransaction.pm

Kontoauszug verbuchen -> Buchung erstellen -> Lieferanten-Filter verbessern

Falls in dem Datenmodell Drafts.pm, Dialogbuchungen vorhanden sind,
stürzt die Filterfunktion einfach ohne Rückmeldung ab und macht nichts weiter.
Sinnvollerweise nur Ergebnisse filtern, die auch eine vendor_id im Draft haben.

new settings balance, datev, erfolgsrechnung, eurechnung, ustva to client-features

CsvImport::BankTransaction: currency als info spalte anzeigen

CsvImport::Base: benutzte header korrekt setzen

Csv: mappings übersetzen jetzt auch header

Helper::Csv: is_known in dispatcher gefixt

CsvImport: leere Mappings schon beim Einlesen überspringen

JSON::from_json nicht auf decode mappen

CsvImport Mapping: header mit helper parsen

sonst gibt es wieder die gleichen Probleme mit UTF-BOM

added missing numberformat in java-script

added roundings on prints

preferences to client-features managed

featured menu-items visible/unvisible

featured form-objects visible/unvisible

CVar: Flags immer vorhanden

CsvImport: Spaltenzuordnung für non multiplexed

Csv: mapping support

Csv: Doku-Update vor mapping feature

FlattenToForm: Information, ob das item ein Erzeugnis ist, berücksichtigen.

Damit klappt das Drucken mit Stücklisten-Information im neuen
Auftrags-Controller, beim Massenrechnungsdruck und beim autom. Drucken
wiederkehrender Rechnungen.

Hintergrundjob periodische Rechnungen: bei Fehlern Fehlermeldungen ausgeben, …

… nicht die Anzahl der Fehler.

CreatePDF-Helper: template_meta{tmpfile} setzen (jetzt aber mit Wirkung)

f-tex verwendet diese Variable z.B. und kann ohne diese kein PDF erzeugen.

Hatte die Änderung im commit eben dummerweise auskommentiert.

CreatePDF-Helper: template_meta{tmpfile} setzen.

f-tex verwendet diese Variable z.B. und kann ohne diese kein PDF erzeugen.

Zahlungsbedingungen: <%payment_(terms|options)%> werden nicht ersetzt

Refactoring: BankTransaction

minimalen aufgeräumt. Alte Copy&Paste doppelte Checks
an der Stelle entfernt, die ich gelesen und verstanden habe.

BankTransactions GUI Hotfix Verbesserung

Wenn man über die Liste aller Rechnung jetzt auch den
zu verbuchenden Betrag als Hilfestellung angezeigt bekommt, muss dieser
entsprechend konsequent auch bei dem einfachen AJAX-Anklicken
angezeigt werden.

Bankauszug verbuchen invoice_amount vor pay-invoice

Die Reihenfolge der Verarbeitung des Bankausszugs ist jetzt
wichtig. Vorher wurde einfach der Betrag der gesamten Rechnung
abgezogen, jetzt ist es nur noch der offene Betrag, der nach
der Zahlungsverbuchung dann auf 0 ist. Deshalb vorher ...

Feature Kontoauszug verbuchen - nur maximal offene Beträge

amount_open -> open_amount - richtige Helper-Funktion aufrufen

Keine Rechnungen mit Bankauszug verbuchen überbezahlen

Changelog für Änderungen für Kontoauszug verbuchen

inkl. Übersetzung

Verbesserung Visualisierung Bankverbuchen

Ein HTML-Tag zuviel.
open_amount aus SL/DB/Helper/Payments.pm nehmen
anstatt die DB/Invoice.pm unnötigerweise zu erweitern.

bessere visuelle Kontrolle über Bankauszug verbuchen

Der Betrag, der wirklich zugeordnet wird, wird in der GUI angezeigt.
Ferner Berechnungen aus den Templates ausgelagert.

Dokumentation aktualisiert.

Nein, Postgres 8.4 wird NICHT mehr unterstützt.
Auch nicht für Downgrade-Meister aus Zürich.
Nein.
Nein.
Nein. ;-)

vendornotes auch als notes Form Variable

Wie in SL/IS.pm ( c0ed7d2fa ) werden hier die notes doppelt zurückgegeben.

fixup durch löschen von notes vor kopieren

Auch hier kann es passieren dass die notes von Dokumenten z.B. Rechnung durch die
notes des Lieferanten (Kunden) in den Forms-Variablen überschrieben werden,
dann beim Drucken der falsche Text in der (LateX) Rechnung landet.

SelfTests: Weitere Randfälle zumindestens in der Analyse-Ausgabe erwähnen

Hintergrund: Steuerschlüssel können auch bei Zahlungskonten vorhanden sein,
damit wäre eine Verknüpfung mit einer Netto-Rechnung auch nicht sinnvoll.

customernotes auch als notes Form Variable(fixmaster)

Durch den query ct.* werden die notes und per ct.notes as customernotes eingelesen

fixup durch löschen von notes vor kopieren

Einkaufsstornos auch verknüpfen

Analog zur Verkaufs-Ansicht auch die Einkaufsrechnungen bei
Stornos verknüpfn

Verkauf Storno-Rechnungen auch verknüpfen

Ähnlich wie bei Gutschriften sollten Stornorechnungen auch mit
der Ursprungsrechnung verknüpft sein. closes #132

Presenter/Part: Type in Doku.

Order: Doku: weniger Bugs. Typo.

Kosmetik/Lesbarkeit

Ein klares delete statt ein kompliziertes map mit delete.

Order: Mehr Bugs

Order: und nochmal header nach oben

Order: <h1> statt <div class=listtop> für einheitliches spacing

Order: mehr fehlende Sachen in Doku ergänzt

Order: javascript Kleinigkeiten

Order: POD aufgeräumt, reformatiert, Bugs notiert.

Order: Überflüssige Includes entfernt

Weitere Änderungen für den revert von 7735019
Damit ist das Ticket #144 erledigt.

Revert "Ticket 29 Verknüpfte Belege -> keine Verknüpfung von Rechnung nach Auftrag"

This reverts commit 77350196300e930abc7de0df7dbf42e8cd6193b8.

Conflicts:
SL/OE.pm

Auftrags-Controller: Doku und Kommentare

Vergessene hidden Abteilung für FiBu->Berichte->Offene Forderungen/Verbindlichkeiten

neue Vorlagen mit Schweizer Bank-Einzahlungsscheinen mit OpenDocument-Makro

CsvImport: Aufträge: Fallback Lieferbedingungen auf die vom Kunden/Lieferanten.

Setzt die Lieferbedingungen auf die des Kunden oder Lieferanten des Auftrags,
falls in der CSV-Datei keine Lieferbedingungen angegeben sind.

Partpicker styling

- Lupe jetzt inline
- Lupe in svg, kann also mitskalieren
- Inputfeld ist jetzt Model padding-box, size Angaben propagieren besser
  auf die umliegenden Elemente
- getestet in lx-office-erp und kivitendo css

generic_translations: DB-Upgrade in Perl geschrieben wg. Constraint-Namen

In alten PostgreSQL-Versionen hießen Foreign-Key-Constraints oft noch so
was wie »$1«. Da sich das Upgrade-Script also bzgl. des Namens nicht
sicher sein kann, gibt's momentan nur die Möglichkeit, einmal alle
Foreign-Keys zu einer Tabelle wegzuwerfen und diese neu anzulegen.

Dafür wiederum haben wir Support-Funktionen in SL::DBUpgrade2::Base, die
wie nutzen können. Also Umstellung des Scripts auf Perl.

PriceSource: doku update

Mehrere Anforderungen die sich über die Zeit gesammelt haben

Artikelstammdaten: Verkaufspreisänderungen nicht mehr an Erzeugnisse propagieren

changelog-Update zu Zahlungsbedingungen

FlattenToForm: Zahlungsbedingungen des Kunden/Lieferanten nicht kopieren

Es haben die ZB des Beleges zu gelten, nicht die des
Kunden/Lieferanten. Die Variable »payment_terms« wird zwar später wieder
anhand von »payment_id« überschrieben (in »OE::order_details« und dann
»Form::set_payment_options«), aber nur dann, wenn im Beleg auch wirklich
Zahlungsbedingungen ausgewählt sind.

Sind keine ausgewählt, so würde das »payment_terms« von den Kunden-/
Lieferantenstammdaten gesetzt bleiben; das wäre schlicht inkorrekt.

DO.pm: wo croak() genutzt wird auch Carp usen

generic_translations: Einträge automatisch löschen, wenn Sprache gelöscht wird

Zahlungsbedingungen: Unterscheidung zwischen Angeboten/Aufträgen und Rechnungen

Dies führt ein neues Attribut »payment_terms.description_long_invoice«
und dazugehörige Übersetzungen in »generic_translation« ein.

Die Druckvariable »payment_terms« wird nun in Abhängigkeit vom
auszudruckenden Beleg gesetzt:

1. Für Verkaufsrechnungen wird zuerst eine Übersetzung von
   »description_long_invoice« für die ausgewählte Sprache gesucht. Falls
   die leer ist oder keine Sprache ausgewählt, so wird die nicht
   übersetzte »description_long_invoice« genommen. Ist auch die leer, so
   erfolgt ein Fallback auf 2.

2. Für alle anderen Belege oder falls bei 1. nichts heraus gekommen ist,
   wird wie vor dieser Änderung eine Übersetzung von »description_long«
   für die ausgewählte Sprache gesucht. Falls die leer ist oder keine
   Sprache ausgewählt, so wird die nicht übersetzte »description_long«
   genommen.

Preisquellen: Darstellung Lieferrantenrabatt gefixt

analog zu: 5f6e919f09cdbeeac184a138d62586d055e9ee0f
"Preisquellen: Darstellung Kundenpreise gefixt"

locales: Update

Verkaufspreisinformationen: Preisentwicklung der Stammdaten anzeigen

Verkaufspreisinformationen: Typfilter in der Überschrift anzeigen

Dadurch wird auf einen Blick etwas klarer, was die Tabelle anzeigt.

Verkaufspreisinformationen: »Seite:« nicht anzeigen, wenn es nur eine gibt

In dem Fall ist $self->{pages}{cur} 0 oder undef und nicht 1.

Typos in Doku

Typos

Typo in Doku

Recnungen: action nicht in die hiddens schreiben aber id setzen

Jetzt wird ein Schuh draus, Javascript braucht bei OD die #action

Preisquellen: Darstellung Kundenpreise gefixt

Rechnungen: resubmit dispatching gefixt

Rechnungen: action nicht in die hiddens schreiben

Fix für das doppel-action Problem

Revert "Rechnungsmasken auf dispatcher Mechanismus (fixmaster)"

This reverts commit b48c9c84b3b070011b50ae41216c3903a369f661.

Das sollte genau andersrum gefixt werden.

Einkaufsrechnungen: Suche nach Artikelnummer/-beschreibung in Positionen(2)

BUGfix für substr($where, 0, 4, " WHERE "):
$where muss am Anfang innerhalb 4 Zeichen das AND stehen haben,
sonst kommt es zu einem SQL Syntaxerror