(a six-pack in this case).
Can you help me ?
Thanks.
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/more-than-one-unit-of-measue-fo-the-same-product-advice-requested-tp2952350p3308850.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
That sounds fair enough, I will do...
Thanks
Jacques
From: "Hans Bakker"
I leave it up to you to further enhance it?
Regards,
Hans
On Wed, 2011-01-26 at 10:02 +0100, Jacques Le Roux wrote:
Hi Hans,
Almost perfect: the product names are not used, and why not a specific icon for
them?
Also
I leave it up to you to further enhance it?
Regards,
Hans
On Wed, 2011-01-26 at 10:02 +0100, Jacques Le Roux wrote:
> Hi Hans,
>
> Almost perfect: the product names are not used, and why not a specific icon
> for them?
> Also I wonder if we should not widen the left panel? I guess this width ha
Hi Hans,
Almost perfect: the product names are not used, and why not a specific icon for
them?
Also I wonder if we should not widen the left panel? I guess this width has
been set when the most used screen resolution was
800x600 it's now 1024x768
Thanks for your time!
Jacques
From: "Hans Bak
category/catalog tree updated in r1063625
thanks for your comments!
Regards,
Hans
On Sat, 2011-01-15 at 11:06 +0100, Jacques Le Roux wrote:
> Jacopo,
>
> Well spotted! I have fixed your concern at r1059279. I wonder how I missed
> that since I was inspired by
> AgreementServices.getCommission
Actually I had a look and changed my mind. It's the default (defined in
framework/images/webapp/images/jquery/plugins/jsTree/themes/default/style.css) and
1) I think there are good reasons to have set it as is (maybe to make the area
more visible?)
2) I don't want to mess
3) I have not enough ti
OK I will do
Jacques
From: "Hans Bakker"
sure, change it, that is no problem for us.
On Tue, 2011-01-18 at 09:47 +0100, Jacques Le Roux wrote:
Hans,
A last request: I think we should better have a white background for the tree.
Jacques
From: "Hans Bakker"
> Hi Jacques, were are looki
Hans,
A last request: I think we should better have a white background for the tree.
Jacques
From: "Hans Bakker"
Hi Jacques, were are looking at it but very busy.
Regards,
Hans
On Mon, 2011-01-17 at 18:37 +0100, Jacques Le Roux wrote:
Hans,
Inline...
From: "Jacques Le Roux"
> Jacopo
Thanks Hans, much appreciated
Jacques
From: "Hans Bakker"
Hi Jacques, were are looking at it but very busy.
Regards,
Hans
On Mon, 2011-01-17 at 18:37 +0100, Jacques Le Roux wrote:
Hans,
Inline...
From: "Jacques Le Roux"
> Jacopo,
>
> Well spotted! I have fixed your concern at r105927
Hi Jacques, were are looking at it but very busy.
Regards,
Hans
On Mon, 2011-01-17 at 18:37 +0100, Jacques Le Roux wrote:
> Hans,
>
> Inline...
>
> From: "Jacques Le Roux"
> > Jacopo,
> >
> > Well spotted! I have fixed your concern at r1059279. I wonder how I missed
> > that since I was i
Hans,
Inline...
From: "Jacques Le Roux"
Jacopo,
Well spotted! I have fixed your concern at r1059279. I wonder how I missed that since I was inspired by
AgreementServices.getCommissionForProduct() :/
Hans: also could you please look at the catalogs/categories tree: there is only Ids in it,
Jacopo,
Well spotted! I have fixed your concern at r1059279. I wonder how I missed that since I was inspired by
AgreementServices.getCommissionForProduct() :/
Hans: also could you please look at the catalogs/categories tree: there is only Ids in it, at least we should rather have the names
(w
I think that we should not forget about this because the fix proposed by
Jacques (thanks for this) should be considered a temporary one... for example
it doesn't take into account validity dates of the relationship; as a side
note, the same issue (validity dates ignored) was also in the original
Hi Hans,
This has introduced a bug I fixed at r1057153
The isVirtual Product attribute shows around 160 times in *form*.xml,*een*, *.gro*,*.ftl,*.java files. Of course I did not check
them all. But I'd be surprised if your change has not introduced some other side effects...
Could youy please
This change is now implemented in r1040908
Related to the comment from Scott, Instead of using the existing
association, we have created a new product association 'Alternative
Packaging' to not interfere with the usage of Scott.
An explanation can be found at:
https://www.antwebsystems.com/conten
i could also add a new association type "alternative Uom" and then still
use isVirtual=Y/isVariant=Y...which would not block your usage
On Fri, 2010-11-12 at 21:34 +1300, Scott Gray wrote:
> Hi Hans,
>
> I'm still in favor of the approach that I suggested earlier and you haven't
> really me
Hi Hans,
I'm still in favor of the approach that I suggested earlier and you haven't
really mentioned why it wouldn't work for you. If you like and if you are
willing to wait a couple of days I could show you what I mean with some example
entity xml data. You could then load it into a demo in
A longer explanation how we want to implement this can be found at:
http://www.antwebsystems.com/control/ViewBlogArticle?contentId=16750&blogContentId=AWS_BLOG
Regards,
Hans
On Wed, 2010-11-10 at 16:52 +0700, Hans Bakker wrote:
> We are are still getting the best solution, help appreciated.
>
>
We are are still getting the best solution, help appreciated.
We are thinking of the following:
you have a product which you sell in pieces and boxes of ten.
Then the product per piece is the lowest denominator and has a variant
association to a virtual/variant product which is an alternative
pac
This sounds pretty good i even see some coding on this.
Let me do some testing, i will come back with the results.
Regards,
Hans
On Sun, 2010-10-03 at 12:13 -0600, David E Jones wrote:
> For boxes of a product you'll usually have one product that represents the
> individual items (which may or
I see you point from a designer point of view, however there is a
difference when you look at from a workeffort point of view.
something ofbiz has not address fully, yet.
Scott Gray sent the following on 10/3/2010 2:52 PM:
A difficult to use UI dictates the need for a better UI, it doesn't mea
A difficult to use UI dictates the need for a better UI, it doesn't mean that
you need to add new tables and alter the underlying business logic when the
existing processes work just fine.
There is no reason why the user couldn't setup the base UOM product and then
have a special screen/form to
Scott I followed you on the Marketing UOM but I can't find you comments
on Inventory side except to say to use standard procedures.when I did my
multiple UOM I could not find where you would have the all the Products
UOM with out first adding Virtual/variants. this is all by hand and time
consu
I'm sorry you're not making any sense. I've explained how multiple UOMs are
supported OOTB for both just-in-time conversion and for longer lived UOM
inventory that may require effort to produce.
What is so wrong with the current functionality that we need to add new tables?
How would a SECA o
Ok so your talking about receiving different UOM like from different
suppliers but you want one UOM to sell.
That seems to be something to setup per supplier and use the normal
conversions available now.
Unless you expect to get different UOM from the same supplier, in which
case I can see your
For boxes of a product you'll usually have one product that represents the
individual items (which may or may not be for sale directly to the customer),
and one that is a product that represents the box and that is associated with
the individual item. In OFBiz there are a few different product
So having a entity that defines the different UOM that can be sold in
inventory would be a good Idea, at a minimum.
and as Hans Says have a price differential for each UOM.
use a SECA to trigger on the ProductPricing service to run a service to
populate for the Virtual/variants
So all the user
You wouldn't use marketing packages in that situation, you'd just use regular
products and regular production runs.
Regards
Scott
On 4/10/2010, at 12:07 AM, BJ Freeman wrote:
> how would the marketing package allow for inventory levels to be established
> for different UOM. is marketing not a
how would the marketing package allow for inventory levels to be
established for different UOM. is marketing not a "Just in time" type of
management?
What about inventory that takes long lead times to process, that would
delay shipments beyond a reasonable time. This could be from too many
prod
Hi Hans,
I'm not sure I understand what you proposed, could you explain it further?
Virtual/variants and the marketing packages would serve different purposes in
what I was suggesting, the marketing packages would serve to convert the base
uom product to each of the marketing package's uom wher
But involving the complete manufacturing process? please have a look at
my earlier message about adding a field to the productassoc entity
On Sun, 2010-10-03 at 18:13 +1300, Scott Gray wrote:
> If you were to go the marketing package route, the box of 10 would be the
> marketing package and t
Thinking further on he virtual/variant ideawe could store the conversion
in the ProductAssoc table with a field uomConversion between the base
products and the virtual variants uom.
What do you think of that?
Regards,
Hans
Hi Scott, this is sure an interesting idea, but then how does t
If you were to go the marketing package route, the box of 10 would be the
marketing package and the single piece would be the product that all inventory
is stored against. The ProductAssoc (type "component" I think) between the box
of 10 and the piece would have a quantity of 10. Whenever the
Hi Scott, this is sure an interesting idea, but then how does the system
know that they are for example 10 pieces in a box? I still what to have
the same inventory for boxes and pieces.
We should be able to store the conversion between the uom's for this
product somewhere?
Thanks for you input!
Hi Hans,
Sorry if this is a silly question, but why not just use different products for
different UOMs? You could use virtual/variants if you wanted the UOM to be
selectable on a single product page and also marketing packages to
automatically produce inventory for the desired UOM from the bas
Thank you BJ,
I had in mind to create and 'productUomAlternatives' table to the
product with a conversion for example from pieces to boxes with an
optional price adjustment percentage.
The system will have however only one uom where everything gets
converted to.
Anybody else other solutions?
Reg
Yes also like a Feed store will have boxes, Sacks, and loose feed.
I used the multiple pricing model for the Uom Measure
in the product screen made it allow multiple UOM.
added to the code that converts from what is received in inventory to
what is sold so it walks through the Uom. for instance
A question to the community:
sometimes the same products are sold with different units of measure.
Example gold jewelry.
Per piece, per box of 10, per box of 50 and per gram gold weight.
Is here a preference how to implement that?
Remember this has to show up in e-commerce, orders, shipments an
38 matches
Mail list logo
