MYOB API Running Slow Today
Is anyone else experiencing this? Is it related to the 2FA change that went out overnight?
Forum Discussion
It does appear to have improved for us now - no errors in the last hour - from about 2:30pm AEST
Yep - really annoying - something that takes 11 mins - downloading of BackOrder invoices - took 46 mins - yes there are error loops to catch but I have had to broaden these in the last month trying to resolve appalling download times for BOrder invoices - grr .....
However, the reason I posted was a very annoying thing that I am not sure how to fix - if I post an invoice or a BackOrder - something that 'does occur' but today it has happened too many times - [ and yes I know if you turn on - 'warn if duplicate invoice numbers' - this will error your post so I turn it off ] - but when MYOB has another one of its 'Gateway timeouts' - an invoice can actually get through and be posted successfully but we still get a 'gateway error' - so my code says - 'ok try again to post' and you get a double up.
Apart from turning on 'duplicate invoice number warning' - anyone know a way to PREVENTING'
I am doing a mind exercise at the moment trying to consider so coding to check this??
The Doc
Ah Doc, we meet again. I would be great if MYOB provided an idempotency key feature for transactional inserts. Out of interest I find an average 1.5% failure rate, whereby 50% of time an invoice is 'silently' inserted, 50% not. To get around it, I track first send time and confirmation time. If i come around again in the processing queue to find an invoice to be inserted already has a first send time (but no confirmation time,) I search for the invoice in MYOB by my unique key stored in the PO number field. If found, I link to the invoice, if not found I try to reinsert. Seems to work well. I know the PO number won't be able to be commandered like this for everyone but another field might work.
Hi Steve_PP
Thanks for the input - food for thought - can't say I have a figure for fail but it 'seems' that it is easier to assume it hasn't been inserted and go around again as my invoices are quite complex and I don't store a backup format of the invoice to be able to run again.
Not sure how I am going to handle it, but it is good sleep material or running fodder - since posting my invoice numbers are unique and should not be duplicated - but having said that I can download item invoices, but this just adds another big payload to just check whether invoice numbers are duplicated.
At present downloading Sales Orders (back orders) is a lumpy, problematic and prone to a lot of timeouts and is under investigation by MYOB API - so doing this with actual invoices to just get their numbers gives me chills - but I may not have any alternative - let me look at your suggestion and see if it will work.
Thanks
If not using invoice numbers, which is optional, we check for duplicate invoices by comparing customer and sale data including customers number if supplied, JournalMemo if supplied, ShipTo Address if supplied and CurrencyCode if supplied. TransPost will not import a sale if it matches exactly on all the criteria. A similar test is applied to other transaction types. In the latest version the same test is reapplied, after a pause, when retrying.
The problem is working out just how long the pause has to be for this to be reliable. Today it seesm to have needed to be rather long.
