You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Iain Fogg <ia...@westnet.com.au> on 2006/11/15 23:49:19 UTC
Customer number from suppliers
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
Re: Customer number from suppliers
Posted by Iain Fogg <ia...@westnet.com.au>.
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
Re: Customer number from suppliers
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>
Re: Customer number from suppliers
Posted by Iain Fogg <ia...@westnet.com.au>.
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
Re: Customer number from suppliers
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>
>
>
Re: Customer number from suppliers
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>
Re: Customer number from suppliers
Posted by Iain Fogg <ia...@westnet.com.au>.
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
Re: Customer number from suppliers
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>>>
>>>
>>
>>
>>
>
>
>
Re: Customer number from suppliers
Posted by Iain Fogg <ia...@westnet.com.au>.
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
Re: Customer number from suppliers
Posted by Chris Howe <cj...@yahoo.com>.
While the agreement entities may make for a simple
integration with your recent improvements, IMO it's
not an accurate representation of the data field. In
the business sense, a customer Id is a party alias and
can be assigned without the presence or utilization of
an agreement. This may seem like a minor distinction,
however because agreements are by their nature subject
to one time frame and your customer Id is not subject
to the same time frame, you would need to be
maintaining a separate agreement solely for the
purpose of keeping track of your customer Id otherwise
risk expiring information that does not expire.
--- Jacopo Cappellato <ti...@sastau.it> 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
> >
> >
>
>
Re: Customer number from suppliers
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>
>