As a system, when a chargeback fails due to Mastercard being down, QFD should verify if a chargeback ID was created. If the chargeback was created but the document was not successful it should route into the update document flow.

1. When the Mastercard chargeback is successful MC_Claim is called to verify the document status.
   1. If the document was attached successfully, continues through the flow
   2. If the document was not attached QFD will route into the flow to reupload the document.
2. When the Mastercard chargeback fails but after calling MC claim the chargeback was successful, MC claim is called to verify the document status. 
   1. If the document was attached successfully, continues through the flow
   2. If the document was not attached QFD will route into the flow to reupload the document.

Resolved an issue where when a Mastercard chargeback was attempted and an error was received, QFD was not confirming a Chargeback ID was created. This fix ensures that when a chargeback fails QFD will confirm if a chargeback ID was successfully created and verify the document status was successfully attached. If the documentation was not successfully attached the claim will route into the update document flow to re-upload the document.

Issue 1: Deny Debit Date not held onto when deny approval turned on. 

Issue 2: Deny Debit Date in letter does not match when the system processes accounting. 

1. Deny Debit Date needs to be set correctly post approval.
2. When a Deny Debit date is set the letter is routed to approval and the approval is reviewed after same business day, the deny debit date must be updated in the letter to reflect the approval date + the configured padding in Impl Config (DSS Setting - DenyDebitDatePaddingHours.)
   1. The content in the letter has the updated deny debit date
   2. The accounting is performed on the deny debit date in letter
3. If I deny a claim with a regular regulatory denial (5 business days) and the letter is approved on a day past the same business day, the deny debit date is adjusted to 5 business days from the approval.
4. (regression) Deny Debit date cannot be a date in the past
5. (Regression) Reg E Deny Debit date must be 5 business days from approval.

Resolved an issue where when a claim was denied and sent for Deny Approval, if the approval was not completed on the same day, the Deny Debit Date was not being updated to reflect the approval date+ the deny debit date buffer established during the denial. This fix ensures that if a Deny Approval is worked beyond the same business day the Deny Debit Date will be updated in the letter to reflect the buffer from the approval date. Additionally, this ensures the Deny Debit Date is properly reversing any credit on the date indicated in the letter.

As a system, when a user selects Do Not Pursue Recovery for All at disposition and selects the denial reason "Customer Withdrawal" the letter should populate the dispute details as well as the denial date.

1. When a user selects Do Not Pursue Recovery for All at Disposition and due to "Customer Withdrawal" deny reason the letter populates with the transaction grid as expected.
2. If the claim is being withdrawn and the transactions have different credit types issued, the preview of the letter should not display.

Resolved an issue where when a user selected Do Not Pursue Recovery for All at disposition and selected the denial reason "Customer Withdrew" the letter would attempt to populate without a table row. This fix ensures that when a user attempts to withdraw all at disposition the table row populates as expected. Additionally, when a user performs a bulk action to deny a claim with multiple disputes and the disputes have a different credit type (provisional, final, no credit) a letter preview will no longer be available. In its place a disclosure will be displayed indicating that due to the credit types applied a letter will be generated for each scenario and can be viewed in the Notification node to review a preview of each letter.

As a system the defined and legacy Fee Update process should be updated.

The following AC apply to systems that use legacy fee mapping, as well as those that use client info defined fee mapping.

1. When a fee review assignment was performed on a case with pending and posted transactions, and the pending transactions post after the assignment is completed, a second assignment is created when the pending transactions post.
2. When the fee review assignment is worked after the the pending transaction posts, users are not able to refund a fee that was already refunded with the previous assignment.
3. On a multiple dispute claim, only one fee assignment is created per fee.
4. Fee handling should only be defined or legacy.  There should be no way to trigger both.
5. If defined claim level fee processing uses 0 padding days for the start or end range, then the posting date should be used for that range.  We should not add 0 business days or -0 business days, as that will result in adding 1 day if the evaluation happened after hours or on a weekend or holiday.

Updated the Client Defined and Legacy Fee Process. This fix ensures when a fee review assignment was performed on a case with pending and posted transactions, a fee assignment is created for the posted transaction and a second assignment is created when the pending transactions post. Users will be unable to refund a fee that was previously refunded in the first fee assignment on the claim. On a multiple dispute claim, one fee assignment will be generated for all posted disputes, followed by a subsequent fee assignment when any pending transactions post. 

As a system, for Visa recurring cancelled claims the dispute validation rule for determining if a transaction was "Not an Unscheduled Credential-on-file Transaction" should only fail if the POS Entry is 10 and the transaction was not recurring. 

1. Modify the dispute validation rules for Visa dispute reason 13.2 Cancelled Recurring
   1. When the POS entry mode is 10 and the transaction is recurring the dispute has recovery rights.  The recovery rights validation for "Not an Unscheduled Credential-on-File Transaction"  is displayed as pass.  
   2. When POS entry mode is 10 and the transaction is not recurring the recovery rights validation for "Not an Unscheduled Credential-on-File Transaction" is displayed as failed.
   3. When the POS entry mode is not 10 the recovery rights validation for "Not an Unscheduled Credential-on-File Transaction" is displayed as passed.

Resolved an issue where when pursuing recovery on a Visa transaction for Recurring Cancelled the dispute validation rule for determining if a transaction was "Not an Unscheduled Credential-on-file Transaction" was incorrectly failing for recurring transactions. This fix ensures that this validation rule only fails if the POS Entry is 10 and the transaction was not recurring.