Hi all,
We made something very similar.
We use this information of purchasing orders until the reception.
I am going to supply a patch and more details of what we made in the
course of September (at present I am on holidays)
Is there Jira to propose a patch?
Many thanks
Pierre
On 14/08/2017 10:43, Jacques Le Roux wrote:
Thanks Scott,
Inline too
Le 14/08/2017 à 08:20, Scott Gray a écrit :
Hi Vaibhav,
Comments inline.
Regards
Scott
On 11 August 2017 at 02:55, Vaibhav Jain
<[email protected]>
wrote:
Thank you so much Scott for sharing these details, indeed they are
really
helpful.
Kindly see my comments inline.
On Thu, Aug 10, 2017 at 3:22 PM, Scott Gray
<[email protected]>
wrote:
Hi Vaibhav,
It's a good question and mailing list archives (that are available)
don't
really answer the question clearly. At the moment as far as I can
tell,
the quantityUomId and unitsIncluded field do nothing, they're display
only.
I think SupplierProduct.unitsIncluded is the same as
Product.quantityIncluded, the field types are the same and the names
imply
similar things. I actually think unitsIncluded is a better name than
quantityIncluded which is confusing because the number doesn't
relate to
any quantity fields we normally use.
IMO, quantityIncluded name can be better choice, because as my
undestanding
unitsIncluded is used to define units of product (like each, pack etc.)
but we may have products in various UOMs like (weight UOM,
Liquid/Volume
UOM e.t.c.)
The confusing part is that quantityIncluded implies it has some
relation to
the OrderItem.quantity being ordered but that isn't the case. I see
your
point though. Perhaps a name like uomQuantityIncluded would make more
sense.
+1 for uomQuantityIncluded, too late to change?
From the Product entity definition we have this explanation of the
fields:
"If you have a six-pack of 12oz soda cans you would have
quantityIncluded=12, quantityUomId=oz, piecesIncluded=6"
piecesIncluded is missing from ProductSupplier but I think the
definition
for quantityIncluded/unitsIncluded can stand without it.
As per my understanding the quantityIncluded defines the quantity
included
in the respective quantityUomId and we do not need piecesIncluded here.
The need is really based on the real-world use case. piecesIncluded
could
have a place in a purchasing use case in the same way it does for a
selling
use case.
+1 for putting in piecesIncludedin case of purchase also.
"If you have a six-pack of 12oz soda cans you would have
quantityIncluded=6 quantityUomId=pack"
As per my understanding, I think, "oz" is a weightUomId and this
should be
managed at product level not at SupplierProduct. Please let me know
your
thoughts on this.
The purpose of the Product.quantityUomId is to define how we choose to
describe our product. Likewise the SupplierProduct.quantityUomId
defines
how the supplier describes their product.
To extend my earlier use-case: If I am a house painter in NZ but I
import
my paint from the US, then chances are I would be ordering from a
supplier
who works in fluid ounces, US quarts or gallons. Despite that, I still
want to be able to sell paint locally by the litre.
So I think what we can conclude from this detail is that these
fields are
informative and not functional, and they shouldn't have any bearing
against
other fields such as lastPrice.
Agreed!
I think there could be room for making use of the fields, an example:
Let's say you are a house painter and you need to order 12 litres of
paint
for a job. The supplier has two products available, 2 litre tins @
$10
and
4 litre tins @ $15:
<SupplierProduct quantityUomId="VLIQ_L" unitsIncluded="2"
lastPrice="5"
minimumOrderQuantity="1" orderQtyIncrements="1"/>
<SupplierProduct quantityUomId="VLIQ_L" unitsIncluded="4"
lastPrice="3.75"
minimumOrderQuantity="1" orderQtyIncrements="1"/>
So you tell your amazing OFBiz system that you'd like to order 12
liters
of
paint, OFBiz will then look at your SupplierProduct records and
determine
which record gives you the best price and fits within the supplier's
purchasing rules (i.e. you can't order half a tin of paint). OFBiz
ultimately puts the selection into OrderItem.supplierProductId and
sets
the
unitPrice accordingly. As a second function,
OrderItem.supplierProductId
can then also serve to correctly format the PO that the supplier
receives
so that instead of seeing:
"Send me 12 litres of paint @ $3.75/litre please"
they could instead see:
"Send me 3 units of 4 litre paint @ $15/unit please"
It wouldn't alter what we see in the OrderItem record, but it could be
used
for information the supplier receives and perhaps also for shipment
receipt
verification (if you wanted 4L tins and they sent you 2L tins, maybe
that's
an issue that needs to be dealt with).
It's a great use case, what I have concluded from this is,
We should use quantityUomId and quantityIncluded fields,
Just additional thought, if we use these fields then these fileds
should be
the part of OrderItem entity as well. This will help in maintaining the
information at order item level.
I'm not sure, because the fields are informative and have no financial
impact, I don't see that much benefit would be gained from storing the
values on OrderItem. I could be wrong, but I'm not sure what it would
accomplish.
+0, I'm undecided on this. Maybe if they are not used for sales then
they should also not be for purchase, or then they should be in both
cases.
Jacques
Please correct me on this, if I understand anything incorrectly.
I hope that helps. I've made a few assumptions here so if anyone
thinks
Indeed very helpful, thanks so much :)
I'm incorrect please speak up.
Regards
Scott
On 9 August 2017 at 23:31, Vaibhav Jain
<[email protected]>
wrote:
Hello all,
There are two fields, *quant**ityUomId* and *unitsIncluded* in
SupplierProduct entity.
Can someone please elaborate the use of these fields?
After creating a record of SupplierProduct with *quantityUomId*="box"
and
*unitsIncluded*="10", created a purchase order but didn't notice any
change.
How are these fields entertained in the purchase order?
Thanks & Regards
Vaibhav Jain
Hotwax Systems,
[email protected]
--
logoNrd <http://nereide.fr/>
Pierre GAUDIN
Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
[email protected]
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 06 08 40 25 70
ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE
<http://www.libre-entreprise.org/>
