Forgot password? | Forgot username? | Register

Separate Addresses Module would solve Parties History Problem?

Separate Addresses Module would solve Parties History Problem?

Hi all,
I'm not sure if someone has already suggested this, so I apologise in advance if they have! I'm wondering if a separated "Addresses" module would help solve the problem of Parties address histories.

The Parties module could then allow for "Address 1", "Address 2" etc. up to say 5 addresses, with the current one displayed at the top of the list.

There is still the problem of linking a particular address to a particular transaction... but it must be possible to think something up! (or if the address entries are dated, then the dates could perhaps match the dates of the Loans or other attached records... or something!).

-Karen Biddle
Powerhouse Museum, Sydney

Karen Biddle
Registrar / Collecion DB Admin
useravatar
Offline
109 Posts
Female  Website 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Hi Karen

The multiple addresses and address history issue is obviously still a big problem for some- so thanks for adding another suggegstion to the mix. 

Recently I discussed this Parties address problem with KE and one possible (custom) solution was to add the address fields to transaction modules. When a link is made to a party record, the address data is copied over to address fields that reside in the transaction record - allowing it to become fixed (and edited) in the transaction record. The benefit of this solution is it makes reporting much easier!

I think the Smithsonian [? please correct me here if I'm wrong!] have introduced something similar which copies the address upon link, then locks down the address in the transaction/loan module once a transaction is completed or record closed. [This was presented at the London meeting demo sessions...]

This approach would require considerable customisation to the various modules where address based transactions occur (Conservation, Loans, Accessions etc)  and doesn't  provide a very consistent solution to recording address histories across the whole system. But it does appear to solve the issue of reporting agianst a particular transaction.

An automated Address Module that records previous addresses against dates in a similar way to valuations and condition histories might be a useful in conjunction with the above data transfer method which would solve the reporting problems. 

I'd love to hear more suggestions as to how people are handling this issue internally - How do you define an Authority Party record - Do you update records or create new records when a parties address changes? How do you classify records when there are multiple current/active records for a single party?

Perhaps this could be a dedicated session at a future User Group meeting if there is enough interest... if we can find a solution that benefits most users it could be brought in as standard release to prevent us all customising in different ways.

Bern can you tell us more about your proposed solution that has been tentatively discussed for a future upgrade?

Rowena Craick
Collection Systems & Documentation Registrar
Arts Centre Melbourne

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Hi there Rowena

We do not use the Transactions module here at the Powerhouse, so I can't give you input on that. Currently, as you queried, we add a new Parties record if a person's address changes. I'm not sure what you mean by Authority Party, but if you mean an entry that is more of a biog entry, these go into our Thesaurus. If by "Authority Party" you mean person of particular expertise, we give them the Role of "Specialist/Adviser" then in th Specialities field, we add their area of expertise if it is not already there.

A conference segment on this topic would be a good idea, I think!

cheers
-Karen

Karen Biddle
Registrar / Collecion DB Admin
useravatar
Offline
109 Posts
Female  Website 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Thanks for the info Karen

We do similar thing - when a Party changes address we add a new record. I'm very interested to hear you are entering biographical info into the Thesaurus module! Is this for web optimisation?

I'm now attempting to classify our parties data in 2 ways; by defining records in record status field as either an "Authority Record" which is a biographical record used for linking to Catalogue/Narratives, or a "transaction record" when parties are created for the purposes of linking to any other module when name and contact details are required.

(Arts Centre Melbourne doesn't have the Transaction Module either - in this context I'm refering to all other modules that use addresses or contact details as part of a transaction; such as a Loan or Accession, Rights Licence.)

What is proving tricky is retrospectively trying to untangle poorly defined party records and merge duplicates, it cannot be done in bulk! I'm hoping with some better definitions about record type we can prevent further data quality issues arising.

Thanks,
Rowena

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Hi All,

Beth Gamble here from the Smithsonian's National Museum of Natural History.  Prior to our migration of our Transaction Management functions to EMu party addresses were not really utilized.  For the purpose of handling the important "point in time" address information for transactions during the migration we made several customizations to both the Parties module and the merged new Transactions module (combination of Accession Lots and Loans and Deaccession/Disposal data from Catalog module).  I'm not sure how important it is in general to keep history of addresses over time.  It is however important to keep point in time information about involved parties and their contact info for transactions.  So we keep that information in that module and allow the current information to be stored in the Parties module.  In the Parties module for Person type records we created a new tab called Affiliations which allows for a history of organizational affiliations of an individual over time.  We do find that information very useful in a general sense.  This also created a recursive link back to the parties module to record the organization the person is/was associated with.  The multi-valued grid on the Associations tab contains the following fields:

Organization - link to an Organizational Party record)
Current?  Yes/No to mark which of the affiliations is current.
Position - text file for the position or title held at that organization
Start Date - when they began
End Date - when they left
Comment - optional text for any additional details.

When a Current Affiliation is created for a Person record the system asks if the user wishes to retrieve the address information from the organization record and copy it to the Person record.    The address can be tweaked for person specific address details like route codes or room numbers and such if desired.

In the Transactions module we have two link fields in a multi-valued grid for the transactors.  The first field is the Contact and will be a link to a Person or Position party record.  The second is an Organization field which is a link to an Organization party record.  The Transaction also has copy address fields in this grid.  When a new transaction is created a user usually selects a particular contact record from the Parties module, upon insertion the current organization affiliation for that person is copied into the organization link field on the transaction and the postal address or shipping address (can be selected on the transaction screen) is copied into the corresponding fields in the transaction record.  Address fields are completely read-only in the Transaction Module.  While the transaction is being processed (Status field is other than CLOSED) the copy address fields are automatically updated with changed made to these fields in the corresponding linked party record.  Once CLOSED those copy fields become static and are no longer updated with changes in the linked Party record.  This maintains our point in time data.  The same functionality was added to our Movement module which we renamed Shipments.

The one issue that isn't covered in this implementation is change of person names (marriage etc.) and Organizational name changes.  For these I think we would create new records.  Associate the records to the old name records and change the record status of the old names to Inactive so they don't appear in default queries.  By doing this it would insure that the names in past transactions would be preserved as they were at the time of the transaction.

We have a huge data clean up / merge of records to do in our parties module as a result of the migration of our old TM system's data.  There was pretty much no way around that.  We too are finding this task very difficult to do in bulk.

I hope that makes sense to folks.  So far we are happy with how this is working.

Beth Gamble
SI - NMNH - Informatics Office

--- Beth L. Gamble ----------------------------------
Senior Systems Analyst
National Museum of Natural History
Smithsonian Institution

Beth Gamble
Senior Systems Analyst
useravatar
Offline
29 Posts
Female 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Thanks for all the info Beth!

We haven't had particularly deep conversations here about how to solve this problem. You do make a valid point "does it really matter".... it's quite possible we could get by just updating addresses when they change and keeping a note of the old address on the Notes tab.... probably enough considering a lot of transactions are "once only" and the much-older ones are obviously never going to change!

cheers
-Karen

Karen Biddle
Registrar / Collecion DB Admin
useravatar
Offline
109 Posts
Female  Website 
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Separate Addresses Module would solve Parties History Problem?

Hi again everyone

Just a note to say that we have come up with a simple solution to this issue. When a party address (or phone number or Organisation contact name) changes, I have set up some values in the "Mailing Lists" field such as "Change of Address" and "Change of Contact Name" etc. etc. When these values are chosen in this field, an icon appears at the top of the window, advising the user that the address details for this Party have been updated at some point (this is done via an "Image Display" Registry setting). In the meantime, when we enter change of details, we put the old address details in the Notes tab, with a prefix and date, eg. "Change of Address 15/08/2012", followed by the old details. When the user hovers over the alert icon, the popup text tells them to check the Notes tab for details of the old address.

This really should be enough for us! It is very rare (never) that we would have to re-use an old address, except to check it... and it if it is there on the Notes tab, with an alert that tells the user to look there.... this should be enough for us to handle this problem!

regards
-Karen

Karen Biddle
Registrar / Collecion DB Admin
useravatar
Offline
109 Posts
Female  Website 
Administrator has disabled public posting. Please login or register in order to proceed.
There are 0 guests and 0 other users also viewing this topic

Board Info

Board Stats
 
Total Topics:
603
Total Polls:
0
Total Posts:
1363
User Info
 
Total Users:
871
Newest User:
Monica Syrette
Members Online:
3
Guests Online:
114