Answers.Body: <p>So the answer is that it is not possible to change a payment method in core without creating additional financial transactions. </p>
  
  <p><strong>Background:</strong> a decision was made by some with decision powers that every edit should produce such transactions so this is working exactly as designed and the argument given is that this is in order to be compliant with accounting standards. The odd thing is that of all the projects we render IT services for every single CA considers such transactions noise and not helpful at all. I hope at some point we are able to revisit this and be allowed to simply delete payments [possibly with a permission level so a superadmin would need to authorize it] - it's completely reasonable to be able to delete transactions that never happened but were entered accidentally b/c of a default payment method e.g.</p>
  
  <p><strong>Your current options:</strong> a) via the GUI the only way to 'fix' this is for staff/admin to delete the entire contribution and re-enter it. b) via the Database: if you have access to mysql like you do - you can remove the extraneous transactions across a number of tables. I did one for a client this morning. Before you do this track a couple of contributions/'refunds' all the way through through all financial_ tables to familiarize yourself with the structure. </p>
  
  <p><strong>Another way to look at this is:</strong> admin/staff are allowed to delete all financial transactions - 3 in your case (by deleting the contribution) but are not allowed to delete a subset of the 3 - i.e. 2 in your case; whereas if you have permissions to delete all contacts, you can delete a subset; </p>
  
  <p>PS - in credit card payments when mistakes are made a payment can be voided after it has been authorized but before it has settled. Such payments do not show up on a credit card statement. Perhaps we can adopt that concept and allow payment mistakes to be corrected for a limited time, as most mistakes will be caught (almost) immediately. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T22:14:03.307Z
Answers.Text: I'm not a CA (accountant) but have been a part-time bookkeeper for the last 20 years. I don't think the CA's would approve of the records being deleted without *SOME* kind of audit trail, but I agree that audit records wouldn't have to be mixed in with the same transaction records (e.g. in Quickbooks there's a separate audit report). Also if it's a record from a prior *closed* period to be deleted, then likely a restatement would need to be prepared.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-23T02:12:03.010Z
Answers.Text: In cases like themak’s it’s clearly a mistake in data entry (as check is likely the default payment method) - they never received a check for $100 - that check was never returned (-$100) and replaced by a cash payment; if that had actually happened - yes there needs to be an audit trail; but that check - it does not exist - it can not be audited.
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-21T21:02:35.647Z
Answers.LastActivityDate: 2018-12-23T13:57:31.393Z
Answers.LastEditDate: 2018-12-23T13:57:31.393Z
Answers.UserDisplayName: KarinG - Semper IT
Body: <p>A version of <a href="https://civicrm.stackexchange.com/questions/21731/how-to-fix-bookkeeping-transactions-report-so-it-doesnt-show-redundant-transact">this has been asked before</a> - but the answer was quite complex - so I am hoping for an ELI5.</p>
  
  <p>Essentially - when manually adding contributions - sometimes people make mistakes.  when editing a contribution - from check to cash for example - a debit and a credit is processed.  See example below of a contribution that was entered as Check but was actually cash and was changed. While that's typically fine - when trying to find a specific contribution - these old records clutter the results.  Is there a way to make sure they do not appear in searches and reports - or is there a way to simply delete the old payment detail records - as really there was only supposed to be one in the first place.</p>
  
  <p><a href="https://i.sstatic.net/aMxhG.png" rel="noreferrer"><img src="https://i.sstatic.net/aMxhG.png" alt="transations"></a></p>
  
Tags: <civicontribute><contributions><payment>
Title: Change Payment Method without creating additional transactions
ThreadText: # Change Payment Method without creating additional transactions
  
  (Asked by: username_0 on 2018-12-21)
  
  A version of [this has been asked before](https://civicrm.stackexchange.com/questions/21731/how-to-fix-bookkeeping-transactions-report-so-it-doesnt-show-redundant-transact) - but the answer was quite complex - so I am hoping for an ELI5.
  
  Essentially - when manually adding contributions - sometimes people make mistakes. when editing a contribution - from check to cash for example - a debit and a credit is processed. See example below of a contribution that was entered as Check but was actually cash and was changed. While that's typically fine - when trying to find a specific contribution - these old records clutter the results. Is there a way to make sure they do not appear in searches and reports - or is there a way to simply delete the old payment detail records - as really there was only supposed to be one in the first place.
  
  [![transations](https://i.sstatic.net/aMxhG.png)](https://i.sstatic.net/aMxhG.png)
  
  **Tags:** civicontribute, contributions, payment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-12-21. Score: 4 | Accepted answer
  
  So the answer is that it is not possible to change a payment method in core without creating additional financial transactions.
  
  **Background:** a decision was made by some with decision powers that every edit should produce such transactions so this is working exactly as designed and the argument given is that this is in order to be compliant with accounting standards. The odd thing is that of all the projects we render IT services for every single CA considers such transactions noise and not helpful at all. I hope at some point we are able to revisit this and be allowed to simply delete payments [possibly with a permission level so a superadmin would need to authorize it] - it's completely reasonable to be able to delete transactions that never happened but were entered accidentally b/c of a default payment method e.g.
  
  **Your current options:** a) via the GUI the only way to 'fix' this is for staff/admin to delete the entire contribution and re-enter it. b) via the Database: if you have access to mysql like you do - you can remove the extraneous transactions across a number of tables. I did one for a client this morning. Before you do this track a couple of contributions/'refunds' all the way through through all financial\_ tables to familiarize yourself with the structure.
  
  **Another way to look at this is:** admin/staff are allowed to delete all financial transactions - 3 in your case (by deleting the contribution) but are not allowed to delete a subset of the 3 - i.e. 2 in your case; whereas if you have permissions to delete all contacts, you can delete a subset;
  
  PS - in credit card payments when mistakes are made a payment can be voided after it has been authorized but before it has settled. Such payments do not show up on a credit card statement. Perhaps we can adopt that concept and allow payment mistakes to be corrected for a limited time, as most mistakes will be caught (almost) immediately.
  
  > **Comments:**
  > **username_2**: I'm not a CA (accountant) but have been a part-time bookkeeper for the last 20 years. I don't think the CA's would approve of the records being deleted without *SOME* kind of audit trail, but I agree that audit records wouldn't have to be mixed in with the same transaction records (e.g. in Quickbooks there's a separate audit report). Also if it's a record from a prior *closed* period to be deleted, then likely a restatement would need to be prepared.  
  > **username_1**: In cases like username_0’s it’s clearly a mistake in data entry (as check is likely the default payment method) - they never received a check for $100 - that check was never returned (-$100) and replaced by a cash payment; if that had actually happened - yes there needs to be an audit trail; but that check - it does not exist - it can not be audited.  
  
  ---
  
  