GetCustomersModifiedSince

I've been experimenting with GetCustomersModifiedSince method on the API.
http://accountingapi.com/manual_methods_GetCustomersModifiedSince.asp

It looks like it could save a bit of time running the sync process I've developed. I would be keen to understand the behaviour of the ModDate paramater. What timezone does the date operate in - does it get adjusted for daylight saving?

I've been using the date format yyyy-MM-d'T'HH:mm:ss (as described in the SimpleDateFormat class http://docs.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html) and passing in a UTC timestamp and it appears the method only includes contacts that have been updated recently but not at a hour or minute? i.e. contacts that I've updated about and hour before the ModDate parameter I'm passing in are still being included.

Also is there a similar method for getting suppliers available?

hi,

we just emailed the API team about this function. We use it a lot and it does NOT use the time element, only the date hence specifying a time will not make any difference.

the problem we have is if a single customer has been updated, the array pointer of zero does not work and we have to have a special case code to deal with a single entry. it maybe a problem our end but we have asked anyway as having two chunks of code to split out data is a pain to maintain.

cheers

Bill

Hi Bill,

Only working with the date part makes sense - only need to confirm what happens around the hour at either end of the day. We haven't had any trouble with one item vs. multiple items returned from this method - although we using our own in-house SOAP "library".

hi,

Interesting.. Our issue is this, if we use "modifiedsince" in PHP and only have more than one record returned then this is the result of a print array (truncated) :-

Array
(
[GetCustomersModifiedSinceResult] => Array
(
[Customer] => Array
(
[0] => Array
(
[CustomerID] =>

The [0] rightly references the first array as zero, the next customer returns [1] and so on..

if it is a single customer returned then the [0] bit is missing completely, consequently code that looks for an index in [ ] fails to return that customer..

the only solution, a messy one, so far is to detect if the array is the length of a single record then have duplicate code that misses out the index field and therefore returns the data.

I would be interested to know if you have any insight into this issue.

The API team suggested making sure the result is cast as an array, this makes no difference though. (as it of course has all the hallmarks of an array anyway, multiple elements).

cheers

bill

Hi Bill, I guess this a problem with the way the XML is being converted into a PHP object (seen similar problems before in other parsers); because the PHP parser is only seeing a single element it just creating it as an object rather than an array of objects.