Is there a contributions equivalent to the Ticketing Change Const ID security object? If so what is it? If not, what's the best way to go about accomplishing moving a gift that was accidentally processed under the wrong account without refunding the cc charge?
Another option is to move the contribution the way they are when a constituent merge happens, i.e. via SQL, update the customer_no in T_CONTRIBUTION, T_PAYMENT, and, if necessary, T_CREDITEE.
Yeah I was thinking of something like that... t_transaction, payment, contribution, ack_ext, cont_evex, event_extract. Wasn't sure if that were a really bad idea.
I know we could probably back out the gift, refund to cash (or some adjustment), and then use the cash to pay the gift on the correct account, but then we'd have historical backtracking to do to find the cc charge, which I was trying to avoid.
Note: there's nothing to update in t_transaction in this case since it doesn't include a customer_no column. Updating t_contribution and t_payment will take care of t_transaction.
Thinking about the ack tables here, and I don't think I've ever needed to update those in a case like this because it is usually at around that point that the mistake is discovered - we move the contrib, then acknowledge.
So, if we update T_PROMOTION, T_CONTRIBUTION and T_PAYMENT do we have all of the necessary bits covered? I am trying it out in our test system it seems like it all checks out.