Bernd Bleßmann [Thu, 5 Feb 2015 14:44:12 +0000 (15:44 +0100)]
SL::DB::Helpers::Attr as_date geht jetzt auch mit 'now()'.
Ein neu-angelegtes Rose-DB-Objekt mit einer Spalte mit einem
Datums-Default-Wert 'now' liefert 'now()' für diese Methode. Z.B.:
SL::DB::Order->new->itime = 'now()'. Jetzt geht damit z.B.:
SL::DB::Order->new->itime_as_date
Bernd Bleßmann [Thu, 5 Feb 2015 10:47:32 +0000 (11:47 +0100)]
Steuerzone/Zahlungsbedingungen/Buchungskonto in Suchmaske zu Rechnungsberichten …
… aus dem Bereich "Kunde" bzw. "Lieferant" verschoben, da die Daten nicht aus
den Kunden- bzw. Lieferantenstammdaten, sondern aus den Rechnungsdaten gelesen
werden.
Moritz Bunkus [Thu, 5 Feb 2015 09:54:40 +0000 (10:54 +0100)]
CreatePeriodicInvoices: HTML-Formatierung in Langtexten berücksichtigen
Beim Ersetzen der Variablen muss das Format des Textes (HTML oder
normaler Text) berücksichtigt werden, damit Formatierungen richtig
angewandt und die Platzhalter überhaupt erst gefunden werden.
G. Richardson [Tue, 3 Feb 2015 07:34:39 +0000 (08:34 +0100)]
history_erp : Unterscheidung von id und glid
behebt #2493
Es gibt in der Datenbank zwei Sequenzen, mit der die ids von
Datenbankeinträgen gespeichert werden, und die die Historiensuche
betreffen:
glid: ar,ap,gl
id: delivery_orders parts oe customer vendor
In der history_erp gibt es allerdings nur eine Datenbankspalte für
trans_id, wo sowohl ids als auch glids gespeichert werden.
(Wahrscheinlich wurde glid irgendwann mal neu eingeführt, damit man bei
den Buchungen einen durchgängigen Buchungsnummernkreis hat, ohne dies
für die Historie zu berücksichtigen.)
Da das Historienfenster nur eine id als Parameter übergibt kann es also
vorkommen, daß z.B. in einer Artikelhistorie eine Eintrag aus einer
Buchungshistorie erscheint, wenn es eine Buchungs-glid gibt, die gleich
der Artikel-id ist.
Mit diesem Patch wird nun schon im Template festgelegt, ob es sich bei
der Historie um eine Buchung (trans_id_type = glid) oder nicht
(trans_id_type = id) handelt, und die Datenbankabfrage entsprechend
modifiziert. Dies sollte nur die Historie von einzelnen Seiten betreffen
(z.B. Artikel, Kunde, Verkaufsrechnung), nicht die Historiensuchmaschine
unter dem Menüpunkt "System".
Die Modifizierung des SQL-Statements ist allerdings noch recht unschön,
da diese eventuell angepasst werden muß, wenn sich etwas an der
Beschreibung der history_erp Zeilen ändert (wie beispielsweise in Commit 01b4e844b89 ).
Wenn die Historie mal überarbeitet wird sollte besser direkt schon
gespeichert werden, ob es sich um eine Buchung oder nicht handelt, bzw.
den Typ des Objekts, um das es gerade geht.
Und dann wäre es auch noch schön, die Historie in einen Tab zu
verlagern, statt eines Knopfs im Workflow.
Moritz Bunkus [Wed, 4 Feb 2015 13:16:56 +0000 (14:16 +0100)]
Konfigurierbares Angebotsgültigkeits-Intervall: Arbeitstagsprüfung nach Addieren
Die Funktionsweise wurde so geändert, dass zuerst der hier angegebene
Wert (oder 1, wenn kein Wert angegeben) zum aktuellen Datum addiert
wird. Danach wird auf Wochenende geprüft und auf den nächsten Werktag
justiert, sofern notwendig.
G. Richardson [Wed, 28 Jan 2015 16:41:08 +0000 (17:41 +0100)]
get_lists: salesman-case analog zu employee case
mit Commit ca18e0478035f63 ging die Verkäuferauswahl im Verkaufsbericht
kaputt, da durch den all_salesmen-Parameter der param-Wert ALL_EMPLOYEES
nicht benutzt wurde, und die Verkäufer deshalb in all_salesmen statt in
ALL_EMPLOYEES im Template standen.
Um im Verkaufsbericht auch gelöschte Verkäufer zur Auswahl anzuzeigen:
'salesmen' => { "key" => "ALL_SALESMEN", "deleted" => 1 }
Jan Büren [Wed, 28 Jan 2015 16:21:49 +0000 (17:21 +0100)]
Ticket 29 Verknüpfte Belege -> keine Verknüpfung von Rechnung nach Auftrag
Verknüpfung von Rechnung nach Angebot, sowie Auftrag nach Angebot umgesetzt.
Ferner ein einfaches delete $form->{variable_die_resettet_wird} foreach an dieser Stelle
eingebaut (ohne map).
Ferner die Verknüpfung der Belege in eine Schleife gesetzt.
Bernd Bleßmann [Tue, 27 Jan 2015 14:05:59 +0000 (15:05 +0100)]
Rechnungen: Nicht editierbare CVars nicht rendern, aber richtig speichern bzw. drucken.
Die Änderung für Rechnungen (u. Gutschriften) fehlte noch im commit 6b4a71ff376e8337b708127f9f6c63c1d70d0af3
(Nicht editierbare CVars nicht rendern, aber richtig speichern und drucken.)
Jan Büren [Mon, 26 Jan 2015 13:08:31 +0000 (14:08 +0100)]
Aufräumarbeiten verknüpfte Positionen
- converted_from_quotation_orderitems_id entfernt, da es keine
tabelle quotation_orderitems gibt und die variable langfristig nur
verwirrend in der form ist.
- IR.pm auch auf foreach $table_name umgestellt
Jan Büren [Mon, 26 Jan 2015 12:39:41 +0000 (13:39 +0100)]
deliver_order_items_id mit inventory verknüpft
Falls Lieferscheine Warenbewegungen auslösen, sind jetzt auch die
einzelnen Position "rückverfolgbar" und nicht nur der Beleg.
Entsprechende Fremdschlüssel gesetzt
Jan Büren [Sat, 24 Jan 2015 18:01:18 +0000 (19:01 +0100)]
Weitere Positionen verknüpft II
Gutschrift und Rückwartsverknüpfungen umgesetzt. Ferner für
OE.pm und IS.pm den Aufruf von RecordLinks in eine foreach
Schleife gesetzt (einfachere Codewartung).
Kleinigkeiten die mir hier nicht gefällt: converted_from_quotation,
die Variable ist jetzt noch drin und macht "nicht so viel Sinn",
da orderitems nicht zwischen Angebot und Auftrag (oe) unterscheidet.
Ansonsten ist die Positionsverknüpfung z.Z. genauer als die Beleg-Verknüpfung (s.a. #29)
und der nächste Schritt hiefür wäre die Visualisierung an der Oberfläche
G. Richardson [Thu, 22 Jan 2015 16:51:23 +0000 (17:51 +0100)]
Dialogbuchung - Buchen, Storno und Löschen protokollieren
Bisher wurden Dialogbuchungen in der history_erp mit der snumber
"ordnumber" gespeichert, wobei allerdings die trans_id fehlte. Dafür
stand die trans_id in what_done, was die Historiensuche aber nicht
auswerten kann.
Das ergab Einträge in history_erp wie:
id | trans_id | addition | what_done | snumbers
-----+----------+----------+-----------------------+------------
1077 | 100 | SAVED | Buchungsnummer = 100 | ordnumber_
Jetzt wird that ordnumber gl_transaction verwendet.
Für Dialogbuchungen ist in der Historen Suchmaschine nun der Eintrag
"Buchungsnummer" zuständig, bisher wurde dieser für Aufträge verwendet.
Es wird auch wirklich die Buchungsnummer für die Suche verwendet (Spalte
id in gl = trans_id).
Für Angebote und Aufträge werden nun die neuen Felder "Angebotsnummer"
und "Auftragsnummer" verwendet, hier muß man auch nach der Belegnummer
(ordnumber/quonumber), nicht der trans_id, suchen, wie bei den
Rechnungen.
Prinzipiell müßte man die alten Protokollierungen von Dialogbuchungen
rekonstruieren können und auch nachträglich per Skript zumindest
teilweise umwandeln können. Da das aber wahrscheinlich schon immer
kaputt war und scheinbar noch Niemanden ernsthaft gestört hat fängt die
"saubere" Protokollierung von Dialogbuchungen eben mit diesem Update an.
Jan Büren [Thu, 22 Jan 2015 12:01:18 +0000 (13:01 +0100)]
persistente ids für invoice (items)
analog zu do, oe auch die verknüpften items für rechnungen persistent machen.
- invoice_id retrieve_invoice in array übernehmen
- invoice_pos entfernt (war ggf. vor 2006 ähnlich vorgesehen)
- reverse_invoice gekürzt, sodass hier keine invoice gelöscht werden
- delete_invoice erweitert, sodass hier invoice gelöscht wird
- ferner code von IS.pm nach IR.pm portiert (queries in array)
- use_as_new invoice_ids löschen
- ferner bei storno invoice_ids löschen und ...
- bei Verkaufsrechnung Gutschrift
Ferner Kommentare (IR.pm) eingerückt
tests:
Verkaufsrechnung:
gesamten beleg löschen i.O.
update i.O.
als neu speichern i.O.
mittlere position löschen i.O.
Storno i.O.
Gutschrift i.O.
Einkaufsrechnung:
als neu speichern i.O.
Zahlung buchen i.O.
mittlere position löschen i.O.
gesamten beleg löschen i.O.
Storno i.O.
keine Gutschrift möglich
Jan Büren [Thu, 22 Jan 2015 10:58:52 +0000 (11:58 +0100)]
display_row item_ids je nach beleg hinzufügen
zusätzlich is_quotation und is_invoice als status hinzugefügt.
je nach status entsprechend beleg-id (orderitems, delivery_order_items, invoice)
hinzugefügt und den vorgänger (converted_from_(do|oe|quo|)_items_id).
Entsprechend konsequent orderitems_id aus den generellen hidden für rows entfernt,
somit entfällt das Löschen der orderitems_id für Konvertierung von oe -> do|invoice
G. Richardson [Wed, 21 Jan 2015 10:37:14 +0000 (11:37 +0100)]
Partpicker - displayable_name eingeführt und column entfernt
Der Partpicker zeigt jetzt im Autocomplete und bei ausgewählten Artikeln
die Artikelnummer und die Artikelbeschreibung an.
Das Feature column im Partpicker wurde entfernt. Ursprünglich war die
Idee, unterschiedliche Datenbankfelder (als Alternative zu description)
anzeigen zu können, jetzt wird aber einfach durchgängig displayable_name
verwendet.
projects / kivitendo-erp.git / log