From: G. Richardson Date: Tue, 3 Feb 2015 07:34:39 +0000 (+0100) Subject: history_erp : Unterscheidung von id und glid X-Git-Tag: release-3.2.0~57 X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/commitdiff_plain/fd8bde53d5f22fe6923a904682dc25f2b3af8a3d?ds=inline;hp=fd8bde53d5f22fe6923a904682dc25f2b3af8a3d 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. ---