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.
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.