My comments inline...
[...]
QuantityBreak
---------------------
No, don’t get rid of the QuantityBreak entity, and it should be used as
part
of pricing. Many organisations will have standard QuantityBreaks that
apply
to a wide range of products. An organization might want to offer
various
agreed prices to customers, but use the same quantity breaks
consistently.
It should be possible to add a new price for a product without having
to
define quantity breaks, with the risk that the newly entered quantity
breaks
are inconsistent with standard organisation policy.
Maybe this wasn't clear... the goal is to get rid of the QuantityBreak
entity and use the quantity fields directly. This significantly
simplifies
both the data model and the code. In theory what you say is correct,
that
quantity breaks could be maintained separately, but that hasn't happened
in
any of the OFBiz UIs, and in fact I've never seen anything like that
actually used (I've seen them built, but then abandoned because for the
user
they are cumbersome).
If an organization wants a policy of specific quantity breaks they can
certainly implement that and design the user interface for it, even with
the
data model designed this way.
QuantityBreak is also used for shipping, and quantity breaks for shipping
are often in terms of weight. I think that's sensible, and the entity
should
not be removed altogether.
I'm not quite suire I get clearly which were the 2 quantity fields you
spoke about David, I guess it's for pricing and shipping?
Then, I tend to agree with Paul here about keeping the QuantityBreak
Entity even if we could refactor the code to use the 2 fields
(did not look into code and I don't remember OTTOMH). They could still be
useful in some specific cases.
For product pricing as opposed to shipping, how about keeping
QuantityBreak,
but only to support UIs? Remove the relationship between QuantityBreak
and
product pricing. What does everyone think?
Yes that sounds good to me. The best way would be to provide a patch in a
Jira. If it's not used OOTB (Paul's assertion, to be
confirmed) then I think we don't need to provide a way for data migration
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
I prefere keep QuantityBreak entity to given the possibility to define
prototype input for user screen.
With QuantityBreakType it's easier to define many formated table price
depending on product type.
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
