Add/Update Gift Data as part of PostOmatic Processing
We often use PostOmatic (POM) to apply complex logic, concatenating data from multiple sources in RE to determine the final Debit/Credit accounts to which transactions should be written in our financial systems.
There is no simple way to look at a gift in RE and say, "This is the Debit/Credit that was used."
While the output data from POM can be re-imported to RE, currently, this is a secondary manual process. Could POM be updated to include an option for automatically adding the final Debit/Credit outputs to the source gift record?
![](https://secure.gravatar.com/avatar/135fa17901b230e25cedcb52beaa37c9?size=40&default=https%3A%2F%2Fassets.uvcdn.com%2Fpkg%2Fadmin%2Ficons%2Fuser_70-6bcf9e08938533adb9bac95c3e487cb2a6d4a32f890ca6fdc82e3072e0ea0368.png)
Thanks for the idea JPP. Can you be more specific about where you want the debit and credit used to be added back to the gift? There are certainly limitations as to where data could be written back to the gift due to field size constraints as well as considering all of the output that is typically in Post to General Ledger files.
Here are a few more questions for consideration:
What is the goal of having this data in RE/how would that data be used?
Should there be any considerations if an adjustment is being posted due to adjustments creating reversing entries to reverse out what was previously posted and then having new journal entries created for the updated information?
What other scenarios might we need to account for if we added a write-back feature?
Thank you
Steve Brewer
Product Manager
-
JPP commented
Hi Steve,
So many questions! So many ideas.1. Write data to Gift
Obviously, the easiest way to do this would be to write back some gift attribute(s), but I think if we could have the "perfect" scenario, I would want to see it written in the default RE Gift GL Distribution values. Putting it in the default Gift GL Distribution values would make processing Adj/Rev the easiest.2. Goal/Outcomes
The data would be use for two reasons. A) audit/reconciliation reasons [e.g. show me all the gifts that were posted to 100-4000-00-000]; and B) supporting processing Adj/Rev transactions.3. Adj/Rev Considerations
There should be considerations, but those depend on how the data is written.4. Other Scenarios
The best practice is NEVER to delete gifts if they have been posted to GL, but best practice isn't always followed. This would be a case where having the calculated accounts written to the default Gift GL Distribution fields could solve the resulting Reversal transaction problem.