Transaction Reset Date, Plan upgrade process doesn't match previous discussion

4 posts / 0 new
Last post
Transaction Reset Date, Plan upgrade process doesn't match previous discussion

We lost service today because we hit our transaction limit. This happened because our transaction reset date was changed when we upgraded plans. Per this thread:

our transaction reset date was October 29th.

According to this thread:

Upgrading our plan would not change our renewal date.

I received an email that we hit 90% of our allotment on October 29th, but since I "knew" our reset date was the 29th, I didn't take any action. I now know that the reset date was added to the my plan page, but since I don't look at that every day, I didn't know at the time.

I'm more than a little frustrated right now with the forum information not matching reality. It's been pretty clear to me that you weren't really ready for the rollout of these new plans.

Further, I certainly didn't have time to make adjustments to our software to minimize transaction usage. The annoucement was abrupt and there was no way I could allocate time to make the needed changes. The code I wrote was modeled after your api examples, which by my estimation, maximize transaction usage by creating a map first, then adding points, routes etc and re-zooming the map afterward to fit. Again, just another frustrating part of my experience here with a previously great and generous offering with the unlimited free open api.

I understand the need to charge for this offering, but I needed more time for transaction optimization - six months minimum. I also needed mature plan management system which just isn't there yet. I also need clear documentation on what constitues a transaction. The routing and geocoding are pretty obvious. What is less obvious is what constitues a map transaction. We have the very vague "40% of the map changes" but there is no way through the api for us to know when a transaciton is generated. I'm fairly certain we are generating 10+ transactions per map load right now but I just don't know for sure since there's no way to tie a map session to the number of transactions generated.


Sorry, there was a
Sorry, there was a misunderstanding internally. The reset date is changed each time a new plan is purchased. The purchase date of the most recent plan is the reset date each month. If a plan is purchased on the 31st of a month then the reset date is the last day of the month carried on to the next month. So if the package is purchased on October 31 then the next reset date will be November 30. The reset date will remain the 30th until February when the reset date will become the 28th (or 29th).   Sorry for the miscommunication.

It would be nice to be able

It would be nice to be able to "re-buy" the current transaction count to change the reset date rather than having to change the plan then. We were only a couple of days away from our plan reset date, but had to change our plan to get more transactions.

The model you have right now is a confusing hybrid between buying a certain number of transactions and a monthly service plan. I wish you would either allow us to buy a non-expiring number of transactions or allow us to have a true monthly plan with a fixed statement date.

Hi John,
Hi John,   A new addition displaying the reset date is available in the Developer Network on the My Plan page.   Enterprise Edition users are not technically limited to a number of transactions. If the key accumulates more transactions than purchased then the key continues to work while a new price is negotiated with an account manager. Details can be discussed by using the Contact Us link in the upper right.   Otherwise, the number of transactions per month purchased is a hard limit and anything beyond that month returns errors. Sorry for the confusion with the new system but we are working hard to clear up all questions and make it easier for everyone to use and understand.   Thanks for your understanding and feedback.