1. Yes, @AD_Org_ID@ is intended to transfer data between organizations within the same tenant

2. However, that seems wrong for OrgAccess table, so I guess at least we should not do that for OrgAccess table.

3. For other table, perhaps we can add a parameter to 2Pack to give user the option to export actual AD_Org_ID value (i.e ID value for official id and uuid for non-official id).

Right @Ken Longnan - that’s the intention of UUID map, to transfer data between tenants.

I think the @AD_Org_ID@ is intended to transfer data between organizations within the same tenant, but I’m not sure about its usage (never used it), maybe @Heng Sin Low can review this and advice about the use case Ken is mentioning.

Thanks @Carlos Ruiz , the Pack Out as “Data Single” works.

The idea is ok that to allow exporting data from one org to another org, but refer to below picture, multiple original Orgs they are all replaced by @AD_Org_ID@

Open

The better implementation way maybe we could add feature to allow user to define some kind of UUID map for Org. It means export data as it is (no @AD_Org_ID@), please refer to below picture.

Open

I just want to explain that the general UUID Map feature could be good feature candidate for 2Pack.

1. Export 2Pack data from one Tenant (all real and actual data as they are)

2. Define UUID Map (one org → another org, etc, etc)

3. Import 2Pack data into another Tenant (with the help of UUID Map definition)

Hi @Ken Longnan

I reviewed the code and that seems to be intentional, it is there since the first iDempiere version where @Heng Sin Low rewrote 2Pack.

I think the idea is to allow exporting data from one organization (for example HQ), and then import data on another organization (the login org).

If you want to export the record without that, you can define a Pack Out and use the "Data Single" type.