Answers.Body: <p>I presume you are trying both to simplify things for your Finance Administrators and restrict who has direct access to CiviCRM, but I don't think using a front-facing CiviCRM contribution page will accomplish those aims. </p>
  
  <p>If monetary contributions are involved then a front-facing CiviCRM contribution page will need either to have a payment processor specified or to have the "Pay later option" ticked. Once the pay later option is enabled then the email field will be pre-filled when an existing contact is selected.  </p>
  
  <p>However, if the pay later option is ticked then the payment is recorded as "pending (pay later)" so the Finance Aministrators will still need direct access to CiviCRM to record the payment.  You also then have a two-step process rather than a one-step process.</p>
  
  <p>It might be easier to use permissions to restrict what Finance Administrators can do in CiviCRM and train them to use a rear-facing form.</p>
  
  <p>And just for completeness for other people looking at this Q&amp;A, at this time CiviCRM pricesets cannot be used with webforms. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-27T05:00:15.797Z
Answers.Text: though you can reconstruct the equivalent of a Price Set on a webform i think
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-28T08:42:02.800Z
Answers.Text: Thank you Pete : not exactly : it is not really for me a matter of authorization, but of ease : members or participants can pay either on line (via a Contribution Page with a Payment Processor) or by check or cash : I would like to have a Contribution Page so that pertaining administrators could record those easily (i.e. same Contribution Page but rear facing, with same Price Set, but no Payment Processor). Concerning your Webform suggestion, I think you mean using custom fields (?) : it may be a spare solution
Answers.UserDisplayName: Jacques-Marie Moranne
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-28T08:49:31.470Z
Answers.Text: Sorry, I meant thank you JoAnne. BTW, Pete : Congratulations for your Rugby victory (... but we are progressing ...)
Answers.UserDisplayName: Jacques-Marie Moranne
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-25T23:27:26.433Z
Answers.LastActivityDate: 2016-11-25T23:40:30.540Z
Answers.LastEditDate: 2016-11-25T23:40:30.540Z
Answers.UserDisplayName: JoAnne
Answers.Body: <p>Finally, il you use Stripe Processor (maybe also others) and Webforms, you can include the Contribution page in a Webform, which gives the ability :</p>
  
  <ul>
  <li>to record some membership custom data (e.g. check number, and bank id)</li>
  <li>to fix (or let the user choose) pay later vs pay on line</li>
  <li>to actually pay on the way</li>
  <li>and do this all in one</li>
  </ul>
  
  <p>Great !</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-24T15:28:52.527Z
Answers.LastActivityDate: 2016-12-24T15:28:52.527Z
Answers.UserDisplayName: Jacques-Marie Moranne
Body: <p>I want Finance Administrators to have the ability to record cash or check membership contributions with predefined Price Sets.</p>
  
  <p>In this aim, I have created a Contribution Page with no Payment Processor.</p>
  
  <p>But when I use this Contribution Page to record someone else's Check or Cash Contribution (i.e. with ...&amp;cid=0)(e.g. <a href="https://mysite.com/civicrm/contribute/transact?reset=1&amp;id=8&amp;cid=0" rel="nofollow noreferrer">https://mysite.com/civicrm/contribute/transact?reset=1&amp;id=8&amp;cid=0</a>), and select the pertaining user, his email is not displayed (while it is if my Contribution Page specified a Payment Processor) :</p>
  
  <p>... and I get the following message : email is a mandatory field</p>
  
  <p>Is there any solution, or is it a bug ?</p>
  
  <p>(I am in Drupal 7.51 / CiviCRM 4.7.12)</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-11-25T12:22:42.993Z
Comments.Text: Finance Administrators can record (cash or check) offline contributions using pricesets. What do you want to use Contribution page?
Comments.UserDisplayName: Ghost
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-11-28T08:28:01.943Z
Comments.Text: Thank you Ghost : 2 reasons : 1-Filling Contributions is combersome and dangerous if you have a number of checks to record (lots of info to repeat) ; 2-Contributions do not accept (propose) Membership Price Sets.
Comments.UserDisplayName: Jacques-Marie Moranne
Tags: <civicontribute><contribution-page>
Title: Membership Contribution Page for Cash or Check Payment
ThreadText: # Membership Contribution Page for Cash or Check Payment
  
  (Asked by: username_0 on 2016-11-25)
  
  I want Finance Administrators to have the ability to record cash or check membership contributions with predefined Price Sets.
  
  In this aim, I have created a Contribution Page with no Payment Processor.
  
  But when I use this Contribution Page to record someone else's Check or Cash Contribution (i.e. with ...&cid=0)(e.g. <https://mysite.com/civicrm/contribute/transact?reset=1&id=8&cid=0>), and select the pertaining user, his email is not displayed (while it is if my Contribution Page specified a Payment Processor) :
  
  ... and I get the following message : email is a mandatory field
  
  Is there any solution, or is it a bug ?
  
  (I am in Drupal 7.51 / CiviCRM 4.7.12)
  
  **Tags:** civicontribute, contribution-page
  
  > **Comments:**
  > **username_1**: Finance Administrators can record (cash or check) offline contributions using pricesets. What do you want to use Contribution page?  
  > **username_0**: Thank you username_1 : 2 reasons : 1-Filling Contributions is combersome and dangerous if you have a number of checks to record (lots of info to repeat) ; 2-Contributions do not accept (propose) Membership Price Sets.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-11-25. Score: 1
  
  I presume you are trying both to simplify things for your Finance Administrators and restrict who has direct access to CiviCRM, but I don't think using a front-facing CiviCRM contribution page will accomplish those aims.
  
  If monetary contributions are involved then a front-facing CiviCRM contribution page will need either to have a payment processor specified or to have the "Pay later option" ticked. Once the pay later option is enabled then the email field will be pre-filled when an existing contact is selected.
  
  However, if the pay later option is ticked then the payment is recorded as "pending (pay later)" so the Finance Aministrators will still need direct access to CiviCRM to record the payment. You also then have a two-step process rather than a one-step process.
  
  It might be easier to use permissions to restrict what Finance Administrators can do in CiviCRM and train them to use a rear-facing form.
  
  And just for completeness for other people looking at this Q&A, at this time CiviCRM pricesets cannot be used with webforms.
  
  > **Comments:**
  > **username_3**: though you can reconstruct the equivalent of a Price Set on a webform i think  
  > **username_0**: Thank you Pete : not exactly : it is not really for me a matter of authorization, but of ease : members or participants can pay either on line (via a Contribution Page with a Payment Processor) or by check or cash : I would like to have a Contribution Page so that pertaining administrators could record those easily (i.e. same Contribution Page but rear facing, with same Price Set, but no Payment Processor). Concerning your Webform suggestion, I think you mean using custom fields (?) : it may be a spare solution  
  > **username_0**: Sorry, I meant thank you username_2. BTW, Pete : Congratulations for your Rugby victory (... but we are progressing ...)  
  
  ---
  
  ### Answer by username_0 on 2016-12-24. Score: 1
  
  Finally, il you use Stripe Processor (maybe also others) and Webforms, you can include the Contribution page in a Webform, which gives the ability :
  
  * to record some membership custom data (e.g. check number, and bank id)
  * to fix (or let the user choose) pay later vs pay on line
  * to actually pay on the way
  * and do this all in one
  
  Great !
  
  
  ---
  
  