Fehler beim Öffnen von Konten behoben

Jedes Konto hat einen taxkey Eintrag, aber es gibt nicht immer ein
Steuerautomatikkonto.

TopQuickSearch: Auftrag, Angebot, Lieferauftrag, Preisanfrage

oe.pl: Schnellsuche analog zu all:substr:multi::ilike

Typos und spellcheck.t

TopQuickSearch: Doku

TopQuickSearch: Konfiguration in client_config

TopQuickSearch: qw() -> liste, zum einfachen auskommentieren

TopQuickSearch: locales aufgeräumt, debug entfernt

TopQuickSearch: Alle Part Varianten for free

TopQuickSearch: GL controller kann weg

TopQuickSearch: javascript jshint

TopQuickSearch: zwei nicht mehr benötigte javascripte

TopQuickSearch: erste version

Erzeugnissuche

warnings: besseres sanitizing in Form::calculate_tax

Form::round_amount: nicht initialisierte Variable $places

warnings: nicht initialisierte Variable in Helper/Sorted

warnings: nicht initialisierte Variable in Helper/Payment

warnings: diverse nicht initialisierte hash keys in CsvImport

CsvImport/ARTransactions: fehlerhafter check auf undefinierte tax_id

warnings: SL::Controller::CsvImport::num_imported auf 0 initalisieren

Typo: Englische locales waren kaputtgegangen

Beschriftung im Lieferwertbericht korrigiert

Konteneinstellungen - richtiges Konto in ACCOUNT_TAXKEYS

Ging beim Refactorn im letzten Commit kaputt. Wird accno überhaupt
benutzt?

Konten neu anlegen repariert

get_account wurde nicht nur für das Laden bestehender Konten verwendet,
sondern auch für das Füllen von anderen form-Variablen, z.B. für
Steuerschlüssel.
Bei der Gelegenheit auch etwas Rose geübt und refactored.

Erfolgsrechnung: Korrekte Beschriftung in Kontenmasken

UPGRADE aktualisiert

Erfolgsrechnung aus Menü entfernt

Typo-Fehler in Ausgabe gefixt

ein typischer richardson-commit

Typos in Doku

Ausgabe der Dokumentation aktualisiert (mosus änderungen)

MetaSetup AuthSessionContent

MetaSetup Default whitespace

changelog: Memory-Limits

Dokumentation: Update Instruktionen für openSUSE, Fedora

Changelog - mehr Änderungen nachgetragen

Changelog - Task-Server ist nun mandantenfähig

SQL release Upgrade Skripte für 3.4.0

changelog - ein bugfix mehr

Bugfixes im changelog aktualisiert

Auftrags-Controller: changelog

Auftrags-Controller: Link zum neuen Controller aus Auftragsliste (zum Testen).

Auftrags-Controller: Menüeinträge

Auftrags-Controller: POD - hauptsächlich Todos

Auftrags-Controller: unbenutzte action "update" entfernt.

Auftrags-Controller: Warnung beim Speichern mit doppelten Artikeln.

In der Mandantenkonfiguration (Features) abschaltbar.

Auftrags-Controller: javascript-Code in eigene Datei auslagern

Auftrags-Controller: event bindings nicht mehrfach hinzufügen.

Dazu event handler für die Positions-Zeilen mit run_once_for registrieren und
in eine eigene Funktion init_row_handlers() ausgelagert. Damit kann
init_row_handlers() gefahrlos immer nach dem Hinzufügen neuer Positionen
aufgerufen werden, ohne einen Handler mehrmals zu registrieren.

Auftrags-Controller: Preisfaktor berücksichtigen

Auftrags-Controller: Mehrfach-Artikelauswahl: Verbesserungen

- ungültige Artikel nicht anzeigen.
- Artikel nicht mehrfach hinzufügen, wenn ausversehen mehrfach Enter gedrückt
  oder der Weiter-Knopf mehrfach angeklickt wird.

Auftrags-Controller: Verknüpfte Belege als Tab

Auftrags-Controller: Druck-Möglichkeit mit Options

Todos/Anmerkungen
- im Moment werden nur PDF/Bildschirm und PDF/Drucker unterstützt
- Sprache kann die Vorlage steuern, aber nicht das Hinzufügen von übersetzten
  Artikeln
- es kann sicher noch mehr ausgelagert werden, entweder in den
  PrintOptions-Helper oder in einen PrintOptions-Controller, der
  dann auch noch mehr machen könnte
- E-Mail ist nicht berücksichtigt bzw. wird im Controller getrennt behandelt

Auftrags-Controller: serializeArray und push statt serialize und += auf Strings

Auftrags-Controller: longdescription

Auftrags-Controller: Sortieren der Positionen

Auftrags-Controller: Positions-Spalte anzeigen und renummerieren bei Änderungen.

Auftrags-Controller: Preis und Rabatt immer rechtsbündig.

Auftrags-Controller: vorhandene orderitems vor Neu-Schreiben nicht löschen …

Hintergrund: Wird einem Rose-Object eine Relationship als Array übergeben (z.B.
$order->orderitems(@items), so löscht Rose dei DB-Einträge und schreibt sie neu.
In dem Fall werden allerdings auch DB-Trigger ausgelöst, was hier zum
unerwünschten Löschen der record_links auf item-Ebene führte.
Hier wurden die items via assign_attributes als ganzes dem Order-Objekt
hinzugefügt.

Jetzt werden die items einzeln hinzugefügt, wenn sie neu sind und die
vorhandenen, die aus der Makse entfernt wurde, werden extra gelöscht.

Auftrags-Controller: Einheiten per Select ändern können und sellprice anpassen.

Auftrags-Controller: Mehrfach-Artikelauswahl mit Mengeneingabe.

Auftrags-Controller: Webdav

Auftrags-Controller: Abteilungen

Auftrags-Controller: Liefertermin

Auftrags-Controller: Projektauswahl mit Picker (und Eingabefeld nach links).

Auftrags-Controller: PriceSources

Auftrags-Controller: Menge nach der Eingabe neu formatieren.

Auftrags-Controller: css-Klasse: reformat_number zum Neuformatieren von Zahlen

Auftrags-Controller: auch bei geladenen Positionen die ID übergeben.

Auftrags-Controller: Funktion "Speichern und Lieferschein".

Auftrags-Controller: Drucken und E-Mail

Auftrags-Controller: Option für "Steuer im Preis inbegriffen"

Auftrags-Controller: Bemerkungen und interne Bemerkungen

Auftrags-Controller: Zahlungs- und Lieferbedingungen

Auftrags-Controller: Angebotsnummer und Erfassungsdatum mit in die Maske.

Auftrags-Controller: Auftrag löschen können.

Auftrags-Controller: neue Eingabemakse für Aufträge basierend auf Controller

kivi.SalesPurchase.edit_longdescription: callback zum Setzen der Beschreibung angeben können

kivi.SalesPurchase.edit_longdescription: Aufruf auch mit einzelnen Parametern …

ermöglichen, statt mit row. Dafür gibt es eine zweite Funktion "..._with_params.
Diese wird jetzt von kivi.SalesPurchase.edit_longdescription(row) aufgerufen,
damit in den vorhandenen Templates nicht angepasst werden muss.

Test zu SL::Request::unflatten, der prüft, ob nicht Hash-Keys erzeugt werden.

Nicht, dass in einem Array aus Hashes key in einem Hash auftauchen, die nur in
einem anderen drin sind.

FlattenToForm - auch customer_id oder vendor_id übergeben

Dies wird vom neuen OrderController beim Umwandeln in einen Lieferschein
gebraucht, wo nach einem flatten_to_form auf $order delivery_order
aufgerufen wird, wo anhand customer_id oder vendor_id der Kunden geladen
wird.

all für de geändert

Dokumentation für 3.4 angepasst

Besseres kivi-Bild

Versionsnummer angepasst

Selftest Transaction - Syntaxfehler entfernt

SelfTest - bessere Fehlerbehandlung für Einbinden der Test-Module

Fehlermeldung an den TaskServer zurückgeben.
Fehlermeldung(en) in der Status-E-Mail hinzufügen.

SelfTests falscher Zeitraum für Standard-Tests

Selftests konsequent auf fromdate -> todate umgestellt

Ferner Kosmetik von hässlichen SQL Formatierungen

Korrekturen im Hauptbuch verbessert

Prüfung auf Steuerschlüssel nur bei Bestandsmethode

whitespace cleanup

Payment Helper setzt $self->transactions zurück

Als es noch eine Methode transactions in SL::DB::Helper::Payment gab
wurden die acc_trans-Einträge bei Zugriff per $self->transactions jedes
Mal aus der Datenbank ausgelesen:
(SL::DB::Manager::AccTransaction->get_all(query => [ trans_id => $self->id ]);

Seit Commit 01b298ec3 wird stattdessen der aktuelle relationship Array
verwendet, wenn die transactions noch nicht ausgelesen wurden werden sie
wie oben geladen, wenn sie aber schon existieren dann werden die
Transaktionen im Speicher benutzt.

Bei den Tests gab es aber das Problem, daß in pay_invoice die
acc_trans-Einträge der Zahlungen als AccTrans-Objekte unabhängig vom
Rechnungsobjekt gespeichert wurden, und der transaction Array daher
nicht aktualisiert wurde. Am Ende von pay_invoice wird nun per
forget_related der transaction-Array zurückgesetzt, damit bei der
nächsten Verwendung die aktuell gespeicherten Transaktionen nachgeladen
werden.

4. Überarbeitung Prüfen beim Speichern, ob Dokument geändert ist(3)

In der Ruhe liegt die Kraft.
Jetzt sind die Zeilen in den storno-Funktionen wieder eingebaut

DeliveryPlan: Entfernt Einstellung, um nur ausgelagerte Lieferscheine zu berücksichtigen.

Diese Option lieferte hier ungenaue Ergebnisse, da dennoch auch Positionen
angezeigt wurden, für die überhaupt kein Lieferschein erstellt wurde.

Übersetzungen zu: "DeliveryPlan: optional auch mit verlinkten Positionen suchen."

DeliveryPlan: optional auch mit verlinkten Positionen suchen.

Pflichtenheft: keine Fehlermeldung »template not found« bei Click auf »Abschnitte«

Neue Chart Methode new_chart_valid

die prüft, ob es für das Konto ein Folgekonto gibt, und ob das aktuelle
Tagesdatum >= dem Folgedatum ist, d.h. ob eigentlich das Folgekonto
benutzt werden soll. Diese Abfrage war bisher allerdings kaputt und wird
wahrscheinlich auch nirgends sinnvoll genutzt.

Refactoring von orphaned in AM get_account

SL::DB::Chart - Refactoring der Transaktionsmethoden

... der Methoden number_of_transactions und has_transaction.
Machen fast das Gleiche, aber has_transaction liefert nur 0 oder 1
zurück, und ist schneller.

Debitorenbuchungen als CSV importieren

Ähnlich wie der Auftragsimport wird hier gemultiplexed, d.h. es gibt separate
Zeilen für die Debitorenbuchung (ar) und die Buchungszeilen (acc_trans).

Es handelt sich allerdings nicht exakt um acc_trans-Zeilen, die direkt
als acc_trans Objekte importiert werden, sondern es können die gleichen
Informationen wie bei der Debitorenbuchung übergeben werden, also Konto,
Betrag, Steuerschlüssel und Projekt, und daraus werden dann die
acc_trans-Zeilen generiert, inklusive Steuerautomatik.

Das Forderungskonto muß in der Rechnungszeile übergeben werden, der Betrag wird
dann anhand der Buchungszeilen bestimmt.

Beispiel für Import-Format (siehe auch mehr Beispiele in t/controllers/csvimport/artransactions.t)

datatype,customer_id,taxzone_id,currency_id,invnumber,taxincluded,archart
datatype,accno,amount,taxkey
"Rechnung",960,4,1,"invoice",f,1400
"AccTransaction",8400,159.48,3