contact.webSite needed ?
I am going through our system cleaning up things from the RxWorks conversion. We have a number of suppliers for whom a web page address is recorded. During the conversion this got put in as a phone number contact - which obviously now causes problems because we now have phone number validation in place.
Is it time to add a contact.webSite into the system?
I think that this would involve: a) clone say contact.email to build contact.webSite; b) edit party.supplierorganisation (and any other things that can validly have a web site such as party.supplierVeterinaryPractice) to add in contact.webSite as one of the allowed contact types.
Are there any other changes needed?
Regards, Tim G
Re: contact.webSite needed ?
If you want to be able to include the URL in a report, then an xpath function might be needed.
Re: contact.webSite needed ?
Tim - yes I agree that a party:getWebSite() would be a sensible addition.
In my contact.webSite I removed the preferred node, but I suspect that I should not have - if only because it allows you to control the website returned by party:getWebSite().
I added contact.webSite to the supplier organisation and supplier vet practice archetypes. I have a suspicion that it should also be added to party.organisationPractice and party.organisationLocation
I don't know whether the URL should be clickable - ie should you be able to click www.doggycookery.com in the following. It would be neat if you could.
Note that I used the Display Name 'URL' - it might be better to just use 'Address'. Also thinking about it, "Web Site" is probably too restrictive - maybe contact.internet would be better so that you could hold web sites, facebook addresses, etc and the above would look like:
Finally - the 'should add to party.organisationLocation' + 'should have a party:getWebSite' reminds me that (as far as I know) there is no way to access the current (or any other) location. Currently we run separate invoice etc templates for EIAH, AEC and CC because there is no way to access the Practice Location details. Was the omission of party:getLocation an oversight?
[Incidentally - if you are wondering about the 'Printed Name' field in the above, this is just the description node. I needed the ability to have two different suppliers who are in fact the same company - when the order prints out it uses the description node to get the 'real' company name. I needed this setup to handle the automatic ordering of the housecall variants of pet foods (where DoggyChews cost more if you buy them from the housecall business because they get delivered to you - hence there is a CC-DoggyChews (with supplier CC-DoggyFood) and well as the standard DoggyChews (supplier DoggyFood)).]
Regards, Tim G
Re: contact.webSite needed ?
If there is only ever going to be one URL, you can avoid the new contact archetype and make it a node of the supplier. This makes reporting easier as an xpath extension function isn't required.
If there is to be multiple URLs, then my preference would be for a contact.website or contact.url archetype. An xpath extension function would be required to return the URL of the preferred contact.
I'm not sure that the purposes node used in the other contact archetypes is relevant, as these tend to be customer centric.
Regarding party:getLocation() - this function doesn't exist as there is no concept of the current practice location at the level of the extension functions. You can get the location an Invoice was created at however - it is stored in the location node.
Note that the http://www.openvpms.org/project/location-specific-product-pricing project should remove the need to specify multiple suppliers.