|
|
4/18/2017 8:33:08 PM
entitlement and billing startDate are different
|
|
|
4/18/2017 8:03:02 PM
such operations on PENDING subscriptions. See #733
Assuming a null effectiveDate or an effectiveDate > entitlementStartDate and effectiveDate > billingStartDate, the operation will succeed
|
|
|
4/15/2017 12:55:06 AM
change on PENDING subscriptions. See #733
|
4/15/2017 12:54:00 AM
destination test file TestUserApiCancel. See #733
|
4/15/2017 12:52:28 AM
to return latest transition on a given Datime. See #733
Failure to do that menas that the pendingTransition does not necessarily refect correct plan info.
Notes:
1. However, this may lead to an unusual TransitionType (could be CHANGE) (and could cuase issues)
2. Also, code does not include CANCEL event that would also match exactly startDate (this is somewhat arbitrary)
/cc @pierre for review and discussion
|
4/15/2017 12:49:03 AM
(LocalDate -> DateTime). See #733
Because we now have an account reference time computing a LocalDate -> DateTime will use that account reference time and this may lead to weird behavior.
Example (seen in tests):
* Account created on April 14 1:23:35
* Subscription created on April 14 1:23:36
A dryRun operation would provide a LocalDate of April 14, which context would transform into April 14 1:23:35, but this ends up being prior the subscription startDate and leads to weird issues. Note, that correct way to do it with the api is to let user pass null and let system chose correct date.
|
4/14/2017 9:51:46 PM
on PENDING subscription (future billing date). See #733
|
