PO contract

[Rodrigo Aguinaga]

Hi,

  I wanted to know if there's a way to define a PO contract ( or open PO )
on OFBiz.
  What I mean as PO contract, it's a "PO" that could be used many times with
the same supplier and the same prices (at least on a define period of time).
Let's say I always buy supplies on each end of month and I would like to
create the PO every time, so what this does it's to have a pre-build PO so
you can enter the date and release it.
  I think that it could be done like a new type of Quote, one that after you
create a PO from it, let's you create another.
  If this doesn't exist I would like to open a JIRA about it, so please let
me know what you think.


--
Rodrigo Aguinaga Lira

[cjhowe]

If it's not implemented already, it would use the
ShoppingList entities and then possibly a join to an
agreement.

--- Rodrigo Aguinaga <[hidden email]>
wrote:

> Hi,
>
>   I wanted to know if there's a way to define a PO
> contract ( or open PO )
> on OFBiz.
>   What I mean as PO contract, it's a "PO" that could
> be used many times with
> the same supplier and the same prices (at least on a
> define period of time).
> Let's say I always buy supplies on each end of month
> and I would like to
> create the PO every time, so what this does it's to
> have a pre-build PO so
> you can enter the date and release it.
>   I think that it could be done like a new type of
> Quote, one that after you
> create a PO from it, let's you create another.
>   If this doesn't exist I would like to open a JIRA
> about it, so please let
> me know what you think.
>
>
> --
> Rodrigo Aguinaga Lira
>

[David E Jones-2]

These are represented in OFBiz using Agreements. You can specify  
products and agreed on prices and there is a lot of support for  
creating POs from these. Agreements are in the Accounting Manager  
right now, but we plan to move them to the order manager soon.

-David


On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga wrote:

> Hi,
>
>  I wanted to know if there's a way to define a PO contract ( or  
> open PO )
> on OFBiz.
>  What I mean as PO contract, it's a "PO" that could be used many  
> times with
> the same supplier and the same prices (at least on a define period  
> of time).
> Let's say I always buy supplies on each end of month and I would  
> like to
> create the PO every time, so what this does it's to have a pre-
> build PO so
> you can enter the date and release it.
>  I think that it could be done like a new type of Quote, one that  
> after you
> create a PO from it, let's you create another.
>  If this doesn't exist I would like to open a JIRA about it, so  
> please let
> me know what you think.
>
>
> --
> Rodrigo Aguinaga Lira

[Rodrigo Aguinaga]

Yes, I see. And seems to be completely integrated, it's just that I haven't
take a look into this functionality in a very long time, so I didn't realize
the products part just the terms part.

I've been trying to create a PO from a Agreement but I haven't been able to
use the products from the agreement (I mean their prices), it's just that
the don't show up when I create the order, so I thougth that they could be
on the shopping list and they were not. So I manually add one of the
products, but the unit price is the one from the supplier, not the one
defined on the agreement.

I think I must be doing something wrong or maybe there is a bug here, so if
somebody could give some directions on this issue I would appreciate it.

Rodrigo
PS.  I do belive that move this function to orger manager it's a good idea,
but someone with accounting admin privileges, should also be able to modify
this, since there are agreement types like employment and all the agreement
terms options that they should take a look into.

2006/9/2, David E Jones <[hidden email]>:

>
>
> These are represented in OFBiz using Agreements. You can specify
> products and agreed on prices and there is a lot of support for
> creating POs from these. Agreements are in the Accounting Manager
> right now, but we plan to move them to the order manager soon.
>
> -David
>
>
> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga wrote:
>
> > Hi,
> >
> >  I wanted to know if there's a way to define a PO contract ( or
> > open PO )
> > on OFBiz.
> >  What I mean as PO contract, it's a "PO" that could be used many
> > times with
> > the same supplier and the same prices (at least on a define period
> > of time).
> > Let's say I always buy supplies on each end of month and I would
> > like to
> > create the PO every time, so what this does it's to have a pre-
> > build PO so
> > you can enter the date and release it.
> >  I think that it could be done like a new type of Quote, one that
> > after you
> > create a PO from it, let's you create another.
> >  If this doesn't exist I would like to open a JIRA about it, so
> > please let
> > me know what you think.
> >
> >
> > --
> > Rodrigo Aguinaga Lira
>
>

--
--
Rodrigo Aguinaga Lira

[Jacopo Cappellato]

Hi Rodrigo,

at the moment agreement prices are only considered in "sales"
agreements: in its current implementation, the prices set in the
SupplierProduct entity are the only one considered when you create
purchase orders.
However I think that it's time to review the role of the SupplierProduct
entity in the system: this entity has some fields that could be moved to
the Agreement* entities but also has some advanced features not
currently implemented in the Agreement* stuff (for example the prices
per quantity)...
The first simple thing we could implement is this:
in the "calculatePurchasePrice" service, add a new optional input field
- "agreementId" - and if a valid SupplierProduct record is not found
then the price from the agreement is returned.
Does it make sense?

Jacopo


Rodrigo Aguinaga wrote:

> Yes, I see. And seems to be completely integrated, it's just that I haven't
> take a look into this functionality in a very long time, so I didn't
> realize
> the products part just the terms part.
>
> I've been trying to create a PO from a Agreement but I haven't been able to
> use the products from the agreement (I mean their prices), it's just that
> the don't show up when I create the order, so I thougth that they could be
> on the shopping list and they were not. So I manually add one of the
> products, but the unit price is the one from the supplier, not the one
> defined on the agreement.
>
> I think I must be doing something wrong or maybe there is a bug here, so if
> somebody could give some directions on this issue I would appreciate it.
>
> Rodrigo
> PS.  I do belive that move this function to orger manager it's a good idea,
> but someone with accounting admin privileges, should also be able to modify
> this, since there are agreement types like employment and all the agreement
> terms options that they should take a look into.
>
> 2006/9/2, David E Jones <[hidden email]>:
>>
>>
>> These are represented in OFBiz using Agreements. You can specify
>> products and agreed on prices and there is a lot of support for
>> creating POs from these. Agreements are in the Accounting Manager
>> right now, but we plan to move them to the order manager soon.
>>
>> -David
>>
>>
>> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga wrote:
>>
>> > Hi,
>> >
>> >  I wanted to know if there's a way to define a PO contract ( or
>> > open PO )
>> > on OFBiz.
>> >  What I mean as PO contract, it's a "PO" that could be used many
>> > times with
>> > the same supplier and the same prices (at least on a define period
>> > of time).
>> > Let's say I always buy supplies on each end of month and I would
>> > like to
>> > create the PO every time, so what this does it's to have a pre-
>> > build PO so
>> > you can enter the date and release it.
>> >  I think that it could be done like a new type of Quote, one that
>> > after you
>> > create a PO from it, let's you create another.
>> >  If this doesn't exist I would like to open a JIRA about it, so
>> > please let
>> > me know what you think.
>> >
>> >
>> > --
>> > Rodrigo Aguinaga Lira
>>
>>
>
>

[Rodrigo Aguinaga]

Yes it  does makes sense, but this would be like a big change in the
agreement concept I think (it started as a accounting feature), but since
it's going to be move to order managment, I belive this change could be done
with this modifications.

Now that you mentioned the supplier product entity, I wanted to know if
theres like a supplier price list that groups this entites. I haven't found
it and I actually belive there isn't, so it would be a good thing to add
this feature, what do you think??

--
Rodrigo



2006/9/2, Jacopo Cappellato <[hidden email]>:

>
> Hi Rodrigo,
>
> at the moment agreement prices are only considered in "sales"
> agreements: in its current implementation, the prices set in the
> SupplierProduct entity are the only one considered when you create
> purchase orders.
> However I think that it's time to review the role of the SupplierProduct
> entity in the system: this entity has some fields that could be moved to
> the Agreement* entities but also has some advanced features not
> currently implemented in the Agreement* stuff (for example the prices
> per quantity)...
> The first simple thing we could implement is this:
> in the "calculatePurchasePrice" service, add a new optional input field
> - "agreementId" - and if a valid SupplierProduct record is not found
> then the price from the agreement is returned.
> Does it make sense?
>
> Jacopo
>
>
> Rodrigo Aguinaga wrote:
> > Yes, I see. And seems to be completely integrated, it's just that I
> haven't
> > take a look into this functionality in a very long time, so I didn't
> > realize
> > the products part just the terms part.
> >
> > I've been trying to create a PO from a Agreement but I haven't been able
> to
> > use the products from the agreement (I mean their prices), it's just
> that
> > the don't show up when I create the order, so I thougth that they could
> be
> > on the shopping list and they were not. So I manually add one of the
> > products, but the unit price is the one from the supplier, not the one
> > defined on the agreement.
> >
> > I think I must be doing something wrong or maybe there is a bug here, so
> if
> > somebody could give some directions on this issue I would appreciate it.
> >
> > Rodrigo
> > PS.  I do belive that move this function to orger manager it's a good
> idea,
> > but someone with accounting admin privileges, should also be able to
> modify
> > this, since there are agreement types like employment and all the
> agreement
> > terms options that they should take a look into.
> >
> > 2006/9/2, David E Jones <[hidden email]>:
> >>
> >>
> >> These are represented in OFBiz using Agreements. You can specify
> >> products and agreed on prices and there is a lot of support for
> >> creating POs from these. Agreements are in the Accounting Manager
> >> right now, but we plan to move them to the order manager soon.
> >>
> >> -David
> >>
> >>
> >> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga wrote:
> >>
> >> > Hi,
> >> >
> >> >  I wanted to know if there's a way to define a PO contract ( or
> >> > open PO )
> >> > on OFBiz.
> >> >  What I mean as PO contract, it's a "PO" that could be used many
> >> > times with
> >> > the same supplier and the same prices (at least on a define period
> >> > of time).
> >> > Let's say I always buy supplies on each end of month and I would
> >> > like to
> >> > create the PO every time, so what this does it's to have a pre-
> >> > build PO so
> >> > you can enter the date and release it.
> >> >  I think that it could be done like a new type of Quote, one that
> >> > after you
> >> > create a PO from it, let's you create another.
> >> >  If this doesn't exist I would like to open a JIRA about it, so
> >> > please let
> >> > me know what you think.
> >> >
> >> >
> >> > --
> >> > Rodrigo Aguinaga Lira
> >>
> >>
> >
> >
>
>

--
--
Rodrigo Aguinaga Lira

[Jacopo Cappellato]

Hi Rodrigo,

Rodrigo Aguinaga wrote:
> Yes it  does makes sense, but this would be like a big change in the
> agreement concept I think (it started as a accounting feature), but since
> it's going to be move to order managment, I belive this change could be
> done
> with this modifications.
>

Yes, I really think that agreements are the best way to implement this
stuff.
And agreements are already implemented in this way to support sales
price lists (see
http://docs.ofbiz.org/display/OFBENDUSER/Agreements+Price+Lists )
so it would be a 'natural' extension.

> Now that you mentioned the supplier product entity, I wanted to know if
> theres like a supplier price list that groups this entites. I haven't found
> it and I actually belive there isn't, so it would be a good thing to add
> this feature, what do you think??
>

Have a look at the link above to understand how a sales price list based
on agreements is set up; a purchase price list would be organized in the
same way; there is also a PDF report (and XML export) for the agreement
price list.

Jacopo

> --
> Rodrigo
>
>
>
> 2006/9/2, Jacopo Cappellato <[hidden email]>:
>>
>> Hi Rodrigo,
>>
>> at the moment agreement prices are only considered in "sales"
>> agreements: in its current implementation, the prices set in the
>> SupplierProduct entity are the only one considered when you create
>> purchase orders.
>> However I think that it's time to review the role of the SupplierProduct
>> entity in the system: this entity has some fields that could be moved to
>> the Agreement* entities but also has some advanced features not
>> currently implemented in the Agreement* stuff (for example the prices
>> per quantity)...
>> The first simple thing we could implement is this:
>> in the "calculatePurchasePrice" service, add a new optional input field
>> - "agreementId" - and if a valid SupplierProduct record is not found
>> then the price from the agreement is returned.
>> Does it make sense?
>>
>> Jacopo
>>
>>
>> Rodrigo Aguinaga wrote:
>> > Yes, I see. And seems to be completely integrated, it's just that I
>> haven't
>> > take a look into this functionality in a very long time, so I didn't
>> > realize
>> > the products part just the terms part.
>> >
>> > I've been trying to create a PO from a Agreement but I haven't been
>> able
>> to
>> > use the products from the agreement (I mean their prices), it's just
>> that
>> > the don't show up when I create the order, so I thougth that they could
>> be
>> > on the shopping list and they were not. So I manually add one of the
>> > products, but the unit price is the one from the supplier, not the one
>> > defined on the agreement.
>> >
>> > I think I must be doing something wrong or maybe there is a bug
>> here, so
>> if
>> > somebody could give some directions on this issue I would appreciate
>> it.
>> >
>> > Rodrigo
>> > PS.  I do belive that move this function to orger manager it's a good
>> idea,
>> > but someone with accounting admin privileges, should also be able to
>> modify
>> > this, since there are agreement types like employment and all the
>> agreement
>> > terms options that they should take a look into.
>> >
>> > 2006/9/2, David E Jones <[hidden email]>:
>> >>
>> >>
>> >> These are represented in OFBiz using Agreements. You can specify
>> >> products and agreed on prices and there is a lot of support for
>> >> creating POs from these. Agreements are in the Accounting Manager
>> >> right now, but we plan to move them to the order manager soon.
>> >>
>> >> -David
>> >>
>> >>
>> >> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> >  I wanted to know if there's a way to define a PO contract ( or
>> >> > open PO )
>> >> > on OFBiz.
>> >> >  What I mean as PO contract, it's a "PO" that could be used many
>> >> > times with
>> >> > the same supplier and the same prices (at least on a define period
>> >> > of time).
>> >> > Let's say I always buy supplies on each end of month and I would
>> >> > like to
>> >> > create the PO every time, so what this does it's to have a pre-
>> >> > build PO so
>> >> > you can enter the date and release it.
>> >> >  I think that it could be done like a new type of Quote, one that
>> >> > after you
>> >> > create a PO from it, let's you create another.
>> >> >  If this doesn't exist I would like to open a JIRA about it, so
>> >> > please let
>> >> > me know what you think.
>> >> >
>> >> >
>> >> > --
>> >> > Rodrigo Aguinaga Lira
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[cjhowe]

My 2 cents...

Agreement is a party concept.
It is always a party concept.
It is sometimes also an accounting concept.
It is sometimes also an order concept.
It is sometimes also a product concept.
It is sometimes also a human resources concept.

That said,
Adding screens for simpler support in an order is a
good idea.
Moving screens (adding it in one place and removing it
from another) is a bad idea because you're taking away
support.

In addition a price list is generally not a term of an
agreement (contract), it is an exhibit.  If you wanted
to show that a price from a supplier was contract
based, you would have a join entity between
AgreementTerm and SupplierProduct.  (A lot of this
confusion comes from the fact that products for sale
are treated differently than supplier products.  This
might even be easier if supplier pricing was moved
over to the rest of the product stuff, but that is
perhaps off topic for now).  SupplierProductAgreement
entity would have as fields, agreementId,
agreementTermSeqId, productId, price, currencyUomId,
fromDate, thruDate.  agreementId and
agreementTermSeqId, would reference the term that
specificies the exhibit, productId would reference the
supplier's productId, fromDate and thruDate would be
the time periods of the pricing. Price and
currencyUomId are only there as solutions to supplier
product being treated differently from products for
sale.

re: jacopo's comment about moving SupplierProduct
fields to agreement, they would be better moved to the
Product entity stuff as they only have something to do
with an agreement when an agreement document exists.

I understand the want in making it easy to do this.
The solution in making it easy is through the creating
the  presentation and business logic to support it,
not in changing the data model.

Thanks for listening :)





--- Rodrigo Aguinaga <[hidden email]>
wrote:

> Yes it  does makes sense, but this would be like a
> big change in the
> agreement concept I think (it started as a
> accounting feature), but since
> it's going to be move to order managment, I belive
> this change could be done
> with this modifications.
>
> Now that you mentioned the supplier product entity,
> I wanted to know if
> theres like a supplier price list that groups this
> entites. I haven't found
> it and I actually belive there isn't, so it would be
> a good thing to add
> this feature, what do you think??
>
> --
> Rodrigo
>
>
>
> 2006/9/2, Jacopo Cappellato <[hidden email]>:
> >
> > Hi Rodrigo,
> >
> > at the moment agreement prices are only considered
> in "sales"
> > agreements: in its current implementation, the
> prices set in the
> > SupplierProduct entity are the only one considered
> when you create
> > purchase orders.
> > However I think that it's time to review the role
> of the SupplierProduct
> > entity in the system: this entity has some fields
> that could be moved to
> > the Agreement* entities but also has some advanced
> features not
> > currently implemented in the Agreement* stuff (for
> example the prices
> > per quantity)...
> > The first simple thing we could implement is this:
> > in the "calculatePurchasePrice" service, add a new
> optional input field
> > - "agreementId" - and if a valid SupplierProduct
> record is not found
> > then the price from the agreement is returned.
> > Does it make sense?
> >
> > Jacopo
> >
> >
> > Rodrigo Aguinaga wrote:
> > > Yes, I see. And seems to be completely
> integrated, it's just that I
> > haven't
> > > take a look into this functionality in a very
> long time, so I didn't
> > > realize
> > > the products part just the terms part.
> > >
> > > I've been trying to create a PO from a Agreement
> but I haven't been able
> > to
> > > use the products from the agreement (I mean
> their prices), it's just
> > that
> > > the don't show up when I create the order, so I
> thougth that they could
> > be
> > > on the shopping list and they were not. So I
> manually add one of the
> > > products, but the unit price is the one from the
> supplier, not the one
> > > defined on the agreement.
> > >
> > > I think I must be doing something wrong or maybe
> there is a bug here, so
> > if
> > > somebody could give some directions on this
> issue I would appreciate it.
> > >
> > > Rodrigo
> > > PS.  I do belive that move this function to
> orger manager it's a good
> > idea,
> > > but someone with accounting admin privileges,
> should also be able to
> > modify
> > > this, since there are agreement types like
> employment and all the
> > agreement
> > > terms options that they should take a look into.
> > >
> > > 2006/9/2, David E Jones
> <[hidden email]>:
> > >>
> > >>
> > >> These are represented in OFBiz using
> Agreements. You can specify
> > >> products and agreed on prices and there is a
> lot of support for
> > >> creating POs from these. Agreements are in the
> Accounting Manager
> > >> right now, but we plan to move them to the
> order manager soon.
> > >>
> > >> -David
> > >>
> > >>
> > >> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga
> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> >  I wanted to know if there's a way to define
> a PO contract ( or
> > >> > open PO )
> > >> > on OFBiz.
> > >> >  What I mean as PO contract, it's a "PO" that
> could be used many
> > >> > times with
> > >> > the same supplier and the same prices (at
> least on a define period
> > >> > of time).
> > >> > Let's say I always buy supplies on each end
> of month and I would
> > >> > like to
> > >> > create the PO every time, so what this does
> it's to have a pre-
> > >> > build PO so
> > >> > you can enter the date and release it.
> > >> >  I think that it could be done like a new
> type of Quote, one that
> > >> > after you
> > >> > create a PO from it, let's you create
> another.
> > >> >  If this doesn't exist I would like to open a
> JIRA about it, so
> > >> > please let
> > >> > me know what you think.
> > >> >
> > >> >
> > >> > --
> > >> > Rodrigo Aguinaga Lira
> > >>
> > >>
> > >
> > >
> >
> >
>
>
> --
> --
> Rodrigo Aguinaga Lira
>

[Jacopo Cappellato]

Hi Chris,

Chris Howe wrote:
> My 2 cents...
>
> Agreement is a party concept.
> It is always a party concept.
> It is sometimes also an accounting concept.
> It is sometimes also an order concept.
> It is sometimes also a product concept.
> It is sometimes also a human resources concept.
>

This is fair.

> That said,
> Adding screens for simpler support in an order is a
> good idea.
> Moving screens (adding it in one place and removing it
> from another) is a bad idea because you're taking away
> support.
>

We have two options: keeping all the agreement related screens in one
component (party or product or order instead of accounting) or splitting
the agreement screens in more than one component (party, product,
accounting and order).
There are pros and cons but I'd prefer the former solution.

> In addition a price list is generally not a term of an
> agreement (contract), it is an exhibit.  If you wanted
> to show that a price from a supplier was contract
> based, you would have a join entity between
> AgreementTerm and SupplierProduct.  (A lot of this
> confusion comes from the fact that products for sale
> are treated differently than supplier products.  This
> might even be easier if supplier pricing was moved
> over to the rest of the product stuff, but that is
> perhaps off topic for now).  SupplierProductAgreement
> entity would have as fields, agreementId,
> agreementTermSeqId, productId, price, currencyUomId,
> fromDate, thruDate.  agreementId and
> agreementTermSeqId, would reference the term that
> specificies the exhibit, productId would reference the
> supplier's productId, fromDate and thruDate would be
> the time periods of the pricing. Price and
> currencyUomId are only there as solutions to supplier
> product being treated differently from products for
> sale.
>
> re: jacopo's comment about moving SupplierProduct
> fields to agreement, they would be better moved to the
> Product entity stuff as they only have something to do
> with an agreement when an agreement document exists.
>

I'm not saying I want to move all the SupplierProduct fields to
agreement, but there are some fields that could be integrated in the
agreement data model.
My preference (as a long term goal) would be that of slowing suppressing
the SupplierProduct entity and expanding instead the agreement data model...

> I understand the want in making it easy to do this.
> The solution in making it easy is through the creating
> the  presentation and business logic to support it,
> not in changing the data model.
>

I'm *not* trying to find a quick and dirty solution to my needs, I want
to model correctly these processes, and price lists agreed with
suppliers and customers are definitely agreements.
One option (that we discussed some time ago in the old dev list) was to
add  a new field "agreementId" as a primary key to the ProductPrice
entity but after discussing this we ended up that it was better to keep
the agreement prices in a new entity.

However, in general, keeping things simple is important, I always prefer
to have some basic features in place (maybe with some limitations that
can be implemented when someone needs them) instead of a huge nothing.
:-)

Jacopo

> Thanks for listening :)
>
>
>
>
>
> --- Rodrigo Aguinaga <[hidden email]>
> wrote:
>
>> Yes it  does makes sense, but this would be like a
>> big change in the
>> agreement concept I think (it started as a
>> accounting feature), but since
>> it's going to be move to order managment, I belive
>> this change could be done
>> with this modifications.
>>
>> Now that you mentioned the supplier product entity,
>> I wanted to know if
>> theres like a supplier price list that groups this
>> entites. I haven't found
>> it and I actually belive there isn't, so it would be
>> a good thing to add
>> this feature, what do you think??
>>
>> --
>> Rodrigo
>>
>>
>>
>> 2006/9/2, Jacopo Cappellato <[hidden email]>:
>>> Hi Rodrigo,
>>>
>>> at the moment agreement prices are only considered
>> in "sales"
>>> agreements: in its current implementation, the
>> prices set in the
>>> SupplierProduct entity are the only one considered
>> when you create
>>> purchase orders.
>>> However I think that it's time to review the role
>> of the SupplierProduct
>>> entity in the system: this entity has some fields
>> that could be moved to
>>> the Agreement* entities but also has some advanced
>> features not
>>> currently implemented in the Agreement* stuff (for
>> example the prices
>>> per quantity)...
>>> The first simple thing we could implement is this:
>>> in the "calculatePurchasePrice" service, add a new
>> optional input field
>>> - "agreementId" - and if a valid SupplierProduct
>> record is not found
>>> then the price from the agreement is returned.
>>> Does it make sense?
>>>
>>> Jacopo
>>>
>>>
>>> Rodrigo Aguinaga wrote:
>>>> Yes, I see. And seems to be completely
>> integrated, it's just that I
>>> haven't
>>>> take a look into this functionality in a very
>> long time, so I didn't
>>>> realize
>>>> the products part just the terms part.
>>>>
>>>> I've been trying to create a PO from a Agreement
>> but I haven't been able
>>> to
>>>> use the products from the agreement (I mean
>> their prices), it's just
>>> that
>>>> the don't show up when I create the order, so I
>> thougth that they could
>>> be
>>>> on the shopping list and they were not. So I
>> manually add one of the
>>>> products, but the unit price is the one from the
>> supplier, not the one
>>>> defined on the agreement.
>>>>
>>>> I think I must be doing something wrong or maybe
>> there is a bug here, so
>>> if
>>>> somebody could give some directions on this
>> issue I would appreciate it.
>>>> Rodrigo
>>>> PS.  I do belive that move this function to
>> orger manager it's a good
>>> idea,
>>>> but someone with accounting admin privileges,
>> should also be able to
>>> modify
>>>> this, since there are agreement types like
>> employment and all the
>>> agreement
>>>> terms options that they should take a look into.
>>>>
>>>> 2006/9/2, David E Jones
>> <[hidden email]>:
>>>>>
>>>>> These are represented in OFBiz using
>> Agreements. You can specify
>>>>> products and agreed on prices and there is a
>> lot of support for
>>>>> creating POs from these. Agreements are in the
>> Accounting Manager
>>>>> right now, but we plan to move them to the
>> order manager soon.
>>>>> -David
>>>>>
>>>>>
>>>>> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga
>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>  I wanted to know if there's a way to define
>> a PO contract ( or
>>>>>> open PO )
>>>>>> on OFBiz.
>>>>>>  What I mean as PO contract, it's a "PO" that
>> could be used many
>>>>>> times with
>>>>>> the same supplier and the same prices (at
>> least on a define period
>>>>>> of time).
>>>>>> Let's say I always buy supplies on each end
>> of month and I would
>>>>>> like to
>>>>>> create the PO every time, so what this does
>> it's to have a pre-
>>>>>> build PO so
>>>>>> you can enter the date and release it.
>>>>>>  I think that it could be done like a new
>> type of Quote, one that
>>>>>> after you
>>>>>> create a PO from it, let's you create
>> another.
>>>>>>  If this doesn't exist I would like to open a
>> JIRA about it, so
>>>>>> please let
>>>>>> me know what you think.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rodrigo Aguinaga Lira
>>>>>
>>>>
>>>
>>
>> --
>> --
>> Rodrigo Aguinaga Lira
>>

[cjhowe]

Let's see how well my "snips" work :)

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

> Hi Chris,
>


> We have two options: keeping all the agreement
> related screens in one
> component (party or product or order instead of
> accounting) or splitting
> the agreement screens in more than one component
> (party, product,
> accounting and order).
> There are pros and cons but I'd prefer the former
> solution.

IMO all agreement Create/Update/Delete logic should
remain in party component there should also be
retrieve logic that allows allows retrieval of
agreements that a party is party to.

Each other component should have screens that support
the generic agreement TYPES that one would find
related to that component.  Any special retrieval
logic would be in the component that the logic is
specific to.  If there are complex
Create/Update/Delete logic that is needed, those
logics should in the end call on the party services to
actually change the raw data.  This approach keeps
everything modularized.

> I'm not saying I want to move all the
> SupplierProduct fields to
> agreement, but there are some fields that could be
> integrated in the
> agreement data model.
> My preference (as a long term goal) would be that of
> slowing suppressing
> the SupplierProduct entity and expanding instead the
> agreement data model...

I think we're allowing the fact that sales pricing is
not consolodated to make us believe that pricing based
on a price list is somehow also special.  All you need
to show that a price you have in your system is based
on an agreement is to have a join entity between
AgreementItem and ProductPrice.

I agree that it's beneficial to phase out
SupplierProduct entity, but it should be integrated
into the Product entities as a seperate productType.
The SupplierProduct has nothing to do with an
Agreement.  This is shown by being able to conduct
business with most supplier's absent an agreement at
all.  While you can argue there is a verbal agreement,
I doubt you would want to maintain that data.

> I'm *not* trying to find a quick and dirty solution
> to my needs, I want
> to model correctly these processes, and price lists
> agreed with
> suppliers and customers are definitely agreements.
> One option (that we discussed some time ago in the
> old dev list) was to
> add  a new field "agreementId" as a primary key to
> the ProductPrice
> entity but after discussing this we ended up that it
> was better to keep
> the agreement prices in a new entity.
>
> However, in general, keeping things simple is
> important, I always prefer
> to have some basic features in place (maybe with
> some limitations that
> can be implemented when someone needs them) instead
> of a huge nothing.

The agreement entities should be reference entities.
Calculations should not be based on them as that would
be treating these price lists as if they were somehow
different that other pricing.  If you want to show
that a price is based off an agreement create a join
entity that allows you to show this relationship.
This shouldn't be a FK because your price can be based
on several agreements or several agreement items. (ie.
a distributor having an exhibit that contains an
everyday price list + a seperate agreement that if his
supplier offers a discount to the general public, then
the company recieves x discount off of the general
public's discount).  

The agreement is ancilary information and as such
should be allowed to be looked at seperately when
trying to work with the fruits of agreement.  When
your business logic is trying to get a price for to
create a PO, it shouldn't have to be aware that this
price is based on an agreement.  

When you're entering the agreement and you get to the
agreementItem that is talking about the price list,
your screen can have all the input boxes it wants to
enter your price list.  When you submit the agreement
your logic should be creating ProductPriceRules (not
ProductPrice as I mentioned earlier) this will allow
you to easily create quantity based pricing, etc.

You'll always have two conditions,
partyId =
and
productId =
Then you're join entity will have the agreementId,
agreementItemId and the productPriceRuleId, etc

This seems a much more natural relationship instead of
imbedding the product into the agreement.


> :-)
>
> Jacopo
>

[Jacopo Cappellato]

Hi Chris,

Chris Howe wrote:

> Let's see how well my "snips" work :)
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> Hi Chris,
>>
>
> IMO all agreement Create/Update/Delete logic should
> remain in party component there should also be
> retrieve logic that allows allows retrieval of
> agreements that a party is party to.
>
> Each other component should have screens that support
> the generic agreement TYPES that one would find
> related to that component.  Any special retrieval
> logic would be in the component that the logic is
> specific to.  If there are complex
> Create/Update/Delete logic that is needed, those
> logics should in the end call on the party services to
> actually change the raw data.  This approach keeps
> everything modularized.
>

About where to put the *existing* agreement screens (agreement header,
terms, items, item terms, parties, products): I'm not sure to understand
your comments, could you please be more precise and tell me in which
components you would like to see them?

> I think we're allowing the fact that sales pricing is
> not consolodated to make us believe that pricing based
> on a price list is somehow also special.  All you need
> to show that a price you have in your system is based
> on an agreement is to have a join entity between
> AgreementItem and ProductPrice.
>
> I agree that it's beneficial to phase out
> SupplierProduct entity, but it should be integrated
> into the Product entities as a seperate productType.
> The SupplierProduct has nothing to do with an
> Agreement.  This is shown by being able to conduct
> business with most supplier's absent an agreement at
> all.  While you can argue there is a verbal agreement,
> I doubt you would want to maintain that data.
>

The information in the SupplierProduct are really information that could
be modeled as an agreement (maybe implicit).

> The agreement entities should be reference entities.
> Calculations should not be based on them as that would
> be treating these price lists as if they were somehow
> different that other pricing.  If you want to show
> that a price is based off an agreement create a join
> entity that allows you to show this relationship.
> This shouldn't be a FK because your price can be based
> on several agreements or several agreement items. (ie.
> a distributor having an exhibit that contains an
> everyday price list + a seperate agreement that if his
> supplier offers a discount to the general public, then
> the company recieves x discount off of the general
> public's discount).  
>

No. I could sell (or buy) the same product at different prices (even
from to the same party) based on different agreements (for example with
different terms). So, if you want to use the ProductPrice entity you'll
have to add the agreementId as a PK. And, as I told you before, there
were reasons against this approach.

> The agreement is ancilary information and as such
> should be allowed to be looked at seperately when
> trying to work with the fruits of agreement.  When
> your business logic is trying to get a price for to
> create a PO, it shouldn't have to be aware that this
> price is based on an agreement.  
>

Why?

> When you're entering the agreement and you get to the
> agreementItem that is talking about the price list,
> your screen can have all the input boxes it wants to
> enter your price list.  When you submit the agreement
> your logic should be creating ProductPriceRules (not
> ProductPrice as I mentioned earlier) this will allow
> you to easily create quantity based pricing, etc.
>

I'm against using price rules to implement price lists based on
agreements: it is not a natural way of handling this, it leads to
complex (in the negative way) data and business logics to treat them.

Chris, thanks for your comments and time but, by the way, are you
planning to implement this stuff or your comments are only here for the
sake of this discussion?

Jacopo

> You'll always have two conditions,
> partyId =
> and
> productId =
> Then you're join entity will have the agreementId,
> agreementItemId and the productPriceRuleId, etc
>
> This seems a much more natural relationship instead of
> imbedding the product into the agreement.
>
>
>> :-)
>>
>> Jacopo
>>

[cjhowe]

I've just looked over the Agreement entity and the
"history" of it in svn.  I can completely see why
we're coming at this from different perspectives.
Agreement.productId has ALWAYS been there.  I'm
shocked.   I assumed Agreement was meant to be generic
(there I go assuming again).  If Agreement.productId
exists, the Agreement entities are anything but
generic.  If productId is a foreign key, the Agreement
entities are not designed to support employment
agreements, order agreements, etc. and technically,
not even pricing lists (as that would be require a one
to many relationship between agreements and products,
but this is a one to one relationship).  

Hopefully, by the end of the week I'll be finished
with the changes I'm making to the party relationships
 http://issues.apache.org/jira/browse/OFBIZ-149

(for my local use, but will be available in JIRA when
I'm done, and if there's any interest I'll create a
patch that replaces the current party relationship
stuff)

After that I'd be more than happy to
collaborate/develop a generic Agreement model that
will be easier to model and integrate with other
generic models as we'll end up needing it to be
generic in our local implementation.

[David E Jones-2]

On Sep 3, 2006, at 3:28 PM, Chris Howe wrote:

> I've just looked over the Agreement entity and the
> "history" of it in svn.  I can completely see why
> we're coming at this from different perspectives.
> Agreement.productId has ALWAYS been there.  I'm
> shocked.   I assumed Agreement was meant to be generic
> (there I go assuming again).  If Agreement.productId
> exists, the Agreement entities are anything but
> generic.  If productId is a foreign key, the Agreement
> entities are not designed to support employment
> agreements, order agreements, etc. and technically,
> not even pricing lists (as that would be require a one
> to many relationship between agreements and products,
> but this is a one to one relationship).

What are you talking about? I don't see how this could be true at  
all. Just because a field is on an entity doesn't mean it can't be  
null, even if it is a foreign key. When all fields in an fk are null  
the foreign key constraint is ignored.

I may not be understanding what you're trying to express or what sort  
of limitation you're seeing, but if this were coming from a different  
source it's the type of thing I'd label and file away as a baseless  
FUD attack on the project... ;)

> Hopefully, by the end of the week I'll be finished
> with the changes I'm making to the party relationships
>  http://issues.apache.org/jira/browse/OFBIZ-149
>
> (for my local use, but will be available in JIRA when
> I'm done, and if there's any interest I'll create a
> patch that replaces the current party relationship
> stuff)

Yes, please do submit it, but please also respect the feedback that  
this will most likely never replace the current party relationship  
stuff, especially not if the various objections to it are not  
addressed where it would not sufficiently replace existing  
functionality.

The way to submit such patches is as a new feature, not a replacement  
for an extremely commonly used, understood, and accepted feature.

-David

[Jacopo Cappellato]

Hi Chris, (all)

hmmm... I was hoping that your comments were motivated by a careful
review of the OFBiz existing data model and processes, not by general
and abstract assumptions of how you think an agreement data model should
be designed.

Hopefully now we are not in the process of drafting out the agreement
data model from scratch (and the OFBiz data model in general): the data
model is already in place (and it's very very good, even if it is not
perfect), we have many users running their applications on it, and now
we are trying to implement/complete the processes based on it and
sometimes, while building them, we refine the data model itself.

This is the current status of the OFBiz project and we should all be on
the same track: I really think it would be a bad thing for the project
(confusion for users/developers, slow down development, backward
compatibility issues) if we were to assume that, every time a new
feature is discussed, it is a good chance to re-implement the OFBiz data
model starting from some very different abstract data model we have in mind.

We are working on OFBiz an we should focus on OFBiz, limiting our
comments on what we know of OFBiz.

And finally, as regards the existing OFBiz data model and features, I
think it is wise to limit our remarks  based on real use cases we are
facing with OFBiz and not on the use cases we could imagine that could
happen: by my experience, when we try to forecast each and every use
cases we'll be however missing many of them - the real ones ;-) - and we
will spend a lot of time writing code to handle useless scenarios (that
no one will use, test, implement).

Sorry for the long post,

Jacopo

Chris Howe wrote:

> I've just looked over the Agreement entity and the
> "history" of it in svn.  I can completely see why
> we're coming at this from different perspectives.
> Agreement.productId has ALWAYS been there.  I'm
> shocked.   I assumed Agreement was meant to be generic
> (there I go assuming again).  If Agreement.productId
> exists, the Agreement entities are anything but
> generic.  If productId is a foreign key, the Agreement
> entities are not designed to support employment
> agreements, order agreements, etc. and technically,
> not even pricing lists (as that would be require a one
> to many relationship between agreements and products,
> but this is a one to one relationship).  
>
> Hopefully, by the end of the week I'll be finished
> with the changes I'm making to the party relationships
>  http://issues.apache.org/jira/browse/OFBIZ-149
>
> (for my local use, but will be available in JIRA when
> I'm done, and if there's any interest I'll create a
> patch that replaces the current party relationship
> stuff)
>
> After that I'd be more than happy to
> collaborate/develop a generic Agreement model that
> will be easier to model and integrate with other
> generic models as we'll end up needing it to be
> generic in our local implementation.

[cjhowe]

Replies inline

--- David E Jones <[hidden email]>
wrote:

>
> What are you talking about? I don't see how this
> could be true at  
> all. Just because a field is on an entity doesn't
> mean it can't be  
> null, even if it is a foreign key. When all fields
> in an fk are null  
> the foreign key constraint is ignored.
>

I really am not interested in rehashing a discussion
that you're going to ignore and walk away from without
considering my approach or pointing out how it is
inferior to the current approach. I'm also not
interested in a discussion that you're going to brush
off and point me to links that actually support my
assertions.  I don't see the discussion as a waste of
time, so I am willing to have it if you're willing to
stick around for it.

> I may not be understanding what you're trying to
> express or what sort  
> of limitation you're seeing, but if this were coming
> from a different  
> source it's the type of thing I'd label and file
> away as a baseless  
> FUD attack on the project... ;)
>

How is pointing out a flaw, and then volunteering to
take the time to correct it constitute fear,
uncertainty or doubt?  I eat the dog food, so I'm just
as interested in it tasting good as you are from the
POV of selling it.  Please don't label me as a
ditractor for suggesting things could be a little
better and also supplying step by step explainations
on how to accomplish the improvements.

>
> Yes, please do submit it, but please also respect
> the feedback that  
> this will most likely never replace the current
> party relationship  
> stuff, especially not if the various objections to
> it are not  
> addressed where it would not sufficiently replace
> existing  
> functionality.
>
> The way to submit such patches is as a new feature,
> not a replacement  
> for an extremely commonly used, understood, and
> accepted feature.
>
> -David
>

That couldn't be code mongering talk there, could it?
David, you've already mentioned how to approach it.
And I'm taking your advice because you've personally
taught me on several occasions not to waste time
touching the code base on things that take time to
write.  Because if they took time to write then they
probably take too much time to review and solicit
feedback.

I apologize for the negative tone of this post. It's
just frustrating to have discussions that sound like
the community is behind modularization of components
and making it simple to customize and reuse great
logic patterns so that it can be implemented in the
unique fashion that is your (general audience)
company, but then hold on to so tightly the things
that are preventing that from happening.

[David E Jones-2]

As I see it with interaction in any community a person who wishes to  
interact has two choices:

1. speak in a way that is open to response and focused on the topics  
at hand

2. speak in general terms instead of about details and use personal  
attacks to shut down the discussion

-David


On Sep 4, 2006, at 12:05 AM, Chris Howe wrote:

> Replies inline
>
> --- David E Jones <[hidden email]>
> wrote:
>
>>
>> What are you talking about? I don't see how this
>> could be true at
>> all. Just because a field is on an entity doesn't
>> mean it can't be
>> null, even if it is a foreign key. When all fields
>> in an fk are null
>> the foreign key constraint is ignored.
>>
>
> I really am not interested in rehashing a discussion
> that you're going to ignore and walk away from without
> considering my approach or pointing out how it is
> inferior to the current approach. I'm also not
> interested in a discussion that you're going to brush
> off and point me to links that actually support my
> assertions.  I don't see the discussion as a waste of
> time, so I am willing to have it if you're willing to
> stick around for it.
>
>> I may not be understanding what you're trying to
>> express or what sort
>> of limitation you're seeing, but if this were coming
>> from a different
>> source it's the type of thing I'd label and file
>> away as a baseless
>> FUD attack on the project... ;)
>>
>
> How is pointing out a flaw, and then volunteering to
> take the time to correct it constitute fear,
> uncertainty or doubt?  I eat the dog food, so I'm just
> as interested in it tasting good as you are from the
> POV of selling it.  Please don't label me as a
> ditractor for suggesting things could be a little
> better and also supplying step by step explainations
> on how to accomplish the improvements.
>
>>
>> Yes, please do submit it, but please also respect
>> the feedback that
>> this will most likely never replace the current
>> party relationship
>> stuff, especially not if the various objections to
>> it are not
>> addressed where it would not sufficiently replace
>> existing
>> functionality.
>>
>> The way to submit such patches is as a new feature,
>> not a replacement
>> for an extremely commonly used, understood, and
>> accepted feature.
>>
>> -David
>>
>
> That couldn't be code mongering talk there, could it?
> David, you've already mentioned how to approach it.
> And I'm taking your advice because you've personally
> taught me on several occasions not to waste time
> touching the code base on things that take time to
> write.  Because if they took time to write then they
> probably take too much time to review and solicit
> feedback.
>
> I apologize for the negative tone of this post. It's
> just frustrating to have discussions that sound like
> the community is behind modularization of components
> and making it simple to customize and reuse great
> logic patterns so that it can be implemented in the
> unique fashion that is your (general audience)
> company, but then hold on to so tightly the things
> that are preventing that from happening.
>

[cjhowe]

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

> Hi Chris, (all)
>
> hmmm... I was hoping that your comments were
> motivated by a careful
> review of the OFBiz existing data model and
> processes, not by general
> and abstract assumptions of how you think an
> agreement data model should
> be designed.
>

Aside from the assumption being in fact of base, I
don't think it was an unfair assumption given that
OFBiz generally has a generic data model.  How does
the generic term "Agreement" have anything to do with
Product?  If, for example, the Order entities can be
so elegantly seperated from Party, why can't agreement
be elegantly seperated from Product?

> Hopefully now we are not in the process of drafting
> out the agreement
> data model from scratch (and the OFBiz data model in
> general): the data
> model is already in place (and it's very very good,
> even if it is not
> perfect), we have many users running their
> applications on it, and now
> we are trying to implement/complete the processes
> based on it and
> sometimes, while building them, we refine the data
> model itself.
>

I agree that it is generally a very very good data
model.  However, the imperfections in it are obscurely
imperfect.  Creating functionality based on non
generic, nonmodularized principles forces anyone to
run that part of their business in the manner that
you've implemented it, roll their own in a way that
doesn't allow them to benefit from advancements in
interoperability or not integrate that part of their
business with OFBiz.  

> This is the current status of the OFBiz project and
> we should all be on
> the same track: I really think it would be a bad
> thing for the project
> (confusion for users/developers, slow down
> development, backward
> compatibility issues) if we were to assume that,
> every time a new
> feature is discussed, it is a good chance to
> re-implement the OFBiz data
> model starting from some very different abstract
> data model we have in mind.
>

The only track that we "should" all be on is an
interest in the project improving.  I'm positive that
we are all on that track.  How we go about that
improving, we should be as diverse as possible.

Feel free to go full steam ahead on your feature.
Someone else who has more general use of agreements
and product pricing is simply going to have to
redouble your efforts to allow it to work with other
functionality.

Backwards compatability issues stem from there being a
need in functionality that cannot be obtained from the
current structure.  So, had the structure been generic
enough to obtain said functionality, there wouldn't be
a backwards compatability issue.  Users imagination on
how to use OFBiz is not going to decrease.  There's
not going to be a desire for less functionality.  

> We are working on OFBiz an we should focus on OFBiz,
> limiting our
> comments on what we know of OFBiz.
>

I think that should be slightly rephrased.  We should
limit our comments on what we know of business
processes and how to consistantly implement those
process with OFBiz.

> And finally, as regards the existing OFBiz data
> model and features, I
> think it is wise to limit our remarks  based on real
> use cases we are
> facing with OFBiz and not on the use cases we could
> imagine that could
> happen: by my experience, when we try to forecast
> each and every use
> cases we'll be however missing many of them - the
> real ones ;-) - and we
> will spend a lot of time writing code to handle
> useless scenarios (that
> no one will use, test, implement).
>

With OFBiz's now completed Apache 2.0 license anyone
can strip and scrape any part of OFBiz they want to
market as their own implementation and still take
advantage of the Apache goodwill.  You all who consult
based on OFBiz will be in competition with these other
implementations.  Why would you want to allow them to
point out specifically where things aren't generic
enough to support a contract that you're both going
after?  Limit the remarks at your own peril (that line
was for David ;) a little legitimate FUD for ya).

[Jacopo Cappellato]

Chris,

Chris Howe wrote:
>
  > With OFBiz's now completed Apache 2.0 license anyone
> can strip and scrape any part of OFBiz they want to
> market as their own implementation and still take
> advantage of the Apache goodwill.  You all who consult
> based on OFBiz will be in competition with these other
> implementations.

This was already possible with the original (MIT) license, and in fact
there are other projects originated by the OFBiz codebase before the
license change.

>  Why would you want to allow them to
> point out specifically where things aren't generic
> enough to support a contract that you're both going
> after?  Limit the remarks at your own peril (that line
> was for David ;) a little legitimate FUD for ya).

Sorry, I don't understand.

About your other comments, sorry but they are too generic/abstract and
so I cannot reply to them now.

Jacopo

[cjhowe]

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

>
> This was already possible with the original (MIT)
> license, and in fact
> there are other projects originated by the OFBiz
> codebase before the
> license change.

The point was about taking advantage of Apache's
goodwill (name, marketability, etc).  With the MIT
license and even the mixed licence there's too much
confusion on what that means.  With the entire project
now being Apache 2.0 licensed there's no confusion.

>
> >  Why would you want to allow them to
> > point out specifically where things aren't generic
> > enough to support a contract that you're both
> going
> > after?  Limit the remarks at your own peril (that
> line
> > was for David ;) a little legitimate FUD for ya).
>
> Sorry, I don't understand.
>

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?

[Jacopo Cappellato]

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