You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Vamsi <va...@gmail.com> on 2007/01/31 06:29:39 UTC
Problem in Virtual products
Hi,
I created a virtual configurable product and added three
variants and 1 multichoice configuration to that(Varaint product id's
2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
display varaints in different way . When I am trying add product to the cart
it is giving a error "Tried adding the virtual product XXXX(productid :
2000) adding ,not added " .I observerd in the request parameter(I changed
form method to "get") the product id that is going to add is 2000 when
change that product id to one of the variant product it is working fine and
show it in shopping cart list.
We can't add a virtual product to shopping cart?
When I am selecting configuration it is not showing the product price with
configuration.
My question is how the fillproductconfigwrapper method identifies the
configuration parameter from request
I am thankful for any kind of help
regards
Vamsi
--
View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
Vamsi,
I can confirm what Jacopo is saying here. The variant price may not be shown in the ecommerce
screen, but it definitely is used in calculating the costs in your cart.
Jonathon
Jacopo Cappellato wrote:
> 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.
>
> Jacopo
>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jonathon,
Thanks for your tip. As a commiter I have to use OFBiz OOTB with last version to be sure to rely on what is supposed to be tested.
BTW, what do you thinkof my last response to David ?
Thanks
Jacques
----- Original Message -----
From: "Jonathon -- Improov" <jo...@improov.com>
To: <us...@ofbiz.apache.org>
Sent: Thursday, February 01, 2007 1:09 AM
Subject: Re: Problem in Virtual products
> Jacques,
>
> I usually test such things after disabling all promos and price rules. Simplify the test case.
>
> Jonathon
>
> Jacques Le Roux wrote:
> > Jacopo,
> >
> > From: "Jacopo Cappellato" <ti...@sastau.it>
> >> 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
> > virtual had also Competitive and List Prices. So I just tested by adding Competitive and List Prices to the variant WG-9943-B3
same
> > result.
> >
> > Am'I missing something here, promotions, prices rules ?
> >
> > Jacques
> >
> >> Jacopo
> >
> >
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
Jacques,
I usually test such things after disabling all promos and price rules. Simplify the test case.
Jonathon
Jacques Le Roux wrote:
> Jacopo,
>
> From: "Jacopo Cappellato" <ti...@sastau.it>
>> 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
> virtual had also Competitive and List Prices. So I just tested by adding Competitive and List Prices to the variant WG-9943-B3 same
> result.
>
> Am'I missing something here, promotions, prices rules ?
>
> Jacques
>
>> Jacopo
>
>
Re: Problem in Virtual products
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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.
-David
On Feb 2, 2007, at 2:28 AM, Jacques Le Roux wrote:
> There are no bug. But do you think it's good that an user may enter
> prices for a variant in another currency than the one used for
> virtual and in such case this prices will never be used. The
> Occam's razor principle would tend to cut this problem at root. Less
> inconsistency in UI is always better for a software to spread and
> should always be researched, that's my point of view.
>
> I know they are some other points like that in current UI. No hurry
> but good to enhance as soon as found.
>
> Jacques
>
>
>>
>> I don't see any problem here.
>>
>> The code looks for price information on the product. If no price
>> 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:
>>
>>> 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.
>>> 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.
>>> Of course I understand that in a perfect world we should support
>>> 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
>>>
>>>> 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
>>>>> 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.
>>>>
>>>> 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
>>>>>> wonder if having a currency different for virtual and variants
>>>>>> have a
>>>>>> sense. Having variants with different currencies is another
>>>>>> problem...
>>>>>
>>>>> 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" <jo...@improov.com>
>>>>>>> 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.
>>>>>>
>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>
>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>> 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
>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>> tested by
>>>>>>>>>>>> adding Competitive and List Prices to the variant
>>>>>>>>>>>> WG-9943-B3
>>>>>>>>>>> same
>>>>>>>>>>>> result.
>>>>>>>>>>>>
>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
There are no bug. But do you think it's good that an user may enter prices for a variant in another currency than the one used for
virtual and in such case this prices will never be used. The Occam's razor principle would tend to cut this problem at root. Less
inconsistency in UI is always better for a software to spread and should always be researched, that's my point of view.
I know they are some other points like that in current UI. No hurry but good to enhance as soon as found.
Jacques
>
> I don't see any problem here.
>
> The code looks for price information on the product. If no price
> 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:
>
> > 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.
> > 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.
> > Of course I understand that in a perfect world we should support
> > 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
> >
> >> 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
> >>> 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.
> >>
> >> 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
> >>>> wonder if having a currency different for virtual and variants
> >>>> have a
> >>>> sense. Having variants with different currencies is another
> >>>> problem...
> >>>
> >>> 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" <jo...@improov.com>
> >>>>> 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.
> >>>>
> >>>> 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" <jo...@hotwaxmedia.com>
> >>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Jacopo,
> >>>>>>>>>>
> >>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>> 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
> >>>>>>>>>> virtual had also Competitive and List Prices. So I just
> >>>>>>>>>> tested by
> >>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>>>>>>> same
> >>>>>>>>>> result.
> >>>>>>>>>>
> >>>>>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>>>>
> >>>>>>>>>> Jacques
> >>>>>>>>>>
> >>>>>>>>>>> Jacopo
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>
Re: Problem in Virtual products
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 2, 2007, at 2:58 AM, Jonathon -- Improov wrote:
> 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.
No. The price stuff will look for prices according to the currency
set on the ProductStore.
-David
> If that's the case, it is a bug.
>
> I haven't tested this out.
>
> Jacques, is the above correct?
>
> Jonathon
>
> David E. Jones wrote:
>> I don't see any problem here.
>> The code looks for price information on the product. If no price
>> 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:
>>> 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.
>>> 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.
>>> Of course I understand that in a perfect world we should support
>>> 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
>>>
>>>> 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
>>>>> 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.
>>>>
>>>> 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
>>>>>> wonder if having a currency different for virtual and variants
>>>>>> have a
>>>>>> sense. Having variants with different currencies is another
>>>>>> problem...
>>>>>
>>>>> 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" <jo...@improov.com>
>>>>>>> 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.
>>>>>>
>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>
>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>> 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
>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>> tested by
>>>>>>>>>>>> adding Competitive and List Prices to the variant
>>>>>>>>>>>> WG-9943-B3
>>>>>>>>>>> same
>>>>>>>>>>>> result.
>>>>>>>>>>>>
>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Currency in store and eCommerce
Posted by "Lindsey L." <li...@plateau.com>.
Hello Jacques and David,
I realize that the activity on this issue is a little old, but I have a
scenario that would greatly benefit from a solution or complete
documentation around this issue. Just to recap, the issue was about virtual
products being set in one currency and their variants set in a different
currency and how to get the currency to display for the variant. David had
mentioned that the currency set for the store is what determines the final
currency for products.
Jacques had 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 ?>>
David 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.>>
My question is about what was ultimately determined on this issue (I
apologize if I am asking for a repeat of something already stated).
My scenario is this:
Default Currency in Store is set to USD
Virtual Product ABC is set in USD
Variant Product ABC-1 is set in USD
Variant Product ABC-2 is set in GBP
When a user selects the variant product in British pounds, is there a way to
show the pricing in this currency, even if the default Currency Uom for the
store is USD?? Or is the best practice to have multiple stores, each with
their own currencies?
I would appreciate any direction you could give me.
Thanks in advance for your help,
Lindsey
--
View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tp8723541p14339702.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Currency in store and eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
David,
If I set the default price on one variant, say Giant Widget B3 [ID:WG-9943-B3], it has no impact on the price shown in eCommerce
(also on the price that shows when you have choseen all features, and the price in cart).
Then if I set competitive price on Giant Widget B3 it has no impact either.
Then if I set the list price on Giant Widget B3 the price that shows when you have choseen all features, and the price in cart are
changed to this value. But nor the competitive price, nor the list price are changed in eCommerce.
I tried to unload/reload the OFBiz instance but this has no impact either.
So yes, this seems that a bug has slipped in... Before opening a Jira issue I would prefer that someone else check that and confirm
in case I miss something.
Thanks
Jacques
From: "David E Jones" <jo...@hotwaxmedia.com>
>
> On Dec 16, 2007, at 3:19 AM, Jacques Le Roux wrote:
>
>> Yes you are right, I did not try with all prices. I overrided only
>> the default price. Overriding competitive price has also no
>> impact.
>
> What do you mean by overriding the competitive price? Do you mean
> defining one on the variant the overlaps in all other ways with one on
> the virtual? That _should_ work.
>
>> The public price should be overriden to show directly when you
>> choose all the variations.
>
> I'm not sure what you mean when you say "choose all the variations",
> so I'm not sure what to say about this... Which page and specific user
> action are you referring to?
>
>> Note that this feature is recent
>> and does not exist in release4.0.
>
> Now that is scaring me quite a bit... the functionality to use a
> virtual products prices by default and the variants to override if
> they exist has been around for a LONG time and nothing should have
> changed in that. If something has, it is probably a bug and should be
> fixed.
>
> -David
>
>
>> De : "David E Jones" <jo...@hotwaxmedia.com>
>>> On Sat, 15 Dec 2007 23:02:18 +0100
>>> "Jacques Le Roux" <ja...@les7arts.com> wrote:
>>>
>>>> Also remember that for your variants prices to appear you need to
>>>> *NOT* set prices in the virtual (respectively for each types of
>>>> prices)
>>>
>>> Not sure if I read this right, but it seems incorrect. Prices on
>>> variants should always override the prices on a virtual product, if
>>> present.
>>>
>>> -David
>>>
>>
>
>
Re: Currency in store and eCommerce
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Dec 16, 2007, at 3:19 AM, Jacques Le Roux wrote:
> Yes you are right, I did not try with all prices. I overrided only
> the default price. Overriding competitive price has also no
> impact.
What do you mean by overriding the competitive price? Do you mean
defining one on the variant the overlaps in all other ways with one on
the virtual? That _should_ work.
> The public price should be overriden to show directly when you
> choose all the variations.
I'm not sure what you mean when you say "choose all the variations",
so I'm not sure what to say about this... Which page and specific user
action are you referring to?
> Note that this feature is recent
> and does not exist in release4.0.
Now that is scaring me quite a bit... the functionality to use a
virtual products prices by default and the variants to override if
they exist has been around for a LONG time and nothing should have
changed in that. If something has, it is probably a bug and should be
fixed.
-David
> De : "David E Jones" <jo...@hotwaxmedia.com>
>> On Sat, 15 Dec 2007 23:02:18 +0100
>> "Jacques Le Roux" <ja...@les7arts.com> wrote:
>>
>>> Also remember that for your variants prices to appear you need to
>>> *NOT* set prices in the virtual (respectively for each types of
>>> prices)
>>
>> Not sure if I read this right, but it seems incorrect. Prices on
>> variants should always override the prices on a virtual product, if
>> present.
>>
>> -David
>>
>
Re: Currency in store and eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
David,
Yes you are right, I did not try with all prices. I overrided only the default price. Overriding competitive price has also no
impact. The public price should be overriden to show directly when you choose all the variations. Note that this feature is recent
and does not exist in release4.0.
Jacques
De : "David E Jones" <jo...@hotwaxmedia.com>
> On Sat, 15 Dec 2007 23:02:18 +0100
> "Jacques Le Roux" <ja...@les7arts.com> wrote:
>
> > Also remember that for your variants prices to appear you need to
> > *NOT* set prices in the virtual (respectively for each types of
> > prices)
>
> Not sure if I read this right, but it seems incorrect. Prices on
> variants should always override the prices on a virtual product, if
> present.
>
> -David
>
Re: Currency in store and eCommerce
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Sat, 15 Dec 2007 23:02:18 +0100
"Jacques Le Roux" <ja...@les7arts.com> wrote:
> Also remember that for your variants prices to appear you need to
> *NOT* set prices in the virtual (respectively for each types of
> prices)
Not sure if I read this right, but it seems incorrect. Prices on
variants should always override the prices on a virtual product, if
present.
-David
Re: Currency in store and eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
The point was http://www.nabble.com/Problem-in-Virtual-products-to8723541.html#a14339702
It seems from a quick investigation that setSessionCurrencyUom is available in code but not (yet?) used in UI.
I guess the idea is to use it if there is a need to allow user to choose his/her currency else the currency is determined by the
store currency.
Hence in your case it seems that you needs 2 stores else price in GBP will never show. Except if using setSessionCurrencyUom you
implement a mean in UI for the user to choose himself/herself his/her currency.
Also remember that for your variants prices to appear you need to *NOT* set prices in the virtual (respectively for each types of
prices)
Jacques
De : "Lindsey L." <li...@plateau.com>
>
> Hello Jacques and David,
>
> I realize that the activity on this issue is a little old, but I have a
> scenario that would greatly benefit from a solution or complete
> documentation around this issue. Just to recap, the issue was about virtual
> products being set in one currency and their variants set in a different
> currency and how to get the currency to display for the variant. David had
> mentioned that the currency set for the store is what determines the final
> currency for products.
>
> Jacques had 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 ?>>
>
> David 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.>>
>
> My question is about what was ultimately determined on this issue (I
> apologize if I am asking for a repeat of something already stated).
>
> My scenario is this:
> Default Currency in Store is set to USD
> Virtual Product ABC is set in USD
> Variant Product ABC-1 is set in USD
> Variant Product ABC-2 is set in GBP
>
> When a user selects the variant product in British pounds, is there a way to
> show the pricing in this currency, even if the default Currency Uom for the
> store is USD?? Or is the best practice to have multiple stores, each with
> their own currencies?
>
>
> I would appreciate any direction you could give me.
>
> Thanks in advance for your help,
> Lindsey
> --
> View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tp8723541p14339702.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: Currency in store and eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks David,
I will have a look at it.
Jacques
>
> The main event for this in the ecommerce controller.xml file is
> "setSessionCurrencyUom".
>
> -David
>
>
> On Feb 4, 2007, at 1:05 AM, Jacques Le Roux wrote:
>
> > 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.
> >
> > 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 ?
> >
> > Jacques
> >
> >
> > ----- Original Message -----
> > From: "David E. Jones" <jo...@hotwaxmedia.com>
> > To: <us...@ofbiz.apache.org>
> > Sent: Sunday, February 04, 2007 2:48 AM
> > Subject: Re: Problem in Virtual products... Sequels...
> >
> >
> >>
> >> 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
> >>> currency ? Or in other words, may the "Product Store Group"
> >>> concept be
> >>> 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
> >>> *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
> >>> 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
> >>>
> >>>
> >>>> 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.>>
> >>>>>>
> >>>>>> Mmm... Strange that a default value might not be overriden in
> >>>>>> some
> >>>>>> 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
> >>>>>> 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
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>> Jonathon
> >>>>>>>
> >>>>>>> David E. Jones wrote:
> >>>>>>>>
> >>>>>>>> I don't see any problem here.
> >>>>>>>>
> >>>>>>>> The code looks for price information on the product. If no
> >>>>>>>> price
> >>>>>>>> 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:
> >>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>> 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.
> >>>>>>>>> Of course I understand that in a perfect world we should
> >>>>>>>>> support
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>>> wonder if having a currency different for virtual and
> >>>>>>>>>>>> variants
> >>>>>>>>>>>> have a
> >>>>>>>>>>>> sense. Having variants with different currencies is another
> >>>>>>>>>>>> problem...
> >>>>>>>>>>>
> >>>>>>>>>>> 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" <jo...@improov.com>
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I
> >>>>>>>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>>>> tested by
> >>>>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant
> >>>>>>>>>>>>>>>>>> WG-9943-B3
> >>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>> result.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices
> >>>>>>>>>>>>>>>>>> rules ?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Jacopo
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> >>
> >
>
>
Re: Currency in store and eCommerce
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
The main event for this in the ecommerce controller.xml file is
"setSessionCurrencyUom".
-David
On Feb 4, 2007, at 1:05 AM, Jacques Le Roux wrote:
> 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.
>
> 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 ?
>
> Jacques
>
>
> ----- Original Message -----
> From: "David E. Jones" <jo...@hotwaxmedia.com>
> To: <us...@ofbiz.apache.org>
> Sent: Sunday, February 04, 2007 2:48 AM
> Subject: Re: Problem in Virtual products... Sequels...
>
>
>>
>> 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
>>> currency ? Or in other words, may the "Product Store Group"
>>> concept be
>>> 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
>>> *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
>>> 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
>>>
>>>
>>>> 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.>>
>>>>>>
>>>>>> Mmm... Strange that a default value might not be overriden in
>>>>>> some
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>> David E. Jones wrote:
>>>>>>>>
>>>>>>>> I don't see any problem here.
>>>>>>>>
>>>>>>>> The code looks for price information on the product. If no
>>>>>>>> price
>>>>>>>> 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:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>> 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.
>>>>>>>>> Of course I understand that in a perfect world we should
>>>>>>>>> support
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>> wonder if having a currency different for virtual and
>>>>>>>>>>>> variants
>>>>>>>>>>>> have a
>>>>>>>>>>>> sense. Having variants with different currencies is another
>>>>>>>>>>>> problem...
>>>>>>>>>>>
>>>>>>>>>>> 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" <jo...@improov.com>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I
>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant
>>>>>>>>>>>>>>>>>> WG-9943-B3
>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices
>>>>>>>>>>>>>>>>>> rules ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>
Currency in store and eCommerce
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.
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 ?
Jacques
----- Original Message -----
From: "David E. Jones" <jo...@hotwaxmedia.com>
To: <us...@ofbiz.apache.org>
Sent: Sunday, February 04, 2007 2:48 AM
Subject: Re: Problem in Virtual products... Sequels...
>
> 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
> > currency ? Or in other words, may the "Product Store Group" concept be
> > 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
> > *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
> > 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
> >
> >
> >> 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.>>
> >>>>
> >>>> Mmm... Strange that a default value might not be overriden in some
> >>>> 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
> >>>> 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
> >>>> 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
> >>>>
> >>>>
> >>>>> Jonathon
> >>>>>
> >>>>> David E. Jones wrote:
> >>>>>>
> >>>>>> I don't see any problem here.
> >>>>>>
> >>>>>> The code looks for price information on the product. If no price
> >>>>>> 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:
> >>>>>>
> >>>>>>> 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.
> >>>>>>> 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.
> >>>>>>> Of course I understand that in a perfect world we should support
> >>>>>>> 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
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>>> wonder if having a currency different for virtual and
> >>>>>>>>>> variants
> >>>>>>>>>> have a
> >>>>>>>>>> sense. Having variants with different currencies is another
> >>>>>>>>>> problem...
> >>>>>>>>>
> >>>>>>>>> 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" <jo...@improov.com>
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
> >>>>>>>>>>>>>>>> tested by
> >>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant
> >>>>>>>>>>>>>>>> WG-9943-B3
> >>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>> result.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Jacopo
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >
>
>
Re: Problem in Virtual products... Sequels...
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
> currency ? Or in other words, may the "Product Store Group" concept be
> 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
> *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
> 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
>
>
>> 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.>>
>>>>
>>>> Mmm... Strange that a default value might not be overriden in some
>>>> 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
>>>> 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
>>>> 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
>>>>
>>>>
>>>>> Jonathon
>>>>>
>>>>> David E. Jones wrote:
>>>>>>
>>>>>> I don't see any problem here.
>>>>>>
>>>>>> The code looks for price information on the product. If no price
>>>>>> 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:
>>>>>>
>>>>>>> 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.
>>>>>>> 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.
>>>>>>> Of course I understand that in a perfect world we should support
>>>>>>> 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
>>>>>>>
>>>>>>>> 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
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>> wonder if having a currency different for virtual and
>>>>>>>>>> variants
>>>>>>>>>> have a
>>>>>>>>>> sense. Having variants with different currencies is another
>>>>>>>>>> problem...
>>>>>>>>>
>>>>>>>>> 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" <jo...@improov.com>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant
>>>>>>>>>>>>>>>> WG-9943-B3
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>
Re: Problem in Virtual products... Sequels...
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jonathon,
> Jacques,
>
> Jacques 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 ?
>
> I've seen applications that use just 1 base/core currency for the entire store, and just do a
> real-time calculation (say with oanda exchange rate server) when a non-base/non-core currency is used.
Thanks , I did not know oanda.
> Personally, I don't see many stores handling > 1 currency. Taking in "fixed prices in foreign
> currencies" is actually quite bad for business, because that subjects the business to forex
> fluctuations.
>
> Imagine having a store with fixed price tags in EUR and in a currency (fictitious for
> illustration) WildMoney that fluctuates like mad. Now imagine shoppers coming in with WildMoney
> only on days when WildMoney is wildly weak against the EUR. This store will be losing a lot of money!
Yes I agree, and moreover sometimes prices are different according to countries (typical for luxury goods). But in some case it may
usefull to use an exchange rate server.
> > 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 ?
>
> More than enough. In-application (in vivo) help texts are a lot more user-friendly than docs
> separated from the application (in vitro? assuming the application is glass :) ).
>
> > 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) ?
>
> ERPs are naturally complex, with different flavors/functionalities for different businesses/companies.
>
> Complex as they may be, companies that employ ERPs (whether coded in-house in PHP, or designed by
> vendors in OOTB form) often do/must document their usage of those ERPs. Even if they use OOTB
> products, there will be parts of the product they don't use, or use in a "special" way. They'd
> need to document that as well.
>
> We really should document the ERP part of OFBiz. I currently refer to OFBiz as 2 parts: OFBiz-ERP
> and OFBiz-core.
Functionnal name (marketing name ;o) for applications and framework. Are new names really needed ?
> About effort in documentation, it is always significant or at least substantial. Say we write some
> program codes, test it, debug it, and "voila! it works", and we leave it at that. Then we need to
> document our program at the "functional level" (ie, "yeah, it seems to work this way from a user's
> POV"). And if our coding style is not declarative and clean, we then need to review our codes to
> make sure it correctly goes from "A to B to C" rather than "A to B to A to B to C".
>
> And that's just one function in our program, or 1 small module in a larger program. We repeat the
> above for other modules. And eventually, we document the cross-references between modules. And
> this is the difficult part.
>
> Example:
> "If Jonathon bows, Jacques coughs. If Jacques coughs, David claps. If David claps, Jonathon
> dances. If Jonathon dances, Jacques coughs." Hmm. Now how do we document this?
>
> We can try a "breadth-first" approach in documentation. Make sure all developers understand the
> codes first. Then with spare resources, we make sure all users understand the application. Then we
> try to make the higher management (who won't even need to work, much less USE OFBiz?) understand
> the purchase of the application.
>
> (I know, real-world business and marketing techniques mess up that order.)
For the moment my only concern is tho help first time user to better understand backend UI and principles of use.
> > 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.
>
> I agree with your assessment of IE vs Firefox. Firefox isn't entirely completely implemented; some
> UIs do not render correctly yet. IE quirks and errors are more numerous than Firefox, but is more
> widely used. If I code things correctly and that happens to suit Firefox 99% of the time, I'll see
> broken UIs in IE.
>
> I've long given up wishing that IE does not force us to code things "wrongly".
I was only speaking of the tooltip aspect. Actually, Opera has also an interesting behaviour because the tooltip is not hidden after
5 sec : you easily can read a 1000 char. (or more) explanations ! The only drawback is that with Opera you can't defines your own
new lines returns.
This because if we want to use tooltip to give more informations to user (backoffice only) we may recommend to use a specific
browser, why not ?
BTW, will anybody complain if I begin to document backend UI thru tooltips ?
Jacques
> Jonathon
>
> 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.
> >
> > 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* ?
> >
> > 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 currency ? Or in other words, may the "Product Store Group" concept
be
> > 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 *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
> > 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
> >
> >
> >> 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.>>
> >>>>
> >>>> Mmm... Strange that a default value might not be overriden in some
> >>>> 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
> >>>> 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
> >>>> 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
> >>>>
> >>>>
> >>>>> Jonathon
> >>>>>
> >>>>> David E. Jones wrote:
> >>>>>> I don't see any problem here.
> >>>>>>
> >>>>>> The code looks for price information on the product. If no price
> >>>>>> 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:
> >>>>>>
> >>>>>>> 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.
> >>>>>>> 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.
> >>>>>>> Of course I understand that in a perfect world we should support
> >>>>>>> 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
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>> 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.
> >>>>>>>> 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
> >>>>>>>>>> wonder if having a currency different for virtual and variants
> >>>>>>>>>> have a
> >>>>>>>>>> sense. Having variants with different currencies is another
> >>>>>>>>>> problem...
> >>>>>>>>> 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" <jo...@improov.com>
> >>>>>>>>>>> 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.
> >>>>>>>>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
> >>>>>>>>>>>>>>>> tested by
> >>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>> result.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Jacopo
> >>>>>>>>>>
> >
> >
Re: Problem in Virtual products... Sequels...
Posted by Jonathon -- Improov <jo...@improov.com>.
Jacques,
Jacques 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 ?
I've seen applications that use just 1 base/core currency for the entire store, and just do a
real-time calculation (say with oanda exchange rate server) when a non-base/non-core currency is used.
Personally, I don't see many stores handling > 1 currency. Taking in "fixed prices in foreign
currencies" is actually quite bad for business, because that subjects the business to forex
fluctuations.
Imagine having a store with fixed price tags in EUR and in a currency (fictitious for
illustration) WildMoney that fluctuates like mad. Now imagine shoppers coming in with WildMoney
only on days when WildMoney is wildly weak against the EUR. This store will be losing a lot of money!
> 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 ?
More than enough. In-application (in vivo) help texts are a lot more user-friendly than docs
separated from the application (in vitro? assuming the application is glass :) ).
> 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) ?
ERPs are naturally complex, with different flavors/functionalities for different businesses/companies.
Complex as they may be, companies that employ ERPs (whether coded in-house in PHP, or designed by
vendors in OOTB form) often do/must document their usage of those ERPs. Even if they use OOTB
products, there will be parts of the product they don't use, or use in a "special" way. They'd
need to document that as well.
We really should document the ERP part of OFBiz. I currently refer to OFBiz as 2 parts: OFBiz-ERP
and OFBiz-core.
About effort in documentation, it is always significant or at least substantial. Say we write some
program codes, test it, debug it, and "voila! it works", and we leave it at that. Then we need to
document our program at the "functional level" (ie, "yeah, it seems to work this way from a user's
POV"). And if our coding style is not declarative and clean, we then need to review our codes to
make sure it correctly goes from "A to B to C" rather than "A to B to A to B to C".
And that's just one function in our program, or 1 small module in a larger program. We repeat the
above for other modules. And eventually, we document the cross-references between modules. And
this is the difficult part.
Example:
"If Jonathon bows, Jacques coughs. If Jacques coughs, David claps. If David claps, Jonathon
dances. If Jonathon dances, Jacques coughs." Hmm. Now how do we document this?
We can try a "breadth-first" approach in documentation. Make sure all developers understand the
codes first. Then with spare resources, we make sure all users understand the application. Then we
try to make the higher management (who won't even need to work, much less USE OFBiz?) understand
the purchase of the application.
(I know, real-world business and marketing techniques mess up that order.)
> 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.
I agree with your assessment of IE vs Firefox. Firefox isn't entirely completely implemented; some
UIs do not render correctly yet. IE quirks and errors are more numerous than Firefox, but is more
widely used. If I code things correctly and that happens to suit Firefox 99% of the time, I'll see
broken UIs in IE.
I've long given up wishing that IE does not force us to code things "wrongly".
Jonathon
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.
>
> 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* ?
>
> 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 currency ? Or in other words, may the "Product Store Group" concept be
> 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 *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
> 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
>
>
>> 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.>>
>>>>
>>>> Mmm... Strange that a default value might not be overriden in some
>>>> 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
>>>> 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
>>>> 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
>>>>
>>>>
>>>>> Jonathon
>>>>>
>>>>> David E. Jones wrote:
>>>>>> I don't see any problem here.
>>>>>>
>>>>>> The code looks for price information on the product. If no price
>>>>>> 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:
>>>>>>
>>>>>>> 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.
>>>>>>> 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.
>>>>>>> Of course I understand that in a perfect world we should support
>>>>>>> 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
>>>>>>>
>>>>>>>> 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
>>>>>>>>> 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.
>>>>>>>> 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
>>>>>>>>>> wonder if having a currency different for virtual and variants
>>>>>>>>>> have a
>>>>>>>>>> sense. Having variants with different currencies is another
>>>>>>>>>> problem...
>>>>>>>>> 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" <jo...@improov.com>
>>>>>>>>>>> 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.
>>>>>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>
>
>
Re: Problem in Virtual products... Sequels...
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.
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* ?
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 currency ? Or in other words, may the "Product Store Group" concept be
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 *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
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
> 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.>>
> >>
> >> Mmm... Strange that a default value might not be overriden in some
> >> 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
> >> 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
> >> 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
> >>
> >>
> >>> Jonathon
> >>>
> >>> David E. Jones wrote:
> >>>>
> >>>> I don't see any problem here.
> >>>>
> >>>> The code looks for price information on the product. If no price
> >>>> 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:
> >>>>
> >>>>> 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.
> >>>>> 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.
> >>>>> Of course I understand that in a perfect world we should support
> >>>>> 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
> >>>>>
> >>>>>> 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
> >>>>>>> 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.
> >>>>>>
> >>>>>> 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
> >>>>>>>> wonder if having a currency different for virtual and variants
> >>>>>>>> have a
> >>>>>>>> sense. Having variants with different currencies is another
> >>>>>>>> problem...
> >>>>>>>
> >>>>>>> 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" <jo...@improov.com>
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
> >>>>>>>>>>>>>> tested by
> >>>>>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>>>>>>>>>>> same
> >>>>>>>>>>>>>> result.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jacques
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Jacopo
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
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.>>
>>
>> Mmm... Strange that a default value might not be overriden in some
>> 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
>> 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
>> 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
>>
>>
>>> Jonathon
>>>
>>> David E. Jones wrote:
>>>>
>>>> I don't see any problem here.
>>>>
>>>> The code looks for price information on the product. If no price
>>>> 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:
>>>>
>>>>> 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.
>>>>> 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.
>>>>> Of course I understand that in a perfect world we should support
>>>>> 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
>>>>>
>>>>>> 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
>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>>> wonder if having a currency different for virtual and variants
>>>>>>>> have a
>>>>>>>> sense. Having variants with different currencies is another
>>>>>>>> problem...
>>>>>>>
>>>>>>> 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" <jo...@improov.com>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>>>>>>>>>>> same
>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: Problem in Virtual products
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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.>>
>
> Mmm... Strange that a default value might not be overriden in some
> 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
> 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
> 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
>
>
>> Jonathon
>>
>> David E. Jones wrote:
>>>
>>> I don't see any problem here.
>>>
>>> The code looks for price information on the product. If no price
>>> 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:
>>>
>>>> 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.
>>>> 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.
>>>> Of course I understand that in a perfect world we should support
>>>> 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
>>>>
>>>>> 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
>>>>>> 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.
>>>>>
>>>>> 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
>>>>>>> wonder if having a currency different for virtual and
>>>>>>> variants have a
>>>>>>> sense. Having variants with different currencies is another
>>>>>>> problem...
>>>>>>
>>>>>> 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" <jo...@improov.com>
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>>>> tested by
>>>>>>>>>>>>> adding Competitive and List Prices to the variant
>>>>>>>>>>>>> WG-9943-B3
>>>>>>>>>>>> same
>>>>>>>>>>>>> result.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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. 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.>>
Mmm... Strange that a default value might not be overriden in some 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 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 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
> Jonathon
>
> David E. Jones wrote:
> >
> > I don't see any problem here.
> >
> > The code looks for price information on the product. If no price
> > 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:
> >
> >> 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.
> >> 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.
> >> Of course I understand that in a perfect world we should support
> >> 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
> >>
> >>> 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
> >>>> 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.
> >>>
> >>> 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
> >>>>> wonder if having a currency different for virtual and variants have a
> >>>>> sense. Having variants with different currencies is another problem...
> >>>>
> >>>> 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" <jo...@improov.com>
> >>>>>> 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.
> >>>>>
> >>>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>> To: <us...@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" <ja...@les7arts.com>
> >>>>>>>>>> To: <us...@ofbiz.apache.org>
> >>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Jacopo,
> >>>>>>>>>>>
> >>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>>>>>> 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
> >>>>>>>>>>> virtual had also Competitive and List Prices. So I just
> >>>>>>>>>>> tested by
> >>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>>>>>>>> same
> >>>>>>>>>>> result.
> >>>>>>>>>>>
> >>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>>>>>
> >>>>>>>>>>> Jacques
> >>>>>>>>>>>
> >>>>>>>>>>>> Jacopo
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
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?
Jonathon
David E. Jones wrote:
>
> I don't see any problem here.
>
> The code looks for price information on the product. If no price
> 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:
>
>> 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.
>> 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.
>> Of course I understand that in a perfect world we should support
>> 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
>>
>>> 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
>>>> 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.
>>>
>>> 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
>>>>> wonder if having a currency different for virtual and variants have a
>>>>> sense. Having variants with different currencies is another problem...
>>>>
>>>> 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" <jo...@improov.com>
>>>>>> 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.
>>>>>
>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Jacopo,
>>>>>>>>>>>
>>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>>> 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
>>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>>> tested by
>>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>>>>>>>> same
>>>>>>>>>>> result.
>>>>>>>>>>>
>>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Problem in Virtual products
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
I don't see any problem here.
The code looks for price information on the product. If no price
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:
> 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.
> 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.
> Of course I understand that in a perfect world we should support
> 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
>
>> 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
>>> 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.
>>
>> 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
>>>> wonder if having a currency different for virtual and variants
>>>> have a
>>>> sense. Having variants with different currencies is another
>>>> problem...
>>>
>>> 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" <jo...@improov.com>
>>>>> 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.
>>>>
>>>> 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" <jo...@hotwaxmedia.com>
>>>>>> To: <us...@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" <ja...@les7arts.com>
>>>>>>>>> To: <us...@ofbiz.apache.org>
>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>>>>> 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
>>>>>>>>>> virtual had also Competitive and List Prices. So I just
>>>>>>>>>> tested by
>>>>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>>>>>>> same
>>>>>>>>>> result.
>>>>>>>>>>
>>>>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>
>>>>
>>>>
>>>
>>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.
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.
Of course I understand that in a perfect world we should support 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
> 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
> > 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.
>
> 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
> > > wonder if having a currency different for virtual and variants have a
> > > sense. Having variants with different currencies is another problem...
> >
> > 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" <jo...@improov.com>
> > >> 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.
> > >
> > > 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" <jo...@hotwaxmedia.com>
> > >>> To: <us...@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" <ja...@les7arts.com>
> > >>>>>> To: <us...@ofbiz.apache.org>
> > >>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> > >>>>>> Subject: Re: Problem in Virtual products
> > >>>>>>
> > >>>>>>
> > >>>>>>> Jacopo,
> > >>>>>>>
> > >>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> > >>>>>>>> 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
> > >>>>>>> virtual had also Competitive and List Prices. So I just tested by
> > >>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> > >>>>>> same
> > >>>>>>> result.
> > >>>>>>>
> > >>>>>>> Am'I missing something here, promotions, prices rules ?
> > >>>>>>>
> > >>>>>>> Jacques
> > >>>>>>>
> > >>>>>>>> Jacopo
> > >>>
> > >
> > >
> >
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
> 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.
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
> > wonder if having a currency different for virtual and variants have a
> > sense. Having variants with different currencies is another problem...
>
> 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" <jo...@improov.com>
> >> 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.
> >
> > 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" <jo...@hotwaxmedia.com>
> >>> To: <us...@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" <ja...@les7arts.com>
> >>>>>> To: <us...@ofbiz.apache.org>
> >>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>> Subject: Re: Problem in Virtual products
> >>>>>>
> >>>>>>
> >>>>>>> Jacopo,
> >>>>>>>
> >>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>>>> 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
> >>>>>>> virtual had also Competitive and List Prices. So I just tested by
> >>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>>>> same
> >>>>>>> result.
> >>>>>>>
> >>>>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>> Jacopo
> >>>
> >
> >
>
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
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
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.
>> 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...
Hmm. In OO sense, it doesn't make sense that virtuals have a price even. 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.
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
Jonathon
Jacques Le Roux wrote:
> Jonathon,
>
> From: "Jonathon -- Improov" <jo...@improov.com>
>> 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.
>
> 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" <jo...@hotwaxmedia.com>
>>> To: <us...@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" <ja...@les7arts.com>
>>>>>> To: <us...@ofbiz.apache.org>
>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>> Subject: Re: Problem in Virtual products
>>>>>>
>>>>>>
>>>>>>> Jacopo,
>>>>>>>
>>>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>>>> 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
>>>>>>> virtual had also Competitive and List Prices. So I just tested by
>>>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>>>> same
>>>>>>> result.
>>>>>>>
>>>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>> Jacopo
>>>
>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jonathon,
From: "Jonathon -- Improov" <jo...@improov.com>
> 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.
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" <jo...@hotwaxmedia.com>
> > To: <us...@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" <ja...@les7arts.com>
> >>>> To: <us...@ofbiz.apache.org>
> >>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>> Subject: Re: Problem in Virtual products
> >>>>
> >>>>
> >>>>> Jacopo,
> >>>>>
> >>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>>>> 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
> >>>>> virtual had also Competitive and List Prices. So I just tested by
> >>>>> adding Competitive and List Prices to the variant WG-9943-B3
> >>>> same
> >>>>> result.
> >>>>>
> >>>>> Am'I missing something here, promotions, prices rules ?
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>> Jacopo
> >>
> >
> >
Re: Problem in Virtual products
Posted by Jonathon -- Improov <jo...@improov.com>.
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).
However, I strongly suspect that's not exactly how it works now. Let me know if anyone needs me to
help in research; my current project doesn't handle more than 1 currency... yet.
A sticky issue: which currency/price takes precedence, variant or virtual? I'd say variant prices
should override virtual.
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" <jo...@hotwaxmedia.com>
> To: <us...@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" <ja...@les7arts.com>
>>>> To: <us...@ofbiz.apache.org>
>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>> Subject: Re: Problem in Virtual products
>>>>
>>>>
>>>>> Jacopo,
>>>>>
>>>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>>>> 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
>>>>> virtual had also Competitive and List Prices. So I just tested by
>>>>> adding Competitive and List Prices to the variant WG-9943-B3
>>>> same
>>>>> result.
>>>>>
>>>>> Am'I missing something here, promotions, prices rules ?
>>>>>
>>>>> Jacques
>>>>>
>>>>>> Jacopo
>>
>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <jo...@hotwaxmedia.com>
To: <us...@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" <ja...@les7arts.com>
> >> To: <us...@ofbiz.apache.org>
> >> Sent: Wednesday, January 31, 2007 5:02 PM
> >> Subject: Re: Problem in Virtual products
> >>
> >>
> >>> Jacopo,
> >>>
> >>> From: "Jacopo Cappellato" <ti...@sastau.it>
> >>>> 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
> >>> virtual had also Competitive and List Prices. So I just tested by
> >>> adding Competitive and List Prices to the variant WG-9943-B3
> >> same
> >>> result.
> >>>
> >>> Am'I missing something here, promotions, prices rules ?
> >>>
> >>> Jacques
> >>>
> >>>> Jacopo
> >
>
>
Re: Problem in Virtual products
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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" <ja...@les7arts.com>
>> To: <us...@ofbiz.apache.org>
>> Sent: Wednesday, January 31, 2007 5:02 PM
>> Subject: Re: Problem in Virtual products
>>
>>
>>> Jacopo,
>>>
>>> From: "Jacopo Cappellato" <ti...@sastau.it>
>>>> 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
>>> virtual had also Competitive and List Prices. So I just tested by
>>> adding Competitive and List Prices to the variant WG-9943-B3
>> same
>>> result.
>>>
>>> Am'I missing something here, promotions, prices rules ?
>>>
>>> Jacques
>>>
>>>> Jacopo
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@les7arts.com>
> To: <us...@ofbiz.apache.org>
> Sent: Wednesday, January 31, 2007 5:02 PM
> Subject: Re: Problem in Virtual products
>
>
> > Jacopo,
> >
> > From: "Jacopo Cappellato" <ti...@sastau.it>
> > > 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
> > virtual had also Competitive and List Prices. So I just tested by adding Competitive and List Prices to the variant WG-9943-B3
> same
> > result.
> >
> > Am'I missing something here, promotions, prices rules ?
> >
> > Jacques
> >
> > > Jacopo
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@les7arts.com>
To: <us...@ofbiz.apache.org>
Sent: Wednesday, January 31, 2007 5:02 PM
Subject: Re: Problem in Virtual products
> Jacopo,
>
> From: "Jacopo Cappellato" <ti...@sastau.it>
> > 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
> virtual had also Competitive and List Prices. So I just tested by adding Competitive and List Prices to the variant WG-9943-B3
same
> result.
>
> Am'I missing something here, promotions, prices rules ?
>
> Jacques
>
> > Jacopo
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jacopo,
From: "Jacopo Cappellato" <ti...@sastau.it>
> 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
virtual had also Competitive and List Prices. So I just tested by adding Competitive and List Prices to the variant WG-9943-B3 same
result.
Am'I missing something here, promotions, prices rules ?
Jacques
> Jacopo
Re: Problem in Virtual products
Posted by Jacopo Cappellato <ti...@sastau.it>.
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.
Jacopo
Re: Problem in Virtual products
Posted by Vamsi Gmail! <va...@gmail.com>.
Thanks for responding and for your answers .
I found a turn around solution for this virtual configurable products
On 1/31/07, Jacques Le Roux <ja...@les7arts.com> wrote:
>
> Vamsi
>
> Very quick answer.
>
> >
> >
> > Hi,
> >
> > I created a virtual configurable product and added three
> > variants and 1 multichoice configuration to that(Varaint product id's
> > 2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
> > display varaints in different way . When I am trying add product to the
> cart
> > it is giving a error "Tried adding the virtual product XXXX(productid :
> > 2000) adding ,not added " .I observerd in the request parameter(I
> changed
> > form method to "get") the product id that is going to add is 2000 when
> > change that product id to one of the variant product it is working fine
> and
> > show it in shopping cart list.
> > We can't add a virtual product to shopping cart?
>
> No you can't add virtuals only variants. Virtual exist only for
> "generating" variants.
>
> > 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.
>
> > My question is how the fillproductconfigwrapper method identifies the
> > configuration parameter from request
>
> Sorry no time for that one, you will have to help yourself
>
> Jacques
>
> > I am thankful for any kind of help
> >
> > regards
> > Vamsi
> > --
> > View this message in context:
> http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
--
M.S.S.Vamsi Krishna
SoftWare Engineer
ecomZera
www.ecomzera.com
9885648063
Re: Problem in Virtual products
Posted by Vamsi Gmail! <va...@gmail.com>.
Thanks for responding and for your answers .
I found a turn around solution for this virtual configurable products
On 1/31/07, Jacques Le Roux <ja...@les7arts.com> wrote:
>
> Vamsi
>
> Very quick answer.
>
> >
> >
> > Hi,
> >
> > I created a virtual configurable product and added three
> > variants and 1 multichoice configuration to that(Varaint product id's
> > 2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
> > display varaints in different way . When I am trying add product to the
> cart
> > it is giving a error "Tried adding the virtual product XXXX(productid :
> > 2000) adding ,not added " .I observerd in the request parameter(I
> changed
> > form method to "get") the product id that is going to add is 2000 when
> > change that product id to one of the variant product it is working fine
> and
> > show it in shopping cart list.
> > We can't add a virtual product to shopping cart?
>
> No you can't add virtuals only variants. Virtual exist only for
> "generating" variants.
>
> > 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.
>
> > My question is how the fillproductconfigwrapper method identifies the
> > configuration parameter from request
>
> Sorry no time for that one, you will have to help yourself
>
> Jacques
>
> > I am thankful for any kind of help
> >
> > regards
> > Vamsi
> > --
> > View this message in context:
> http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Vamsi
Very quick answer.
>
>
> Hi,
>
> I created a virtual configurable product and added three
> variants and 1 multichoice configuration to that(Varaint product id's
> 2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
> display varaints in different way . When I am trying add product to the cart
> it is giving a error "Tried adding the virtual product XXXX(productid :
> 2000) adding ,not added " .I observerd in the request parameter(I changed
> form method to "get") the product id that is going to add is 2000 when
> change that product id to one of the variant product it is working fine and
> show it in shopping cart list.
> We can't add a virtual product to shopping cart?
No you can't add virtuals only variants. Virtual exist only for "generating" variants.
> 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.
> My question is how the fillproductconfigwrapper method identifies the
> configuration parameter from request
Sorry no time for that one, you will have to help yourself
Jacques
> I am thankful for any kind of help
>
> regards
> Vamsi
> --
> View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Problem in Virtual products
Posted by Jacques Le Roux <ja...@les7arts.com>.
I review this patch, now to be forgiven for telling nonsense on ML :/
Jacques
----- Original Message -----
From: "Eric Crawford" <ph...@gmail.com>
To: <us...@ofbiz.apache.org>
Sent: Wednesday, January 31, 2007 3:40 PM
Subject: Re: Problem in Virtual products
> There was a patch submitted for the following JIRA issue that might
> help with displaying the variant price.
>
> https://issues.apache.org/jira/browse/OFBIZ-618
>
> On 1/31/07, Vamsi <va...@gmail.com> wrote:
> >
> >
> > Hi,
> >
> > I created a virtual configurable product and added three
> > variants and 1 multichoice configuration to that(Varaint product id's
> > 2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
> > display varaints in different way . When I am trying add product to the cart
> > it is giving a error "Tried adding the virtual product XXXX(productid :
> > 2000) adding ,not added " .I observerd in the request parameter(I changed
> > form method to "get") the product id that is going to add is 2000 when
> > change that product id to one of the variant product it is working fine and
> > show it in shopping cart list.
> > We can't add a virtual product to shopping cart?
> > When I am selecting configuration it is not showing the product price with
> > configuration.
> > My question is how the fillproductconfigwrapper method identifies the
> > configuration parameter from request
> >
> > I am thankful for any kind of help
> >
> > regards
> > Vamsi
> > --
> > View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
> >
Re: Problem in Virtual products
Posted by Eric Crawford <ph...@gmail.com>.
There was a patch submitted for the following JIRA issue that might
help with displaying the variant price.
https://issues.apache.org/jira/browse/OFBIZ-618
On 1/31/07, Vamsi <va...@gmail.com> wrote:
>
>
> Hi,
>
> I created a virtual configurable product and added three
> variants and 1 multichoice configuration to that(Varaint product id's
> 2000V1, 2000V2, 2000V3) .I made some changes in product detail page to
> display varaints in different way . When I am trying add product to the cart
> it is giving a error "Tried adding the virtual product XXXX(productid :
> 2000) adding ,not added " .I observerd in the request parameter(I changed
> form method to "get") the product id that is going to add is 2000 when
> change that product id to one of the variant product it is working fine and
> show it in shopping cart list.
> We can't add a virtual product to shopping cart?
> When I am selecting configuration it is not showing the product price with
> configuration.
> My question is how the fillproductconfigwrapper method identifies the
> configuration parameter from request
>
> I am thankful for any kind of help
>
> regards
> Vamsi
> --
> View this message in context: http://www.nabble.com/Problem-in-Virtual-products-tf3146776.html#a8723541
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>