Orders and People

[bcooney]

I am developing a system for a kitchen design firm. Their contracts (orders) typically capture a husband and wife as the "client."

 

My design has Party>PartyRole<Order as the structure. I also have a Party>Relationship<Party structure.

 

I understand that it is important for them to "know" the relationship between the two people that present as "clients."

 

We've discovered, of course, that 10% of the time, the two people are not husband and wife. They can be two husbands, partners, a father and daughter, a shell company (celebrities hiding their identity).

 

So, I've challenged this age-old husband/wife idea and allowed more than one party to be a client on a contract.

 

Still, they are left with the desire to easily capture upon greeting the potential client, the two names and their relationship.

 

Would be very interested in sharing some thoughts! - Barbara

[comment]

A few points I would question:

 

Do they really track (or need to track) their clients to the point where they will NOT create a new record for a client of five years ago? I would have thought a simple Orders -< Clients would be quite sufficient. Referals, OTOH, might be something worth tracking.

 

I cannot see what business it is of your client to know the exact relationship between the two (or three, or five) people buying a kitchen together. Would they perhaps also like to examine their marriage certificate, or send them to have their DNA tested in case of a father and a daughter? 

 

But even if I suppose that somehow they need this information (and that their clients are so unwise as to be willing to share it), I still don't  see a need for a join table linking Clients to Clients. Surely a "Role" field in the Clients table (or, if you must, in the table joining Orders and Clients) must be enough. I was going to say that this is not a genealogy data base - but the truth is you wouldn't find such thing in a genealogy database either: people have roles in a family, not one towards another.

[OlgerDiekstra]

I kinda agree with Comment in terms of whether you'd really need it. If I think about how things come about in the business where I work, more often than not, lots of solutions are created for one off situations. I tend to review what people want/like and consider whether there's a more universal way of solving that. Perhaps you can have a must read note (that's something we use) to relay important information about a customer (ie, Father and Daughter are purchasing a kitchen to surprise Mother and therefore don't want her to know). You can populate a must read note with anything you like. Such a note can then be highlighted on the customer's record. Does it matter whether two males buying a kitchen are husbands, brothers, or father-son? They're two guys buying a kitchen. Who cares about their relationship as long as they pay the invoice.

[LaRetta]

Hi Barbara!!

 

Their contracts (orders) typically capture a husband and wife as the "client."

 

I DO however see the need for all parties to exist on a contract which would hold all parties responsible in case of divorce OR their different roles would designate their responsibility and 'relationship'.   These would be business rules.  I would not imagine a child can sign a contract unless they are 18 (again this is not a design decision but rather a business rule) but it could still involve father and daughter if the daughter was of contract age.  I do not see the Contact as an Invoice - the latter being a result (or partial result) of the Contract.

 

Here is an example of what I gather from your description (attached screen shot).  With this configuration, you can place a portal of parties anywhere and see all parties involved in the transaction.  The parties themselves are not tied to the invoice but rather to the commitment (contract).

 

 

 

 

 

 

 

 

[bcooney]

I appreciate all your thoughts. The primary issue that is happening is that they are entering Mr & Mrs James Smith in the Last Name field for the client. Argh! So, perhaps this is more a UI issue.

 

Yes, LaRetta, ideally a Contract has one or more related Invoices. However, since they swear!! that there is only one Invoice, I am treating the Contract as an Invoice.

[LaRetta]

There are some things I do not let a client choose.  Always a single invoice?  I doubt it.  So what if their check bounces and you must invoice them for $35.00 NSF fee?  You can't add it onto their 'single' invoice (because you've closed month-end) - you must invoice them again.  Or what if they wish to create a Change Order?  

 

My point wasn't about Contracts vs Invoices specifically anyway but that the people's roles CAN be important to the administration of a Contract and THAT would be good reason to track all parties involved (answering more of Comment's question).  Roles would determine who has a right to call up and change a spec, for example.  If your Users want to know 'non-critical members', they can be notes simply as:  Son Johnny, 6 and dog Rover.

 

added month-end reference

[comment]

the people's roles CAN be important to the administration of a Contract and THAT would be good reason to track all parties involved (answering more of Comment's question). 

 

I am not sure how that answers more (or some) of my question/s. Recording people's roles with regard to the contract is crucial - I don't think anyone would question that. If one of the clients is the paying party, then of course that needs to be recorded somewhere. I just don't see how a role of 'the lesbian lover of the adopted daughter' can be "important to the administration of a Contract".

[OlgerDiekstra]

Well... What if that lesbian lover is bisexual and also has a relationship with one of the husbands, who happens to be the father of the son's daughter? There's potential for some extra revenue there...

:-P That could be important to the administration.

[comment]

There's potential for some extra revenue there...

 

 

How so?

[OlgerDiekstra]

Blackmail. :-P

[comment]

Blackmail. :-P

 

LOL, that is so last century... People today will brag about these things wherever you'll let them.

[bcooney]

Oh my, didn't realize how much more entertaining my question would be compared to filtered portals, lol. More info: people info is captured at the lead stage by a "greeter." You just walked into the showroom and we capture names, phones, and "how did you hear about us" info. It's then that the relationship is noted. The next step is an appointment with a designer. So, understanding roles and relationships starts there... I suppose. Also, I've been told that "people" want Mr & Mrs. Smith as the name on the contract.

Comment, to your point, tracking referrals is very important as that is how leads are assigned. That is why I choose to have a party table and for each party create a record. The user adds a party using a popover that has a portal picker or new button. I'm hoping to eliminate duplicate entries as much as possible. So, at some point a designer is assigned to a party (which isn't as straight forward as you'd first think).

Olger, I do provide a general comment field as well on the "leadsheet."

[Mark Scott]

There are some things I do not let a client choose.  Always a single invoice?  I doubt it.

 

+1.  

 

My inclination would be to separate these into two tables, but treat it (provisionally) as a 1:1 rel'p.  As long as your clients don't look under the hood, they won't even know that the Order-Invoice "entity" has been divvied up into separate, related tables.  But when they come back a year from now and say "Gosh, seems we do need to have multiple invoices per order after all," (or, worse yet, "One invoice per order?  We never said that!"), all that would be needed would be a layout redesign to show the invoices in a portal, reflecting the 1:M rel'p that it really was all along, rather than a schema remodel.  (OK, some reports and scripting would probably have to get updated too, but still a bit easier than splitting the tables and their data.)

 

Sorry, Barbara, for getting tangential to your primary question, especially as your primary question led to much more entertaining discussion.  ;-)

 

Mark

[bcooney]

I promise to reconsider treating the contract as the one and only invoice!