Answers.Body: <p>Consensus seems to be:</p>
  <ol>
  <li>This is not normal behavior.</li>
  <li>There are no known steps to repro, nor a known cause.</li>
  </ol>
  <p>I've filed a bug report at <a href="https://lab.civicrm.org/dev/core/-/issues/4318" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues/4318</a> ; hopefully others who encounter this issue can add useful information there. (Would be great if we can find some actual steps to repro at will!)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-05-25T16:49:35.520Z
Answers.LastActivityDate: 2023-05-25T16:49:35.520Z
Answers.UserDisplayName: TwoMice
Body: <p>On several sites (all currently running CiviCRM 5.58.1 but all having existed much longer) I have found contributions which have no line items -- that is, rows in <code>civicrm_contribution</code> that have no corresponding rows in <code>civicrm_line_item</code>.</p>
  <p><a href="https://i.sstatic.net/ECYcl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ECYcl.png" alt="enter image description here" /></a></p>
  <p>Could this in any way be normal?</p>
  <p>I'm unable to reproduce such a situation at will, except by manually deleting rows in <code>civicrm_line_item</code> via API or SQL. It seems any contribution record will, by design, have at least one line_item, even if using a quick-config contribution instead of a visible price set, or if manually creating even a zero-dollar contribution in the back-end.</p>
  <p>This situation leads to a fatal error (&quot;Return value of CRM_Financial_BAO_Order::getPriceSetID() must be of the type int, null returned&quot;) when attempting to generate a PDF invoice with &quot;Download Invoice&quot; for the given contribution, apparently on the assumption that this situation is not expected by core code.</p>
  <p><strong>Question:</strong> Is there any reasonable way -- i.e. not a bug -- that CiviCRM could be creating this situation? If so, I can explore a bug report on the above-mentioned fatal error. If not, I'll need to investigate further how this situation is arising on various sites. (And if you want to check on your own sites and comment on your findings, I'm naturally curious about that too.)</p>
  <p>For reference, this query identifies the number of contributions having no line items:</p>
  <pre><code>SELECT count(*)
  FROM 
  civicrm_contribution ctr
  left join civicrm_line_item li on li.contribution_id = ctr.id
  where li.id is null;
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-05-05T23:21:11.440Z
Comments.Text: I have seen this before but can't remember exactly - possibly on a site with webform (drupal 7) but where it was missing the legacy transact extension?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-05-06T15:51:26.437Z
Comments.Text: We have a handful (about 0.06% of all contributions), only 4 in the last 5 years. A number of them are $0 contributions from price set event registrations, but there are membership sign ups and other transactions too. Looks like something that happens occasionally due to some rare bug to me.
Comments.UserDisplayName: Lars SG
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-05-07T20:00:21.180Z
Comments.Text: I recollect a few of these - a quick search in our ticket system only came up with a case where "membershiprenewalcontrol extension" was involved (we then fixed it) - but does potentially point at extensions as also a source these
Comments.UserDisplayName: petednz - fuzion
Tags: <civicontribute><line-items>
Title: Contribution has no line_items. Shouldn't that be impossible?
ThreadText: # Contribution has no line_items. Shouldn't that be impossible?
  
  (Asked by: username_0 on 2023-05-05)
  
  On several sites (all currently running CiviCRM 5.58.1 but all having existed much longer) I have found contributions which have no line items -- that is, rows in `civicrm_contribution` that have no corresponding rows in `civicrm_line_item`.
  
  [![enter image description here](https://i.sstatic.net/ECYcl.png)](https://i.sstatic.net/ECYcl.png)
  
  Could this in any way be normal?
  
  I'm unable to reproduce such a situation at will, except by manually deleting rows in `civicrm_line_item` via API or SQL. It seems any contribution record will, by design, have at least one line\_item, even if using a quick-config contribution instead of a visible price set, or if manually creating even a zero-dollar contribution in the back-end.
  
  This situation leads to a fatal error ("Return value of CRM\_Financial\_BAO\_Order::getPriceSetID() must be of the type int, null returned") when attempting to generate a PDF invoice with "Download Invoice" for the given contribution, apparently on the assumption that this situation is not expected by core code.
  
  **Question:** Is there any reasonable way -- i.e. not a bug -- that CiviCRM could be creating this situation? If so, I can explore a bug report on the above-mentioned fatal error. If not, I'll need to investigate further how this situation is arising on various sites. (And if you want to check on your own sites and comment on your findings, I'm naturally curious about that too.)
  
  For reference, this query identifies the number of contributions having no line items:
  
  ```
  SELECT count(*)
  FROM 
  civicrm_contribution ctr
  left join civicrm_line_item li on li.contribution_id = ctr.id
  where li.id is null;
  
  ```
  
  **Tags:** civicontribute, line-items
  
  > **Comments:**
  > **username_1**: I have seen this before but can't remember exactly - possibly on a site with webform (drupal 7) but where it was missing the legacy transact extension?  
  > **username_2**: We have a handful (about 0.06% of all contributions), only 4 in the last 5 years. A number of them are $0 contributions from price set event registrations, but there are membership sign ups and other transactions too. Looks like something that happens occasionally due to some rare bug to me.  
  > **username_3**: I recollect a few of these - a quick search in our ticket system only came up with a case where "membershiprenewalcontrol extension" was involved (we then fixed it) - but does potentially point at extensions as also a source these  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2023-05-25. Score: 2 | Accepted answer
  
  Consensus seems to be:
  
  1. This is not normal behavior.
  2. There are no known steps to repro, nor a known cause.
  
  I've filed a bug report at <https://lab.civicrm.org/dev/core/-/issues/4318> ; hopefully others who encounter this issue can add useful information there. (Would be great if we can find some actual steps to repro at will!)
  
  
  ---
  
  