Customer number from suppliers
Locked
 
|
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
|
|
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 > > |
|
|
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 <[hidden email]> 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 > > > > > > |
|
|
In reply to this post by Jacopo Cappellato
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
|
|
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 >>> >>> >> >> >> > > > |
|
|
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
|
|
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 > |
|
|
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
|
|
In reply to this post by David E Jones-2
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
|
|
In reply to this post by Iain Fogg
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 > |
|
|
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 |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |