I'm trying to figure out how to incorporate Ontime2007 into my application support. I have over 450 unique customers but in several cases, I may have contacts that support more than one customer. In my system, I have a Customers table, a Contacts table and then a CustomerContactsLink table to associate the two tables. I'm thinking that this isn't going to work with OnTime. Does anyone have any suggestions on this? Thanks.

---

Walt Krzystek

In OnTime a contact can only be associated with one customer.  You would have to create multiple contacts with the same name for each customer.  The email address would be the only thing that might be a problem because it has to be unique.

---

Dan Suceava
http://www.axosoft.com

If there aren't too many contacts who support multiple customers, then a solution for Walt might be as follows: For each customer having the same contact person, set up an email group in your email server's address book which contains only a single email address (the email address of the contact person).

Then in OnTime you can set up separate customers, each having the same contact with the same name, and for each contact you enter one of the unique email group names which you defined earlier.

In effect, the email group name serves as an alias for the real email address. OnTime won't complain because it thinks you entered different email addresses for these contacts. Your email server will take care of funneling the mails targeted at the various group-names all to the same recipient.

Yeah, I had thought of this type of workaround as well, the problem comes with maintenance. We work quite extensively through distributors and associations where I have a single (or a couple) of main contacts for several different organizations that I ultimately have to manage as if they were separate customers. This will get quite messy though.

I'm guessing that the purpose of maintaining unique email addresses for the CustomerContacts is for the customer portal authentication. At this point, there really isnt any way that I could use that now. Even with unique email aliases managed by mail server, the end user wouldn't really know what to use for login without having them intimately familiar with the process, ie, username_customercode@domain.com.

For such an extensive database design and with so much flexibility in the data you can store and how you can store it, this customer / contacts data design really is unfortunate.

---

Walt Krzystek