PartyRelationship makes sense to me.
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
