Answers.Body: <p>I think it's not there because it would need a fair bit of work to make it function well in all cases.  I find that folks who have a lot of similar events are the ones who are most surprised it's not available.  Part of it may be that their needs are simple (they don't have to deal with price differences), and part of it may be that they're more likely to have people switching between similar events.</p>
  
  <p>The database side isn't too complicated.  You'd need to update the table that aligns participant records and contributions, and then the contribution would appear to apply to the right event.  I've even done this manually through the database for someone who was in a pinch and had a bunch of people on the wrong event.</p>
  
  <p>However, you'd need to decide what happens when the paid amounts are different, the financial types for the two events' fees are different, and the meaning of the price options of the two events are different.  For the latter, I mean this: what if someone wants to change their registration from the $200 ticket for the annual gala to the $200 VIP sponsor ticket for the picnic in the park?  That information is in the price option selected, and you'd need to decide what happens when that moves.</p>
  
  <p>Finally, there's the issue of partial credit or overpayment--when the prices aren't the same (as you mentioned).</p>
  
  <p>Again, there are technical solutions to all of this, but the assumptions that one person may make aren't necessarily what the end user would make.  A solution that goes into core needs to be reasonable for everyone.</p>
  
  <p>What Joe mentions--a cancelled registration and a new registration--is almost certainly the way to go.  You can do that now; the only real issue is when the bookkeeping shows a refund and payment that never really hit the bank account--you're just applying the credit for the one event to the new event.  Automating that would be very convenient for many CiviCRM users, but it would also cause confusion and pitfalls for others.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-30T20:56:25.463Z
Answers.Text: Thanks Andrew. This outlines most of the problems I suspected might exist with a simple hack to re-enable this feature.
  
  This client in particular is already using a considerably customized interface for Civi in many cases so it wouldn't be unreasonable to add the functionality. Seeing a break in Contribution <-> Event functionality would be problematic though.
Answers.UserDisplayName: EranSch
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-30T14:40:25.683Z
Answers.LastActivityDate: 2015-03-30T14:40:25.683Z
Answers.UserDisplayName: Andie Hunt
Answers.Body: <p>From a bookeeping perspective it wouldn't be too hard to implement. But as it's not a frequent use case it may have not been implemented during the refactoring for CiviAccounts a couple of years ago. </p>
  
  <p>Were we implementing this as a core enhancement I would want to ensure that scheduled emails work properly through this change of events. I wouldn't want to send any ones after the change that pertain to the old event, and I think the user should perhaps be warned about missing any scheduled events as a result of the change. For example, a mail scheduled for 2 days after registration in Event A may not go out if the change to that event is made made more than 2 days after the registration. </p>
  
  <p>I don't foresee any reporting problems, but there would need to be regression testing. Basically, there would be one additional cancelled registration in the original event, and one additional registration in the new event.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T21:54:10.000Z
Answers.LastActivityDate: 2015-03-26T21:54:10.000Z
Answers.UserDisplayName: Joe Murray
Body: <p>I've been doing some thinking on this but haven't tested it yet. Essentially, we've a user who would like to <em>always</em> have the ability of changing Participants' events. </p>
  
  <p>It seems as though the default CiviCRM functionality here is to allow changing events up until a payment has been made. That aside, it's still feasible to change the registered Event via API or otherwise. </p>
  
  <p>I'm wondering is if there is a repercussion of changing the registered event after a Contribution has been made. Is this functionality disabled for the convenience of not having to worry about mismatched price sets or is there a deeper issue of breaking some kind of reporting functionality?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-26T19:02:21.283Z
Comments.Text: From a bookeeping perspective it wouldn't be too hard to implement. But as it's not a frequent use case it may have not been implemented during the refactoring for CiviAccounts a couple of years ago. I would want to see that scheduled emails work properly through this change of events. I don't see any reporting problems. Is this a change you would like to see implemented? Would you have funding to support that?
Comments.UserDisplayName: Joe Murray
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-26T19:38:14.037Z
Comments.Text: This is more of a hypothetical at the moment. I'm more just wondering of the implications surrounding this type of change being made.
Comments.UserDisplayName: EranSch
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-26T21:49:37.357Z
Comments.Text: This post is on the edge between a suitable one for the Q&A format on StackExchange and a discussion thread more appropriate to a forum. I think my comment should be an answer.
Comments.UserDisplayName: Joe Murray
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-31T16:12:33.583Z
Comments.Text: Gee, this is an extremely common use case for our organization. We run educational classes and, due to schedule conflicts, they will need to re-register for a later class. Their payment has already been accepted and recorded. The future class has the same price. I went into edit the participant and was surprised I just couldn't select an alternate event. I've fudged a work around, do understand the technical issues, but I would disagree that it's not a common use case. Comes up for us nearly every class that we teach.
Comments.UserDisplayName: Karl Rudnick
Tags: <civievent><contributions>
Title: Is it a bad idea to change a Participant's registered event after a payment has been made?
ThreadText: # Is it a bad idea to change a Participant's registered event after a payment has been made?
  
  (Asked by: username_0 on 2015-03-26)
  
  I've been doing some thinking on this but haven't tested it yet. Essentially, we've a user who would like to *always* have the ability of changing Participants' events.
  
  It seems as though the default CiviCRM functionality here is to allow changing events up until a payment has been made. That aside, it's still feasible to change the registered Event via API or otherwise.
  
  I'm wondering is if there is a repercussion of changing the registered event after a Contribution has been made. Is this functionality disabled for the convenience of not having to worry about mismatched price sets or is there a deeper issue of breaking some kind of reporting functionality?
  
  **Tags:** civievent, contributions
  
  > **Comments:**
  > **username_1**: From a bookeeping perspective it wouldn't be too hard to implement. But as it's not a frequent use case it may have not been implemented during the refactoring for CiviAccounts a couple of years ago. I would want to see that scheduled emails work properly through this change of events. I don't see any reporting problems. Is this a change you would like to see implemented? Would you have funding to support that?  
  > **username_0**: This is more of a hypothetical at the moment. I'm more just wondering of the implications surrounding this type of change being made.  
  > **username_1**: This post is on the edge between a suitable one for the Q&A format on StackExchange and a discussion thread more appropriate to a forum. I think my comment should be an answer.  
  > **username_2**: Gee, this is an extremely common use case for our organization. We run educational classes and, due to schedule conflicts, they will need to re-register for a later class. Their payment has already been accepted and recorded. The future class has the same price. I went into edit the participant and was surprised I just couldn't select an alternate event. I've fudged a work around, do understand the technical issues, but I would disagree that it's not a common use case. Comes up for us nearly every class that we teach.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2015-03-30. Score: 1 | Accepted answer
  
  I think it's not there because it would need a fair bit of work to make it function well in all cases. I find that folks who have a lot of similar events are the ones who are most surprised it's not available. Part of it may be that their needs are simple (they don't have to deal with price differences), and part of it may be that they're more likely to have people switching between similar events.
  
  The database side isn't too complicated. You'd need to update the table that aligns participant records and contributions, and then the contribution would appear to apply to the right event. I've even done this manually through the database for someone who was in a pinch and had a bunch of people on the wrong event.
  
  However, you'd need to decide what happens when the paid amounts are different, the financial types for the two events' fees are different, and the meaning of the price options of the two events are different. For the latter, I mean this: what if someone wants to change their registration from the $200 ticket for the annual gala to the $200 VIP sponsor ticket for the picnic in the park? That information is in the price option selected, and you'd need to decide what happens when that moves.
  
  Finally, there's the issue of partial credit or overpayment--when the prices aren't the same (as you mentioned).
  
  Again, there are technical solutions to all of this, but the assumptions that one person may make aren't necessarily what the end user would make. A solution that goes into core needs to be reasonable for everyone.
  
  What Joe mentions--a cancelled registration and a new registration--is almost certainly the way to go. You can do that now; the only real issue is when the bookkeeping shows a refund and payment that never really hit the bank account--you're just applying the credit for the one event to the new event. Automating that would be very convenient for many CiviCRM users, but it would also cause confusion and pitfalls for others.
  
  > **Comments:**
  > **username_0**: Thanks Andrew. This outlines most of the problems I suspected might exist with a simple hack to re-enable this feature.  This client in particular is already using a considerably customized interface for Civi in many cases so it wouldn't be unreasonable to add the functionality. Seeing a break in Contribution <-> Event functionality would be problematic though.  
  
  ---
  
  ### Answer by username_1 on 2015-03-26. Score: 2
  
  From a bookeeping perspective it wouldn't be too hard to implement. But as it's not a frequent use case it may have not been implemented during the refactoring for CiviAccounts a couple of years ago.
  
  Were we implementing this as a core enhancement I would want to ensure that scheduled emails work properly through this change of events. I wouldn't want to send any ones after the change that pertain to the old event, and I think the user should perhaps be warned about missing any scheduled events as a result of the change. For example, a mail scheduled for 2 days after registration in Event A may not go out if the change to that event is made made more than 2 days after the registration.
  
  I don't foresee any reporting problems, but there would need to be regression testing. Basically, there would be one additional cancelled registration in the original event, and one additional registration in the new event.
  
  
  ---
  
  