9

I think a location type of something like "Rejected" will give you great flexibility. If you want to get a bit more elaborate, combine the location type with a custom field that tracks the reason for nondelivery. By using a location type, it simplifies searching, exporting, and importing when you want to run those addresses through NCOA or have a user work ...


8

I'd use SQL. Take a backup first, of course, and test on a non-production server. Then run: UPDATE civicrm_address ca JOIN civicrm_contact cc ON ca.contact_id = cc.id SET location_type_id = 3 WHERE location_type_id = 2 AND cc.contact_type = 'Organization';


6

It would require a change to the core function CRM_Event_BAO_Event::getLocationEvent(). Right now, it only pulls addresses that are tied to existing events. Theoretically, the schema supports addresses that are tied to contacts also being tied to events, but there's no way to set the contact ID on an event address or vice-versa. In one sense, it would be ...


6

Have you tried making adjustments under Administer > Localisation > Address Settings?


6

Use a combination of smart groups, tags, CiviRules, and CiviReports. A. Create a Smart Group Use Search Builder to search for Contact :: Envelope # :: Not Empty OR Not Null OR > 0 From search results, create new smart group (called "Has Envelope #") B. Create a tag called "Update External Address" C. Setup a CiviRule Create a Rule with the Linked Event ...


6

In Administer > Localization > Address Settings, you can change the mailing label format to use {contact.state_province_name} instead of {contact.state_province}. It is not currently ready, but the localization (translation) system of CiviCRM does have support to define better defaults based on the locale. Work is being tracked in: https://lab.civicrm.org/...


5

I solved this using the Drupal modules CiviCRM Entity and Views Bulk Operations. This gave me a very powerful way to search, filter, and mass-modify the addresses in our database. Create a new view that shows CiviCRM Address entities and provides a page Add a Bulk Operations: CiviCRM Address field and configure it under "Selected bulk operations" to "...


5

I would second Erik's suggestion of adding an "on hold" or "bad address" property to postal mail addresses, similar to what civicrm has for email address. The "invalid postal address" scenario is common enough, and this has come up a few times, that a generic solution is definitely worth it and avoid orgs that do a fair amount of mailings work around this. ...


5

If you completly want to delete the addresses, you could also delete them from the database with a query like DELETE FROM civicrm_address WHERE location_type_id = xx AND contact_id IN (SELECT entity_id FROM civicrm_entity_tag WHERE entity_table = 'civicrm_contact' AND tag_id = yy) Where xx stands for the id of the location type you want to delete and yy is ...


4

If you have a state/province field on its own, it will have all options for the countries' states you enable on your site. If you have a country field alongside a state/province field of the same location type, the state listing will depend upon the selected country (regardless of whether the country's states are enabled). My hunch is that you have ...


4

It would be a simple extension to write, and would likely make a small group of users quite happy. Just fyi, it's currently possible to add a custom field to addresses, so you could create a contact reference field limited to the contacts who host as a custom address field. It would appear on the event location form if you do. Then you will likely want to ...


4

The list of states isn't editable by the end user, so it will require filing a bug to get APO, FPO (and whatever the third one is) added as state. In the meantime, I recommend using APO as the city, and not filling in the state or country (per USPS recommendations).


4

@Zeno when you have create option you don't have to look for replace please use create key word to create new or to update the record if record exist $result = civicrm_api3('Address', 'create', array( 'sequential' => 1, 'contact_id' => 202, 'location_type_id' => "Work", 'street_address' => "test", 'street_number_suffix' => 506, ))...


4

You can use the search builder to search for empty fields, e.g. Steet-Address or ZIP Code. From the result, you could create a (smart) group and then exclude contacts in that group from the mailing.


4

You can control the address format in Administer menu » Localization » Address Settings, so your mailing labels generate how you'd like. What CiviCRM does not currently do is print different mailing label formats based on the country of the record. I've got a proposal to a client who will fund this improvement if the proposal is accepted, but at this time ...


4

CiviCRM allows you to over-ride the settings through php. You can over-ride default value for Contact Country. Add the below snippet in your sites civicrm.settings.php file global $civicrm_setting; $civicrm_setting['Localization Preferences']['defaultContactCountry'] = ''; Ref: Override CiviCRM Settings HTH Pradeep


4

You need to enable Mapping and Geocoding from civicrm/admin/setting/mapping?reset=1 Enter your API Key or Application ID. An API Key is required for the Google Maps API. Refer to developers.google.com for the latest information. Save the form and you should be able to see latitude and longitude based on your contact's address. Note that it displays when you ...


3

There are lots of problems with the setvalue api. This is a good example of why everyone should stop using it. The plan is to deprecate setvalue soon and remove it in a future version. See https://issues.civicrm.org/jira/browse/CRM-16643


3

The cheapest solution would be to combine "Home" and "Main" into one option that can be used for both individuals and organizations. Just have to come up with a word that has both meanings...


3

If the households and individuals exist in the database but individuals do not have a shared address with the household, you can run the following sql to create a csv that you can import. On the import use update and link the first 7 columns to the appropriate columns. (If you don't link the street address, city, state, etc., the individual's shown address ...


3

A workaround is to import the address along with the Master Address ID. So import like you are importing a new address but also include the Master Address ID, mapped to the "Master Address Belongs To" field. It links them and populates the address.


3

I guess I would add an 'on hold' custom field to the Address entity?


3

I've never done it, but I think Tyrell's SmartyStreets extension provides it. One thing to point out, however, for anyone who does it another way: county names repeat a lot, and the ID numbers of counties in CiviCRM are totally arbitrary, unlike states. The way to look up county is to find the state and then find the county name within the state.


3

It is complicated to add a sort order on address labels. I think it is possible to add a sort order to your search and that sort order is used in printing labels. However, in a recent project, we dealt with the exact problem and using the search did not do the trick. I don't know why anymmore. But we solved the problem by creating a custom report template ...


3

I had this problem too on the main Civi911.com checkout form, and then I was all the more sheepish when it turns out the issue was reported by my coworker Tyrell for one of our clients! It's a bug in 7.x-4.11 and earlier: https://www.drupal.org/node/2516936 If you upgrade, the state/province in the billing address should update along with the country.


3

I only now stumbled on this question, so will copy-paste my response from the forum: I am the developer of civicrm-region-lookup. I use it on CiviCRM 4.6, and it would require a small fix for CiviCRM 4.7, but it should work otherwise. Although it is probably not the most user-friendly solution. It was meant to be flexible and vendor-neutral (i.e. not rely ...


3

This is possible in the "trunk" version of CiviCRM, and will be available in CiviCRM 4.7.15, releasing January 4, 2017. Earlier versions of CiviCRM don't have a StateProvince API. Using the "Join" feature of the API, you can pull in fields from related tables. See my screenshot for how I would construct an address pulling in actual state/province names (...


3

This is how you set the address of all people in a certain group (group id = 13), to be the address of a specific, different contact (address id 15432) SET @InGroup:=13; SET @MasterAddress:=15432; UPDATE civicrm_address SET master_id = @MasterAddress WHERE contact_id IN (SELECT contact_id FROM civicrm_group_contact WHERE status = 'Added' ...


3

It does sound like a reasonable feature request, and the good news is that it's already been implemented. The pull request was merged in March, so any version of CiviCRM from 4.7.18 upwards should include it in the advanced search criteria. I checked locally and here's a screenshot of the changed address fields in advanced search:


3

In the advanced search under the "Address Fields" you can choose "Address Location" which defaults to primary only. By selecting all of them you can search by any address type. answer taken from this thread Using custom fields to store secondary addresses


Only top voted, non community-wiki answers of a minimum length are eligible