Thanks David, I will have a look at it.
Jacques > > The main event for this in the ecommerce controller.xml file is > "setSessionCurrencyUom". > > -David > > > On Feb 4, 2007, at 1:05 AM, Jacques Le Roux wrote: > > > David, > > > >> Actually, these were answers to the other parts of your email, which > >> is why I put them below the part I was responding to. > > > > Yes I know. The first part below was only to ask new questions. > > Anyway they are answered by your last (new and very interesting) > > information. Since "From ecommerce you can select a different > > currency at run-time." explicitly shows that 1 store can deal with > > more that 1 currency. However, how an user can select a currency, > > please ? > > > > Jacques > > > > > > ----- Original Message ----- > > From: "David E. Jones" <[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 > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>> > >> > >> > > > >
