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
