On Dec 29, 2006, at 6:54 PM, Ean Schuessler wrote:
On Friday 29 December 2006 19:40, David E Jones wrote:
This is the million dollar question (sorry for the localized saying).
There is still some debate about whether we want to continue on the
(unfinished) path of the quantity/amount pair, or just go back to a
fractional quantity on its own.
Personally I'd much rather see the quantity/amount move forward, but
it is incomplete and so needs some work. I've heard things actually
function if the integer restriction is removed, so that is probably
the easier, but less flexible and future proof, way to go (ie just
tweak it to accept franctional quantities).
It seems to me that fractional quantities (perhaps with a flag that
blocks
non-integer values for some items) is cleaner. I would think that
typically
different "amount" type things would show up as actual separate SKUs.
For instance, in the lumber example, I would think you would have
separate
actual SKUs for a 8' and 10' board and that you would not want to
ring up 3
8' boards as a 2.4 amount of a 10' SKU.
The fractional quantities seem to work for me. I need to try the
amount stuff,
does that reflect into inventories correctly? How does that part work?
For amounts there is a field on the product (requireAmount if I
remember right) to denote that a product should be purchased with
both a quantity and amount.
You're right that things which are pre-cut should be variants or
something with separate productIds and those would not have a
fractional amount. Some things are easily cut in a somewhat build-to-
order fashion, like rope or wire or rolls of anything really. The
idea with the combination of an integer quantity and a fractional
amount is that you could specify, with the rope example, that you
want 4 lengths of rope that are 100 ft each (ft being the amount unit
on the product).
The way it _should_ work in inventory checking, reserving, and
issuing is to multiply the quantity by the amount to get the
fractional quantity for the InventoryItem, etc. I think this is where
the implementation historically left off, and I don't know if it has
seen any action since its early days. This really needs to be tested
and finished for the purchase and reservation, issuing and shipping,
invoicing, returning, etc.
-David
