Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-1746

Changing the renew date results in a prorated invoice with the wrong start date range

    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

        admin Paul Phillips created issue -
        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        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?

        Show
        tyson Tyson Phillips (Inactive) added a comment - 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?
        Hide
        admin 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.

        Show
        admin 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.
        Hide
        cody 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:

        1. 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.
        2. 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.

        Show
        cody 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.
        Hide
        cody 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.

        Show
        cody 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.
        Hide
        tyson 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.

        Show
        tyson 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.
        tyson Tyson Phillips (Inactive) made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        tyson Tyson Phillips (Inactive) made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            tyson Tyson Phillips (Inactive)
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              4/Aug/15