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?
Hi Amanda,
I'm unaware of any way to change the Const ID like we can in ticketing (though that would be pretty cool), so we have a payment method we use as a holding pen for money that needs to be moved from one account to another. I make sure that it is understood that this payment GL needs to end up back at zero by posting time.
Cheers!
Hi,
At this point the only way to move monies between constituents is to adjust the contribution to zerio, refunding the moniey onto your an account payment method and then pay the on account monies into a gift voucher. You can then use the gift voucher to pay for the contribution in the new constituent.
Lesley
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.
I have moved gifts this way a few times and it always makes me a bit nervous since there is no audit trail. I suggest adding notes - wherever your company adds such notes.
I also recommend updating t_promotion as well.Dale
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.