Problem in Virtual products

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

David E Jones

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" <[hidden email]>
>>>>> 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" <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> 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" <[hidden email]>
>>>>>>>>> To: <[hidden email]>
>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Jacopo,
>>>>>>>>>>
>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>> 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
>>>>>>
>>>>
>>>>
>>>
>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

Jacques Le Roux
Administrator
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" <[hidden email]>
> >>>>> 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" <[hidden email]>
> >>>>>> To: <[hidden email]>
> >>>>>> 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" <[hidden email]>
> >>>>>>>>> To: <[hidden email]>
> >>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Jacopo,
> >>>>>>>>>>
> >>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>> 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
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

David E Jones

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" <[hidden email]>
>>>>>>> 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" <[hidden email]>
>>>>>>>> To: <[hidden email]>
>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>
>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

jonwimp
In reply to this post by David E Jones
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" <[hidden email]>
>>>>>> 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" <[hidden email]>
>>>>>>> To: <[hidden email]>
>>>>>>> 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" <[hidden email]>
>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Jacopo,
>>>>>>>>>>>
>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

Jacques Le Roux
Administrator
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" <[hidden email]>
> >>>>>> 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" <[hidden email]>
> >>>>>>> To: <[hidden email]>
> >>>>>>> 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" <[hidden email]>
> >>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Jacopo,
> >>>>>>>>>>>
> >>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>>> 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
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >

Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

David E Jones
In reply to this post by jonwimp

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" <[hidden email]>
>>>>>>> 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" <[hidden email]>
>>>>>>>> To: <[hidden email]>
>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>
>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

David E Jones
In reply to this post by Jacques Le Roux

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" <[hidden email]>
>>>>>>>> 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" <[hidden email]>
>>>>>>>>> To: <[hidden email]>
>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem in Virtual products

jonwimp
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" <[hidden email]>
>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
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" <[hidden email]>
> >>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >

Reply | Threaded
Open this post in threaded view
|

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

David E Jones

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

> David,
>
> I try to understand things deeper. Many questions...
>
> I said :
> <<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" <[hidden email]>
>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

jonwimp
In reply to this post by Jacques Le Roux
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" <[hidden email]>
>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Currency in store and eCommerce

Jacques Le Roux
Administrator
In reply to this post by David E Jones
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" <[hidden email]>
To: <[hidden email]>
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" <[hidden email]>
> >>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
In reply to this post by jonwimp
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" <[hidden email]>
> >>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

David E Jones
In reply to this post by Jacques Le Roux

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" <[hidden email]>
> To: <[hidden email]>
> 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" <[hidden email]>
>>>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>>>> 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" <[hidden email]>
>>>>>>>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
>>>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jacopo,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

Jacques Le Roux
Administrator
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" <[hidden email]>
> > To: <[hidden email]>
> > 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" <[hidden email]>
> >>>>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>>>> 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" <[hidden email]>
> >>>>>>>>>>>>>>>>> To: <[hidden email]>
> >>>>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM
> >>>>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Jacopo,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[hidden email]>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

Lindsey L.
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
Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

Jacques Le Roux
Administrator
In reply to this post by Jacques Le Roux
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." <[hidden email]>

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

Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

David E Jones
On Sat, 15 Dec 2007 23:02:18 +0100
"Jacques Le Roux" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

Jacques Le Roux
Administrator
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" <[hidden email]>

> On Sat, 15 Dec 2007 23:02:18 +0100
> "Jacques Le Roux" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Currency in store and eCommerce

David E Jones

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" <[hidden email]>
>> On Sat, 15 Dec 2007 23:02:18 +0100
>> "Jacques Le Roux" <[hidden email]> 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
>>
>


smime.p7s (3K) Download Attachment
123