Suggestion to remove the archetype contact.fax in favour of bringing fax numbers into the existing archetype contact.phone.
This was posted on the Developers Forum
http://www.openvpms.org/forum/openvpms-developers-sms-numbers-fax-phone-numbers-and-little-pedantry
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.
https://openvpms.atlassian.net/browse/ARCH-54
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.
