SupplierProduct and agreements

[Jacopo Cappellato]

Hi all,

I'd like to add two new optional fields to the SupplierProduct entity:
agreementId and angreementItemSeqId

In this way it will be possible to associate the supplier product
entries to an existing agreement with a supplier. Then I will create a
new subscreen under the Agreement screen to list and manage all the
SupplierProduct entries associated to the agreement (and supplier).

Is it ok?

Jacopo

[David E Jones]

This is an interesting idea to perhaps reconcile the different worlds of ProductSupplier versus Agreement to figure out purchase prices. How do you see these working together once this link is estabished?

-David


Jacopo Cappellato wrote:

> Hi all,
>
> I'd like to add two new optional fields to the SupplierProduct entity:
> agreementId and angreementItemSeqId
>
> In this way it will be possible to associate the supplier product
> entries to an existing agreement with a supplier. Then I will create a
> new subscreen under the Agreement screen to list and manage all the
> SupplierProduct entries associated to the agreement (and supplier).
>
> Is it ok?
>
> Jacopo
>

[Jacopo Cappellato]

David,

ideally, I'd like to define the two fields as primary key fields (I know
that this entity has already a very complex primary key...) for the
SupplierProduct entity; of course they could be set to "_NA_" if no
agreement information is available.

Then, if an agreement is associated to a purchase order at the beginning
of the order entry, it will be used not only to set a currency and the
terms for the order (as is now) but also to select the SupplierProduct
belonging to that agreement; if they are not found then the _NA_ ones
could be used.

Jacopo



David E Jones wrote:

>
> This is an interesting idea to perhaps reconcile the different worlds of
> ProductSupplier versus Agreement to figure out purchase prices. How do
> you see these working together once this link is estabished?
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Hi all,
>>
>> I'd like to add two new optional fields to the SupplierProduct entity:
>> agreementId and angreementItemSeqId
>>
>> In this way it will be possible to associate the supplier product
>> entries to an existing agreement with a supplier. Then I will create a
>> new subscreen under the Agreement screen to list and manage all the
>> SupplierProduct entries associated to the agreement (and supplier).
>>
>> Is it ok?
>>
>> Jacopo
>>

[Jacques Le Roux]

I have no objections

Jacques

De : "Jacopo Cappellato" <[hidden email]>

> Hi all,
>
> I'd like to add two new optional fields to the SupplierProduct entity:
> agreementId and angreementItemSeqId
>
> In this way it will be possible to associate the supplier product
> entries to an existing agreement with a supplier. Then I will create a
> new subscreen under the Agreement screen to list and manage all the
> SupplierProduct entries associated to the agreement (and supplier).
>
> Is it ok?
>
> Jacopo

[David E Jones]

Interesting, and cool. Do they need to be part of the primary key? I guess the point of that would be to support multiple Agreement/Item associations for a certain set of SupplierProduct parameters.

This would give you basically a to effectively have a many-to-many association between and Agreement/Item and a certain set of SupplierProduct values. So, I guess that's my question, do we really need that or is it adequate to have multiple SupplierProduct records for a single Agreement/Item, but for a given set of SupplierProduct values you would only have one Agreement/Item that it points to.

If we really do need a many-to-many association, perhaps a join entity going between them would be a good idea, and then it could have from/thru dates and flexibility for future fields that describe the relationship and such.

-David


Jacopo Cappellato wrote:

> David,
>
> ideally, I'd like to define the two fields as primary key fields (I know
> that this entity has already a very complex primary key...) for the
> SupplierProduct entity; of course they could be set to "_NA_" if no
> agreement information is available.
>
> Then, if an agreement is associated to a purchase order at the beginning
> of the order entry, it will be used not only to set a currency and the
> terms for the order (as is now) but also to select the SupplierProduct
> belonging to that agreement; if they are not found then the _NA_ ones
> could be used.
>
> Jacopo
>
>
>
> David E Jones wrote:
>>
>> This is an interesting idea to perhaps reconcile the different worlds
>> of ProductSupplier versus Agreement to figure out purchase prices. How
>> do you see these working together once this link is estabished?
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> I'd like to add two new optional fields to the SupplierProduct
>>> entity: agreementId and angreementItemSeqId
>>>
>>> In this way it will be possible to associate the supplier product
>>> entries to an existing agreement with a supplier. Then I will create
>>> a new subscreen under the Agreement screen to list and manage all the
>>> SupplierProduct entries associated to the agreement (and supplier).
>>>
>>> Is it ok?
>>>
>>> Jacopo
>>>
>
>

[Jacopo Cappellato]

David,

I understand your point and it makes a perfect sense to me.
The use case I'm working on right now will not require to have the two
fields in the primary key, so I'd say that for now we could just add
agreement/item as non-primary-key fields; we can revisit this later to
see if it would be useful to add support to a many-to-many association
(using a join entity).

Jacopo

David E Jones wrote:

>
> Interesting, and cool. Do they need to be part of the primary key? I
> guess the point of that would be to support multiple Agreement/Item
> associations for a certain set of SupplierProduct parameters.
>
> This would give you basically a to effectively have a many-to-many
> association between and Agreement/Item and a certain set of
> SupplierProduct values. So, I guess that's my question, do we really
> need that or is it adequate to have multiple SupplierProduct records for
> a single Agreement/Item, but for a given set of SupplierProduct values
> you would only have one Agreement/Item that it points to.
>
> If we really do need a many-to-many association, perhaps a join entity
> going between them would be a good idea, and then it could have
> from/thru dates and flexibility for future fields that describe the
> relationship and such.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> ideally, I'd like to define the two fields as primary key fields (I
>> know that this entity has already a very complex primary key...) for
>> the SupplierProduct entity; of course they could be set to "_NA_" if
>> no agreement information is available.
>>
>> Then, if an agreement is associated to a purchase order at the
>> beginning of the order entry, it will be used not only to set a
>> currency and the terms for the order (as is now) but also to select
>> the SupplierProduct belonging to that agreement; if they are not found
>> then the _NA_ ones could be used.
>>
>> Jacopo
>>
>>
>>
>> David E Jones wrote:
>>>
>>> This is an interesting idea to perhaps reconcile the different worlds
>>> of ProductSupplier versus Agreement to figure out purchase prices.
>>> How do you see these working together once this link is estabished?
>>>
>>> -David
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> Hi all,
>>>>
>>>> I'd like to add two new optional fields to the SupplierProduct
>>>> entity: agreementId and angreementItemSeqId
>>>>
>>>> In this way it will be possible to associate the supplier product
>>>> entries to an existing agreement with a supplier. Then I will create
>>>> a new subscreen under the Agreement screen to list and manage all
>>>> the SupplierProduct entries associated to the agreement (and supplier).
>>>>
>>>> Is it ok?
>>>>
>>>> Jacopo
>>>>
>>
>>

[Jacopo Cappellato]

Ok,

the first part of my work is in rev. 554680
Now in my TODO list (as a lower priority task) is to add code to
create/updateSupplierProduct and to updateAgreement and
updateAgreementItem to check is the supplier set in the agreement and
the currency set in the agreement item are always compatible with the
SupplierProduct records associated with the agreement item.

Jacopo


Jacopo Cappellato wrote:

> David,
>
> I understand your point and it makes a perfect sense to me.
> The use case I'm working on right now will not require to have the two
> fields in the primary key, so I'd say that for now we could just add
> agreement/item as non-primary-key fields; we can revisit this later to
> see if it would be useful to add support to a many-to-many association
> (using a join entity).
>
> Jacopo
>
> David E Jones wrote:
>>
>> Interesting, and cool. Do they need to be part of the primary key? I
>> guess the point of that would be to support multiple Agreement/Item
>> associations for a certain set of SupplierProduct parameters.
>>
>> This would give you basically a to effectively have a many-to-many
>> association between and Agreement/Item and a certain set of
>> SupplierProduct values. So, I guess that's my question, do we really
>> need that or is it adequate to have multiple SupplierProduct records
>> for a single Agreement/Item, but for a given set of SupplierProduct
>> values you would only have one Agreement/Item that it points to.
>>
>> If we really do need a many-to-many association, perhaps a join entity
>> going between them would be a good idea, and then it could have
>> from/thru dates and flexibility for future fields that describe the
>> relationship and such.
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> David,
>>>
>>> ideally, I'd like to define the two fields as primary key fields (I
>>> know that this entity has already a very complex primary key...) for
>>> the SupplierProduct entity; of course they could be set to "_NA_" if
>>> no agreement information is available.
>>>
>>> Then, if an agreement is associated to a purchase order at the
>>> beginning of the order entry, it will be used not only to set a
>>> currency and the terms for the order (as is now) but also to select
>>> the SupplierProduct belonging to that agreement; if they are not
>>> found then the _NA_ ones could be used.
>>>
>>> Jacopo
>>>
>>>
>>>
>>> David E Jones wrote:
>>>>
>>>> This is an interesting idea to perhaps reconcile the different
>>>> worlds of ProductSupplier versus Agreement to figure out purchase
>>>> prices. How do you see these working together once this link is
>>>> estabished?
>>>>
>>>> -David
>>>>
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> Hi all,
>>>>>
>>>>> I'd like to add two new optional fields to the SupplierProduct
>>>>> entity: agreementId and angreementItemSeqId
>>>>>
>>>>> In this way it will be possible to associate the supplier product
>>>>> entries to an existing agreement with a supplier. Then I will
>>>>> create a new subscreen under the Agreement screen to list and
>>>>> manage all the SupplierProduct entries associated to the agreement
>>>>> (and supplier).
>>>>>
>>>>> Is it ok?
>>>>>
>>>>> Jacopo
>>>>>
>>>
>>>
>