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

Berichte->Projektbuchungen nutzt jetzt den Projektpicker

Tabelle parts: Fremdschlüssel für Konten - bessere Namen

Tabelle parts: Fremdschlüssel für Konten

Bug #199 - Kundenrabatt in Einkaufsrechnungspositionen

Behebt Fehler #199 (Redmine)

PartPicker Testseite - convertible_unit Beispiel

Test für Erzeugnisse per Rose erstellen erweitert

Erzeugnisfremdschlüssel auf Artikel 2

auch die Spalte id verlinken.

Die Tabelle assembly ist etwas Banane und nicht gerade Rose-freundlich.

* die Spalte id entspricht der id des eigentlichen Erzeugnisses, alle
Artikel eines Erzeugnisses haben den gleichen Eintrag in id.

* die Spalte assembly_id ist der Primary Key der Tabelle.

* die Spalte parts_id entspricht der id der Ware, das Teil des
Erzeugnisses ist.

Ein besserer Name für die Tabelle wäre assembly_items.

Rose Dateien für Tabelle user_preferences

Test für Erzeugnisse

Erzeugnisfremdschlüssel auf Artikel

Tabelle assemblies mit parts verknüpfen

nicht benutzte Spalte parts.alternate entfernen

Auftrag in Lieferschein wandeln: Rose-DB-Handle für Item-Verknüpfungen verwenden

Sonst wirkt die transaction nicht und es kann sein, dass record_links
angelegt werden, auch wenn die Transaktion abgebrochen wird.

Test bank_transactions - am Ende aufräumen

Kunde: Datenbanktabelle "klass" nach "pricegroup_id" migriert

und einen Fremdschlüssel gesetzt.

S:C:BankTransaction: Kosmetik für bessere Lesbarkeit (Einrückung, Anordnung…)

POD für Methode closed in SL/DB/Invoice

Die derzeitige Umsetzung ist mMn falsch bei Überzahlungen, die sollten
auch offen sein.

Kontoauszug verbuchen - Beschriftung verbessert.

Übernommene Vorschläge zeigen die Rechnungsnummer und den offenen Betrag
der Rechnung an, die Beschriftung lautet nun auch "offener Betrag".

SL/DB/BankTransaction.pm - carp statt die

Controller BankTransaction - Einrückungen und Kommentare

Test für Rechnungen bezahlen per 'Kontoauszug verbuchen'

Refactoring und Einrückungen in BankTransaction.pm

TopQuickSearch: Und Verlinkung auch wieder hergestellt

Sicherheit: ReDoS in trim() umgehen.

trim hat bisher whitespace mit dem regex /^\p{WSpace}+|\p{WSpace}+$/
getrimmt. Der ist aber anfällig gegen große Mengen Whitespace in der
Mitte, weil dann das Backtracking in O(n²) läuft:

$_ = "--".(" "x200000)."and more"; s/^\p{WSpace}+|\p{WSpace}+$//;
-> 0m16.572s

Für genau den Fall hat die Perl Engine aber Optimierungen, die bei
Regexes die rechts geankert sind einfach von hinten sucht. Die
funktionieren aber nur wenn einzeln gesucht wird. Also sind das jetzt
zwei separate Regexes.

$_ = "--".(" "x200000)."and more"; s/^\p{WSpace}+//; s/\p{WSpace}+$//;
-> 0m0.022s

Fertigen ohne Prüfung nach Bestand(2)

Das Prüfen ob Lager das "Standard-Lager für Auslagern ohne Prüfung auf Bestand"
ist genügt nicht, es können Bauteile dieses Lager auch als Standardlager haben

Fertigen ohne Prüfung nach Bestand

Wird bei einem Bestandteil das "Standard-Lager für Auslagern ohne Prüfung auf Bestand"
verwendet, wird ohne Prüfung ausgelagert.

Dies geschieht nur beim gewählten Feature "Zum Fertigen Standardlager des Bestandteils verwenden"

changelog zu Feature "Zum Fertigen Standardlager des Bestandteils verwenden"

Die Implementierung befindet sich in den commits
'Funktion "Erzeugnis fertigen" sucht Bestandteile im falschen Lager.(x)'
3160b0888 8814ec731f 26dab9db58 0f214df54e

Funktion "Erzeugnis fertigen" sucht Bestandteile im falschen Lager.(4)

Falls das Bestandteil bei gesetztem "transfer_default_warehouse_for_assembly"
kein Standardlager besitzt und es kein "Standard-Lager für Auslagern ohne Prüfung auf Bestand"
in der Mandantenkonfig gesetzt ist,
wird eine Fehlermeldung erzeugt.

Dies ist nun die vollständige Implementierung dieser Sache von OD.

TopQuickSearch: typisierte Suche gefixt

TopQuickSearch: Alle Artikelsuchen haben nur Erzeugnisse gefunden

...hat keiner gemerkt...

TopQuickSearch: all Filter Bei Aufträgen in den callback aufnehmen

TopQuickSearch: all filter bei Waren in den callback aufnehmen

is: top100 gegrillt. standardfunktion kann das genauso.

Ich hatte das beim Umstellen auf TT damals dringelassen, weil es noch
die addtop100 Funktionalität gab, mit der man sich Favoritenlisten bauen
konnte. Das ist jetzt fast 9 Jahre her, und die Funktion ist seit dem
kaputt.

Weg damit. Wenn gewünscht kann das beim merge von OD wieder
berücksichtigt werden.

TopQuickSearch: Bei Kunden den neuen all filter in den callback aufnehmen

changelog und UPGRADE zu den GIN Indizes

Mahnungen: Mahnungsdatum gefixt

Bisher wurde beim Erstellen neuer Mahnungen in der Spalte "Zahlbar bis"
ein Datum angezeigt, was wohl das wharscheinliche Zahlungsziel der neu zu
erstellen Mahnung anzeigen sollte. Die gleiche Überschrift wird aber
überall sonst in den Mahnung für das Ziel einer bereits erstellten
Mahnugn verwendet, und in diesem Fall ist das Datum auch noch falsch.

Dadurch, dass es schon beim Laden aus der Datenbank berechnet wird, wird
es aus dem heutigen Tag und dem duedate der Mahnungskonfiguration der
Rechnung berechnet. Diese Mahnungskonfiguration ist aber nur vorhanden,
wenn die Rechnung schonmal angemahnt wurde, und bezieht sich dann auf
die Konfiguration der bereits bestehenden Mahnstufe, nicht auf die der
nächsten. Das Datum war also völlig nutzlos.

Jetzt wird einfach wie überall sonst auch das Datum der bestehenden
Mahnung angezeigt.

BankTransaction: Verlinkungen auf alten Vorlagencode upgedated.

Behebt redmine#194 "Fehler »load_draft not defined in locale/de/all« beim
Entwurfladen aus Bankauszug verbuchen"

Drafts: load kann jetzt zusätzliche Argumente aus form übernehmen

Kontoauszug verbuchen: Fehlermeldung und falscher Betrag

Werden mehrere Rechnungen mit einer Banküberweisung bezahlt,
bekommt letzte Rechnung immer den Rest des Betrages,
auch wenn sie überbucht wird.

fix Redmine #192

Eine Rückbuchung von ganz bezahlten Rechnungen kann über diesen Weg nicht gemacht werden

Payment-Helper - create_bank_transaction bekommt "purpose" param

und Beispiel für das Erstellen einer Zahlung für mehrere Rechnung mit
Skonto in POD.

Funktion "Erzeugnis fertigen" sucht Bestandteile im falschen Lager.(3)

Die fehlende Methode get_basic_warehouse_info() ist analog zu
get_basic_bin_info() aufgebaut und wird auch später in dem verbesserten Verbrauchsbericht von OD
benötigt

Einrückungen in WH.pm

Verbesserung Englische Übersetzung

Kundenstammdaten: Lieferadresse speichern, wenn beliebiges Feld gesetzt

Vorher wurde nur gespeichert, wenn der Name gesetzt war. Das ist
allerdings inkonsistent mit dem Verhalten von vor der Umstellung der
Maske auf das Controller-Modell. Weiterhin gibt es bei der
Lieferadressenbehandlung beim Drucken auch keine Sonderbehandlung mehr,
die vom Lieferadressen-Namen abhängt. Daher sollte das Speichern
ebenfalls nicht davon abhängen.

Funktion "Erzeugnis fertigen" sucht Bestandteile im falschen Lager.(2)

Auf Wunsch von Jan ist dies kein Bug mehr, sondern ist nun per Mandantenkonfig konfigurierbar

Als default wird das Ziellager genommen, falls "transfer_default_warehouse_for_assembly" gesetzt,
wird das Standardlager des Bestandteils verwendet.

Anmerkung:
Wo wir derzeit in der unstable wh.pl:create_assembly() verwendet/aufgerufen ?
Kann ich nicht finden.

Flashanzeige erweitert: Nun auch Details

Für alle drei Flashanzeigen gibt es Detailanzeigen/optionalen Timeout

Details als textueller Link [Details]
ebenfalls wird Fenster nach oben gescrolled, damit flash info sichtbar ist.
Bei einigen Fehlermeldungen, z.B. bei LaTex Fehlern empfiehlt es sich,
kleinere Fehlermeldungen anzuzeigen, die dem Kunden verständlicher sind,
in den Details kann der lange Fehlertext (z.B auch sql Fehler) angezeigt werden

Änderung in clientjs:

nach Ausgabe einer Flash Anzeige (Info/Warning/Error)
wird nach oben gesprungen ( derzeit zum frame-header).

Damit wird die Anzeige auf jeden Fall sichtbar.

Flashanzeige erweitert: Funktion zum Text löschen nach Timeout

Bei neuen Controllern, die per AJAX laufen, ist es empfehlenswert
bestimmte Texte nach einer gewissen Zeit implizit zu löschen,
damit eine weitere identische Anzeige erkennbar ist.

Die Funktion ist derzeit explizit per js->run('kivi.clear_flash','info',10000) im Controller einzubauen,

ggf, später als eigenständige clientjs - Funktion

PartPicker styling: Höhe in chrome

Für später: lx-office-erp.css überschreibt natives <input> styling mit
einem pseudo-windows 7 Look, und kann das svg deshalb einfach als
Hintergrundbild setzen.

kivitendo.css belässt es aber bei nativer appearance. Sobald man da dann
versucht das Hintergrundbild zu ändern, wird die nicht mehr vom Window
Toolkit gerendert, sonderm vom Browser mit dessen Standardstylesheet.
Ergo muss da die Lupe als inline-block über dem input Feld positioniert
werden.

Der gesamte Picker muss sich inline verhalten, die einzelnen Teile
darin aber mit spacing Informationen gestyled werden. Dafür ist display:
inline-block da. Blöderweise klappt vertical alignment innerhalb eines
inline-blocks nur wenn man ein leeresa Pseudoelement vorne vor setzt.

PartPicker Styling: Fix für Chrome

Reapply "Partpicker styling"

3.4.1 ist durch, also wieder rein, auf dass es bis zum nächsten Release
gefixt wird.

Experimentell: Trigram Indizes auf Spalten die mit ILIKE durchsucht werden.

UserPreferences: erste version

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

This reverts commit 86299a413d457abfa10f657b243d00b194702824.

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

Kontoauszug verbuchen - SEPA-Zahlungen berücksichtigen und schließen 2

auch bei Verbuchen per "Vorschlag" die SEPA-Zahlungen schließen.

Typos in Doku

Dokumentation: /users/ Rechte in apache2.4 waren waren falsch.

Lieferbedingungen haben kein Attribut description_long_invoice

Im Commit de009a3fee7e0471c3e095ce92d8708ff2b42597 »Zahlungsbedingungen:
Unterscheidung zwischen Angeboten/Aufträgen und Rechnungen« wurden
in den Druckroutinen fälschlicherweise auch für die Lieferbedingungen
das Setzen von »description_long_invoice« implementiert, obwohl die
Lieferbedingungen keine Unterscheidung zwischen Angeboten/Aufträgen und
Rechnungen bekommen haben.

Daher revertet der jetzige Commit diejenigen Hunks aus
de009a3fee7e0471c3e095ce92d8708ff2b42597, die die Lieferbedigungen
angefasst haben.

Bericht Debitorenbuchungen - Gutschriften < 1€ erkennen

Die Prüfung auf amount < 0 wurde nach dem format_amount aufgerufen,
dadurch wurden Beträge von z.B. -0,77 nicht als Gutschriften erkannt.
Die amount-Prüfung wird jetzt nach dem format-amount aufgerufen.

Typos in Doku