dbconnect_noauto entfernt

User: Kommentare entfernt

CsvImport/Base: single-dbh

Achtung: der hier schreibt ein for {} continue um in deutlich
komplexeres Offset Handling. Muss extra getestet werden.

Form: single-dbh (partiell)

standard_dbh->rollback fehlt noch

CustomVariableConfig: single-dbh

CsvImport: mehr single-dbh

CsvImport/Base: single-dbh

CsvImport: single-dbh

CsvReport: single-dbh

TransNumber: single-dbh

meerge: IO: single-dbh return

RecordLinks: single-dbh

IO: single-dbh

common.pl: single-dbh

Common: single-dbh

ARAP: single-dbh

CVar: single-dbh

GenericTranslations: single-dbh

AM: single-dbh und disconnects

AccTransCorrections: single-dbh

FU: single-dbh

SEPA: single-dbh

Notes: single-dbh

DATEV: single-dbh

TODO: single-dbh

DN: single-dbh und disconnects

SL:: single-dbh und disconnects

CP: single-dbh

GL: single-dbh

AP: single-dbh

AR: single-dbh

IR: single-dbh

IS: single-dbh

DO: single-dbh

OE: single-dbh

IC: single-dbh für delete und update_prices

IC: Umstellung IC::save auf single dbh

Nur noch ein DB-Hanlde pro Request zum Client aufmachen

Auftrags-Controller: lastcost nur vom Artikel nehmen, wenn die Position neu ist

Ansonsten werden die EKs von schon in der DB gespeicherten Aufträgen immer mit
denen des Artikels überschrieben.

siehe auch commit 370d43e2028e8a450055048f1354da48163d3954
"Order Controller - lastcost von Positionen mit speichern"
und refs #201 (redmine)

Kreditoren- und Debitorenbuchung: Erneuern per JS bei Wechsel des Beleg-Projekts

behebt #207 (redmine)

BUG_FIX Userpreferences

Falls keine Id vorhanden muss ein insert gemacht werden

Fehlende impliziten Übersetzungen für Zahlungsart

Wird in bank_transfer_edit gebraucht

CSV-Import Artikel: Einige Erweiterungen

CSV-Import von Artikel hat nun für existierende Artikel folgende Optionen:

     1. Eigenschaften von existierenden Einträgen aktualisieren
     2. Eigenschaften von existierenden Artikeln aktualisieren / Nicht vorhandene überspringen
     3. Preise von vorhandenen Artikeln aktualisieren
     4. Preise von vorhandenen Artikel aktualisieren / Nicht vorhandene überspringen
     5. Mit neuer Artikelnummer einfügen
     6. Eintrag überspringen

    Zusätzlich können nun Spalten "Lager","Lagerort" als Name oder ID eingelesen werden,
    sowie Übersetzungen z.B. als 'description_EN' oder 'description_IT'.
    Auch cvars können als 'cvars_<name>' importiert werden.
    Ebenfalls sind weitere Bemerkungen an den einzelnen Importzeilen eingebaut.

Geierlein: alter Elsterexport überarbeitet

Generierung der Params in ODGeierlein

Neuer Controller für AJAX Request
Verallgemeinern (Teile aus ustva.pl nach SL/USTVA.pm

elster_format angepasst

Die Formate der Steuernummern für Baden-Württemberg und Rheinland-Pfalz
sind in Geierlein anders als früher in taxbird

Geierlein auf gleichem Webserver

Da LocalStorage nur innerhalb einer Domaine funktioniert,
Wurde nun innerhalb Kivitendo der crome/content Baum von Geierlein installiert.

Also
cd geierlein/chrome/content
mkdir {kivitendoDocumentRoot}/geierlein
tar cf - * | tar xf - -C {kivitendoDocumentRoot}/geierlein

Natürlich gibt es auch Möglichkeiten, dies per alias-Config im apache2 zu machen

Konfigurerierbar in kivitendo.conf

Falls geierlein_path gestetzt ist das Feature enabled
Pfadnahme zeigt zu geierleinverzeichnis innerhalb des kivitendo Verzeichnisses

UStVa Einstellungen in Datenbank

Kein finanzamt.ini mehr sondern fa_bufa_nr in Defaults,
über diese BundesFinanzamtnummer greift man auf Finanzamt Rose-Objekt zu.
Das ist nun auch modifizierbar.
Nutzung von Rose,
Sonderfälle in stnr pattern (BaWü)

Falls keine Daten in Defaults wird ein ggf. vorhandenes finanzamt.ini gelesen
und die Daten von dort übernommen

Die Steuernummer wird nun nicht mehr in der Mandantenkonfig
sondern in den UStVa Einstellungen editiert

Bisher Keine Umstellung auf IBAN, BIC (ist dies notwendig?)

Übergabe ohne kz83
Geierlein berechnet das Ergebnis selbst,
es werden nun nur Eingangsbeträge übergeben

UTF-8 Umwandlung finanzamt.ini Texte

Links zu Mandantenkonfig eingearbeitet

Implementiert RedMine Feature #168

2. Version POD zu create_assembly

Probiert insgesamt mehr 'auf den Punkt' und trotzdem
user-verständlich zu beschreiben.

1. Version POD zu create_assembly

create_assembly wird transfer_assembly ersetzen.
Dies ist die erste Version alle aktuellen optionalen Verfahren
für 'Erzeugnis fertigen' zu ergänzen.
Aktuell offen ist die Liste der Parameter, sowie das
Verhalten bzgl. best_before

special_chars: Weitere Symbole für LaTeX

special_chars: Omega für LaTex als mathematisches Symbol.

new_lastmtime mit $provided_dbh aufrufen

fix für #204

new_lastmtime um optionalen dbh erweitert

Kosmetik, bessere Beschreibung für neuen SelfTests (#24)

Copy und Paste-Fehler bei Beschreibung im Positiv-Testfall
übersehen, sowie Einrückungen verbessert.

Payment-Helfer: Rechnen mit undefinierten Werten vermeiden

Weiteren Transaction-Selftest

Falls ein datepaid im Nebenbuch gesetzt ist, so darf paid nicht
auf 0 sein, wenn es keine Zahlungen in der acc_trans hierzu gibt.

Merge branch 'f-use-with_transaction-instead-of-do_transaction'

»with_transaction« anstelle von »do_transaction« verwenden

Es sollte so selten wie möglich »do_transaction« verwndet werden, damit
man sich immer angewöhnt, »with_transaction« zu nutzen.

Hintergründe und Unterschiede zwischen den beiden Funktionen sind in der
Dokumentation von SL/DB.pm beschrieben.

Auftragscontroller: nach Löschen Redirect zum Anlegen, nicht zum Bearbeiten

Pflichtenheft: Zugriff auf nicht vorhandenes »visible_item« verhindern

Sind im Baum gerade Textblöcke ausgewählt, so liefert die Funktion
»visible_item« undef zurück, weil aktuell kein Item (= Abschnitt oder
Funktionsblock) sichtbar ist.

Wird in so einem Moment ein Abschnitt oder Funktionsblock per Drag &
Drop verschoben, so darf daher kein Zugriff auf Funktionen von
»visible_item« stattfinden. Die Prüfung, ob aktuell überhaupt Abschnitte
zu sehen sind, muss daher vorher erfolgen.

Rechnungsmassenerstellen: keine DB-Transaktion um convert_to_invoice()

convert_to_invoice() macht selber intern bereits eine Transaktion auf;
daher ist die außen unnötig.

Weiterhin waren die Parameter merkwürdig übergeben:

• Für eine On-The-Fly-Unterscheidung für »diese Parameter« vs. »keine
  Parameter« benötigt man keine sub; das geht einfach mit einem ternären
  Operator.
• »Keine Parameter« drückt man nicht durch »undef« aus, sondern durch
  die leere Liste »()«. Wird »undef« als einziger Parameter übergeben,
  so wird in der Funktion de Facto das hier gemacht:

  my %hash = (undef);

  und das ergibt eine Warnung, dass eine Liste mit ungerader Anzahl von
  Elementen in ein Hash umgewandelt werden soll.

SL::DB::with_transaction: bessere Doku zu den zwei Hauptunterschieden

Admin: Task-Server-Benutzer in Mandantenliste anzeigen

TaskServer-Steuerung: Temp-Datei automatisch entfernen lassen

Bankauszug: nur Warnung wegen Überzahlung bei tatsächlicher Überzahlung

Bankauszug: Dialog »Rechnung zuweisen«: Fokus auf Rechnungsnummernfeld

CSV-Helfer: Error-Felder versionsunabhängig setzen

Unterschiedliche Versionen von Text::CSV_XS geben beim Aufruf von
»error_diag« unterschiedliche Felder zurück: neuere geben mehr
zurück.

Es gibt aber einen Testcase, der das Fehler-Array auf exakte
Übereinstimmung prüft. Da sorgt also jegliches neu hinzugekommenes Feld
dafür, dass der Test fehlschlägt.

Also nur die Felder explizit an SL::Helper::Csv::Error übergeben, die
uns wirklich interessieren, und nicht das von »error_diag«
zurückgebebene Array 1:1 durchreichen.

SL::DB::Part: Setter für type=assembly bzgl. inventory_accno_id fixen

inventory_accno_id muss für Typ »assembly« immer auf undef stehen. Das
testet auch der Testcase. »type« hat allerdings das Falsche gemacht,
wofür im Testcase versucht wurde, ein Workaround zu implementieren,
indem »inventory_accno_id« explizit überschrieben werden.

Leider schlug der Test manchmal fehl, trotz des Workarounds: je nachdem,
ob beim Anlegen (»new_assembly«) zuerst der Parameter für »type« oder
der für »inventory_accno_id« ausgeführt wurde.  Die Reihenfolge der
Ausführung ist deswegen nicht deterministisch, weil in Perl das
Iterieren über Hashes gewollt nichtdeterministisch ist, um
Sicherheitsproblemen vorzubeugen.

Wir wandeln Funktionsparameter beim Anlegen von Rose-Objekten explizit
von Listen in Hashes (SL::DB::Object::assign_attributes); anschließend
wird über das Hash iteriert. Im konkreten Fall enthält das Hash sowohl
»type« als auch »inventory_accno_id«, und je Perls internem Seed
bzgl. der Hashiteration wurde mal die eine, mal die andere
Setter-Funktion zuerst ausgeführt.

Merge branch 'bank-transaction-improvements'

Bankeinzug: bei Überzahlung eine Warnung ausgeben

Eine Überzahlung ist oftmals OK oder unvermeidbar, sollte aber von der
BenutzerIn begutachtet werden.

Bankauszug: Unterzahlung mehrerer Rechnungen verhindern

Wenn mehrere Rechnungen ausgewählt werden, so verteilt der Algorithmus
schlicht den Betrag der Überweisungen auf die Rechnungen in der
Reihenfolge, in der die Rechnungen ausgewählt wurden. Dabei wird so
lange der volle offene Betrag bezahlt wie möglich, der Rest kommt auf
die folgende Rechnung.

Allerdings ist für das Programm nicht ersichtlich, welche Anteile
welcher Rechnungen des Kunden/Lieferanten tatsächlich damit beglichen
wurden.

Also muss verhindert werden, dass das passiert; eine Warnung genügt
nicht.

Bankauszug: Transaktionsrichtung mit Belegrichtung abgleichen

Erhält man eine Zahlung, so darf man diese nur mit Belegen verbuchen
können, die Zahlungen in Empfangsrichtung bedingen: Verkaufsrechnungen
und Gutschriften im Einkauf.

Analog gilt das auch für ausgehende Zahlungen. Hier passen nur
Einkaufsrechnungen sowie Gutschriften von Verkaufsrechnungen.

Alle anderen Zuordnungen werden mit einem Fehler zurückgewiesen.

Bankauszug verbuchen: etwas Dokumentation ergänzen

Bankauszug verbuchen: Warnungen/Fehler anzeigen; pro Zeile eine DB-Transaktion

Das Verbuchen von Bankauszügen wird nun in Datenbanktransaktionen
gekapselt. Damit die BenutzerIn bei einem Fehler nicht alles erneut
einstellen muss, wird eine Datenbanktransaktion pro
Banktransaktion benutzt.

Treten dabei Warnungen oder Fehler auf, so werden diese nun in einer
Tabelle übersichtlich dargestellt. Die Tabelle enthält sowohl die Daten
der Banktransaktion, bei der das Problem auftrat (entfernte
Kontonummer/BIC, entferne KontobesitzerIn, Betrag, Transaktionsdatum),
als auch Links zu den mit dieser Transaktion verknüpften
Rechnungen. Damit wird die BearbeiterIn in die Lage versetzt, die Fehler
genauer zu analysieren.

drafts/load.html entfernen, nach Umstellung auf Controller nicht mehr benötigt

ic/choice.html entfernen, da nur von top100 benutzt

Herr Savic und ich werden eine

Payment-Helfer: with_transaction() anstelle von do_transaction() nutzen

»do_transaction()« kommt von Rose::DB selber. Es schert sich nicht
darum, ob bereits eine Transaktion läuft, sondern macht einfach eine mit
»BEGIN« auf. Am Ende der an »do_transaction()« übergebenen Sub committet
sie dann (oder macht einen Rollback).

Problematisch ist das dann, wenn in dem Moment bereits eine Transaktion
läuft und man eigentlich möchte, dass sowohl die externen Änderungen als
auch die von »pay_invoice()« durchgeführten Änderungen alle ganz oder
alle gar nicht committet werden. Genau das bietet
»SL::DB::with_transaction()«, das nur dann eine neue Transkation
startet, falls noch keine läuft, und den Code ansonsten direkt ausführt.

Anders als »do_transaction()« wertet »with_transaction()« den
Rückgabewert der übergebenen Sub aus. Ist dieser im Perl-Sinne false, so
wird ein Rollback durchgeführt — nicht nur bei einer Ausnahme. Daher
muss in diesem Fall unsere übergebene Sub zusätzlich einen wahren
Wert (hier: »1«) zurückgeben, um Erfolg zu signalisieren.

Payment-Helfer: Kosmetik (Einrückung, keine ; am Ende von if)

CsvImport: deutlich anzeigen, ob Vorschau oder echter Import

CsvImport: Kosmetik (Anordnung)

Untere Scroll-Balken anzeigen, falls Bereich > Browser

Letter: is_sales nicht in init_letter clobbern

Briefe: Sprache im Druck

Preisquellen: weitere TODO doku

Order Controller - lastcost von Positionen mit speichern

ansonsten ist die Margenberechnung im Verkaufsbericht falsch (lastcost
ist immer 0). Siehe Ticket #201

Doku: PriceSource Verhalten für Belegumwandlungen

Wie beschrieben in redmine#199:

Wenn ein Kunde einen Kundenrabatt hat, und man aus einem Auftrag einen
Lieferantenauftrag macht, wird die active_discount_source der Artikel
(z.B. "customer_discount/1162") mit auf die Einkaufsseite des Workflows
übernommen, und das fliegt einem dann bei der EK-Rechnung um die Ohren.

Wahrscheinlich wäre es aber besser, beim Wechsel von VK zu EK die
Kundenrabatte und Kundenpreisregeln herauszufiltern, da diese nichts mit
den Vereinbarungen mit dem Lieferanten zu tun haben. Und dann sollten
bei den Positionen die Lieferantenregeln vorbelegt werden, so als ob man
den Auftrag händisch eingegeben hätte.

Tests: ic.pl nicht mehr vom html-tag counter ausschließen

Nachdem top100 rausgeflogen ist, ist das mit 13 tags sogar noch gut im
Mittelfeld der Sünder.

Tests: closed bei Überzahlungen auf TODO gesetzt

Konten: typo

CustomerVendor: agnostische number Methode für beide

Briefe: [D] Button entfernt.

show_vc_details.js kann das format nicht.

Flash: Fehlende Übersetzung

Tests: warnings in t/part/assembly.t

Briefe: Lieferantenbriefe

Workflow Lieferschein -> Rechnung. Kundenrabatt mit Nachkommastellen i.O.

Zu den weiteren lästigen Rabattfehlern nun auch noch der Fall,
wo der Workflow im Lieferschein beginnt und ein Kundenrabatt mit
Nachkommastellen existiert.

Rabatt mit Nachkommastellen Workflow Auftrag -> Rechnung

Ursprüngliche Idee von Waldemar in OD-Bugfixes hier: 3c705b61f32d81c41352fe
Getestet mit: Kundenrabatt, Individuellen-Rabatt, Preisregel-Rabatt
Sowie ferner ohne Rabatt und mit freiem Rabatt ohne Nachkommastellen

Behebt den Auftrags -> Rechnungsteil von  #99

BUG-FIX:  LOCK TABLE parts in CVS-Import Artikel

Problematik, dass alles andere mit Rose gemacht wird,
die Teilenummern holen, jedoch nicht.

Siehe auch Redmine #190

BUG-FIX: Rose kann nur sort_by

order_by wird stillschweigend ignoriert

Weitere Fixes?

Spellcheck - separate

OrderController - Funtion umbenannt (dependend->dependant)

do.pl sort Funktion verbessert

parse_amount/format_amount Problem bei Nachkommastellen.
Hintergrund: Ein save mit no_redirect wird benötigt, damit
ein erneutes Update die Reihenfolge auch an der Oberfläche anzeigt.
Leider wird save somit zweimal aufgerufen und damit auch 2x parse_amount
Entsprechend zwischendrin einmal mit format_amount wieder ausgeglichen.

Lieferschein-Positions-Rabatt mit Nachkommastellen

behebt #200. Nachkommastellen werden beim Workflow Lieferschein -> Rechnung
verschluckt, da ein parse_amount fehlt.

Projektbericht - Datumsfelder besser prüfen