[CORE-1390] Invoice line item service renew date may be incorrect after renewal - Blesta

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

relates to

CORE-747 Add service price override option

Closed

CORE-1484 A service's last renew date does not get updated on renewal

Closed

Activity

Ascending order - Click to sort in descending order

Tyson Phillips (Inactive) created issue - 26/Aug/14 7:42 PM

Tyson Phillips (Inactive) made changes - 26/Aug/14 7:48 PM

Field	Original Value	New Value
Fix Version/s		3.3.0-b2 [ 10507 ]
Fix Version/s	3.3.0-b1 [ 10100 ]

Tyson Phillips (Inactive) made changes - 26/Aug/14 7:49 PM

Link

This issue relates to CORE-625 [ CORE-625 ]

Tyson Phillips (Inactive) made changes - 26/Aug/14 7:50 PM

Affects Version/s		3.0.0 [ 10000 ]
Affects Version/s	3.2.2 [ 10505 ]

Tyson Phillips (Inactive) made changes - 26/Aug/14 7:52 PM

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

Paul Phillips made changes - 15/Sep/14 12:11 PM

Fix Version/s		3.3.0 [ 10508 ]
Fix Version/s	3.3.0-b2 [ 10507 ]

Paul Phillips made changes - 24/Sep/14 4:48 PM

Fix Version/s		3.4.0 [ 10400 ]
Fix Version/s	3.3.0 [ 10508 ]

Tyson Phillips (Inactive) made changes - 17/Oct/14 1:59 PM

Fix Version/s

3.3.2 [ 10602 ]

Tyson Phillips (Inactive) made changes - 17/Oct/14 3:46 PM

Link

This issue relates to ~~CORE-1484~~ [ ~~CORE-1484~~ ]

Tyson Phillips (Inactive) made changes - 17/Oct/14 4:03 PM

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 Phillips (Inactive) made changes - 17/Oct/14 4:04 PM

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 Phillips (Inactive) made changes - 17/Oct/14 4:04 PM

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

Permalink

Tyson Phillips (Inactive) added a comment - 17/Oct/14 4:43 PM

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 Phillips (Inactive) added a comment - 17/Oct/14 4:43 PM 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

Permalink

Paul Phillips added a comment - 20/Oct/14 4:30 PM

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

Paul Phillips added a comment - 20/Oct/14 4:30 PM 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 Phillips (Inactive) made changes - 21/Oct/14 6:36 PM

Status

Open [ 1 ]

In Progress [ 3 ]

Tyson Phillips (Inactive) made changes - 22/Oct/14 12:58 PM

Link

This issue relates to ~~CORE-747~~ [ ~~CORE-747~~ ]

Hide

Permalink

Tyson Phillips (Inactive) added a comment - 22/Oct/14 12:59 PM

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 Phillips (Inactive) added a comment - 22/Oct/14 12:59 PM The new renew dates were not used in the line item description because of some refactoring in CORE-747 to remove duplicate code.

Tyson Phillips (Inactive) made changes - 22/Oct/14 12:59 PM

Status	In Progress [ 3 ]	Resolved [ 5 ]
Resolution		Fixed [ 1 ]

Tyson Phillips (Inactive) made changes - 06/Nov/14 7:26 PM

Status

Resolved [ 5 ]

Closed [ 6 ]

People

Assignee:

Tyson Phillips (Inactive)

Reporter:

Tyson Phillips (Inactive)

Votes:

0 Vote for this issue

Watchers:

2 Start watching this issue

Dates

Created:

26/Aug/14 7:42 PM

Updated:

06/Nov/14 7:26 PM

Resolved:

22/Oct/14 12:59 PM

Fix Release Date:

11/Nov/14

Agile

View on Board