PO contract

[cjhowe]

Who's priorities?  I already offered to make the
necessary corrections.  You insisted that we should
push forward with what is there instead of making the
corrections.  Would you be okay with me making the
necessary corrections to make the agreements generic?


With a clear seperation between products and
agreements and only their join tables defining thier
relationship, price lists and other calculated prices
can more easily reuse current calculating services.

--- Jacopo Cappellato <[hidden email]> wrote:

> Chris Howe wrote:
> >
> >
> > If you are a consultant selling services based on
> > OFBiz, why would you want to allow a potential
> > competitor to point out that OFBiz recognizes it's
> > imperfections, but refuses to do anything about
> it?
>
> Ah... I see what you mean now, thanks.
> Well, in general I think it's fair that OFBiz is not
> a perfect system
> (however it is much more better than many other OS
> and commercial
> products) and our resources (time and money) are
> very limited... so it's
> not really a matter of refusing to fix
> imperfections, rather it is a
> matter of priorities.
>
> Jacopo
>

[Jacopo Cappellato]

Chris,

sincerely speaking, I'd be a bit worried about the quality of the final
results since it seems to me that you don't have a clear understanding
of how the current *OFBiz* agreement stuff is designed and used.
Please, understand that this is not a lack of trust on your skills, but
such a big task (that will include existing data model, services and
user interface refactoring) would be a challenging task for everyone
(even for core contributors like, for example, Si, David and me).

I'd like to hear the opinions from others about this subject: do we
really need to refactor the agreement data model or can we complete and
refine the existing processes? what are the most urgent limitations in
the current agreement data model?

If you really need to perform this task, I'd suggest to implement it as
an alternative model instead of a replacement of existing
functionalities... maybe it would be easier to implement... but it is
obviously up to you.

Jacopo


Chris Howe wrote:

> Who's priorities?  I already offered to make the
> necessary corrections.  You insisted that we should
> push forward with what is there instead of making the
> corrections.  Would you be okay with me making the
> necessary corrections to make the agreements generic?
>
>
> With a clear seperation between products and
> agreements and only their join tables defining thier
> relationship, price lists and other calculated prices
> can more easily reuse current calculating services.
>

[davidnwelton]

> sincerely speaking, I'd be a bit worried about the quality of the final
> results since it seems to me that you don't have a clear understanding
> of how the current *OFBiz* agreement stuff is designed and used.
> Please, understand that this is not a lack of trust on your skills, but
> such a big task (that will include existing data model, services and
> user interface refactoring) would be a challenging task for everyone
> (even for core contributors like, for example, Si, David and me).
>
> I'd like to hear the opinions from others about this subject: do we
> really need to refactor the agreement data model or can we complete and
> refine the existing processes? what are the most urgent limitations in
> the current agreement data model?

I'd be interested to hear more concrete details about how the proposed
change would work, as well as see working code, to get a better idea.
That's usually more useful than 'meta' discussions, as long as
everyone understands that the potential changes might not be adopted.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[cjhowe]

It's really not a large change.  Just a correction.
The first link is how the data model currently is.
This second is my proposed change.  While there could
be some tidying up with the fks to the Party entities,
that's a bit beyond the scope and certainly beyond a
pressing need.

http://aycu23.webshots.com/image/3062/2002215157491048351_rs.jpg

http://aycu13.webshots.com/image/2172/2002213016819728875_rs.jpg

Admittedly this is without looking at the code, based
on function following form they shouldn't be
difficult.

1)Remove Agreement.productId, relationships to Product
entities should be through agreementProductAppl.

2)Remove AgreementProductAppl.price.
agreementProductAppl is best suited for agreement
items not based on price

3)Remove AgreementItem.currencyUomId.  When referring
to price lists this is defined in the price rule.
When it's referring to a lump sum, it's defined in the
agreement text.  This can probably be improved through
another manner, but becuase you're not supporting a
number value, currencyUomId wouldn't be helping in a
conversion.

4) merge AgreementPartyApplic and AgreementPartyRole.
AgreementPartyApplic.partyId doesn't mean much without
a context of role.   AgreementPartyRole can be equally
beneficial as AgreementItemPartyRole and leaving
AgreementItemSeqId null.

5) create AgreementPriceRuleApplic or
AgreementPriceRule (to satisfy field length
constraints).  link this to either AgreementItem or
Addendum (I prefer addendum as this is where price
lists are generally spelled out).  fromDate and
thruDate i think would be redundant on this with the
ProductPriceRule.fromDate and thruDate.

6) Investigate further the function of
AgreementTerm.invoiceItemTypeId

As far as actual code, I think it's pretty straight
forward from other implementations, but would be happy
to write some up next week when I have a bit more free
time.
--- David Welton <[hidden email]> wrote:

> > sincerely speaking, I'd be a bit worried about the
> quality of the final
> > results since it seems to me that you don't have a
> clear understanding
> > of how the current *OFBiz* agreement stuff is
> designed and used.
> > Please, understand that this is not a lack of
> trust on your skills, but
> > such a big task (that will include existing data
> model, services and
> > user interface refactoring) would be a challenging
> task for everyone
> > (even for core contributors like, for example, Si,
> David and me).
> >
> > I'd like to hear the opinions from others about
> this subject: do we
> > really need to refactor the agreement data model
> or can we complete and
> > refine the existing processes? what are the most
> urgent limitations in
> > the current agreement data model?
>
> I'd be interested to hear more concrete details
> about how the proposed
> change would work, as well as see working code, to
> get a better idea.
> That's usually more useful than 'meta' discussions,
> as long as
> everyone understands that the potential changes
> might not be adopted.
>
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>