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
          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 ]
          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