TFRS - Credit transfer incorrectly categorized in TFRS

[Grulin]

Describe the Bug
Credit Transfer ID #2704 in TFRS is incorrectly categorized as a Category A transfer. The agreement date is February 20th, 2024, and the recorded date is September 3rd, 2024. According to the transfer categorization rules, this should be a Category B transfer, as the agreement was reached more than six months but less than one year prior to the transfer. However, it has been incorrectly labeled as Category A.

Expected Behaviour
The transfer should be categorized based on the time between the agreement date and the recorded date:

• Category A: The agreement to transfer credits was reached within six months of the credit transfer.
• Category B: The agreement to transfer credits was reached between six months to one year prior to the credit transfer.
• Category C: The agreement to transfer credits was reached more than one year prior to the credit transfer.
• Category D: Transfers reported with zero or near-zero price.

In this case, with an agreement date of February 20th, 2024 and a recorded date of September 3rd, 2024, the transfer should be categorized as Category B.

Actual Behaviour
Credit Transfer ID #2704 is incorrectly categorized as a Category A transfer, despite the time between the agreement and recorded dates falling into the Category B range.

Implications

• Incorrect categorization may impact the reporting and tracking of credit transfers, leading to potential misreporting in compliance or review processes.

Steps To Reproduce
Steps to reproduce the behaviour:
User/Role: IDIR

1. Navigate to Credit Transfer ID TFRS - revert org status label changes on Edit organization page in main release #2704 in TFRS.
2. Review the agreement date (February 20th, 2024) and the recorded date (September 3rd, 2024).
3. Observe that the transfer is categorized as Category A when it should be Category B.

[Grulin]

@prv-proton Yay! Thank you for this. Do you know what caused it?

[prv-proton]

@prv-proton Yay! Thank you for this. Do you know what caused it?

Yes @Grulin, code wasn't considering the edge case scenario where the difference is exactly 6 months, but ignoring any extra days.