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