Re: Currency in store and eCommerce

[David E. Jones]

-David


On Feb 4, 2007, at 1:05 AM, Jacques Le Roux wrote:

The main event for this in the ecommerce controller.xml file is "setSessionCurrencyUom".

David,

Actually, these were answers to the other parts of your email, which
is why I put them below the part I was responding to.

Jacques


----- Original Message -----
From: "David E. Jones" <[EMAIL PROTECTED]>
To: <user@ofbiz.apache.org>
Sent: Sunday, February 04, 2007 2:48 AM
Subject: Re: Problem in Virtual products... Sequels...

Yes I know. The first part below was only to ask new questions. Anyway they are answered by your last (new and very interesting) information. Since "From ecommerce you can select a different currency at run-time." explicitly shows that 1 store can deal with more that 1 currency. However, how an user can select a currency, please ?

On Feb 3, 2007, at 2:57 PM, Jacques Le Roux wrote:

David,

I try to understand things deeper. Many questions...

I said :
<<So as I thought it's better to handle different currencies in
different stores for now. Am I missing something here ? >>
    Is that always true ? Is it a recommended best practice to do
so (having 1 store by currency) ? Are there other scenarios,
future scenarios ?

You said :

No. The price stuff will look for prices according to the currency
set on the ProductStore.

and

NO! Not totally correct. In this case of the ProductStore
currency was
USD then the virtual product's prices would be used. If the
ProductStore
currency was EUR, then the variant product's prices would be used.

Actually, these were answers to the other parts of your email, which
is why I put them below the part I was responding to.

I never answered the question you included above.

So why the string "Default Currency Uom Id" for the currency field
in Catalog/Store ? Would not "Currency Uom Id" be more
appropriate as this data looks like more a constraint (can't be
overriden), at least for products ? Are there other reasons to put
*Default* ?

The word "Default" does have a very important meaning there. It was
not chosen lightly or randomly.

As a general recommendation, in any situation like this I highly
recommend looking for reasons why something IS the way it is rather
than looking for reasons why it "shouldn't be" the way it is.

This goes back to the "OFBiz Committers Roles and Responsibilities"
page:

http://docs.ofbiz.org/x/mQ

Especially the section with the bold first sentence of: "Rule #2 for
a committer is the same as for a scientist: read before you write."

In this case the trip up, from a purely logical perspective, seems to
be with the incorrect assertion "this data looks like more a
constraint (can't be overriden)", but it _can_ be overridden. From
ecommerce you can select a different currency at run-time.

-David

In Undersun User Documentation (thanks David and Andy for this !) I
read in explanation of the field "Default Currency Uom Id" :
"Which national currency will be used if none is
specified.". Hence "Default" I suppose. But it seems not to act as
a default value from what you stated above David. On the
contrary, it specifies the currency that will be chosen between
several. I use chosen because I can't see a case where "no currency
is specified" (and where a default value will then be used).
Because when you define a price a currency is always set. And
currencies are only used in prices, isn'it ?

I suppose also that "Product Store Group" has no effect on

used to deal with multi-currencies ?

I understand that a product may be shared between stores thru
catalogs/categories and may have prices in each currency needed by
each store. In such cases, one more time "Default Currency Uom Id"
defines the currency of the store and not "a default currency for
this store if none is specified", isn'it ?

I agree with Jonathon that the error message is too general and
should be changed to help users identifie the real origin of the
problem. But note that this is at the functionnal level. Idid not
look at the code. Perhaps under the hood it's more complicated...
Especially if the routine that calculates prices is widely
generalised.

Perhaps it's only a matter of words, replacing "Default Currency
Uom Id" by "Currency Uom Id for this store" and explaining more
with an HTML-title-tooltip might be enough ?

Also I'm here trying to grab knowledge at the User level (unlike
for instance Jonathon wich claims to reverse) and perhaps OFBiz was
not conceived in this spirit. That might explain the lack of

simply ERPs can't be or rather are difficult to be documented for
users (I'm not an ERP veterans) ?

Subtle slight nuances, great effects...  Everybody still there ?
Not sure even if I am...

Actually what I'm trying to do is to find a way to put the most
possible "advanced and accurate documentation" easily at reach of
users, that's all. In order to do so I tested the rendering of HTML
field title attribute (tooltip in widgets) in 4 browsers on
Windows.

Browser                length max    duration    wrap lines
---------------------------------------------------------
Firefox 1.5.0.9        80 char        5 sec        never
IE 6                     at least 1000    5 sec        if in source
IE 7                     at least 1000    5 sec        if in source
Opera 9.02.         at least 1000    no limit      always

The most consistent behaviour is obtained by IE :(. Here Firefox
(All Mozilla browser I guess) is not a good candidate. I
desesperately
looked for an extension (or even an hack, mm...mm) but did not find
any.

It might be interesting to have behaviours on Linux (Mmm..Gnome,
KDE, XFCE,...) and Mac

Note also that title used as tooltip is often not recommended for
accessiblity reasons (many screenreaders don't read title text by
default). But users may change this default.
http://www.sf.id.au/WE05/indexa.html

Interesting article on <abbr> tag also : http://www.alistapart.com/
articles/hattrick (takes some time to read)

Thanks

Jacques

currency ? Or in other words, may the "Product Store Group" concept be *advanced* user's documentation (advanced documentation not user). Or

Haha! Comical tragedies. Sigh.

Thanks for that very concise and definitive "documentation" for
this aspect, David.

I can understand how Jacques (and me) could've easily been misled
by our test cases; outcome a
little too ambiguous (no proper warning messages?). Digging into
codes directly would've avoided
that "misunderstanding" between us (users) and OFBiz (application).

Jonathon

David E. Jones wrote:

On Feb 2, 2007, at 4:06 AM, Jacques Le Roux wrote:

Jonathon, David,

David,

As I understand from Jacques issue descriptions:

1. Price set for Virtual product in USD
2. Price set for related Variant product in EUR
3. Price for Variant is not used at all.

If that's the case, it is a bug.

I haven't tested this out.

Jacques, is the above correct?

Yes totaly correct.

NO! Not totally correct. In this case of the ProductStore
currency was
USD then the virtual product's prices would be used. If the
ProductStore
currency was EUR, then the variant product's prices would be used.

This all sounds like a misunderstanding.

-David

David answered
<<The only reason to put a price on the virtual product is to
act as a
default, so it is totally optional and for many product sets may
not
exist at all. That is true in general, and could even vary by
currency depending on what people want to do with it. In other
words,
I don't think we should put in a check or requirement like that
because there are perfectly valid scenarios where you would not
want
that.>>


case, isn'it ?

BTW I agree that it's not a big deal. Just wanted a better
interface,
could this requirement break something ?

I just tested without prices for virtual and a price in USD for a

as default currency. The variant with EUR price is not accepted :
    *  Could not find a valid price for the product with ID
[WG-9943-B4], not adding to cart.

So as I thought it's better to handle different currencies in
different stores for now. Am I missing something here ? Else
this last
fact close this discussion and should be reported as best user
practice.

Because I guess we need more user doc than dev at this moment...

Thanks


Jacques

Mmm... Strange that a default value might not be overriden in some variant and another variant with EUR for the same store having USD

Jonathon

David E. Jones wrote:

I don't see any problem here.


information for a certain type, currency, etc is not found and
the
product is a variant it will find the corresponding virtual
product and
look for the price information there.

What else could/would it do?

What is the bug here?

-David


On Feb 1, 2007, at 12:50 AM, Jacques Le Roux wrote:

The code looks for price information on the product. If no price

Finally, I want to make an abstract of what I understand :

Variants herit prices from virtual.

currencies than virtual.
But this last functionnality (regarding currency at least) is
not
working yet.

Is that correct ? If yes, I will open a Jira issue for this
peculiar
case where I will propose to restrict currency in variants to
virtual's, for the moment.

different currencies for different variants. But I guess this
can
wait... Because I'm only reasoning at the businness level for
the
moment. And I guess at the technological level things may be
less
clear.

Thanks for your attention

Jacques

Variants may override prices from virtual, hence have different Of course I understand that in a perfect world we should support

Jonathon,

Jacques,

I was asking myself, in a principe of reality, if we
should not,
for the
moment, restrict variants currencies to their virtual's.

"undefined behavior" (for multiple
currencies), we should at least let users know that their
virtual
products' currencies count and
the related variants' don't. Or better yet, prevent users
from using
a different currency for
variants.

Agreed. This will tie up that "loose end". Rather than having

pragmatic ! I think I will create at least a Jira  issue for
this

Later was what I was suggesting. it's easy to do, in one word :

if

nobody disagree (with strong arguments ;o)

A sticky issue: which currency/price takes precedence,
variant or
virtual?
I'd say variant prices should override virtual.

virtuals are

sense). So I
wonder if having a currency different for virtual and
variants
have a
sense. Having variants with different currencies is another
problem...

Yes variants should override. But has this a sense ? Because never used as product, they are abstract (in Oriented Object

Hmm. In OO sense, it doesn't make sense that virtuals have
a price
even.

Yes true, but difficult to manage because product UI is
generalised
and morevover because of your point below.

However, in
user-interface sense, users would want to have a "standard
price"
set for all variants, for ease
of use if for nothing else.
Hence, I can see why some users might want to tie currency/
price to
virtuals.

Yes true, OO heritage ;o). So remains the case of different
currencies for different variants. But is that realistic
(this is a

real

question for real people) ?

Well, at least we share/discuss what we know so that others
can grab
our info and enhance OFBiz,
though we ourselves have no time to fix this issue. :P

We may hope so, but I would prefer to do job because else I
will wait
for sure. I just want to know if nobody see drawbacks in
arguments above, or have better ideas  ?


Thanks

Jacques

Jonathon

Jacques Le Roux wrote:

Jonathon,

From: "Jonathon -- Improov" <[EMAIL PROTECTED]>

I think David's point about supporting multiple
currencies is
valid, ie OFBiz should operate that
way. It'll be nice to be able to use different currencies
for
different variants (eg. some sold in
some countries but not in others).

Yes I totally agree.

However, I strongly suspect that's not exactly how it
works now.

I agree too. Yes for the moment people wanting to deal with
multiple currencies create a store by currency, I guess.

Let me know if anyone needs me to
help in research; my current project doesn't handle more
than 1
currency... yet.

I would create a Jira issue for this. This is not a
priority for me
either. And I suspect that it may be a large task to do.

So

that's why I was asking myself, in a principe of reality,
if we
should not, for the moment, restrict variants currencies to

their

virtual's.

A sticky issue: which currency/price takes precedence,
variant or
virtual? I'd say variant prices
should override virtual.

virtuals are never used as product, they are abstract (in

Yes variants should override. But has this a sense ? Because

Oriented

Object sense). So I wonder if having a currency different for

virtual and variants have a sense. Having variants with

different

currencies is another problem...

Thanks for your thoughts

Jacques

Jonathon

Jacques Le Roux wrote:

Do you mean that it should work like I tried to use it
or that we
should make it work, or  ?

Jacques

----- Original Message -----
From: "David E. Jones" <[EMAIL PROTECTED]>
To: <user@ofbiz.apache.org>
Sent: Wednesday, January 31, 2007 10:45 PM
Subject: Re: Problem in Virtual products

The point is to support prices in multiple currencies
simultaneously...

-David


On Jan 31, 2007, at 1:41 PM, Jacques Le Roux wrote:

Finally after my apologies I thought a bit about this.
Should we
not restrict variants currency to the one set in
virtual ?
Because
even if someone set variants prices to another
currency it will
not
be used. And this can fool an user as I have been.

What do you think ?

Jacques

Sorry,

I used euro and not dollar for variant prices. So
yes, you are
right Jacopo and sorry

Jacques

----- Original Message -----
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
To: <user@ofbiz.apache.org>
Sent: Wednesday, January 31, 2007 5:02 PM
Subject: Re: Problem in Virtual products

Jacopo,

From: "Jacopo Cappellato" <[EMAIL PROTECTED]>

Jacques Le Roux wrote:

Vamsi

When I am selecting configuration it is not
showing the
product price with
configuration.

AFAIK there are no specific prices for variants.
If you
set a
price for a variants this will have no effect. The
price
set

for

the

virtual product will be used.

I'm pretty sure that the variant price is used if
set, it
will
appear as
soon as you add the variant to the cart.

I tested it before by creating a default price for
WG-9943-B3
and
it was not applied but the virtual price was
applied. BTW the

tested by
adding Competitive and List Prices to the variant
WG-9943-B3

virtual had also Competitive and List Prices. So I just

same

result.



Jacques

Am'I missing something here, promotions, prices rules ?

Jacopo

smime.p7s
Description: S/MIME cryptographic signature