Jan Büren [Wed, 3 Aug 2016 12:55:24 +0000 (14:55 +0200)]
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.
Jan Büren [Wed, 3 Aug 2016 12:50:44 +0000 (14:50 +0200)]
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
Jan Büren [Mon, 1 Aug 2016 13:50:15 +0000 (15:50 +0200)]
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.
Sven Schöling [Thu, 21 Jul 2016 09:23:35 +0000 (11:23 +0200)]
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:
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.
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
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)' 3160b08888814ec731f26dab9db580f214df54e
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.
Sven Schöling [Wed, 20 Jul 2016 11:37:47 +0000 (13:37 +0200)]
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.
Sven Schöling [Wed, 20 Jul 2016 08:55:02 +0000 (10:55 +0200)]
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.
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
Moritz Bunkus [Mon, 18 Jul 2016 08:20:40 +0000 (10:20 +0200)]
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.
Martin Helmling [Thu, 28 May 2015 15:51:42 +0000 (17:51 +0200)]
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,
Sven Schöling [Thu, 14 Jul 2016 15:24:14 +0000 (17:24 +0200)]
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.
Moritz Bunkus [Tue, 12 Jul 2016 13:51:16 +0000 (15:51 +0200)]
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.
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.
G. Richardson [Thu, 9 Jun 2016 16:41:43 +0000 (18:41 +0200)]
Neues Recht "Verknüpfte Belege"
Hintergrund ist, daß es derzeit z.B. möglich ist, daß Benutzer die nur
Rechte haben um Angebote zu sehen, über die verknüpften Belege eine
Übersicht über alle anderen Belege aus dem Workflow, bis hin zur
Rechnung zu sehen. Zumindest eine Zusammenfassung (Datum, Beträge), ohne
jedoch die Belege öffnen zu können. Dies ist aber nicht immer gewünscht,
daher kann man jetzt die Reiter für verknüpfte Belege komplett
ausblenden.
Eine bessere Lösung wäre nur die Belege anzuzeigen, für die der Benutzer
auch Bearbeitungsrechte hat.
G. Richardson [Thu, 23 Jun 2016 14:41:50 +0000 (16:41 +0200)]
PriceTaxCalculator - Währungskurs abhängig von Belegtyp
Bei OE-Belegen wird alles in der Belegwährung gespeichert, daher keine
Wechselkursumrechnung (exchangerate = 1).
Bei Rechnungsbelegen wird hingegen der Währungskurs berücksichtigt.
G. Richardson [Tue, 14 Jun 2016 13:27:56 +0000 (15:27 +0200)]
AR/AP.pm - Währungskonten prüfen
Vor dem Buchen von Zahlungen mit Wechselkursen auf die Standardkonten
von Wechselkurserträgen und Wechselkursaufwendungen prüfen. Abbrechen
wenn keine definiert, ansonsten geht sowieso die SQL-Abfrage kaputt.
G. Richardson [Fri, 17 Jul 2015 09:07:59 +0000 (11:07 +0200)]
Neue PaymentHelper Funktion create_bank_transaction
Simuliert den MT940-Import und erstellt gültige Kontoauszugsimportzeilen für
Rechnungen, mit denen man z.B. den "Kontoauszug verbuchen" testen kann.
Ist also v.A. für Tests oder beim Entwickeln nützlich.
1. Ich habe keine Ahnung, was diese unmotivierten -> sollten, die ab
und zu einfach so auftraten. Sie sind nicht nur überflüssig, sie sind
nach dem DocBook-Schema an dieser Stelle auch einfach ungültig.
2. Text darf nach dem DocBook-Schema nur in bestimmten Nodes erscheinen,
nicht einfach innerhalb einer <section>. Da fehlte schlicht die
Einfassung in <para>.
Waldemar Toews [Tue, 30 Jun 2015 12:01:03 +0000 (14:01 +0200)]
BUG-Fix: Vergleich der Artikel (bestellt, bezahlt) angepasst.
Die Erzeugnisse in Rechnungspositionen werden in Positionstabelle
(invoice) zusammen mit Bestandteilen gespeichert. Bei der Prüfung was
bestellt und was bezahlt wurde, kommen dann falsche Ergebnisse.
In SQL: Rechnungspositionen ohne Bestandteile des Erzeugnisses mit
Positionen aus dem Auftrag vergleichen.
BUG-Fix: Die Anzeige der fällige Wiedervorlagen ist falsch (zu hoch).
In ERP-Dokumenten werden werden "zu viele" Wiedervorlagen angezeigt.
Bei der Berechnung werden sowohl offene als auch geschlossene Wiedervorlagen berücksichtigt.
BUG-Fix: Kreditorenbuchungen: Währung wird nicht übernommen.
Es werden IMMER die Währungeinstellungen vom Lieferanten genommen.
Variable currency wird beim Hollen der Lieferanten-Daten überschrieben.
Den Variablen-Wert vom Stammdaten-Hollen gesichert und danach zurückgeschrieben.
Waldemar Toews [Thu, 22 May 2014 09:13:51 +0000 (11:13 +0200)]
BUG-Fix: Funktion "Erzeugnis fertigen" sucht Bestandteile im falschen Lager.
Bei Lager->Erzeugnis fertigen werden die Bestandteile anscheinend im "Ziellager" gesucht.
Richtig wäre die einzelnen Bestandteile aus dem jeweiligen Standardlager auszulagern.
Auch die Fehlermeldung wurde entsprechend ergänzt:
"Zum Fertigen fehlen ... im Lager ..."
G. Richardson [Tue, 28 Jun 2016 08:44:58 +0000 (10:44 +0200)]
"Kontoauszug verbuchen - SEPA-Zahlungen berücksichtigen und schließen
Erstellt man SEPA-Überweisungen für das Bankprogramm, verbucht die
Zahlungsausgänge aber per "Kontoauszug verbuchen", wird der
ursprüngliche SEPA-Prozess unterbrochen. Dort war vorgesehen, daß man
nach dem Import/Export den SEPA-Export manuell abschliesst, wodurch
automatisch die betroffenen Rechnungen bezahlt wurden, mit dem
Zahlungsdatum laut SEPA-Export. Entfällt dieser Schritt wegen Verbuchung
per Kontoauszug bleiben die SEPA-Exporte hingegen immer offen. Außer daß
die Liste immer weiter wächst hat das auch den Effekt, daß für
Rechnungen mit noch offenen SEPA-Exports nicht erneut SEPA-Überweisungen
erstellt werden können, was bei Teilzahlungen aber erforderlich ist.
Mit dieser Erweiterung wird nun beim "Kontoauszug verbuchen" auch
geprüft, ob es für die Rechnung eine SEPA-Anweisung gibt, und hierfür
extra Punkte vergeben. Außerdem wird bei erfolgreicher Zahlung der
Rechnung auch der SEPA-Export für die Rechnung geschlossen.
Wenn dabei festgestellt wird, daß alle Export einer SEPA-Export-Gruppe
bezahlt sind, wird auch die SEPA-Export-Gruppe geschlossen.