Summary: When denying a claim, the deny reasons were limited and did not include all configured deny reason.

Steps to Reproduce:

1. proceed with denying a claim 
2. All applicable deny reasons do not appear

1. When denying a claim, Out Of Timeframe deny reason is displayed to the user when applicable.
2. (regression) Reg Z Fraud Claim out of timeframe is not an applicable deny reason.

Resolved an issue where applicable deny reasons were not appearing when denying a claim. This fix ensures that, where applicable, the configured denial reasons are available.

Summary: Current usage of the ManualAccountingRuleList property on ImplConfig is not performant. 

Expected Result: Manual accounting should work without referencing D_ImplConfig.ManualAccountingRuleList

Actual Result: Currently, manual accounting requires D_ImplConfig.ManualAccountingRuleList to have a value.  

1. D_ImplConfig should not contain a property for ManualAccountingRuleList
2. Manual accounting should work as intended/allow you to select accounting rules to manually apply

Resolved an issue where manual accounting could not be performed without referencing a list on ImplConfig. This fix ensures that manual accounting work as intended and users are able to select accounting rules to manually apply.

Reported Issue: When a merchant credit is applied to a case, and the case is denied, then re-opened users should not be able to select the same credits again if its been fully applied to a dispute.

1. When a dispute is reopened that was denied for merchant credit, merchant credit is no longer applied to the dispute.
2. If the claim is reopened and merchant credit is matched, regardless of the iteration it should be sent to review.
3. If the credit was applied at the claim level and dispute level, the dispute level applied credits is indexed and includes the claim ID 

Resolved an issue where if a merchant credit was applied to a case, and the case is denied, then re-opened,  and a merchant credit is matched again the claim could be re-denied for the same credit. This fix ensures that if a claim was denied for merchant credit, and reopened, if a merchant credit is found, regardless of the iteration, it will be routed to a user for review.

As a system, QFD should not auto-deny for a merchant credit when the merchant credit is not equal to the complete original transaction amount. Additionally, if a merchant name is 4 digits, the auto-match criteria should only look for the first 4 digits instead of the normal 5 digits in a merchant description.

1. When a user disputes a a partial amount of a transaction and a merchant credit exists for more than the disputed amount but less than the original transaction, the claim should not deny for auto-merchant credit and should be routed for the user to review
2. When a merchant name contains only 4 characters a table will exist to match merchant credits.
   1. When the merchant name contains the name Lyft, Uber or Amzn, the criteria to check if the Name matches, should be changed to use 4 digits instead of the 5 digits.
3. When a credit is expected and the expected credit arn, transaction id or authorization code matches what QFD expects to match on:
   1. The amount of the credit must match the amount of the dispute to auto deny for merchant credit
   2. If the amount of the credit does not match the amount of the dispute, the merchant credit flow goes to manual review.

Resolved an issue where a merchant credit check was matching incorrectly. This fix ensures that QFD will not auto-deny a claim for a merchant credit if the merchant credit is not equal to the complete original transaction amount. Additionally, updated the matching criteria for merchants with only 4 digits descriptions, including Lift, Uber, and Amzn to only validate the first 4 digits of the description instead of 5.

As a system, we should be able to pursue the max chargebacks per association.

1. When disputing Mastercard claim QFD should only consider Mastercard network when counting FNS.
2. When a chargeback was rejected and resubmitted only accepted chargebacks count 
3. Auto-chargebacks are submitted for disputes under the FNS count.
4. When the chargeback counter is reached the system will not send another chargeback.
   1. When disputing a Visa fraud case for (10.4) the system will only allow 35  Fraud chargebacks to be submitted across all cases in the system.
      1. When a client cannot store card number the validation is run on card id and only 35 Fraud chargebacks to be submitted.  When the 36th Fraud chargeback will be prevented by the dispute validation rules.
      2. When a client can store card number the validation is run on card number and only 35 Fraud chargebacks to be submitted.  When the 36th Fraud chargeback will be prevented by the dispute validation rules.
   2. When disputing a MC fraud case for (All Reasons) the system will only allow 15 Fraud chargebacks to be submitted across all cases in the system.
      1. When a client cannot store card number the validation is run on card id and only 15 Fraud chargebacks to be submitted.  When the 16th Fraud chargeback will be prevented by the dispute validation rules.
      2. When a client can store card number the validation is run on card number and only 15 Fraud chargebacks to be submitted.  When the 16th Fraud chargeback will be prevented by the dispute validation rules.
5. A chargeback will not be submitted if the transaction date occurred after submitting two or more chargebacks involving the same Mastercard card account for any of the following message reason codes: 4837, 4840, 4870, or 4871.
   1. For reason code 4863 first chargebacks will be included in the FNS count once the FNS fraud chargeback count is two or greater.
6. When disputing a Visa Fraud case for (10.3 or 10.4) the system will not allow a fraud transaction to be disputed that posted after a fraud report has been filed on the same card.
   1. When a client cannot store card number this validation is run on card id.
   2. When a client can store card number this validation is run on card.

Resolved an issue where the max number of chargebacks per association were being performed as the system was counting chargebacks performed with other associations.

Current Behavior: If multiple documents are required, and one of them does not have a template for missing documents (see GenerateRequiredDocuments activity) and a statement of fraud/dispute is required, no attachment is included on the claim because the activity is exits upon not finding the template.

Expected Behavior:  Regardless of other required documents, if a statement of fraud/dispute is required, it must always be included as an attachment.

1. When Reg E docs are enabled and another document is required per the association rules the statement of dispute is attached to the confirmation letter.
   1. When a Paid by Other means Claim requires besides the proof of payment, the Statement of Dispute, the confirmation letter should have the Statement of Dispute attached.
   2. When a Credit Not processed Claim requires, besides the Copy Of Credit Transaction Receipt Or Voided Transaction Receipt, a Statement of Dispute, the confirmation letter should have the Statement of Dispute attached.
2. (regression) When reg e docs are enabled and a fraud card claim is disputed the statement of fraud is attached to the confirmation letter.

Resolved an error where the Statement of Dispute or Statement of Fraud were not automatically attached to the confirmation letter when required.