Hey everyone,
We're working on a contribution history import where old pledges are imported as a single payment, since that's all the contribution import utility is capable of. But we want to maintain a history that shows if a donor prefers to do multiple payments over time or something else.
My approach is to have an LP_CONTRIBUTION_IMPORT step that runs after each contribution that will check if the imported contribution was a pledge, and if so, insert rows into T_SCHEDULE that detail the historical pledge payments. Can anyone think of any issues with this approach? I believe since the pledge will already be fully paid, this doesn't need to involve any of the financial transaction tables. But I'm a bit curious about the mir_lock column, and whether I should actually be inserting to a mirror table in a way that references the controlled batch being used for the import.
Any thoughts or advice?
MIR_lock() has been largely obsolete since 2001.
You had me for a good 24 hours before I clicked that link, Gawain.
I'm also discovering that if the received amount matches the contribution amount, it will be imported as a gift and not a pledge. So now I'm trying to figure out how much I can fudge/hack the import process to get these scheduled payments included.
I know I found somewhere or saw on a forum somewhere that mir_lock (shows up in a few places, I think) is obsolete, but I don't remember where or what it was originally.
Will definitely be interested in how you solve the issue. There's a chance we might have to do something similar some time in the next few years.
It does appear to still be used to indicate which batch is working on a transactional table, including when you've got a controlled batch working on the TM_ mirror tables.
I've been exploring this more and think I've got my solution. I can get the import process to generate a payment schedule based on the first, last, and total number of pledge payments I want to import. This happens automatically based on the input data. In my post-import step in LP_CONTRIBUTION_IMPORT, then I can modify the schedule rows in TM_SCHEDULE, and even mess with TM_TRANSACTION to turn one pledge payment into multiple ones with different dates (I don't think I need to be as scared of this as I was). Then the usual process of closing the controlled batch post-import moves all of that stuff into the non-mirror tables.
I'm pretty sure everything I'm doing will end up being transactionally-consistent, but ultimately it doesn't matter too much since nothing involving these gifts will ever be posted to the ledger. I do have to make sure all of the schedule entries have a receivable status of current, however; otherwise they could get caught up in a future-to-current process later on.
Anyway, still have to write the code for all of this, so I'll report back if something else comes up.