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" <[EMAIL PROTECTED]> To: <[email protected]> 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" <[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 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" <[EMAIL PROTECTED]> > >>>>>>>>>>>> To: <[email protected]> > >>>>>>>>>>>> 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" <[EMAIL PROTECTED]> > >>>>>>>>>>>>>>> To: <[email protected]> > >>>>>>>>>>>>>>> Sent: Wednesday, January 31, 2007 5:02 PM > >>>>>>>>>>>>>>> Subject: Re: Problem in Virtual products > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Jacopo, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> From: "Jacopo Cappellato" <[EMAIL PROTECTED]> > >>>>>>>>>>>>>>>>> Jacques Le Roux wrote: > >>>>>>>>>>>>>>>>>> Vamsi > >>>>>>>>>>>>>>>>>>> When I am selecting configuration it is not > >>>>>>>>>>>>>>>>>>> showing the > >>>>>>>>>>>>>>>>>>> product price with > >>>>>>>>>>>>>>>>>>> configuration. > >>>>>>>>>>>>>>>>>> AFAIK there are no specific prices for variants. > >>>>>>>>>>>>>>>>>> If you > >>>>>>>>>>>>>>>>>> set a > >>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > > > >
