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

Invoice line item service renew date may be incorrect after renewal

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.3.2, 3.4.0-b1
    • Component/s: None
    • Labels:
      None

      Description

      When service line items are added, they include the service renew date range from the start date to the renew date,
      e.g. a 1 month term could be:
      (Jan 1, 2014 - Feb 1, 2014)
      i.e.
      (date_added - date_renews)

      When the service renews, however, the start date is determined as the last renew date, or the date added,
      i.e.
      ([date_last_renewed if not null otherwise date_added] - date_renews)

      The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
      e.g.
      Manual Service Invoice (correct):
      (Jan 1, 2014 - Feb 1, 2014)
      Renewed Service Invoice (incorrect - starts in February):
      (Jan 1, 2014 - Mar 1, 2014)

      A similar situation occurs with prorated services:
      e.g. Manual:
      (Jan 27, 2014 - Feb 1, 2014)
      Renewed:
      (Jan 27, 2014 - March 1, 2014)


      Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

      Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
      Created January 1, 2014, renews February 1, 2014
      Renews February 1, 2014 - March 1, 2014
      Renews February 1, 2014 - April 1, 2014
      Renews February 1, 2014 - May 1, 2014
      ...- CORE-1484

        Issue Links

          Activity

          tyson Tyson Phillips (Inactive) created issue -
          tyson Tyson Phillips (Inactive) made changes -
          Field Original Value New Value
          Fix Version/s 3.3.0-b2 [ 10507 ]
          Fix Version/s 3.3.0-b1 [ 10100 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-625 [ CORE-625 ]
          tyson Tyson Phillips (Inactive) made changes -
          Affects Version/s 3.0.0 [ 10000 ]
          Affects Version/s 3.2.2 [ 10505 ]
          tyson Tyson Phillips (Inactive) made changes -
          Description When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...
          When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...
          admin Paul Phillips made changes -
          Fix Version/s 3.3.0 [ 10508 ]
          Fix Version/s 3.3.0-b2 [ 10507 ]
          admin Paul Phillips made changes -
          Fix Version/s 3.4.0 [ 10400 ]
          Fix Version/s 3.3.0 [ 10508 ]
          tyson Tyson Phillips (Inactive) made changes -
          Fix Version/s 3.3.2 [ 10602 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-1484 [ CORE-1484 ]
          tyson Tyson Phillips (Inactive) made changes -
          Description When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...
          When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          -Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...- CORE-1484
          tyson Tyson Phillips (Inactive) made changes -
          Description When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          -Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...- CORE-1484
          When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          -Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.-

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...- CORE-1484
          tyson Tyson Phillips (Inactive) made changes -
          Description When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          -Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.-

          Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:
          Created January 1, 2014, renews February 1, 2014
          Renews February 1, 2014 - March 1, 2014
          Renews February 1, 2014 - April 1, 2014
          Renews February 1, 2014 - May 1, 2014
          ...- CORE-1484
          When service line items are added, they include the service renew date range from the start date to the renew date,
          e.g. a 1 month term could be:
          (Jan 1, 2014 - Feb 1, 2014)
          i.e.
          (date_added - date_renews)

          When the service renews, however, the start date is determined as the last renew date, or the date added,
          i.e.
          ([date_last_renewed if not null otherwise date_added] - date_renews)


          The problem with this is that the first time a service renews, there is no last renew date, and so it uses the date the service was added.
          e.g.
          Manual Service Invoice (correct):
          (Jan 1, 2014 - Feb 1, 2014)
          Renewed Service Invoice (incorrect - starts in February):
          (Jan 1, 2014 - Mar 1, 2014)

          A similar situation occurs with prorated services:
          e.g. Manual:
          (Jan 27, 2014 - Feb 1, 2014)
          Renewed:
          (Jan 27, 2014 - March 1, 2014)


          -----
          -Additionally, and possibly a separate task, the last renew date for a service does not always get updated, which can cause these line item dates to be off by larger margins.-

          -Consider a 1 month service that was created in January 2014, but has never renewed. When the cron runs to catch up, the last renew date is only updated once, which results in:-
          -Created January 1, 2014, renews February 1, 2014-
          -Renews February 1, 2014 - March 1, 2014-
          -Renews February 1, 2014 - April 1, 2014-
          -Renews February 1, 2014 - May 1, 2014-
          ...- CORE-1484
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          This issue may be isolated to the cron renewing services by updating renew dates after the invoice was already created.

          So if the service was added for January 15 -> February 15, it would be renewed for February 15 -> March 15, but the invoice line item on renewal would say January 15 -> February 15 instead of February 15 -> March 15.

          Show
          tyson Tyson Phillips (Inactive) added a comment - This issue may be isolated to the cron renewing services by updating renew dates after the invoice was already created. So if the service was added for January 15 -> February 15, it would be renewed for February 15 -> March 15, but the invoice line item on renewal would say January 15 -> February 15 instead of February 15 -> March 15.
          Hide
          admin Paul Phillips added a comment -

          I believe this issue was introduced in 3.3.0 as I have invoices for services for which the dates were correct when running 3.2, which are now renewing with an incorrect date range. The date range now appears as (service creation date - invoice due date) For example a service created on Nov 9, 2013 renewing quarterly was just invoiced for Nov 9, 2014 renewal for 3 months. The service has a date range of: (Nov 09, 2013 - Nov 09, 2014) however, it should be (Nov 09, 2014 - Feb 09, 2015)

          Show
          admin Paul Phillips added a comment - I believe this issue was introduced in 3.3.0 as I have invoices for services for which the dates were correct when running 3.2, which are now renewing with an incorrect date range. The date range now appears as (service creation date - invoice due date) For example a service created on Nov 9, 2013 renewing quarterly was just invoiced for Nov 9, 2014 renewal for 3 months. The service has a date range of: (Nov 09, 2013 - Nov 09, 2014) however, it should be (Nov 09, 2014 - Feb 09, 2015)
          tyson Tyson Phillips (Inactive) made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-747 [ CORE-747 ]
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          The new renew dates were not used in the line item description because of some refactoring in CORE-747 to remove duplicate code.

          Show
          tyson Tyson Phillips (Inactive) added a comment - The new renew dates were not used in the line item description because of some refactoring in CORE-747 to remove duplicate code.
          tyson Tyson Phillips (Inactive) made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          tyson Tyson Phillips (Inactive) made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                11/Nov/14