OOP and business rules

I'm still trying to get my head around OOP, and I need some input. In short, should an object embed the business rules that govern it's use or should the script manipulating those objects control implementing the business rules?

By way of background, I'm working on a site which includes a section for allowing users to subscribe to publications and change some details about the subscriptions they've opted to receive. When a user updates a subscription, if they change attributes like the delivery method or the language of the publication, the client wants the existing subscription to be canceled and a new subscription created.

The subscription object has methods for updating, adding, and canceling subscriptions, which are called by a script which processes the input from the subscription update form. Should that script determine when it's appropriate to cancel the existing subscription and create a new one, or should that logic be built into the update method of the subscription object?

On the one hand, it seems like adding the logic into subscription object makes it easier to update in future. On the other, it seems like I lose some flexibility in how the object is manipulated. What do y'all think?

[edit]
Also impacting this is how the submitted values to update the subscription to (e.g., the new delivery method selected) should be passed to the object so that it can determine if an update to the existing subscription should be made or if the existing subscription canceled and a new one created.

generally speaking the object should reflect only what that individual object does. I personally would have the application destroy and create a new object - NOT have the object handle it.

It will allow for greater reusability of the object code as well.

OOP (Object Oriented Programming) concept is use in programming language like asp.net, java.