Bernd Bleßmann [Fri, 3 Aug 2018 13:08:31 +0000 (15:08 +0200)]
Auftrags-Controller: nur neue Maske/Links hierhin, wenn experimentelle Features an
- in Menüs Verkauf/Einkauf: Links zu Angebot u. Auftrag)
- in Berichten Angebot/Auftrag und Lieferscheine: Links zu Angeboten und Auträgen
- im Presenter (und damit in der Liste der verknüpfte Belege)
- Todo-Liste
Bernd Bleßmann [Fri, 10 Aug 2018 11:01:57 +0000 (13:01 +0200)]
Auftrags-Controller: kein Unterstrich vor privaten Funktionen
In einem Controller wird den von aussen zugänglichen Funktionen "action_"
vorangestellt, deshalb ist zur Unterscheidung das Voranstellen eines
Unterstrichs unnötig und verschlechtert die Lesbarkeit.
Auftrags-Controller: Null-Werte in Eingabezeile von leer unterscheiden.
Die Idee war, bei einem leeren Wert in der Eingabezeile ein default zu
nehmen (Menge => 1, Preis => "bester" Preis, Rabatt => "bester" Rabatt).
Bisher wurde aber nicht zwischen leer und 0 bzw. 0,00 unterschieden, so dass
dann auch die default-Werte genommen wurden.
Das wird jetzt unterschieden.
Jan Büren [Wed, 18 Jul 2018 12:43:33 +0000 (14:43 +0200)]
Liefertermin Erinnerung für Auftrags-Controller
Falls in Mandanten-Konfig aktiviert, wird ein leerer Eintrag in
Liefertermin in Aufträgen beim Speichern oder
beim Workflow 'Speichern und Lieferschein' angemahnt.
Jan Büren [Mon, 16 Jul 2018 10:40:11 +0000 (12:40 +0200)]
bank_transactions.t Testfälle angepasst
Zwei Testfälle (Vorauswahl der Vorschlagsliste) passen aktuell nicht.
Die sind von Odyn 032b03ab96f8ba6d89, dies ist in kivitendo so nicht implementiert.
aqbanking-cli benutzt im Standardprofil transactionCode, und das wurde
auch hier beim umwandeln im Header generiert. Das interne Feld wurde
aber mittlerweile umbenannt zu transaction_code, also wurde
transaction_code nicht mitimportiert. Das hatte dann zur Folge, dass
SEPA Sammelüberweisungen nicht abgeglichen werden konnten.
Jan Büren [Thu, 12 Jul 2018 13:35:16 +0000 (15:35 +0200)]
BankTransaction weniger Code ist mehr Wert
Aufgrund des klarer formulierten PODs kann eine Routine und
eine weitere zu "schwache" Bedingung entfernt werden.
Fast alle kivi-Testfälle inkl. adaptierter odyn-Testfälle laufen sauber durch.
Jan Büren [Thu, 12 Jul 2018 13:20:10 +0000 (15:20 +0200)]
POD Ergänzungen
BankTransaction::save_single_bank_transaction kann nur
1 noch niemals vorher verbuchte Bankbewegung mit n Belegen verbuchen.
Sollte etwas klarer im POD und später in der Methode deutlich gemacht werden.
Nette Idee aus odyn (Start des Gedankens #f09c2b407faa7 Ende des Gedankens #765a3d421e7).
Zwei Sollbruchstellen in odyn, deshalb in kivi neu formuliert:
Sollbruchstellen:
a) Ein Aufruf von BankTransaction::action_list kann Zustände im Datenmodell verändern
b) Der Benutzer kann beliebige Zahlenwerte oder neue Konten in der Dialogbuchungsmaske eingeben
Konsequenz:
-> Zustände des Datenmodells in gl.pl post_transactions ändern, Werte per Rose hierzu aus der DB (und nicht aus $form)
Möglichst viel dem Benutzer auf die Flossen hauen, wenn die Buchungsmaske unlogisch benutzt wird
Martin Helmling [Tue, 26 Jun 2018 14:07:32 +0000 (16:07 +0200)]
Bankimport: Fehler beim Verbuchen von Teilzahlungen: Rollback bei Fehler
Falls ein Fehler auftritt wird kein Rollback von der bereits gemachten Zahlung und dem neuen Recordlink gemacht,
lediglich die Banktransaktion wird nicht verändert
Erweiterung durch ein Test test_bt_error
-> liefert erstmal kein rollback fehler, test dennoch von odyn übernommen (jb)
Bankimport: Rundungsproblem beim Vergleich Rechnungsbetrag - Kontobetrag
Durch explizites Runden konnte die perl Floatingpoint Arithmetik nicht überzeugt werden,
deshalb werden nun die Formatierten Strings der Beträge noch zusätzlich verglichen.
Hiermit wird der "exact_match" beim Vergleich von z.B. 3456,28 und 3456,29 nicht mehr gefunden
Bankimport: Prüfung des reinen Ziffernanteils der Rechnung
Falls Rechnungen in der Rechnungsnummer ein Prefix vor der Nummer haben
und dies nicht exakt im Verwendungszweck der Kontobewegung aufgeführt ist,
wurde dies nicht als Bewertungskriterium herangezogen.
Nun wird dies mit etwas wenig Punkte bewertet.
In diesem einfachen Verfahren wird bei einer Rechnungsnummer 'RE12345' auch ein 'Blabala 12 nix 34 ddd 5' erkannt,
was aber recht unwahrscheinlich ist.
Moritz Bunkus [Tue, 26 Jun 2018 11:57:04 +0000 (13:57 +0200)]
LaTeX-Escaping: gewisse Formen von »no line to end here« vermeiden
Passiert, wenn im HTML so ein Konstrukt existert:
…Text</p><p> <br>
Das wird zu einem Paragraphen, einem Leerzeichen und einem forcierten
Zeilenumbruch:
----schipp----
Text
\newline
----schipp----
Durch die Leerzeile fängt für LaTeX dann dort ein neuer Absatz an. Der
ist soweit leer. Das Leerzeichen am Anfang der Zeile ist kein
Inhalt. Also gibt es aus Sicht von LaTeX dann keinen Zeileninhalt,
sobald es das `\newline` trifft.
Moritz Bunkus [Thu, 21 Jun 2018 11:20:35 +0000 (13:20 +0200)]
Finanzübersicht: »einmalige« Periodizität bei wiederkehrenden Rechnung gefixt
Die Finanzübersicht nutzt die Funktion
`SL::DB::PeriodicInvoicesConfig::calculate_invoice_dates`, um jedes
Ausführungsdatum innerhalb eines Zeitraumes zu berechnen. Dort wurde
»einmalig« fälschlicherweise wie »jeden Monat wiederholen«
behandelt. Dadurch tauchten die solche wiederkehrenden Rechnungen in
der Finanzübersicht in jedem Monat auf, sofern die Konfiguration noch
aktiv ist.
Beim eigentlichen Erzeugen der wiederkehrenden Rechnungen hingegen war
das deshalb kein Problem, weil so eine Konfiguration direkt nach dem
ersten Erzeugen der Rechnung auf inaktiv gesetzt wird.
Moritz Bunkus [Tue, 12 Jun 2018 07:07:27 +0000 (09:07 +0200)]
Kreditorenbuchungen: Flag »cleared« beim Zahlungsbuchen beibehalten
Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.
Das Flag einer Zahlung wird nun beibehalten, sofern:
• die Zahlung bereits vorher existiert hat (Präsenz der
`acc_trans_id`)
• Wert und Konto gleich geblieben sind
Moritz Bunkus [Tue, 12 Jun 2018 07:00:00 +0000 (09:00 +0200)]
Debitorenbuchungen: Flag »cleared« beim Zahlungsbuchen beibehalten
Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.
Das Flag einer Zahlung wird nun beibehalten, sofern:
• die Zahlung bereits vorher existiert hat (Präsenz der
`acc_trans_id`)
• Wert und Konto gleich geblieben sind
Moritz Bunkus [Mon, 11 Jun 2018 14:31:11 +0000 (16:31 +0200)]
Einkaufsrechnungen: Flag »cleared« beim Zahlungsbuchen beibehalten
Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.
Das Flag einer Zahlung wird nun beibehalten, sofern:
• die Zahlung bereits vorher existiert hat (Präsenz der
`acc_trans_id`)
• Wert und Konto gleich geblieben sind
Moritz Bunkus [Mon, 11 Jun 2018 13:55:25 +0000 (15:55 +0200)]
Verkaufsrechnungen: Flag »cleared« beim Zahlungsbuchen beibehalten
Existierende Zahlungen werden aus acc_trans komplett gelöscht und neu
eingefügt. Dabei geht der Status des Flags »cleared« verloren, der
anzeigt, dass eine Zahlung mit dem Konto abgeglichen wurde.
Das Flag einer Zahlung wird nun beibehalten, sofern:
• die Zahlung bereits vorher existiert hat (Präsenz der
`acc_trans_id`)
• Wert und Konto gleich geblieben sind
Jan Büren [Mon, 4 Jun 2018 09:04:57 +0000 (11:04 +0200)]
SelfTest false positive vermeiden
$self->all_passed enthält nicht mehr den Zustand, ob alle
Tests erfolgreich waren. Als Workaround auf zwei negativ
Status-Meldungen prüfen, die bei Problemen gesetzt sind.
Jan Büren [Mon, 4 Jun 2018 08:57:03 +0000 (10:57 +0200)]
Payment::pay_invoice with skonto -> Steuersatz ist eindeutig
tax_id in acc_trans definiert sicherer den Steuersatz als der
taxkey (Steuerschlüssel von DATEV), s.a. FK-Constraint:
"acc_trans_tax_id_fkey" FOREIGN KEY (tax_id) REFERENCES tax(id)
Bernd Bleßmann [Wed, 30 May 2018 13:26:18 +0000 (15:26 +0200)]
CSV-Helfer: Leere Zeilen ignorieren.
Als leere Zeilen hier gelten auch Zeilen, die nur das Trennzeichen enthalten.
Mit leeren Zeilen gab es immer wieder Probleme, teils mit schwer zu
interpretierenden Fehlermeldungen, teils mit nicht gewünschtem Verhalten, z.B.
beim Warenimport das Anlegen neuer Artikel für jede leere Zeile.
Bernd Bleßmann [Mon, 28 May 2018 09:29:46 +0000 (11:29 +0200)]
Auftrags-Controller: fake id für Items nach Workflow setzen.
Für items, die hinzugefügt werden, also noch nicht in der DB gespeichert sind,
muss eine fake id gesetzt werden, damit diese bei den actions, die einzelne
items betreffen, auch richtig gefunden/zugeordnet werden können.
Das behebt z.B. einen Fehler mit falschen Preisquellen nach dem Workflow
Angebot -> Auftrag, wo immer die Preisquellen der ersten Postion im Dialog
verwendet wurde.
Jan Büren [Tue, 22 May 2018 06:52:09 +0000 (08:52 +0200)]
Fix: #354 Zahlungsbedingung falsch bei Workflow Lieferschein -> Rechnung
Bisher wurde nur nach dem ersten Treffen der richtigen Auftragsnummer gesucht.
Dabei konnten Zahlungsbedingungen vom Einkaufs-Auftrag nach Verkaufs-Rechnung übernommen werden.
Entsprechend zusätzlichen Filter nach vc_id eingebaut.
Bernd Bleßmann [Wed, 16 May 2018 14:58:36 +0000 (16:58 +0200)]
Auftrags-Controller: Kunde/Lieferant vorbelegen, wenn deren id übergeben wird
Für die Workflow-Links aus den Kunden-/Lieferantenstammdaten heraus werden
die customer_id oder vendor_id berücksichtigt und die Kunden-/Lieferanten-
abhängigen Attribute im Order-Objekt entprechend gesetzt.
projects / kivitendo-erp.git / log