Leighton,

Because of your ms_membership API design, I think this change should be pretty easy. I was just looking at the code today, and although I haven't looked at everything, here is my basic strategy to make the changes:

1) Add an optional expiration argument to ms_membership_insert_new_membership().
2) Add a conditional for ms_membership_insert_new_membership() to set either the expiration from argument or by lookup using ms_membership_get_expiration_date().
3) Add extra form fields for "fixed expiration" to membership admin form. This would require adding extra database fields for the additional form values. I'd assume a module .install file update function would handle this. I think only ms_membership.install would need the extra fields, but I have to look at the orders and other stuff.
4) Possibly add extra form fields for "fixed expiration" to manual membership assignment.

I was relieved to see a per-user expiration value stored in the database. It makes this feature easier to implement.

As for prorating, I don't need it. It would need more admin form additions too. I would have to add or modify existing db schema as well. I could probably add prorating in, but I am not sure how it should work. Should it be a percentage-based or fixed-amount-based?

For example, if percentage-based, I would think if someone signed up in June (month 6), then that's only 6/12 (e.g., reduced to a 1/2 membership term), which would be 50% off of the full year's membership price. If I were to use prorating, I would probably use this type. It also requires the least schema modification, as it can be calculated.

Otherwise, maybe someone shouldn't be allowed to get that much off, then a fixed prorate amount would be, say, $50 at most, off of the full membership price, no matter when the user signed up for the year membership. I would not prefer this type.

A prorate could also work on what I would call a fixed table. So 1/2 through the membership, they get $50 off, 3/4 of the way through the membership, the user gets $150 off. The prices wouldn't have to be linear, just something to encourage someone to get a membership no matter how far into the membership timeline the user wants to sign up. I would not prefer this type.

EDIT:
It seems there is information stored in the Drupal users table in the data field that is referenced from ms_memberships. Such fields as ms_membership_start_date and ms_membership_expiration that confuse me as I thought similar information was already stored in the ms_memberships table. I have a bit more research to do. :)

That clears things up. Thanks!

Luckily, I have convinced the client to take advantage of the way the MS Membership Suite system currently works. Once they realized how much easier it was having the system do things instead of the original, manual way, they agreed to switch their membership setup.