Jacques,
Jacques said:
> <<So as I thought it's better to handle different currencies in different
> stores for now. Am I missing something here ? >>
> Is that always true ? Is it a recommended best practice to do so (having 1
> store by currency) ? Are there other scenarios, future scenarios ?
I've seen applications that use just 1 base/core currency for the entire store, and just do a
real-time calculation (say with oanda exchange rate server) when a non-base/non-core currency is used.
Personally, I don't see many stores handling > 1 currency. Taking in "fixed prices in foreign
currencies" is actually quite bad for business, because that subjects the business to forex
fluctuations.
Imagine having a store with fixed price tags in EUR and in a currency (fictitious for
illustration) WildMoney that fluctuates like mad. Now imagine shoppers coming in with WildMoney
only on days when WildMoney is wildly weak against the EUR. This store will be losing a lot of money!
> Perhaps it's only a matter of words, replacing "Default Currency Uom Id" by
> "Currency Uom Id for this store" and explaining more with an
> HTML-title-tooltip might be enough ?
More than enough. In-application (in vivo) help texts are a lot more user-friendly than docs
separated from the application (in vitro? assuming the application is glass :) ).
> Also I'm here trying to grab knowledge at the User level (unlike for instance
> Jonathon wich claims to reverse) and perhaps OFBiz was not conceived in this
> spirit. That might explain the lack of *advanced* user's documentation
> (advanced documentation not user). Or simply ERPs can't be or rather are
> difficult to be documented for users (I'm not an ERP veterans) ?
ERPs are naturally complex, with different flavors/functionalities for
different businesses/companies.
Complex as they may be, companies that employ ERPs (whether coded in-house in PHP, or designed by
vendors in OOTB form) often do/must document their usage of those ERPs. Even if they use OOTB
products, there will be parts of the product they don't use, or use in a "special" way. They'd
need to document that as well.
We really should document the ERP part of OFBiz. I currently refer to OFBiz as 2 parts: OFBiz-ERP
and OFBiz-core.
About effort in documentation, it is always significant or at least substantial. Say we write some
program codes, test it, debug it, and "voila! it works", and we leave it at that. Then we need to
document our program at the "functional level" (ie, "yeah, it seems to work this way from a user's
POV"). And if our coding style is not declarative and clean, we then need to review our codes to
make sure it correctly goes from "A to B to C" rather than "A to B to A to B to C".
And that's just one function in our program, or 1 small module in a larger program. We repeat the
above for other modules. And eventually, we document the cross-references between modules. And
this is the difficult part.
Example:
"If Jonathon bows, Jacques coughs. If Jacques coughs, David claps. If David claps, Jonathon
dances. If Jonathon dances, Jacques coughs." Hmm. Now how do we document this?
We can try a "breadth-first" approach in documentation. Make sure all developers understand the
codes first. Then with spare resources, we make sure all users understand the application. Then we
try to make the higher management (who won't even need to work, much less USE OFBiz?) understand
the purchase of the application.
(I know, real-world business and marketing techniques mess up that order.)
> The most consistent behaviour is obtained by IE :(. Here Firefox (All Mozilla
> browser I guess) is not a good candidate. I desesperately looked for an
> extension (or even an hack, mm...mm) but did not find any.
I agree with your assessment of IE vs Firefox. Firefox isn't entirely completely implemented; some
UIs do not render correctly yet. IE quirks and errors are more numerous than Firefox, but is more
widely used. If I code things correctly and that happens to suit Firefox 99% of the time, I'll see
broken UIs in IE.
I've long given up wishing that IE does not force us to code things "wrongly".
Jonathon
Jacques Le Roux wrote:
David,
I try to understand things deeper. Many questions...
I said :
<<So as I thought it's better to handle different currencies in different stores for
now. Am I missing something here ? >>
Is that always true ? Is it a recommended best practice to do so (having 1
store by currency) ? Are there other scenarios,
future scenarios ?
You said :
No. The price stuff will look for prices according to the currency
set on the ProductStore.
and
NO! Not totally correct. In this case of the ProductStore currency was
USD then the virtual product's prices would be used. If the ProductStore
currency was EUR, then the variant product's prices would be used.
So why the string "Default Currency Uom Id" for the currency field in Catalog/Store ?
Would not "Currency Uom Id" be more
appropriate as this data looks like more a constraint (can't be overriden), at
least for products ? Are there other reasons to put
*Default* ?
In Undersun User Documentation (thanks David and Andy for this !) I read in explanation
of the field "Default Currency Uom Id" :
"Which national currency will be used if none is
specified.". Hence "Default" I suppose. But it seems not to act as a default
value from what you stated above David. On the
contrary, it specifies the currency that will be chosen between several. I use
chosen because I can't see a case where "no currency
is specified" (and where a default value will then be used). Because when you
define a price a currency is always set. And
currencies are only used in prices, isn'it ?
I suppose also that "Product Store Group" has no effect on currency ? Or in other words,
may the "Product Store Group" concept be
used to deal with multi-currencies ?
I understand that a product may be shared between stores thru
catalogs/categories and may have prices in each currency needed by
each store. In such cases, one more time "Default Currency Uom Id" defines the
currency of the store and not "a default currency for
this store if none is specified", isn'it ?
I agree with Jonathon that the error message is too general and should be
changed to help users identifie the real origin of the
problem. But note that this is at the functionnal level. Idid not look at the
code. Perhaps under the hood it's more complicated...
Especially if the routine that calculates prices is widely generalised.
Perhaps it's only a matter of words, replacing "Default Currency Uom Id" by
"Currency Uom Id for this store" and explaining more
with an HTML-title-tooltip might be enough ?
Also I'm here trying to grab knowledge at the User level (unlike for instance
Jonathon wich claims to reverse) and perhaps OFBiz was
not conceived in this spirit. That might explain the lack of *advanced* user's
documentation (advanced documentation not user). Or
simply ERPs can't be or rather are difficult to be documented for users (I'm
not an ERP veterans) ?
Subtle slight nuances, great effects... Everybody still there ? Not sure even
if I am...
Actually what I'm trying to do is to find a way to put the most possible "advanced
and accurate documentation" easily at reach of
users, that's all. In order to do so I tested the rendering of HTML field title
attribute (tooltip in widgets) in 4 browsers on
Windows.
Browser length max duration wrap lines
---------------------------------------------------------
Firefox 1.5.0.9 80 char 5 sec never
IE 6 at least 1000 5 sec if in source
IE 7 at least 1000 5 sec if in source
Opera 9.02. at least 1000 no limit always
The most consistent behaviour is obtained by IE :(. Here Firefox (All Mozilla
browser I guess) is not a good candidate. I
desesperately
looked for an extension (or even an hack, mm...mm) but did not find any.
It might be interesting to have behaviours on Linux (Mmm..Gnome, KDE, XFCE,...)
and Mac
Note also that title used as tooltip is often not recommended for accessiblity
reasons (many screenreaders don't read title text by
default). But users may change this default.
http://www.sf.id.au/WE05/indexa.html
Interesting article on <abbr> tag also :
http://www.alistapart.com/articles/hattrick (takes some time to read)
Thanks
Jacques
Haha! Comical tragedies. Sigh.
Thanks for that very concise and definitive "documentation" for this aspect,
David.
I can understand how Jacques (and me) could've easily been misled by our test
cases; outcome a
little too ambiguous (no proper warning messages?). Digging into codes directly
would've avoided
that "misunderstanding" between us (users) and OFBiz (application).
Jonathon
David E. Jones wrote:
On Feb 2, 2007, at 4:06 AM, Jacques Le Roux wrote:
Jonathon, David,
David,
As I understand from Jacques issue descriptions:
1. Price set for Virtual product in USD
2. Price set for related Variant product in EUR
3. Price for Variant is not used at all.
If that's the case, it is a bug.
I haven't tested this out.
Jacques, is the above correct?
Yes totaly correct.
NO! Not totally correct. In this case of the ProductStore currency was
USD then the virtual product's prices would be used. If the ProductStore
currency was EUR, then the variant product's prices would be used.
This all sounds like a misunderstanding.
-David
David answered
<<The only reason to put a price on the virtual product is to act as a
default, so it is totally optional and for many product sets may not
exist at all. That is true in general, and could even vary by
currency depending on what people want to do with it. In other words,
I don't think we should put in a check or requirement like that
because there are perfectly valid scenarios where you would not want
that.>>
Mmm... Strange that a default value might not be overriden in some
case, isn'it ?
BTW I agree that it's not a big deal. Just wanted a better interface,
could this requirement break something ?
I just tested without prices for virtual and a price in USD for a
variant and another variant with EUR for the same store having USD
as default currency. The variant with EUR price is not accepted :
* Could not find a valid price for the product with ID
[WG-9943-B4], not adding to cart.
So as I thought it's better to handle different currencies in
different stores for now. Am I missing something here ? Else this last
fact close this discussion and should be reported as best user practice.
Because I guess we need more user doc than dev at this moment...
Thanks
Jacques
Jonathon
David E. Jones wrote:
I don't see any problem here.
The code looks for price information on the product. If no price
information for a certain type, currency, etc is not found and the
product is a variant it will find the corresponding virtual product and
look for the price information there.
What else could/would it do?
What is the bug here?
-David
On Feb 1, 2007, at 12:50 AM, Jacques Le Roux wrote:
Finally, I want to make an abstract of what I understand :
Variants herit prices from virtual.
Variants may override prices from virtual, hence have different
currencies than virtual.
But this last functionnality (regarding currency at least) is not
working yet.
Is that correct ? If yes, I will open a Jira issue for this peculiar
case where I will propose to restrict currency in variants to
virtual's, for the moment.
Of course I understand that in a perfect world we should support
different currencies for different variants. But I guess this can
wait... Because I'm only reasoning at the businness level for the
moment. And I guess at the technological level things may be less
clear.
Thanks for your attention
Jacques
Jonathon,
Jacques,
I was asking myself, in a principe of reality, if we should not,
for the
moment, restrict variants currencies to their virtual's.
Agreed. This will tie up that "loose end". Rather than having
"undefined behavior" (for multiple
currencies), we should at least let users know that their virtual
products' currencies count and
the related variants' don't. Or better yet, prevent users from using
a different currency for
variants.
Later was what I was suggesting. it's easy to do, in one word :
pragmatic ! I think I will create at least a Jira issue for this
if
nobody disagree (with strong arguments ;o)
A sticky issue: which currency/price takes precedence, variant or
virtual?
I'd say variant prices should override virtual.
Yes variants should override. But has this a sense ? Because
virtuals are
never used as product, they are abstract (in Oriented Object
sense). So I
wonder if having a currency different for virtual and variants
have a
sense. Having variants with different currencies is another
problem...
Hmm. In OO sense, it doesn't make sense that virtuals have a price
even.
Yes true, but difficult to manage because product UI is generalised
and morevover because of your point below.
However, in
user-interface sense, users would want to have a "standard price"
set for all variants, for ease
of use if for nothing else.
Hence, I can see why some users might want to tie currency/price to
virtuals.
Yes true, OO heritage ;o). So remains the case of different
currencies for different variants. But is that realistic (this is a
real
question for real people) ?
Well, at least we share/discuss what we know so that others can grab
our info and enhance OFBiz,
though we ourselves have no time to fix this issue. :P
We may hope so, but I would prefer to do job because else I will wait
for sure. I just want to know if nobody see drawbacks in
arguments above, or have better ideas ?
Thanks
Jacques
Jonathon
Jacques Le Roux wrote:
Jonathon,
From: "Jonathon -- Improov" <[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
