Import/Export for tables that use account elements


It is not easy possible to share tables between implementations that use account elements. I want to share financial reports like balance sheet, win&loss, tax declaration between different users who use the same (or a similar) coa file.

atm there is no guarantee that the ids of the account elements between different instances (or different clients in one instance) are the same. If I want to save a financial report (like a balance sheet) as a 2pack then the "C_ElementValue_ID" is written in the XML file as the id of the Element. It would be better to save it as the value. Then we can load a fine crafted balance sheet into any other installation that uses the same account elements.

A further improvement came into our mind while discussing with hieplq (thanks!). We can use a new field "report_account" in the account element table (instead of "value") to identify the account. This allows e.g. a "win from sold goods" position in a w&l report to use the right account in different numbered coas. This will lead to an w&l 2pack that can be used in germany and in austria (they have different coa numbering schemes). For this to work smoothly we have to adapt the coa importer to load (or create) this additional column.




Hiep Lq
September 4, 2014, 8:33 AM

sorry by miss code comment. i will explain.

1. when import run by GUI, all tab is init at show window.
so when run import by process, i must add below code.

if ((gridTab.getWindowNo() == -1) && gWin != null){

this code can move to process (TestImportData), but when you write many TestImportData, code is duplicate.

2. when import run by GUI, when import success, need reload data for user.
when import by process, not need reload data. (if still load will have exception)
below code for this.

if (gridTab.getWindowNo() != -1)

if (gridTab.getWindowNo() != -1)

Carlos Ruiz
September 4, 2014, 1:32 PM

Thanks for the detailed explanation, it sounds good - I'll take a look later.

Carlos Ruiz
August 26, 2015, 8:41 PM

, I was reviewing the patch you attached IDEMPIERE-1976.patch - but I don't see what is intended for. I made lots of tests with and without the patch and the behavior is the same.

Is this fixing something?


Carlos Ruiz

Hiep Lq
August 28, 2015, 9:34 AM

thanks for review.
recall explain in prev comment.
this pack has tow patch:
1. init tabs, because we run imp/exp without GUI.
2. don't reload after import, because i see error when test.

(1) it's ok to let outter process as ImportCSVProcess init tab. but it will make duplicate code when you has more process same ImportCSVProcess. other solution is a static method.

(2) i also can't redo for error message. but it still necessary, because in process mode, not need reload data.

Thomas Bayen
May 9, 2020, 4:44 PM

I reproduced the problem at iDempiere Triage Day. It is still there.

I created a new accounting element, added a line in the t financial report for the blaance sheet and wrote a packout entry to write the rp_reportlineset, pa_reportline and rp_reportsource. In the resulting zip file was an xml file that contained the newly created pl_reportsource entry. It used the uuid to link to the element.

To claryfy the problem: If another installation created a similar accounting sheet manually (not copeid by 2pack from my installation) but uses the very same coa and has the same accounting element numbers, then it should be possible to share a financial report as a 2pack.

Im am not able to check the given patches and like someone to do that.


Carlos Ruiz


Thomas Bayen


Tested By



Affects versions