[jira] [Commented] (OFBIZ-3764) Storing supplier relationship sub-class & two related fixes

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275979#comment-14275979 ]

Nicolas Malin commented on OFBIZ-3764:
--------------------------------------

Hmmm sure it's a strange case :)

I think isn't a better way to manage your several accounts. The product component work well.

The thread origin is adding adding an accountNumber who is an identification string. But accountNumber is so restrictive and we can set only one value on a relation. I don't see the improvement betwee this and adding directly the new field on PartyRelationship entity.

So the main ask for me is what we want set as value on this new entity. My proposition run only on identification information.
I can imagine an example :
 * DemoCustomer CUSTOMER DemoSupplier SUPPLIER 2015-01-01 00:00:00 SUPPLIER_REL ACCOUNT_NUMBER  12343
 * DemoCustomer CUSTOMER DemoSupplier SUPPLIER 2015-01-01 00:00:00 SUPPLIER_REL REFERENCE_SYS E4564R
 * DemoSupplier SUPPLIER DemoCustomer CUSTOMER 2015-01-01 00:00:00 CUSTOMER_REL REFERENCE_SYS 10023
We can use these information by an automate to exchange with the customer erp and supplier erp directly with their own partyId's system

If we want set more than one ACCOUNT_NUMBER identification, it's possible to add another pk partyRelIdentificationId to have :
 * 10010 DemoCustomer CUSTOMER DemoSupplier SUPPLIER 2015-01-01 00:00:00 SUPPLIER_REL ACCOUNT_NUMBER  12343
 * 10011 DemoCustomer CUSTOMER DemoSupplier SUPPLIER 2015-01-01 00:00:00 SUPPLIER_REL ACCOUNT_NUMBER  123265
But I think isn't easier to use an automatic resolution to use what account to sharing when.

Pierre, I understand your proposition to use more generalization but set an enumValue or enumId it's to me define a range value, it's will better to use the EntityAttr pattern to define the generalization (so PartyRelationshipAttr)

> 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)