Details
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
Field | Original Value | New Value |
---|---|---|
Fix Version/s | 3.3.0-b2 [ 10507 ] | |
Fix Version/s | 3.3.0-b1 [ 10100 ] |
Link | This issue relates to CORE-625 [ CORE-625 ] |
Affects Version/s | 3.0.0 [ 10000 ] | |
Affects Version/s | 3.2.2 [ 10505 ] |
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 ... |
Fix Version/s | 3.3.0 [ 10508 ] | |
Fix Version/s | 3.3.0-b2 [ 10507 ] |
Fix Version/s | 3.4.0 [ 10400 ] | |
Fix Version/s | 3.3.0 [ 10508 ] |
Fix Version/s | 3.3.2 [ 10602 ] |
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 ...- |
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 ...- |
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- ...- |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |