Answers.Body: <p>I suggest you create an issue at <a href="https://lab.civicrm.org/dev/core/-/issues" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues</a></p>
  <p>I'd think it should be treated in the same way as if you matched on a contact id that was soft-deleted.</p>
  <p>The message you quote appears to be generated from <code>CRM_Contribute_Import_Parser_Contribution::deprecatedFormatParams()</code> but given the name, a quick fix to that function to handle external id is not the answer.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-13T19:07:23.633Z
Answers.LastActivityDate: 2020-11-13T19:07:23.633Z
Answers.UserDisplayName: Aidan
Body: <p>I have a client whose accounting team has run into the following issue (admittedly an edge case but causes a lot of confusion and troubleshooting time for the team so we want to fix). Following the bug reporting instructions I have replicated this in two demo instances (dmaster and wpmaster) and now want to know if anyone else has experienced this. Here are the conditions/steps. To your knowledge is this a known issue?</p>
  <ul>
  <li>The import matches contributions to contact by External ID</li>
  <li>A given contact has been de-duped and the External ID needed for correct contribution matching has been overwritten by a different External ID</li>
  <li>The contact record with the correct External ID is in the trash</li>
  <li>The contribution import runs without throwing any error message</li>
  <li>The contribution does not appear in the contact record because its External ID does not match, and it DOES appear on the contact record that is in the trash (soft delete).</li>
  </ul>
  <p>To summarize: When contributions are imported matching to External ID, expected behavior to get an error message and failed import line if I import a contribution that matches to a contact that is soft-deleted. Instead I get no error message and a successful import matched to a soft-deleted contact.</p>
  <p>System info: The client is running Civi 5.31.0 on WP 5.5.3 but since I replicated on dmaster and wpmaster that seems less relevant.</p>
  <p>Other relevant info: When using other methods of matching to a contact, the system behaves as expected (i.e., gives an error message and does not import the contribution):</p>
  <ul>
  <li>Email address as matching method gives &quot;No matching Contact found for ([EMAIL ADDRESS])&quot;</li>
  <li>Contact ID as matching method gives &quot;Invalid Contact ID: contact_id 204 is a soft-deleted contact.&quot;</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-11-13T19:16:12.973Z
Comments.Text: Does it occur if you use this for your import? https://github.com/eileenmcnaughton/nz.co.fuzion.csvimport
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-11-18T18:39:54.640Z
Comments.Text: I have not tested with that extension bc they don't have it and I and can't use their developer resources to install it. But it is great to know about, TY!
Comments.UserDisplayName: Lisa J
Tags: <contributions><import><issues><external-id>
Title: possible bug: when using External ID as matching method, imported contributions can get matched to contacts in the trash--would expect error instead
ThreadText: # possible bug: when using External ID as matching method, imported contributions can get matched to contacts in the trash--would expect error instead
  
  (Asked by: username_0 on 2020-11-12)
  
  I have a client whose accounting team has run into the following issue (admittedly an edge case but causes a lot of confusion and troubleshooting time for the team so we want to fix). Following the bug reporting instructions I have replicated this in two demo instances (dmaster and wpmaster) and now want to know if anyone else has experienced this. Here are the conditions/steps. To your knowledge is this a known issue?
  
  * The import matches contributions to contact by External ID
  * A given contact has been de-duped and the External ID needed for correct contribution matching has been overwritten by a different External ID
  * The contact record with the correct External ID is in the trash
  * The contribution import runs without throwing any error message
  * The contribution does not appear in the contact record because its External ID does not match, and it DOES appear on the contact record that is in the trash (soft delete).
  
  To summarize: When contributions are imported matching to External ID, expected behavior to get an error message and failed import line if I import a contribution that matches to a contact that is soft-deleted. Instead I get no error message and a successful import matched to a soft-deleted contact.
  
  System info: The client is running Civi 5.31.0 on WP 5.5.3 but since I replicated on dmaster and wpmaster that seems less relevant.
  
  Other relevant info: When using other methods of matching to a contact, the system behaves as expected (i.e., gives an error message and does not import the contribution):
  
  * Email address as matching method gives "No matching Contact found for ([EMAIL ADDRESS])"
  * Contact ID as matching method gives "Invalid Contact ID: contact\_id 204 is a soft-deleted contact."
  
  **Tags:** contributions, import, issues, external-id
  
  > **Comments:**
  > **username_1**: Does it occur if you use this for your import? https://github.com/eileenmcnaughton/nz.co.fuzion.csvimport  
  > **username_0**: I have not tested with that extension bc they don't have it and I and can't use their developer resources to install it. But it is great to know about, TY!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2020-11-13. Score: 1
  
  I suggest you create an issue at <https://lab.civicrm.org/dev/core/-/issues>
  
  I'd think it should be treated in the same way as if you matched on a contact id that was soft-deleted.
  
  The message you quote appears to be generated from `CRM_Contribute_Import_Parser_Contribution::deprecatedFormatParams()` but given the name, a quick fix to that function to handle external id is not the answer.
  
  
  ---
  
  