8.2 Currency rate by document or by transaction - IDEMPIERE-4083

[mpow...@gmail.com]

this is with reference to the new 8.2 feature " currency rate by document or by transaction" documented here: https://idempiere.atlassian.net/browse/IDEMPIERE-4083.

This new feature is very useful, in fact, a required feature because there are situations in which we need to overwrite a document's foreign currency rates manually, for us in Thailand n cases like these: specific hedge rates at the time of foreign currency payment (with underlying forward contract), customer export invoices in foreign currency to be recorded at a specific currency rate, other than the government's announced standard conversion rates.

But we encounter the following problem with the new solution:

- We operate in a multi-country/multi-currency/multi-organization on a single-client environment. 

- Every country in our single client has its own local accounting schema, THB in Thailand, IDR in Indonesia, AUD in Australia etc.

- The primary schema represents a common currency, our group currency USD, as there can only be a single primary schema. 

Here is where we encounter a problem: 

- The document conversion rates we need to manually enter are between any foreign currency (e.g. EUR, USD etc.) and the LOCAL currency (THB in TH, IDR in ID) but what the system currently does is to apply the manual conversion rate between the foreign currency and the primary schema currency, e.g. EUR to USD (assuming the primary schema is the local currency). This isn't the case for a multi-country and single-client setup.

- As a further consequence, for foreign currency USD, the conversion rate field is not displayed because the USD is the primary schema currency.

So in a multi-country, multi-schema setup, the new currency conversion solution should support the conversion between any foreign currency (incl. the primary schema's currency) into a "local" schema currency, that is, any schema other than the primary schema. In our example:

Payment in foreign currency EUR:

In TH, enter manual conversion rate from EUR>THB Schema

In AU, enter manual conversion rate from EUR>AUD Schema

Or more generally: Apply the specified currency rate to the accounting schema the (payment) document's ad_org is a member of but NOT to the primary schema.

Perhaps this can be solved using a switch in the system configuration table.

Cheers,

Michael

 

[Heng Sin Low]

Part of the issue here with this request is in the current model, we don't actually have a place to specify the primary schema for an organization. We do have the organization only field at accounting schema table but that doesn't quite work for the primary schema purpose since the app's doesn't stop you from having multiple accounting schema with the same organization only value.

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/b935699c-c760-470c-b2e4-cd3429e8f57an%40googlegroups.com.

[mpow...@gmail.com]

Hello Hengsin, 

I  agree. Given the current limitation, could we still consider a workaround which allows us to define (e.g. via System Configuration) whether the primary or the alternative schema - the organization is a member of - is being used for manual currency rate conversion. In this workaround, a problem would arise if an organization is a member of multiple alternative schemas (with different currencies) because there is only one manual currency conversion rate per document.

Other alternatives I can think of:

- Display an accounting schema field for selection in the document header when manually entering a document conversion rate with a meaningful default value, e.g. primary schema. All other schemas would be converted using the specified conversion type, e.g. spot.

- We change the accounting schema logic where each organization is assigned to a primary schema with an option to assign the organization to other alternative schemas. 

What do you think?

[Heng Sin Low]

I guess the following approach is workable:

1. add a system config to use orgonly accounting schema as the primary schema for org

2. when an org is a member of multiple schema (through org only flag), we take the first accounting schema (order by c_acctschema_id) as the primary accounting schema

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/79c2183d-fd93-4139-91b7-4b4910709890n%40googlegroups.com.

[Hiep Lq]

"order by c_acctschema_id" quite magic and hard to control maybe new checkbox "is primary accounting" on "Accounting Schema" tab

it display when System config "on" and choose a org

Lê Quý Hiệp
Email: hie...@hasuvimex.vn
Skype: admin.hasuvimex

Company: Thanh Hoa Fishery Import - Export J.s.c  (Hasuvimex) DL 47

Add: Lot E, Le Mon Industrial Zone, Thanh Hoa, Vietnam

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/CAC%3D6jXH1RY4-8d3vFYp9o-sqTR79TMAKqC5UoMLqKKCAEGk1eA%40mail.gmail.com.

[mpow...@gmail.com]

@Hengsin, Hiep, thanks for your inputs! 

a. A client's primary accounting schema is defined at client-creation under Client>Client Info>Primary Accounting Schema (e.g. USD).

b. I fully agree with you on a solution using a system configuration where we can 'overwrite' the client's primary schema (USD) by defining an organization-specific primary accounting schema, e.g. in a local currency such as THB, MYR, EUR

c. If an organization with org-specific primary schema is ALSO a member of another accounting schema or schemas (through org only flag), e.g. the USD schema, GL postings should be generated for all schemas the organization is a member of (today's functionality), however, the primary schema - e.g. important for document conversion purposes, is the one defined in b.)   

d. If an organization has NO org-specific primary schema in system configuration, the primary schema is the one defined at client level. See a.)

Do you agree?

[Heng Sin Low]

yes, that sounds good. what do you think about hiep's suggestion above ?

On Wed, Feb 24, 2021 at 4:56 PM mpow...@gmail.com <mpow...@gmail.com> wrote:

@Hengsin, Hiep, thanks for your inputs! 

a. A client's primary accounting schema is defined at client-creation under Client>Client Info>Primary Accounting Schema (e.g. USD).

b. I fully agree with you on a solution using a system configuration where we can 'overwrite' the client's primary schema (USD) by defining an organization-specific primary accounting schema, e.g. in a local currency such as THB, MYR, EUR

c. If an organization with org-specific primary schema is ALSO a member of another accounting schema or schemas (through org only flag), e.g. the USD schema, GL postings should be generated for all schemas the organization is a member of (today's functionality), however, the primary schema - e.g. important for document conversion purposes, is the one defined in b.)   

d. If an organization has NO org-specific primary schema in system configuration, the primary schema is the one defined at client level. See a.)

Do you agree?

Cheers!

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/00ed0191-ba92-4690-97e4-5782d7a1e4ddn%40googlegroups.com.

[mpow...@gmail.com]

I agree with Hiep that the order by logic is hard to control. 

If I understand Hiep correctly, his solution would allow us to define organization-specific schemas, which is in line with what I proposed. 

I'm ok with this approach but what's important that we maintain today's ability for an organization  to be a member of multiple schemas for parallel accounting, for example MYR schema and USD schema.

Also, if we change the primary schema approach, we need to decide what to do about today's primary schema logic: Client>Client Info>Primary Accounting Schema (e.g. USD).