[ https://issues.apache.org/jira/browse/OFBIZ-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274246#comment-14274246 ] Nicolas Malin commented on OFBIZ-3764: -------------------------------------- I'm not fan that entites whit business oriented name like Supplier*, so the Adrian's proposition is just better for me ;) . If the cover is associate different value like an account on a relation, with do not use the same pattern like PartyIdentification ? PartyRelationship * - * PartyRelIdentification * - PartyIdentificationType or with dedicate Type : PartyRelationship * - * PartyRelIdentification * - PartyRelIdentificationType > Storing supplier relationship sub-class & two related fixes > ----------------------------------------------------------- > > Key: OFBIZ-3764 > URL: https://issues.apache.org/jira/browse/OFBIZ-3764 > Project: OFBiz > Issue Type: Bug > Components: party, product > Reporter: Bob Morley > Attachments: OFBIZ-3764_SupplierRel.patch > > > Despite how much I typed; this is really a very small patch. :) > This patch adds a new entity "SupplierRel" which is a sub-class of "PartyRelationship" (as well as a view-entity for convenience). It provides a new field "accountNumber" that can be used to store the long-term account number assigned to the relationship between the Company and its Supplier. The life of this account number is longer than any agreement between the two, so it has been put on this informal relationship. Moreover, it is possible to have an informal relationship between a company and a supplier with out an explicit binding agreement -- this was discussed most recently in this thread: > http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162 > ALSO -- this patch fixes two problems that I encountered when attempting to create a party relationship. > a) It did not look right to have an empty dropdown for status -- I created the standard "Created" status under the PARTY_REL_STATUS type so that we show the only applicable status. There does not appear to be any specific logic looking for party relationships with a blank status, so creating ones with this status should not cause any issues. > b) When creating the PartyRelationship the response in the controller was of type "view-last" which was a problem because the last controller request was typically the ajax one to "FindPartyName" which was used as part of the party lookup field in that form. The net result, was that on success it would render the PartyName instead of replaying the EditPartyRelationships. Changed form "view-last" to "view" to resolve this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) |
Will this handle the situation where the company has a number of
accounts or contracts with a supplier? For example a condo association might have several account numbers with the electric utility if there are several buildings or meters. Same for telecom if there are a number of different services purchased from the telecom server but billed with different account numbers. (Bell Canada does this) On 12/01/2015 5:04 PM, Nicolas Malin (JIRA) wrote: > [ https://issues.apache.org/jira/browse/OFBIZ-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274246#comment-14274246 ] > > Nicolas Malin commented on OFBIZ-3764: > -------------------------------------- > > I'm not fan that entites whit business oriented name like Supplier*, so the Adrian's proposition is just better for me ;) . > > If the cover is associate different value like an account on a relation, with do not use the same pattern like PartyIdentification ? > > PartyRelationship * - * PartyRelIdentification * - PartyIdentificationType > > or with dedicate Type : > > PartyRelationship * - * PartyRelIdentification * - PartyRelIdentificationType > > > >> Storing supplier relationship sub-class & two related fixes >> ----------------------------------------------------------- >> >> Key: OFBIZ-3764 >> URL: https://issues.apache.org/jira/browse/OFBIZ-3764 >> Project: OFBiz >> Issue Type: Bug >> Components: party, product >> Reporter: Bob Morley >> Attachments: OFBIZ-3764_SupplierRel.patch >> >> >> Despite how much I typed; this is really a very small patch. :) >> This patch adds a new entity "SupplierRel" which is a sub-class of "PartyRelationship" (as well as a view-entity for convenience). It provides a new field "accountNumber" that can be used to store the long-term account number assigned to the relationship between the Company and its Supplier. The life of this account number is longer than any agreement between the two, so it has been put on this informal relationship. Moreover, it is possible to have an informal relationship between a company and a supplier with out an explicit binding agreement -- this was discussed most recently in this thread: >> http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162 >> ALSO -- this patch fixes two problems that I encountered when attempting to create a party relationship. >> a) It did not look right to have an empty dropdown for status -- I created the standard "Created" status under the PARTY_REL_STATUS type so that we show the only applicable status. There does not appear to be any specific logic looking for party relationships with a blank status, so creating ones with this status should not cause any issues. >> b) When creating the PartyRelationship the response in the controller was of type "view-last" which was a problem because the last controller request was typically the ajax one to "FindPartyName" which was used as part of the party lookup field in that form. The net result, was that on success it would render the PartyName instead of replaying the EditPartyRelationships. Changed form "view-last" to "view" to resolve this issue. > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Administrator
|
Please Ron preferably answer directly in the Jira issue, done for you
Jacques Le 12/01/2015 23:32, Ron Wheeler a écrit : > Will this handle the situation where the company has a number of accounts or contracts with a supplier? > For example a condo association might have several account numbers with the electric utility if there are several buildings or meters. > Same for telecom if there are a number of different services purchased from the telecom server but billed with different account numbers. (Bell > Canada does this) |
Free forum by Nabble | Edit this page |