Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.5.1
-
Fix Version/s: 3.5.2
-
Component/s: Staff Interface
-
Labels:None
Description
When changing the renew date for a service with prorate checked, the resulting invoice shows a date range that seems incorrect.
For example, the line item of a prorated invoice may say for the date range (July 15, 2015 - October 1, 2015) where July 15 is the current day and October 1 is the new renew date. However, the renew date was originally September 9, and a previous invoice was generated to cover August 9, 2015 through September 9, 2015. Thus, it seems the date range in the prorated invoice should be (September 9, 2015 - October 1, 2015) which accurately represents the amount charged for the invoice. In my example, the prorated invoice was $21 on a $30 monthly package.
Activity
In that case, would the date in the past represent the service coverage date for the invoice?
The beginning service coverage date is not accurate when changing the renew date unless, I suppose, the renew date was changed to today. Whether it fits for both cases I'm not sure, I just want the date range to accurately represent the coverage period for the invoice.
Paul Phillips
added a comment - In that case, would the date in the past represent the service coverage date for the invoice?
The beginning service coverage date is not accurate when changing the renew date unless, I suppose, the renew date was changed to today. Whether it fits for both cases I'm not sure, I just want the date range to accurately represent the coverage period for the invoice. Assuming we require the current issued invoice to be paid in full (or has been paid in full), what I would expect in the given case of:
- Current date: Jul 15
- Current renew date: Sep 9
- New renew date: Oct 1
Is this:
- Credit issued for time not used: Jul 15 - Sep 9
- Prorated invoice for Jul 15 - Oct 1
Here's why:
- The credit (Jul 15 - Sep 9) gives back funds for the Aug 9 - Sep 9 invoice that is open (and possibly unpaid) but MUST be paid.
- The invoice (Jul 15 - Oct 1) ensures that we are collecting funds for the date the change went into effect through the new renewal date.
Now, if we don't expect the Aug 9 - Sep 9 invoice to be paid, there is no need to issue the credit from Jul 15 - Sep 9. But you run into problems if the invoice is paid, or partially paid. So it's just easier to require that existing invoices be paid.
Cody Phillips (Inactive)
added a comment - Assuming we require the current issued invoice to be paid in full (or has been paid in full), what I would expect in the given case of:
Current date: Jul 15
Current renew date: Sep 9
New renew date: Oct 1
Is this:
Credit issued for time not used: Jul 15 - Sep 9
Prorated invoice for Jul 15 - Oct 1
Here's why:
The credit (Jul 15 - Sep 9) gives back funds for the Aug 9 - Sep 9 invoice that is open (and possibly unpaid) but MUST be paid .
The invoice (Jul 15 - Oct 1) ensures that we are collecting funds for the date the change went into effect through the new renewal date.
Now, if we don't expect the Aug 9 - Sep 9 invoice to be paid, there is no need to issue the credit from Jul 15 - Sep 9. But you run into problems if the invoice is paid, or partially paid. So it's just easier to require that existing invoices be paid. After talking with Paul, the issue he describes is the special case of moving a renew date forward ONLY (e.g. From Sep 9 to Oct 1). In this case the prorated calculation is performed correctly (invoice created for Sep 9 through Oct 1), however the date displayed on the invoice line item is current date - new renew. That should be old renew date - new renew date, which is what is used in the calculation itself.
Cody Phillips (Inactive)
added a comment - - edited After talking with Paul, the issue he describes is the special case of moving a renew date forward ONLY (e.g. From Sep 9 to Oct 1). In this case the prorated calculation is performed correctly (invoice created for Sep 9 through Oct 1), however the date displayed on the invoice line item is current date - new renew . That should be old renew date - new renew date , which is what is used in the calculation itself. Renew date changes into the future will now show the line item start date as the old renew date as Cody mentioned above.
Tyson Phillips (Inactive)
added a comment - Renew date changes into the future will now show the line item start date as the old renew date as Cody mentioned above. 
The date range is always:
(today - new renew date)
These dates are also those used to prorate the service.
Considering your suggestion, if the renew date were to decrease, you would end up with a backward date range, e.g. (August 9, 2015 - August 1, 2015), for a negative amount. Is that the desired behavior?