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 USDas 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 JacquesJonathon 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 theproduct is a variant it will find the corresponding virtual product andlook 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 peculiarcase 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 JacquesJonathon,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 andthe related variants' don't. Or better yet, prevent users from usinga 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 thisifnobody disagree (with strong arguments ;o)A sticky issue: which currency/price takes precedence, variant orvirtual? 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 Iwonder 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 priceeven.Yes true, but difficult to manage because product UI is generalisedand 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 tovirtuals.Yes true, OO heritage ;o). So remains the case of differentcurrencies for different variants. But is that realistic (this is arealquestion for real people) ?Well, at least we share/discuss what we know so that others can grabour info and enhance OFBiz, though we ourselves have no time to fix this issue. :PWe may hope so, but I would prefer to do job because else I will waitfor sure. I just want to know if nobody see drawbacks in arguments above, or have better ideas ? Thanks JacquesJonathon Jacques Le Roux wrote:Jonathon, From: "Jonathon -- Improov" <[EMAIL PROTECTED]>I think David's point about supporting multiple currencies is valid, ie OFBiz should operate that way. It'll be nice to be able to use different currencies for different variants (eg. some sold in some countries but not in others).Yes I totally agree.However, I strongly suspect that's not exactly how it works now.I agree too. Yes for the moment people wanting to deal with multiple currencies create a store by currency, I guess.Let me know if anyone needs me to help in research; my current project doesn't handle more than 1 currency... yet.I would create a Jira issue for this. This is not a priority for meeither. And I suspect that it may be a large task to do.Sothat's why I was asking myself, in a principe of reality, if we should not, for the moment, restrict variants currencies totheirvirtual's.A sticky issue: which currency/price takes precedence, variant orvirtual? 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 (inOrientedObject sense). So I wonder if having a currency different for virtual and variants have a sense. Having variants withdifferentcurrencies is another problem... Thanks for your thoughts JacquesJonathon Jacques Le Roux wrote:Do you mean that it should work like I tried to use it or that weshould make it work, or ? Jacques ----- Original Message ----- From: "David E. Jones" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, January 31, 2007 10:45 PM Subject: Re: Problem in Virtual productsThe 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 willnot be used. And this can fool an user as I have been. What do you think ? JacquesSorry,I used euro and not dollar for variant prices. So yes, you areright Jacopo and sorry Jacques ----- Original Message ----- From: "Jacques Le Roux" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, January 31, 2007 5:02 PM Subject: Re: Problem in Virtual productsJacopo, From: "Jacopo Cappellato" <[EMAIL PROTECTED]>Jacques Le Roux wrote:VamsiAFAIK there are no specific prices for variants. If you set a price for a variants this will have no effect. The price setWhen I am selecting configuration it is not showing the product price with configuration.fortheI tested it before by creating a default price for WG-9943-B3I'm pretty sure that the variant price is used if set, it willvirtual product will be used.appear as soon as you add the variant to the cart.andit was not applied but the virtual price was applied. BTW thevirtual had also Competitive and List Prices. So I just tested byadding Competitive and List Prices to the variant WG-9943-B3sameresult. Am'I missing something here, promotions, prices rules ? JacquesJacopo
smime.p7s
Description: S/MIME cryptographic signature
