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

Invoice service coverage dates may be incorrect

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.3.2
    • Fix Version/s: 4.3.2
    • Component/s: None
    • Labels:
      None

      Description

      This relates to CORE-2794

      The service coverage dates always appear as (current date - (current date + service term)). This is problematic if for example, the invoice cron hasn't run in a while and then plays catch up.

      As an example, a service that renews daily for which the cron hasn't run for about a week, will when the cron runs generate around 7 invoices for that service. All of the invoices show the same date coverage in the invoice line item, e.g. "VPS 1 - test.invoicedelivery.com (Aug 23, 2018 - Aug 24, 2018)" even though the first invoice should cover say "Aug 15, 2018 - Aug 16, 2018", then 16-17, 17-18, 18-19, etc.

      This gives the impression that the invoices are duplicates and does not accurately represent the time period the invoice covers.

      Instead, the dates covered should be:

      (service renew date - (service renew date + service term))

      Then, the renew date is bumped forward, and the next invoice is generated similarly.

        Issue Links

          Activity

          admin Paul Phillips created issue -
          admin Paul Phillips made changes -
          Field Original Value New Value
          Description This relates to CORE-2794

          The service coverage dates always appear as (current date - (current date + service term)). This is problematic if for example, the invoice cron hasn't run in a while and then plays catch up.

          As an example, a service that renews daily for which the cron hasn't run for about a week, will when the cron runs generate around 7 invoices for that service. All of the invoices show the same date coverage in the invoice line item, e.g. "VPS 1 - test.invoicedelivery.com (Aug 23, 2018 - Aug 24, 2018)" even though the first invoice should cover say "Aug 15, 2018 - Aug 16, 2018", then 16-17, 18-19, etc.

          This gives the impression that the invoices are duplicates and does not accurately represent the time period the invoice covers.

          Instead, the dates covered should be:

          (service renew date - (service renew date + service term))

          Then, the renew date is bumped forward, and the next invoice is generated similarly.
          This relates to CORE-2794

          The service coverage dates always appear as (current date - (current date + service term)). This is problematic if for example, the invoice cron hasn't run in a while and then plays catch up.

          As an example, a service that renews daily for which the cron hasn't run for about a week, will when the cron runs generate around 7 invoices for that service. All of the invoices show the same date coverage in the invoice line item, e.g. "VPS 1 - test.invoicedelivery.com (Aug 23, 2018 - Aug 24, 2018)" even though the first invoice should cover say "Aug 15, 2018 - Aug 16, 2018", then 16-17, 17-18, 18-19, etc.

          This gives the impression that the invoices are duplicates and does not accurately represent the time period the invoice covers.

          Instead, the dates covered should be:

          (service renew date - (service renew date + service term))

          Then, the renew date is bumped forward, and the next invoice is generated similarly.
          tyson Tyson Phillips (Inactive) made changes -
          Sprint 4.4.0 Sprint 3 [ 59 ]
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue Discovered while testing CORE-2794 [ CORE-2794 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-2212 [ CORE-2212 ]
          Automated transition triggered when Tyson Phillips (Inactive) created a branch in Stash -
          Status Open [ 1 ] In Progress [ 3 ]
          Automated transition triggered when Tyson Phillips (Inactive) created pull request #518 in Stash -
          Status In Progress [ 3 ] In Review [ 5 ]
          Resolution Fixed [ 1 ]
          tyson Tyson Phillips (Inactive) made changes -
          Remaining Estimate 0 minutes [ 0 ]
          Time Spent 2 hours, 3 minutes [ 7380 ]
          Worklog Id 11442 [ 11442 ]
          Automated transition triggered when Tyson Phillips (Inactive) merged pull request #518 in Stash -
          Status In Review [ 5 ] Closed [ 6 ]
          tyson Tyson Phillips (Inactive) made changes -
          Link This issue relates to CORE-2829 [ CORE-2829 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                27/Aug/18

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours, 3 minutes
                2h 3m

                  Agile