Any suggestions for how to design the date fields for a subscription database? I've used the database functions of Lotus 1-2-3 to do this for the past 15+ years and now want to convert it to Alpha Five.
The subscriptions are to a variety of newspapers, but primarily the New York Times. Subscription periods are measured in weeks, mostly 13, 26 or 52, but could be any number of weeks. Subscribers can call in to put their subscriptions on hold for any number of weeks, in which case we extend their subscriptions. They can go on hold multiple times during any subscription period.
My Lotus database uses the following fields:
Start Date,
# Weeks,
First Hold,
Last Hold,
Hold Weeks,
Additional Weeks,
Extended,
Expire Date.
Start Date, # Weeks, First Hold, Last Hold and Additional Weeks are all user entered. Hold Weeks, Extended and Expire Date are all calculated. First Hold is the first date of a hold period and Last Hold is the last date of a hold period. Hold weeks calculates the number of weeks in the hold period. If the subscriber calls in for additional hold periods during the subsciption term, the number in Hold Weeks (from the previous hold period) is manually added by the user to the number in Additional Weeks and then the new First Hold and Last Hold dates are entered.
(Extended)=(Hold Weeks)+(Additional Weeks).
(Expire Date)=(Start Date)+(# Weeks)+(Extended).
All of my Lotus data entry is macro driven. So when a subscriber renews a subsciption the macro automatically calculates the new Start Date from the old Expire Date and then enters that new date in Start Date. Is there a way to do this with Alpha Five (i.e. a calculation based on another field as part of data entry for a user entered field)?
Upon renewal, the Additional Weeks field is automatically reset to zero. However, First Hold and Last Hold are not blanked out. Rather, Extended checks to see whether the hold dates fall within the current subscription term, and only adds in Hold Weeks if true. This allows us to enter hold periods that don't start until after the current Expire Date (we frequently get these future hold requests).
Before I try to replicate this design in Alpha Five I thought I'd ask if anyone can suggest a better structure. If the general design seems OK, how about a way to include multiple hold periods without having to accumulate past hold periods in Additional Weeks? One critical task is to ensure that the Start Date gets properly entered at renewal, and if the Start Date gets calculated from the Expire Date, that the Start Date doesn't get recalcuated again after the Expire Date has been recalculated (this would obviously give the subscriber an extra renewal period).
For backround, I have developed and used (for more than 10 years) an Alpha Four order taking system for a separate business. This will be my first Alpha Five project.
Thanks for any suggestions.
Joe Fox
The subscriptions are to a variety of newspapers, but primarily the New York Times. Subscription periods are measured in weeks, mostly 13, 26 or 52, but could be any number of weeks. Subscribers can call in to put their subscriptions on hold for any number of weeks, in which case we extend their subscriptions. They can go on hold multiple times during any subscription period.
My Lotus database uses the following fields:
Start Date,
# Weeks,
First Hold,
Last Hold,
Hold Weeks,
Additional Weeks,
Extended,
Expire Date.
Start Date, # Weeks, First Hold, Last Hold and Additional Weeks are all user entered. Hold Weeks, Extended and Expire Date are all calculated. First Hold is the first date of a hold period and Last Hold is the last date of a hold period. Hold weeks calculates the number of weeks in the hold period. If the subscriber calls in for additional hold periods during the subsciption term, the number in Hold Weeks (from the previous hold period) is manually added by the user to the number in Additional Weeks and then the new First Hold and Last Hold dates are entered.
(Extended)=(Hold Weeks)+(Additional Weeks).
(Expire Date)=(Start Date)+(# Weeks)+(Extended).
All of my Lotus data entry is macro driven. So when a subscriber renews a subsciption the macro automatically calculates the new Start Date from the old Expire Date and then enters that new date in Start Date. Is there a way to do this with Alpha Five (i.e. a calculation based on another field as part of data entry for a user entered field)?
Upon renewal, the Additional Weeks field is automatically reset to zero. However, First Hold and Last Hold are not blanked out. Rather, Extended checks to see whether the hold dates fall within the current subscription term, and only adds in Hold Weeks if true. This allows us to enter hold periods that don't start until after the current Expire Date (we frequently get these future hold requests).
Before I try to replicate this design in Alpha Five I thought I'd ask if anyone can suggest a better structure. If the general design seems OK, how about a way to include multiple hold periods without having to accumulate past hold periods in Additional Weeks? One critical task is to ensure that the Start Date gets properly entered at renewal, and if the Start Date gets calculated from the Expire Date, that the Start Date doesn't get recalcuated again after the Expire Date has been recalculated (this would obviously give the subscriber an extra renewal period).
For backround, I have developed and used (for more than 10 years) an Alpha Four order taking system for a separate business. This will be my first Alpha Five project.
Thanks for any suggestions.
Joe Fox