Re: Problem in Virtual products... Sequels...

[David E. Jones]

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

David,

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

I said :

future scenarios ?

You 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,

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.

I never answered the question you included above.

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

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* ?

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





-David

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: 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.

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

currencies are only used in prices, isn'it ?


used to deal with multi-currencies ?


this store if none is specified", isn'it ?




with an HTML-title-tooltip might be enough ?






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


desesperately





default). But users may change this default.
http://www.sf.id.au/WE05/indexa.html

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 I suppose also that "Product Store Group" has no effect on currency ? Or in other words, may the "Product Store Group" concept be 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 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 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 *advanced* user's documentation (advanced documentation not user). Or 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 The most consistent behaviour is obtained by IE :(. Here Firefox (All Mozilla browser I guess) is not a good candidate. I 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 Interesting article on <abbr> tag also : http://www.alistapart.com/ articles/hattrick (takes some time to read)

Thanks

Jacques

Haha! Comical tragedies. Sigh.




that "misunderstanding" between us (users) and OFBiz (application).

Jonathon

David E. Jones wrote:

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

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.

currency was EUR, then the variant product's prices would be used.

This all sounds like a misunderstanding.

-David

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

David answered

exist at all. That is true in general, and could even vary by

I don't think we should put in a check or requirement like that

that.>>

Mmm... Strange that a default value might not be overriden in some
case, isn'it ?


could this requirement break something ?

I just tested without prices for virtual and a price in USD for a
variant and another variant with EUR for the same store having USD
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


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

Thanks


Jacques

<<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 currency depending on what people want to do with it. In other words, because there are perfectly valid scenarios where you would not want BTW I agree that it's not a big deal. Just wanted a better interface, different stores for now. Am I missing something here ? Else this last fact close this discussion and should be reported as best user practice.

Jonathon

David E. Jones wrote:

I don't see any problem here.

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

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:

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

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

Variants herit prices from virtual.
Variants may override prices from virtual, hence have different
currencies than virtual.

working yet.


case where I will propose to restrict currency in variants to
virtual's, for the moment.
Of course I understand that in a perfect world we should support

clear.

Thanks for your attention

Jacques

But this last functionnality (regarding currency at least) is not Is that correct ? If yes, I will open a Jira issue for this peculiar 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

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.

Agreed. This will tie up that "loose end". Rather than having
"undefined behavior" (for multiple

products' currencies count and

a different currency for
variants.

currencies), we should at least let users know that their virtual the related variants' don't. Or better yet, prevent users from using

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

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

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.

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

have a
sense. Having variants with different currencies is another
problem...

wonder if having a currency different for virtual and variants

even.

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

and morevover because of your point below.

Yes true, but difficult to manage because product UI is generalised

However, in

set for all variants, for ease
of use if for nothing else.

virtuals.

user-interface sense, users would want to have a "standard price" Hence, I can see why some users might want to tie currency/ price to

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) ?

our info and enhance OFBiz,
though we ourselves have no time to fix this issue. :P

Well, at least we share/discuss what we know so that others can grab

for sure. I just want to know if nobody see drawbacks in
arguments above, or have better ideas  ?


Thanks

Jacques

We may hope so, but I would prefer to do job because else I will wait

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

different variants (eg. some sold in
some countries but not in others).

way. It'll be nice to be able to use different currencies for

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

currency... yet.

help in research; my current project doesn't handle more than 1

either. And I suspect that it may be a large task to do.

I would create a Jira issue for this. This is not a priority for me

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.

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

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

Because

not
be used. And this can fool an user as I have been.

What do you think ?

Jacques

not restrict variants currency to the one set in virtual ? even if someone set variants prices to another currency it will

Sorry,


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

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

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

set

price for a variants this will have no effect. The price

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

virtual had also Competitive and List Prices. So I just
tested by

it was not applied but the virtual price was applied. BTW the adding Competitive and List Prices to the variant WG-9943-B3

same

result.

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

Jacques

Jacopo

smime.p7s
Description: S/MIME cryptographic signature