I agree! We had a recurring gift where the card information expired. After catching on and notifying the constituent, they decided not to continue. Now I have a bunch of individual unapproved batches with a $0.00 amount, from the expired card, that are taking up space in the NXT Gift Batch area.
We understand the importance of preserving gift history where relational data exists. However, us users should have the ability to decide what to keep and what to remove in cases where deletion is appropriate (e.g., test transactions, incorrect entries, or gifts without associated data).
Since BBMS already tracks the transaction history, these records don’t necessarily need to remain in RE, where they can clutter the database and impact usability. We need the flexibility to delete such gifts ensures cleaner data.
Want to be able to delete. Gifts from our online platform are rarely processed for just one date. It's easy to pull gift made today in batch and then accidentally pull it with gifts made later today in tomorrow's batch. Do not want adjusted gift of $0 on record when it was due to error.
This Idea HAS NOT SHIPPED. A gift entered in web view cannot be deleted in either web view or database view.
We need to be able to delete incorrect entries entered in either mode- the web view is just an 'overlay', so there is no reason why gifts entered there are special. We who have the rights to delete gifts are WELL AWARE when the 'trail for gifts' should be preserved through an adjustment, and when the mistaken gift entry should be deleted.
The ability to delete a gift in web view was released earlier this year. That capability allows for gifts with no transactions associated with them to be deleted. As we move forward with our reconciliation unified view, we need to ensure that the trail for gifts is preserved. There are instances where deletion can occur (non transaction ID, transaction occurred but in test mode, etc) but for those gifts where we have relational data, we want to preserve that history and refunds/adjustments are the advised method. We are evaluating feedback for instances where gifts should be able to be deleted as we move forward.
this is causing me A LOT of extra work (and aggravation). Plus it is going to be more work come year end and giving summary time. URGH!!! Why mess with something that was working just fine in database view
When I brought this up with Blackbaud, I was told: "On the whole, Blackbaud suggests that gifts are never deleted in either DB or Webview. Adjusting a gift to $0 allows for better tracking and a reason for why the gift was deleted."
However, we use $0 gifts to mean something else (something that should actually be tracked on a constituent's record). I don't see any reason to track a gift in RE that was entered erroneously and shouldn't exist in the first place. That should be handled outside of the database.
A better solution would be a history of actions performed by users in the system - that way, the incorrect gift wouldn't be attributed to a constituent, but it could be seen that a particular user deleted a gift.
I agree! We had a recurring gift where the card information expired. After catching on and notifying the constituent, they decided not to continue. Now I have a bunch of individual unapproved batches with a $0.00 amount, from the expired card, that are taking up space in the NXT Gift Batch area.
As we are cleaning up data, we need to be able to delete gifts that are entered in error.
Anthony,
We understand the importance of preserving gift history where relational data exists. However, us users should have the ability to decide what to keep and what to remove in cases where deletion is appropriate (e.g., test transactions, incorrect entries, or gifts without associated data).
Since BBMS already tracks the transaction history, these records don’t necessarily need to remain in RE, where they can clutter the database and impact usability. We need the flexibility to delete such gifts ensures cleaner data.
Want to be able to delete. Gifts from our online platform are rarely processed for just one date. It's easy to pull gift made today in batch and then accidentally pull it with gifts made later today in tomorrow's batch. Do not want adjusted gift of $0 on record when it was due to error.
This Idea HAS NOT SHIPPED. A gift entered in web view cannot be deleted in either web view or database view.
We need to be able to delete incorrect entries entered in either mode- the web view is just an 'overlay', so there is no reason why gifts entered there are special. We who have the rights to delete gifts are WELL AWARE when the 'trail for gifts' should be preserved through an adjustment, and when the mistaken gift entry should be deleted.
The ability to delete a gift in web view was released earlier this year. That capability allows for gifts with no transactions associated with them to be deleted. As we move forward with our reconciliation unified view, we need to ensure that the trail for gifts is preserved. There are instances where deletion can occur (non transaction ID, transaction occurred but in test mode, etc) but for those gifts where we have relational data, we want to preserve that history and refunds/adjustments are the advised method. We are evaluating feedback for instances where gifts should be able to be deleted as we move forward.
I thought this ability has already shipped? If it hasn't, it's a no-brainer.
this is causing me A LOT of extra work (and aggravation). Plus it is going to be more work come year end and giving summary time. URGH!!! Why mess with something that was working just fine in database view
When I brought this up with Blackbaud, I was told: "On the whole, Blackbaud suggests that gifts are never deleted in either DB or Webview. Adjusting a gift to $0 allows for better tracking and a reason for why the gift was deleted."
However, we use $0 gifts to mean something else (something that should actually be tracked on a constituent's record). I don't see any reason to track a gift in RE that was entered erroneously and shouldn't exist in the first place. That should be handled outside of the database.
A better solution would be a history of actions performed by users in the system - that way, the incorrect gift wouldn't be attributed to a constituent, but it could be seen that a particular user deleted a gift.