Problem in Virtual products
Locked
123
123
Re: Problem in Virtual products
 
|
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)
Re: Problem in Virtual products
Administrator
|
Re: Problem in Virtual products
|
|
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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > |
Re: Problem in Virtual products
|
|
Re: Problem in Virtual products
|
Administrator
|
Re: Problem in Virtual products
|
|
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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> > |
Re: Problem in Virtual products
|
|
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. 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > |
Re: Problem in Virtual products
|
|
Re: Problem in Virtual products... Sequels...
|
Administrator
|
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. 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 >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> > |
Re: Problem in Virtual products... Sequels...
|
|
Currency in store and eCommerce
|
Administrator
|
Re: Problem in Virtual products... Sequels...
|
Administrator
|
Re: Currency in store and eCommerce
|
|
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 >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >> > |
Re: Currency in store and eCommerce
|
Administrator
|
Re: Currency in store and eCommerce
|
|
Re: Currency in store and eCommerce
|
Administrator
|
Re: Currency in store and eCommerce
|
|
Re: Currency in store and eCommerce
|
Administrator
|
Re: Currency in store and eCommerce
|
|
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 >> > |
| Free forum by Nabble | Edit this page |