Suggestion to remove the archetype con tact.fax in favour of bringing fax numbers into the e xisting archetype contact.phone.

Message from benjamin.charlton@kalingaparkvetsurgery.com.au benjamin.charlton@kalingaparkvetsurgery.com.au

This was posted on the Developers Forum 

http://www.openvpms.org/forum/openvpms-developers-sms-numbers-fax-phone-numbers-and-little-pedantry
[1]

Subsequently a jira(bug report) was filed to correct the fax problem, its a
relatively quick fix

However I suggested that: 

 

1. Many people who still use fax's use it on a shared line, even Telstra
still is pushing the faxstream network over a 2nd line (ie the fax uses a
shared line with the phone, and just gives a different ring that fax machines
can detect and answer selectively)

2. A fax is a phone number there is no difference.

3. It is far easier to add 1 number with 4 purposes and manage that data than
to manage seperate contact archetypes

4. Existing formating code for phone number would apply to fax's  both now
and in future changes.

In the current scope, a customer could potentially have a mobile for work and
home, we are allowed to assign multiple purpose's to a contact.phone,
however....partyRules.GetContact function only allows for 1 defined purpose
to be searchable.  This means that utilizing a contact.phone with purpose's
defines as FAX AND BILLING , MAY not be easily returnable when you consider
there is also the possibility of having a number with  BILLING as a
 purpose.  This could be corrected by adding seperate purpose's for
FAX-Billing, FAX-other etc etc.

This would mean that future revisions to phone numbers would automatically be
applied to fax numbers and not require extra coding.

However it may mean we to make some changes to the xpath functions that
retrieve fax numbers, to allow for fax numbers with different purposes.

 

I would ask for comment, specificially whether anyone uses custom reports
that would break with this change (and they are not sure how to recode them.)
 The existing xpath functions would be changed internally so that in OOO and
ireport the change would be seemless.  This change would require a sql patch
to be applied to existing data, thus it would require extensive testing prior
to release.  

[1]
http://www.openvpms.org/forum/openvpms-developers-sms-numbers-fax-phone-numbers-and-little-pedantry

_______________________________________________
OpenVPMS User Mailing List
users@lists.openvpms.org
To unsubscribe or change your subscription visit:
http://lists.openvpms.org/listinfo/users
Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Suggestion to remove the archetype con tact.fax in ...

Hi Ben

Technically I have no real issue with this suggestion although it will mean I need to modify quite a few of my data migration transforms to cater for the change. My only comment to all the users out there is please pipe up if you DONT want this to happen as silence is apparently consent.

Cheers
Tony

Re: Suggestion to remove the archetype con tact.fax in ...

My comment is, from my point of view and I suspect a lot of other users, this is unclear as to what is exactly being proposed.

Whilst it is clear that a fax number is a telephone number, it serves a totally different function. I like to be able to identify in a clients contact details that a specific number is for fax only----and often fax home and fax work----and do not want to lose this ability.

Re: Suggestion to remove the archetype con tact.fax in ...

I agree with the above comment as far as not really understanding the proposal.

We tend to add fax numbers as phone numbers not the option of fax so you have the ability to type work, home, use fo kennel Vacc Cert etc after the description.

As long as this is how it would still work that is ok for us.

Cheers,

Bernie

Re: Suggestion to remove the archetype con tact.fax in ...

I'll try and answer the above two concerns.

Whilst it is clear that a fax number is a telephone number, it serves a totally different function. I like to be able to identify in a clients contact details that a specific number is for fax only----and often fax home and fax work----and do not want to lose this ability.

The plan here is to add a new PURPOSE to the list which can be added to a contact.phone.  Currently contacts can have more that 1 purpose, so you should be able to add purpose pf say FAX and HOME to a purpose. or FAX and Work etc etc, like we might add, Home and Postal to a single location contact.

Do you currently use these numbers in reports and if so, how do you make sure you select the correct number in a report if a client has 2 fax numbers listed?

We tend to add fax numbers as phone numbers not the option of fax so you have the ability to type work, home, use fo kennel Vacc Cert etc after the description.

This is pretty much what the plan is.  This issue is really quite a technicality, it arose because a user pointed out that fax's and phone numbers formated differently in reports. The reason was that they used seperate "code".  This change brings fax numbers back into the list as phone contacts and adds a new phone contact purpose to designate them as a FAX.  

If anyone can remember back to the changes from 1.3 to 1.4 when the same happened to mobile phones this is similar...clear as mud?

The existing FAX contact archetype did not support searching for purpose's for different fax numbers.

Ben

Change in contact.fax

No issues here with us with changing the fax config.

But... I don't think we would be volunteering to pay for it tho :)

Matt C

Re: Change in contact.fax

After sitting on this for  a while, it probably can be shelved.  

It was a technical change anyway, we may want to use it later, to allow for more complex searches on contact fields, ie contact fields that have more than 1 purpose, but its probably easier just to let it slide. Currently our ability to return various contact fields is limited to the functions provided.  ie gethometelephone etc..

As far as the cost, I had already submitted a patch to Tim to effect the changes, the question we needed answered as a community was whether to apply the patch or not. So I am not sure the cost of making the change would be huge, I leave that to others to discuss.

Re: Change in contact.fax

In hindsight, it would have been better to have the single phone archetype for fixed line, mobile and faxes, with a few more available classifications than just Home and Work e.g.

  • Telephone
  • Phone (Home)
  • Phone (Work)
  • Mobile
  • Mobile (Home)
  • Mobile (Work)
  • Fax
  • Fax (Home)
  • Fax (Work)

These classifications are currently lookup.contactPurpose lookups, which also includes Billing and Correspondence.There is a good case for splitting the phone specific ones into a separate classification as they don't apply to any of the other contact types (Location, Email)

-Tim

Syndicate content