Configure OdataLink to poll for changes: Difference between revisions

No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 10: Line 10:


Since it's likely only the recent months contain changes, we strongly recommend you use Page By Month for optimal performance.
Since it's likely only the recent months contain changes, we strongly recommend you use Page By Month for optimal performance.
= How the Archive Cut Off Date affects polling =
The archive cut off date takes priority over polling.
When you formally configure your Odata Feed with an archive cut off date of 31 December 2025, you're instructing OdataLink that the data prior to this date is locked and will never change. As such, data prior to this date will ALWAYS be sourced from the archive and OdataLink will NOT poll for changes in those periods. It will only poll for changes in months or years after that date.




Line 16: Line 23:
The sensitivity option is there for those that are likely to change the dates of transactions and moved them to other months.  
The sensitivity option is there for those that are likely to change the dates of transactions and moved them to other months.  


It is easier to illustrate it's use with an example. If a transaction is moved from February to March, OdataLink can poll for changes in February but it is likely that MYOB or Xero would indicate no changes. This is because there are no modified transactions in February (since it is now in March). The sensitivity setting allows OdataLink to establish a wider date range.  
It is easier to illustrate it's use with an example. If a transaction is moved from February to March, OdataLink can poll for changes in February but it is likely that MYOB or Xero would indicate no changes. This is because there are no modified transactions in February (since it is now in March). The sensitivity setting allows OdataLink to establish a wider date range for polling purposes.


When sensitivity is set to +/- 1 month, rather than constrict checking for changes only in February, it will send a call asking if anything changed in January to March. If the answer is yes, it will refresh February. It will do the same for March by checking February to April and so on.
When sensitivity is set to +/- 1 month, rather than constrict checking for changes only in February, it will send a call asking if anything changed in January to March. If the answer is yes, it will refresh February. It will do the same for March by checking February to April and so on. This doesn't mean that January data will appear in February. It just means that if anything changed between January to March, we should refresh February to be on the safe side.


When sensitivity is set to +/- 2 month, it would use December to April when checking for changes in February.
When sensitivity is set to +/- 2 month, it would use December to April when checking for changes in February.
Doing this allows OdataLink to keep the archive up to date when transactions dates are changed.




Line 39: Line 48:


Polling for changes was primarily built to increase performance and reduce the costs Xero decided to charge for their API in December 2025. As such, we prioritised the following endpoints:
Polling for changes was primarily built to increase performance and reduce the costs Xero decided to charge for their API in December 2025. As such, we prioritised the following endpoints:
* [[Xero Accounting Endpoint: Contacts]]
'''Xero Accounting Endpoints'''
* [[Xero Accounting Endpoint: ContactsExpanded]]
* [[Xero Accounting Endpoint: Accounts|Accounts]]
* [[Xero Accounting Endpoint: ContactsExpandedTable]]
* [[Xero Accounting Endpoint: BankTransactions|BankTransactions]]
* [[Xero Accounting Endpoint: Invoices]]
* [[Xero Accounting Endpoint: BankTransactionsExpanded|BankTransactionsExpanded]]
* [[Xero Accounting Endpoint: InvoicesExpanded]]
* [[Xero Accounting Endpoint: Contacts|Contacts]]
* [[Xero Accounting Endpoint: InvoicesExpandedTable]]
* [[Xero Accounting Endpoint: ContactsExpanded|ContactsExpanded]]
* [[Xero Accounting Endpoint: ContactsExpandedTable|ContactsExpandedTable]]
* [[Xero Accounting Endpoint: CreditNotes|CreditNotes]]
* [[Xero Accounting Endpoint: CreditNotesExpanded|CreditNotesExpanded]]
* [[Xero Accounting Endpoint: Invoices|Invoices]]
* [[Xero Accounting Endpoint: InvoicesExpanded|InvoicesExpanded]]
* [[Xero Accounting Endpoint: InvoicesExpandedTable|InvoicesExpandedTable]]
* [[Xero Accounting Endpoint: ManualJournals|ManualJournals]]
* [[Xero Accounting Endpoint: ManualJournalsExpanded|ManualJournalsExpanded]]
* [[Xero Accounting Endpoint: Payments|Payments]]
* [[Xero Accounting Endpoint: PaymentsTable|PaymentsTable]]
* [[Xero Accounting Endpoint: PurchaseOrders|PurchaseOrders]]
* [[Xero Accounting Endpoint: Quotes|Quotes]]


The plan is to have all endpoints support polling in some form or another but prioritising the ones used most.
The plan is to have all endpoints support polling in some form or another but prioritising the ones used most.