Seasonal Address

The Seasonal Address functionality allows you to enable and disable an address through an entered a date range on the Individual or Organization Profile.

Example: A university professor’s address can be put on hold from June to August with the hold removed in September when school is back in session.

Note: This is an advanced functionality that operates from a "stored procedure" (SP) and normally requires a level of customization.

Usage

The SP must be enabled to use the Seasonal Address functionality. It is based on the dates entered on the Edit - Address or Name & Address Information pages.

To Add a Seasonal Address:

  1. Go to an Individual Profile or Organization Profile page.
  2. On the addresses child form, click the Add button.
  3. The Add - Individual (or Organization) Address page will display.
  4. Enter the address information (Address Type required-See Tip below).
  5. Enter a date in the seasonal from field.
  6. Enter a date in the seasonal through field.
  7. Click Save.
  8. The address will display in the addresses child form.
Adding a Seasonal Address

Tip: Make sure you add "Seasonal" as an Address Type during the Address and Phone Setup. Technically, the Address Type does not affect NetForum rules, but this can be useful to know that the address is a seasonal and not a permanent address.

To Change an Existing Address to a Seasonal Address:

  1. Go to an Individual Profile or Organization Profile page.
  2. On the Profile page, click the edit button on a record in the addresses child form or the Edit Name & Address button on the Information Panel.
    • The Edit - Individual, Edit - Organization or the Individual or Organization Name & Address Information page will display.
  3. Select Seasonal from the Address Type drop-down list (See Tip above).
  4. Enter a date in the seasonal from field.
  5. Enter a date in the seasonal through field.
  6. Click Save.
  7. The address will display in the addresses child form.

Seasonal Address Update Process

Stored Procedure (SP): co_update_seasonal_address. This SP will flip a customer's primary address to a seasonal address, and then back to the address that was the primary address at the time of the seasonal switch.

Suppose a customer's main address is New York, but they winter in Florida. This process will flip the address to and from New York and Florida. If someone has more than 2 seasonal addresses, this process will work only if the customer goes back to their "main" address between each seasonal address stint.

This SP will flip a primary address to/from a seasonal address based on the months of the seasonal from and seasonal to dates. For example, suppose you have a seasonal address that goes from November to February of the next year. You should enter 11/01/2000 in the from date and 02/01/2001 in the through address. The actual year you enter does not matter, as long as the year of the through date is after the year in the from date, if the seasonal span carries over from one calendar year to the next. Under this setup, on November 1, the customer's primary address will flip to the seasonal address. On March 1, the customer's primary address will flip back to the address that was primary at the time the address was last switched to the secondary address.

Suppose a person's main address is in Florida, but they summer in Aspen. You would make the Florida address be primary, and not enter seasonal dates in that address. For the Aspen address, the from date might be 06/01/2000 and the through date might be 08/01/2000. Since the year of both these dates in in the same year, this process will make this address become primary from June 1 until August 31. Once September 1 rolls around, the customer's primary address will flip back to the address that was primary at the time the address flipped to seasonal address.

Suppose a customer has three addresses. Their main address is New York. They have a winter Florida address, and a summer Aspen address. As long as this customer returns back to NY after each seasonal stint, this scenario will work. You will enter a seasonal address for both Florida and Aspen.

Example:

  • Florida. From address: 11/01/2000; Through Address: 02/01/2001
  • Aspen: From Address 6/1/2000; Through Address: 08/01/2000
  • New York: no season addresses entered

With this setup, the customer's primary address will be as follows:

  • Florida: from 11/1 until 2/28 (or 2/29) of the next year
  • New York: from 3/1 to 5/31 of the same year, and from 9/1 through 10/31 of the same year
  • Aspen: from 6/1 until 8/31 of the same year

The year of the dates you enter in the seasonal from and through dates really does not matter. All that matters is if the from date is earlier than the through date, then this process assumes that the seasonal range does not cross into the next year. If the from date and through date, including the year component, crosses into the next year, then this process assumes the seasonal range goes into the next year.

As such, it can be confusing for users because the year of the seasonal address is irrelevant except for the greater-than/lesser-than notion that triggers whether a seasonal address does or does not carry into the next year or stay within a single calendar year. For this reason, we recommend always using the year 2000 and 2001 as a standard operating procedure.

Limitations

The following exceptional scenarios cannot be handled with this process:

  • If a customer does not rotate back to their "main" address, this process will not work. For example, if the customer above goes right from Florida to Aspen to New York to Florida, etc., this process will not work. This process demands that each seasonal address return back to the earlier primary address to "re-establish" the primary address. Put another way, this process will always flip the customer's primary address back to the address that was primary at the time of the switch. From a technical standpoint, right before the seasonal address flip, this process stamps the customer's current primary address key into the cst_old_cxa_key. When the seasonal address span ends, the process will simply replace the customer's primary address key in cst_cxa_key with what is in cst_old_cxa_key.

Workaround: Manage the addresses manually.

  • If a customer is currently at a seasonal address, you cannot designate a "new" primary address to use when the customer goes back, unless you update the record that was the former primary address. You could update the former primary address (if the customer is actually moving), but you cannot choose a different existing address to become the new primary address in the future, or you cannot add a new address and try to designate this as what should become the new primary address.

Workaround: Manage the exceptions manually. We recommend adding an Assignment to remind you to make the change once the seasonal address "expires" and flips back to the original primary address. At this time, you can designate the new primary address.

  • This process only toggles a customer's primary address. This process will not update addresses pointers in other tables, such as subscriptions, invoices, etc.

Work around: You will need to manage these manually.

  • This process works on a monthly basis. You cannot have an address flip on a particular day of the month; the changes will always flip on the first day of the month.

Work around: You will need to manage these manually.

  • If you would like to assemble a list of mailing labels in advance for a mailing that will be mailed at a future date, there is not a simple way to query for addresses based on a future mail date. For example, suppose it's early May and you have a mailing that will be mailed the last week of May for an expected arrival around June 1 (depending on geography). You need to print the labels on May 15 to deliver them to a shipper who will send the mailing to the Postal Service on May 25, for the expected delivery date around June 1. Ideally, you would like the mailing labels to go to the address a person will live at on June 1. But since you must run your query on May 15, you'll be assembling a list of addresses of where people are on May 15. If there are people with seasonal addresses who move from one address to another between May 15 and June 1, then this particular mailing will go to the address they have just left.

Work around: You will need to manage these manually. In order to do this, you could omit from your main query anyone who has a seasonal address start or end date close to the anticipated "arrival date" of the mailing. Next, run a query of just these people and manually determine their seasonal address. If you have back-end SQL access, you can write a query to pull this information.

Technical Information

AddressCorrectionEnabled system option.