Answers.Body: <p>The state changes from one status to another prompt the creation of accounting transactions that reflect that flow. I don't think there is a definiton of what it means from an accounting perspective to implement some of the state transitions you mention. If that is agreed on then we could allow those transitions. The main thing is that we need to maintain the integrity of the financial information in several tables in the database.</p>
  
  <p>FWIW, there is a GSoC project this summer that may fill in more refund functionality possibly along the lines of the cheque writing done by the grant programs extension, though it would likely also use refunds through online payment processors if they and their plugins support refunds. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-04T23:15:05.630Z
Answers.LastActivityDate: 2015-05-04T23:15:05.630Z
Answers.UserDisplayName: Joe Murray
Body: <p>When we try to handle backend contributions sometimes we need manually change contribution statuses. Unfortunately some contribution status changes are restricted. From 'pending refund' we cannot change back to 'pending' or to 'in progress'. But even a more basic change like from 'pending' to 'in progress'.</p>
  
  <p>I checked the wiki at <a href="http://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Data+Flow#CiviAccountsDataFlow-Otherchangestocontributionstatus" rel="nofollow">http://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Data+Flow#CiviAccountsDataFlow-Otherchangestocontributionstatus</a> but that does not seem totally up to date (pending refund / progress status) </p>
  
  <p>Is there further documentation on an underlying reasoning and workflow logic of these restrictions? What would go wrong if this wasn't restricted? Could the check be a little too harsh?</p>
  
  <p>BTW. They are handled by checkStatusValidation in CRM/Contribute/BAO/contribute.php</p>
  
Tags: <civicontribute>
Title: Reasons for restricting changing contribution statusses?
ThreadText: # Reasons for restricting changing contribution statusses?
  
  (Asked by: username_0 on 2015-05-04)
  
  When we try to handle backend contributions sometimes we need manually change contribution statuses. Unfortunately some contribution status changes are restricted. From 'pending refund' we cannot change back to 'pending' or to 'in progress'. But even a more basic change like from 'pending' to 'in progress'.
  
  I checked the wiki at <http://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Data+Flow#CiviAccountsDataFlow-Otherchangestocontributionstatus> but that does not seem totally up to date (pending refund / progress status)
  
  Is there further documentation on an underlying reasoning and workflow logic of these restrictions? What would go wrong if this wasn't restricted? Could the check be a little too harsh?
  
  BTW. They are handled by checkStatusValidation in CRM/Contribute/BAO/contribute.php
  
  **Tags:** civicontribute
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-05-04. Score: 3
  
  The state changes from one status to another prompt the creation of accounting transactions that reflect that flow. I don't think there is a definiton of what it means from an accounting perspective to implement some of the state transitions you mention. If that is agreed on then we could allow those transitions. The main thing is that we need to maintain the integrity of the financial information in several tables in the database.
  
  FWIW, there is a GSoC project this summer that may fill in more refund functionality possibly along the lines of the cheque writing done by the grant programs extension, though it would likely also use refunds through online payment processors if they and their plugins support refunds.
  
  
  ---
  
  