0016886: Drill down from General Ledger Journal to Financial Account transaction does not work

Openbravo Issue Tracking System - Openbravo ERP
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0016886	Openbravo ERP	09. Financial management	public	2011-04-26 01:27	2011-12-07 13:51

Reporter	pjuvara
Assigned To	mirurita
Priority	urgent	Severity	major	Reproducibility	random
Status	closed	Resolution	fixed
Platform		OS	5	OS Version
Product Version	pi
Target Version	3.0MP6	Fixed in Version
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
Modules	Core
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency Pack	No

Summary	0016886: Drill down from General Ledger Journal to Financial Account transaction does not work
Description	In the General Ledger Journal report, you have a link - Journal Entry - which is supposed to take you to the transaction originating this journal entry. However, in the case of a transaction created in the Financial Account window (for example a movement by GL Item or a Fee) the drill down simply opens the Financial Account window and queries the first account in the table. Instead, it should open the Transactions tab in that window, pointing to the right account and right transaction.
Steps To Reproduce	1) Create a transaction in a bank account; for simplicity create it as a Fee. 2) Wait for the transaction to be posted 3) Run the General Ledger Journal report for today 4) Drill down You will see that you get to the wrong tab, with the wrong data. See attached video (please excuse the audio - my daughter came into the office during the recording). * At minute 00:29 you see that you end up in Cashbook US East Cost (the first record in the Financial Account window) * Instead the drill down should have been to Account "US Bank - Account 1", Transactions tab and record 6. You can see the record at minute 1:01.
Proposed Solution	Do not define two tabs for the same table (financial account) in AD.
Additional Information
Tags	soho
Relationships
Attached Files	IncorrectDrilldown.ogv (4,085,154) 2011-04-26 01:27 https://issues.openbravo.com/file_download.php?file_id=3898&type=bug Error.png (12,905) 2011-09-19 22:52 https://issues.openbravo.com/file_download.php?file_id=4570&type=bug Issue16886_resolved.mpeg (3,818,338) 2011-11-24 11:05 https://issues.openbravo.com/file_download.php?file_id=4780&type=bug

Issue History
Date Modified	Username	Field	Change
2011-04-26 01:27	pjuvara	New Issue
2011-04-26 01:27	pjuvara	Assigned To	=> dalsasua
2011-04-26 01:27	pjuvara	File Added: IncorrectDrilldown.ogv
2011-04-26 01:27	pjuvara	Modules	=> Core
2011-04-26 01:28	pjuvara	Tag Attached: soho
2011-04-26 09:06	dalsasua	Note Added: 0036073
2011-04-26 09:06	dalsasua	Assigned To	dalsasua => eduardo_Argal
2011-04-26 09:06	dalsasua	Reproducibility	always => random
2011-04-26 09:06	dalsasua	Proposed Solution updated
2011-09-19 22:51	psarobe	Note Added: 0041106
2011-09-19 22:52	psarobe	File Added: Error.png
2011-09-19 22:52	psarobe	Assigned To	eduardo_Argal => mirurita
2011-09-19 22:52	psarobe	Priority	normal => urgent
2011-09-19 22:52	psarobe	Status	new => scheduled
2011-09-19 22:52	psarobe	version	3.0RC6.1 => pi
2011-09-19 22:52	psarobe	Target Version	=> 3.0MP4
2011-09-30 10:13	jonalegriaesarte	Note Added: 0041393
2011-10-03 11:01	jonalegriaesarte	Target Version	3.0MP4 => 3.0MP5
2011-10-31 11:57	jonalegriaesarte	Note Added: 0042398
2011-10-31 11:57	jonalegriaesarte	Target Version	3.0MP5 => 3.0MP6
2011-11-24 11:05	mirurita	File Added: Issue16886_resolved.mpeg
2011-11-24 11:07	mirurita	Note Added: 0043144
2011-11-24 11:07	mirurita	Status	scheduled => resolved
2011-11-24 11:07	mirurita	Fixed in Version	=> pi
2011-11-24 11:07	mirurita	Fixed in SCM revision	=> https://code.openbravo.com/erp/devel/pi/rev/ae151cdb869e [^]
2011-11-24 11:07	mirurita	Resolution	open => fixed
2011-12-07 13:51	xabiermerino	Note Added: 0043735
2011-12-07 13:51	xabiermerino	Status	resolved => closed
2011-12-07 13:51	xabiermerino	Fixed in Version	pi =>

Notes

@eduardo_Argal:
In org.openbravo.erpCommon.ad_reports.ReportAcctRedirectUtility.doPost() system determines the URL to display after clicking in the link shown in the left upper corner of the entry.
Here, the following information is provided through the JavaScript link[1] in the html page of the General Ledger Journal window:
- FIN_Finacc_Transaction_ID corresponding to the transaction posted in this entry
- AD_Table_Id for the FIN_Finacc_Transaction table
- DocBaseType for transactions: 'FAT'
With all this information, ReportAcctRedirectUtility servlet builds the URL to be shown.
In case the table is transactions one, the convertTableException function changes it for the financial account one.
Afterwards, the ReportAcctRedirectUtilityData.select() query is executed. This query, with the information provided, throws TWO results: one for the Financial Account tab, and one for the Transactions tab:
select t.name as tableName, tb.name as tabName, w.name as windowName, c.name as columnName
from ad_table t, ad_tab tb, ad_window w, ad_column c
where t.ad_table_id = tb.ad_table_id
  and tb.ad_window_id = w.ad_window_id
  and t.ad_table_id = c.ad_table_id
  and c.iskey = 'Y'
  and t.ad_table_id = 'B129E53BC0E747879F7BA17F0AECEC32' --financial account
  AND (CASE (SELECT MAX(ISSOTRX) FROM C_DOCTYPE D
             WHERE D.DOCBASETYPE = 'FAT'
             AND D.AD_CLIENT_ID = 'FF8080812AFBCB14012AFBD3E373001F')
       WHEN 'N' THEN COALESCE(T.PO_WINDOW_ID, T.AD_WINDOW_ID)
       ELSE T.AD_WINDOW_ID END) = W.AD_WINDOW_ID
------
TableName-TabName-WindowName-ColumnName
FIN_Financial_Account-Account-Financial Account-Account
FIN_Financial_Account-Transactions-Financial Account-Account
This makes that, sometimes, the link navigates to the financial account tab, and other times to the transactions one.
This happens because in AD, we have two tabs defined for the table financial account:
select name, ad_tab_id from ad_tab where ad_table_id='B129E53BC0E747879F7BA17F0AECEC32';
---------------
Name-AdTabId
Account-2845D761A8394468BD3BA4710AA888D4
Transactions-5B9941AC1F6A4529A76FCA7CDA0A7D7A

I guess this was done for one purpose during the APR development. How can we avoid this, without modifying the APR behavior?

[1]: submitPage('DEFAULT', document.frmSecondary, --FIN_Finacc_Transaction_ID-, '4D8C3B3C31D1410DA046140C9F024D17', 'FAT');return false;