Synchronizes transfers on the client side with transfers on record on the server side.
The transfer synchronization request is applicable for bank accounts only and not for the credit card accounts.
This method can be called when a list of recent server responses is needed whether due to requests submitted by multiple clients or other status changes on the server.
Clients can also choose to perform an explicit synchronization before sending any transfer requests (when TransferFunds, ModifyTransfer or CancelTransfer methods are called). This practice allows clients to be up-to-date and possibly interact with the user before sending any new requests.
If this explicit synchronization request is submitted for the first time to the server, the Token parameter has to be 0. In this case, servers should send all available history, allowing a new client (for example) to know about work done by other clients. If a user's account has never been used with OFX, the server returns no history. The response includes responses more recent than the given token, along with a new token returned by this method.
Unless the synchronization is a refresh request (see below), in all subsequent requests, this has to be the previous value of Token this method returned (i.e., received for this type of synchronization request from the server). This will serve as the user's own endpoint. When the server supplies a response, it supplies a new endpoint (Token) as well. A token needs to be unique only within transfers for the specified account.
If a client connection fails, or a client receives a response, but crashes before updating its records, the client will not be able to save the new endpoint. On the next synchronization request, the server sends the same information (plus any further status changes). If a user switches to a backup file, again the client will use the older endpoint in the synchronization request. If multiple clients are in use, each will send requests based on its own endpoint, so that both clients will obtain complete information from the server.
A brand new client, or a client that lost synchronization, might want to learn about in-progress transfers by submitting a synchronization refresh of the transfer requests (i.e., wants a set of changes, rather than asking the server to send everything it knows). It would almost certainly want to do a synchronization refresh of the recurring transfer models, because these often live for months or years.
A client can request a refresh of current state by calling the SynchronizeTransfers where Token parameter is set to REFRESH (not case sensitive). The response will reflect the current state. For example, if you schedule a transfer and then modify it three times, even if this history would have been available for a regular synchronization, on a synchronization refresh request the servers should only send a single add that reflects the current state.
Please note that the servers will not have infinite history available. If the token in the synchronization request was older than the earliest available history, then the LostSync property value returned is True. This allows clients to alert users that some responses have been lost.
The following properties have to be set when this method is called:
Upon a successful reply, if the response contains a list of bank transfers, then the SyncTransfers will be populated and SyncTransfers event will be fired for each transfer transaction. A single transfer has a single Id, but it can undergo several state changes over its life and thus might have several entries in the token history.