epic-ts

epic-ts

epic-ts

Projekt-Picker für Berichte: auch inaktive und ungültige Projekte zeigen

Projekt-Picker: exact match auf GetModels umgestellt

Projekt-Picker-Lupe: changelog

Projekt-Picker-Lupe: Übersetzungen

Projekt-Picker: weitere Elemente auf der Testseite

Projekt-Picker: Parameter f. aktiv/gültig

und Filter-Daten via data an js übergeben

Projekt-Picker-Lupe: erste Ergebnisse direkt anzeigen

Spart einen zweiten Ajax-Aufruf

Projekt-Picker-Lupe: Copy/paste und Anpassungen vom Chart-Picker

Projekt-Picker: js: $type wird nicht gebraucht

Zahlungsbedingungen Kreditorenbuchung leere Werte mit conv_i abfangen

Zu ZB bei Kreditorenbuchung - Vorbelegung Stammdaten Lieferant

Falls kein invoice_obj vorhanden, wieder auf form->payment_id gehen,
da hier die Werte aus den Stammdaten des Lieferanten vorbelegt sind (!)
Jetzt müssten alle Fälle passen:
1. Gespeicherte Werte anzeigen, auch bei ungültigen ZB
2. Lieferanten-Werte aus Stammdaten übernehmen
3. Lieferanten-Werte beim Wechsel des Lieferanten übernehmen

Kommentar zum Payment-Helper

Außer in den Testfällen wird der Helper nicht mit einem
negativen Amount aufgerufen. Im Helper befindet sich etwas
zuviel automagie. Eigentlich braucht man den Param amount nicht,
wird aber überall in kivi übergeben. Eigentlich darf der negativ
sein, verfälscht aber das multiplizieren im Helper.

Zahlungsbedingungen Kreditorenbeleg Speichern und Laden in Maske

Das was Commit 8b5bed7fe5 versprochen hat, jetzt auch in Echt ;-)

BankTransaction: Filter nach Konteninhaber-Namen

Auftrags_Controller: js: hiddens f. Wiedervorlage nur einmal anhängen

Wiedervorlage aus Angebot/Auftrag: Betreff aus Vorgangsbezeichnung vorbelegen

nur "neuer" Controller

Lieferantenbericht: UStID anzeigen lassen können

Kunden/Lieferanten: UStId/Steuernr. eindeutig: changelog

Kunden/Lieferanten: UStId/Steuernr. eindeutig: Prüfung im Controller

Kunden/Lieferanten: UStId/Steuernr. eindeutig: Mandantenkonfiguration

locales-Skript: all/more für js berücksichtigen

Ein Eintrag wird aus all/more genommen, wenn hier vorhanden, sonst aus
all.

locales-Skript: all/more berücksichtigen, …

indem Texte, die ausschließlich dort vorhanden sind, nicht in all
eingetragen werden. Texte, die vorher schon in all sind, bleiben aber
erhalten. Das sind dann (vermutlich) die Texte, die in more für ein
Kundenprojekt eine andere Übersetzung haben sollen (und nicht neu hinzu
kamen).

locales-Skript: POD update

locales-Skript: Option -n / --no-custom-files raus

Funktioniert so ohnehin nicht mehr (wird ignoriert) und -n war doppelt vergeben
(Option n is ambiguous (no-check-files, no-custom-files))

locales-Skript: Kosmetik: Kommentare

- Typo gefixt
- Kommandozeilenparameter nicht im Kommentar: gibt es als Hilfe
  und im POD und waren nicht vollständig

locales-Lauf en

Merge branch 'f-customer-vendor-rights'

Testfall year_end repariert

.. lieber gleich hartkodiert in 2019 bleiben

Quick-Suche: `auth` == undef oder leerer String gefixt

Laut Doku in `SL/Controller/TopQuickSearch/Base.pm` bedeuten undef
oder leerer String als Rückgabewert der Sub `auth`, dass dieses Modul
für alle Benutzer*innen zur Verfügung steht, unabhängig von deren
vorhandenen Gruppenrechten.

Das hat nur nicht funktioniert.

Kundenstammdaten: beim Anlegen Verkäufer*in setzen wenn kein »edit all«-Recht

Personen, die nur »edit«-Rechte, nicht aber »edit all«-Rechte haben,
dürfen nur noch eigene Kunden bearbeiten. Daher ist es sinnvoll, dass
beim Neuanlegen das Feld »Verkäufer*in« bereits auf die aktuelle
Person gesetzt ist.

Kunden-/Lieferantenstammdaten: Berechtigungsmodell gefixt

Neues Modell sieht wie folgt aus:

1. Alle Personen haben Leserechte auf alle Kunden- &
   Lieferantenstammdaten. Das betrifft nicht nur die Stammdatenmasken,
   sondern auch die AJAJ-Autovervollständigung (Kunden-/
   Lieferanten-Picker) oder die Detail-Popup-Fenster in Einkaufs-/
   Verkaufsbelegmasken.

2. Personen mit »edit«-Recht aber ohne »edit all«-Recht dürfen nur die
   eigenen Kundenstammdaten verändern (speichern/löschen), wobei
   »eigen« definiert ist als »aktuelle Person ist Verkäufer*in des
   Kunden«. Neue Kunden dürfen angelegt werden. Bei Lieferanten dürfen
   hingegen alle Stammdaten bearbeitet werden.

3. Personen mit »edit all«-Recht haben Vollzugriff auf alle Kunden- &
   Lieferantenstammdaten.

POD fix: Rose Syntax

Zeitvergleich braucht { . ilike gibt es nicht in Rose:
like_operator => 'like', # only applicable to Postgres, defaulted to undef, i.e. render_as_table() uses 'ilike' for Postgres by default

Bericht Angebote/Aufträge: internen Bemerkungen filtern und anzeigen können

Bericht Angebote/Aufträge: HTML: fehlende Ende-Tags hinzugefügt

Testfall für BT: Punkte. Copy & Paste Fehler von a695c behoben

BT: Punkte. Copy & Paste Fehler von a695c behoben

open_amount mit open_amount vergleichen

S:C:H:ReportGenerator: Spalteninformationen einzeln zuweisen.

Hintergrund: Das "fat-comma (=>)" interpretiert seine rechte Seite im
Listenkontext, was dazu führen kann, dass der Hash, der aufgebaut werden
soll, durcheinander gerät, wenn z.B. $def->{sub} eine Liste zurückliefert
oder gar nichts ($def->{sub} = sub { return }).

Interessant im Zusammenhang:
https://stackoverflow.com/questions/3435122/whats-the-difference-between-return-and-return-undef-in-perl

Buchungsjournal: auch globale Projektnummer im Bericht mit anzeigen

Buchungsjournal: Abteilung im Bericht anzeigen können

Buchungsjournal: Zwischensumme in Suchmaske an den Schluss gesetzt

Buchungsjournal: Spalte f. Bilanz im Bericht direkt hinter Umsatzsteuer

Dann sind die Zahlen zusammen

SL::GL: POD: keine leere section; <gt> escapen

changelog f. Menü- und Rechte-Anpassung "Produktivität"

Berechtigungen für Produktiovität als eigene Kategorie …

und die bisherigen Produktivitäts-Rechte und E-Mail-Journal-Rechte
darunter anzeigen.

Menü Produktivität: Zugriffsrechte nicht am Haupteintrag fest machen …

und eigene Zugriffssregel für E-Mail-Journal.

So kann z.B. das Recht, E-Mail-Journal ansehen, getrennt von der
Produktivität gesetzt werden.

Ein Hauptmenüpunkt wird nicht angezeigt, wenn keiner seiner Kinder
(z.B. wg. fehlender Rechte) angezeigt wird - wenn also keines der Rechte
vorhanden ist, so wird, wie vorher auch, der Haupteintrag auch nicht
gezeigt.

Locales-Läufe

S:D:Helper:TransNumberGenerator: Warnung vermeiden.

Getriggert durch Tests (./t/wh/inventory.t). Tritt aber nur auf, wenn
der Nummerkreis noch leer ist.

Dialogbuchungen um Boolean imported erweitert.

Buchungen mit diesem Boolean können beim DATEV-Export
gefiltert werden. Anwendungsfall sind bspw. in DATEV
erstellte Lohnbuchungen, die dann in kivi importiert werden

GLTransaction:: add_chart_booking um get_active_taxkey erweitert

Der Aufruf von add_chart_booking muss sich nicht mehr
darum kümmern welcher Steuerschlüssel gesetzt sein muss, wenn
er einfach nur den vorkonfigurierten Steuerschlüssel setzen will.
Dementsprechend ist param{tax_id} kein Pflichtparameter mehr.
POD ergänzt und mit Testfällen abgesichert (19% / 16% Fall).

Artikelstammdaten: in Übersetzungen Zeilenumbrüche verwenden können

Das Eingabefeld für die Beschreibung im Basisdaten-Tab erlaubt die
Eingabe von Zeilenumbrüchen. Daher muss das auch für die übersetzen
Beschreibungen gehen.

Merge branch 'f-factur-x-und-xrechnung'

Inventur: Part-Picker such auch nach Lieferantenartikelnummer

Kontoauszug verbuchen: Verkaufsgutschriften nicht negativ bewerten

Punkte für wrong_sign höher gesetzt und beide Gutschriftentypen
jetzt sauber abgegrenzt (credit_note und negative_ap_transaction)

BankTransaction: Treffer für Kreditorengutschriften erhöhen

negativ_ap_transaction sollte keine Strafpunkte mehr fürs
Vorzeichen erhalten. TODO: Verkaufs-Gutschriften prüfen

Kontoauszug verbuchen: Vorschlagsliste verbessern

- Kommentar stimmt nicht mit dem Code überein.
- Die Prüfung verhindert das Banktransaktionen mit einer Summe größer der
  Rechnungssumme als Vorschlag zugewiesen werden. Das war wichtig,
  weil der Payment-Helper zu Beginn immer die komplette Bankbewegung auf
  einen Beleg gebucht hat. Das ist mittlerweile besser gelöst.

Dialogbuchung: js-Validator einbinden. Damit werden die Datumsfelder validiert

… und auch formatiert.

changelog für Leistungsdatum

S/D/Order: new_from_multi: Leistungsdatum nur übernehmen, wenn überall gleich.

Für den Workflow, aus der Auftrags-Liste mehrere Aufträge zu einem
zusammenzufasssen.

Kreditorenbuchungen: Automatisches Setzen von Fälligkeitsdatum

Test: Skonto in Kreditorenbuchungen

Kreditorenbuchungen: Zahlungsbedingungen in Belegvorlagen

Kreditorenbuchungen: Zahlungsbedingungen laden/speichern

Kreditorenbuchungen: Bemerkungenblock an Rechnungen angepasst

mailmap update

Auftrags-Controller: Auftragswahrscheinlichkeit anzeigen: Typo im as_date-Attr.

Merge branch '2020-leistungsdatum'

SL::DB::Invoice->new_from: auch Leistungsdatum (tax_point) übernehmen

Preisanfrage/Aufträge: dort, wo es ein Liefertermin gibt, diesen f. Steuer nehmen

Auftrags-Controller: bei Änderung Leistungsdatum/Liefertermin neu berechnen

Auftrags-Controller: Leistungsdatum bei Workflow berücksichtigen

display_row: ship_$row nicht formatiert ausgeben

Im ganzen Programm wird angenommen, dass `$::form->{ship_$row}`
unformatiert ist, nur an dieser Stelle wird es formatiert
ausgegeben. Das war nicht mal ein Problem, weil es in `update` via
`_update_ship()` komplett neu berechnet wird, ohne auf den aktuellen
Wert in `$::form->{ship_$row}` zurückzugreifen. Trotzdem ist es der
Konsistenz halber wichtig, den Wert auch hier unformatiert auszugeben.

Order-Controller: Umwandlung: Berechnung bereits gelieferter/abgerechneter Mengen gefixt

In $::form steht der Wert für die gelieferte Menge in
`ship_$row`. Dieser Wert wird überall im Programm als unformatiert
angenommen, nur bisher in der Methode nicht, die berechnet, wie viel
von jeder Position bereits abgerechnet/geliefert war. Ergebnis war,
dass ein unformatierter Wert noch mal durch `$::form->parse_amount`
gejagt wurde.

Für einen Wert mit Nachkommaanteil ist das dann problematisch. Wurden
bereits z.B. 123,45 geliefert, so steht in `$::form->{ship_1}` der
Wert `123.45`, einmal durch `parse_amount` ergibt `12345`, was um
einen Faktor 100 zu viel ist.

Order-Controller: Umwandlung: gemeinsamen Code in eigene Funktion ausgelagert

LXDebug dump_sql_result: Spaltenanordnung je nach Inhalt

Spalten, die komplett numerisch sind, werden rechtsbündig angeordnet;
alle anderen linksbündig.

SEPA: In Details: Buttons »Buchen« und »Zahlungsliste« immer anzeigen

Sichtbare Buttons machen viel klarer, welche Funktionalität es an der
Stelle gibt, auch wenn die Buttons deaktiviert sind.

HTTP-Header: Lebenszeit für Session-ID-Cookie setzen gefixt

Der Name des Parameters lautet `-expires`, nicht `-expire`.

Außerdem den Timeout direkt aus `$::auth` lesen, um denselben
Standardwert zu nehmen, falls der Timeout nicht in der Konfiguration
gesetzt ist.

Inventory: Fehlermeldung gefixt

t/wh/inventory.t: Nach Test richtig aufräumen

Inventory Helper: Fehlerhaften Aufruf mit croak abbrechen statt mit Excception

Inventory Helper: Doku Update

Inventory Helper: Allocation ausgelagert in eigene Datei

Inventory Helper: Auf Number Helper Änderungen angepasst

Inventory: mehr tests

Inventory::Allocation: transfer_object

Inventory: doku typos

Inventory: Stückbehandlung und dispotype no_stock entfernt

Inventory: bestbefore handling

Inventory: production order und recipe features entfernt

Inventory: with_objects cleanup

t/wh/inventory.t: Reservierungen entfernt

Inventory Helper: Reservierungen entfernt

Inventory Helper: _qty auf _number umgestellt

Inventory Helper: Bessere Fehlermeldung bei fehlenden Parametern

Alle Fehler im allocate() des Inventory-Helpers werden nun per
SL::X::Inventory::Allocation Fehlermethode erzeugt,
damit es eine einheitliche Prüfung geben kann.

verbessert egw 12413

Inventory-Helper: Constraints erweitert mit "reserve_for"

Nun können auch ausschließlich Reservierungen allokiert werden

zu egw #11765

Inventory-Helper: Nutzung von falschem Parameter

Bei "reserve_for" muss auch der Inhalt des Parameters genutzt werden,
nicht "chargenumber"

Inventory-Helper: Nur gesetzte Constraints berücksichtigen

Werden als Parameter nicht definierte Constraints übergeben,
werden diese nun übersprungen

Inventory: allocate bevorzugt jetzt früherere Lagerbewegung