David,
You're right. All I was trying to reiterate was that in the real world a
relationship can require additional attributes to correctly model the
relationship, and if we adopted a policy of sticking extra attributes in
the PartyRelationship table it would get heavily polluted over time.
In this particular case (and looking at the PartyRelationshipType table
more carefully), the type of the relationship out to be SUPPLIER_REL,
right?. If we add the new attribute to PartyRelationship the value is
meaningful only when the type is SUPPLIER_REL. The alternative
implementation is to change the SUPPLIER_REL type so it hasTable = 'Y',
and then stick the identifier (and any other attributes that are needed
over time) in the new SupplierRel table.
It just seems to me that leveraging the entity model to isolate the data
for the relationship in a table dedicated for that purpose is the right
thing to do. The pragmatist in me says shove it in the PartyRelationship
and move on :-)
Cheers, Iain
David E Jones wrote:
Wouldn't the point be to describe a certain relationship, not create a
new relationship whose only purpose is to store an ID? If the only
purpose was to have a separate record to store the ID then we
shouldn't use the PartyRelationship table at all as it was not meant
for this and something actually meant for this would be far cleaner.
-David
On Nov 17, 2006, at 7:50 AM, Iain Fogg wrote:
David,
Short answer: yes.
Long answer...
If I was going to sit down and build an ER diagram for it, I'm pretty
sure I'd be modelling a relationship between party A (me) and party B
(my supplier), calling the relationship something like
"has_identifier", and sticking an "identifier" attribute on the
relationship. I'd be thinking that the cardinality constraint would
be many-to-many.
This fits nicely with PartyRelationship (except I don't have an
appropriate field to store the identifier directly), so would the
solution be to create a new PartyRelationshipTypeId, say
"ALTERNATIVE_IDENTIFIER" and mark the hasTable attribute to "Y". The
AlternativeIdentifier table then gets populated with the identifier
(and anything else that is important for alternative ids).
This seems to be a better approach that stuffing a new text field
into the PartyRelationship table, since this tends to create bloated
tables where lots of fields don't get used, and are semantically
meaningless a lot of the time. The downside is that there is a lot
more work to support a new table.
I am in no way qualified to judge which is the right way to go since
I'm so new, but if there's anyway to get this feature in quickly, I'm
all for it :-)
Cheers, Iain
David E Jones wrote:
Iain, Jacopo, others,
I must admit this sort of thing seems to be a bit more important and
perhaps widely used than a generic attribute or something that is
kind of hidden in an agreement would be good for.
Also, if the ID is literally how one Party refers to another Party
in the first Party's system (or vice-versa... ?) then it does seem
to make the most sense to put it on the PartyRelationship entity. In
other words from a modeling perspective that seems to be the most
"literal" place to put it.
Does that sound reasonable, or am I off base? In addition to
AgreementTerm and PartyRelationship, can anyone else think of any
place this could/should go?
-David
On Nov 16, 2006, at 8:43 AM, Iain Fogg wrote:
Jacopo,
So that I understand things properly....
I have an agreement with my supplier to use a particular identifier
in my transactions with him, just like we agree that I will pay my
bills within a certain amount of time. So should I create a new
agreement term type (say "Party Identification") and then use the
proposed new "termName" field to store the id? Obviously I need to
tweak the various applications where using this identifier is
important...
BTW, what's the point of the AgreementTermAttribute table? It seems
like a handy place to store all sorts of useful bits and pieces of
info, but there doesn't seem to be a way to manage it in the UI.
Cheers, Iain
Jacopo Cappellato wrote:
Iain,
the ui to manage the agreement terms is here:
https://demo.dejc.com:8443/accounting/control/login?agreementId=1001
However, you are right, currently there is not a field in the
AgreementTerm to store the alphanumeric id, hmmm....
Question for all: what about adding this field to the
AgreementTerm entity?
<field name="termName" type="value"></field>
Jacopo
Iain Fogg wrote:
Jacopo,
Thanks for the suggestion; I'd overlooked the possibility of
using the agreement model. I also read Chris's concern about the
appropriateness of using agreements, but if you don't specify an
expiry date for the agreement, I don't see that that is a big
problem.
I have a slightly more practical problem to consider - how the
heck do I configure my supplier ids!!! If I create (say) a
"legal" term, then I guess I could provide my supplier id as the
"term_value". However, the type of this field is numeric
(numeric(18,2) on postgres). So if one of my suppliers has
assigned me an alphanum id, I'm hosed there.
The agreement_term_attribute table looks just the thing to store
the id, but I'm blowed if I can see where I can maintain this in
the UI - have I been working too hard and missed something?
Cheers, Iain
Jacopo Cappellato wrote:
Iain,
I'd suggest considering the Agreement/AgreementTerm entities:
you create an agreement between your company and the supplier,
then add a new term to specify the assigned id; when you start a
purchase order and select this agreement, the agreement term
will be automatically added to the cart/order/documents.
Jacopo
PS: IMO in general, for the future, we should consider to move
information to the Agreement data model: for example, with a
concept of a default agreement for sales orders, some of the
fields in the product store could be moved in the agreement etc...
Iain Fogg wrote:
I have a large number of suppliers that all assign me a
different customer number. Does anyone know how/where I can
record this information? I need to include the number on things
like my purchase orders.
The obvious place for such an attribute is with the
"party_relationship" (although since this could conceivably be
multi-valued, a new table ala "employment" would be better).
A short-term hack would be to simply store the information as a
"party_attr". For example, if my customer number with supplier
XYZ is 1234, store (XYZ, 123) as a name-value pair in party_attr.
Have I missed something more obvious, like the correct place to
record assigned customer numbers?
Cheers, Iain
--No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/535 - Release Date:
15/11/2006
--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date:
16/11/2006
--No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date:
16/11/2006
--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date:
16/11/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/536 - Release Date: 16/11/2006
