Questions about BudgetOrderService

[Jim McCabe]

The v13 budget API is being replaced by the BudgetOrderService - however the documentation leaves a lot of questions about BudgetOrder.  I am looking for clarification on these questions:

- startDateTime "cannot be in the past", but what if my local server is a few seconds or minutes behind Google's servers? Will it be rejected if the startDateTime is a few minutes in the recent past?

- Both date fields are of type String, with no specification as to what the API expects. It says the times must be before "20361231 235959 America/Los_Angeles", and I'm assuming that is the expected format for the date, but it begs the question about if other time zones are also allowed? This API Forum thread seems to suggest that only Los Angeles is allowed - is that true?

- In v13 we create a v13.reseller.Budget and set the MDO "order ID". In v201109_1 / v201206 BudgetOrder, there is no attribute for the order ID. Instead, we have the "billing account ID". Is it correct to pass the customer ID of the account which owns the MDO order ID?  For example, we have a top-level MCC and sub-MCCs.  I believe the order ID is associated with our top-level MCC, should we therefore pass the customer ID (nnn-nnn-nnnn) of the top level MCC in the BudgetOrder?

Thanks for the help,

Jim

[Jim McCabe]

I am reposting some answers from a member of the AdWords API team, sent to me in email:

- Regarding startTime, it may be rejected if the time is in the past, so they recommend passing a time a few minutes in the future.

- The date syntax is "yyyyMMdd HHmmss ZZ" as specified by the Joda ISODateTimeFormat class following the ISO-8601 standard.  Also a date time with no timezone can be specified, in which case it will take the timezone of the effective account.

[Jim McCabe]

Still awaiting info about the "billing account ID".

[Kevin Winter]

Hi Jim,

  I'm pretty sure you need to use the Id from a BillingAccount returned by BOS.getBillingAccounts.

- Kevin Winter

AdWords API Team

[Jim McCabe]

Hi Kevin -

Actually I have good reason to believe that we should pass the same "order ID" that we traditionally passed in v13.

a) Yesterday I did some testing with new production accounts and was successful when I passed our same old order ID in that field.

b) I also filed a request with the AdWords API support email, as well as our company contact @ Google, and both suggested that we send the order ID.

Since it worked I am fine moving forward with that.  It was just confusing since the name makes it seem like it needs an account ID.

Jim

[Kevin Winter]

Hi Jim,

  I agree - that is very confusing.  When you run getBillingAccounts - do you get a BillingAccount entry for every Order ID?  I'm beginning to suspect that BillingAccount is the new Order (I apologize that I'm not as familiar with the BudgetOrderService as I should be).

- Kevin Winter

AdWords API Team

[veseo]

Is the BudgerOrderService a complete replacement for v13s' AccountService->addBudget method? As I understand it, billingAccountId equals v13's orderId and we pass the clientCustomerId parameter in the header to specify which client's budgets we are manipulating, is that correct?

Also, how can we get "whitelisted", are all resellers from v13 automatically whitelisted or we need to contact someone to be granted access to that service? If not, would we be able to manipulate budgets via v13 after 20 August 2012 as, according to your Sunset dates v13 AccountService will be sunset?

[Kevin Winter]

Hi,

  Yes, the BudgetOrderService is intended to be a completely replacement.  Yes, billingAccountId = orderId (we will be updating the docs).  Yes, provide a clientCustomerId to change which client's budgets you affect.

Regarding the whitelist, anyone who had access to the budget functionality in v13 should also have access to BudgetOrderService.  Speak with your CSR if you have any concerns about this.\

- Kevin Winter

AdWords API Team

[Alexander Nitschke]

I can't really confirm the part about the date syntax. It still works only for me with the Los Angeles timezone. Other timezones (or not specified timezone) lead to exceptions (as I wrote in another post - I got directed to this thread but must say that there's no helpful answer to this problem here, other than stating how it SHOULD be, which confirms this as a bug for me).

Alexander

[Jim McCabe]

Thanks Alexander.  To be cautious we just render the dates using the America/Los_Angeles time zone since we know for certain that it will be supported.

[Allen]

I tried to post with no time zone. And ended up with 17 hours difference between what I posted and what was returned, and that was to an account in my same timezone. +10:00.  So it is not taking the effective account timezone that I can see. And 17 hours is a lot like the difference between us and California.