TRU_ASSOCIATION_MAPPING

Looking at mapping associations, and I have a couple of questions where I’m not sure I’ve seen the answers here:

1.       It appears that it’s okay for an association type to not have a male or female counterpart in TR_XREF, correct?  That being true, when that type of association is created, there will be one tx_xref record with a valid association type and one with a null type.  The one with the null type may be either a hard or soft association. This will result in an entry in TRU_ASSOCIATION_MAPPING with a blank in the Sort and Cur Xref Type columns, and this is all okay?  (from a post by Dale Aucoin, it sounded like these could/would be a sign of malformed associations, in which case part of my premise must be wrong)

2.       We have a number of records where the associated type is not the same as the male or female counterpart for the first type.  For example, the counterparts for Employer are Employee, but we have quite a few records where the one side is Employer and the other side is Assistant, Director, Reporter, Editor, etc.  Another example is Client vs Attorney, Agent, Contractor, etc.

I suspect what we’ll need to do is create types that apply to each of these counterparts individually, but want to make sure that’s the right course before I get on with it

Parents
  •  

    This is good to know, but my original question was not about null xref_no_inv’s but rather null types on the associated record – that is, one side of the association has a type and the other does not.  This would happen if the one type was originally set up in TR_XREF_TYPE with no counterparts.  It seems like it would just be a smart idea to make sure they’ve all got counterparts, but I was thrown off by the fact that the system allows you to set them up without.

Reply
  •  

    This is good to know, but my original question was not about null xref_no_inv’s but rather null types on the associated record – that is, one side of the association has a type and the other does not.  This would happen if the one type was originally set up in TR_XREF_TYPE with no counterparts.  It seems like it would just be a smart idea to make sure they’ve all got counterparts, but I was thrown off by the fact that the system allows you to set them up without.

Children
No Data