MYOB API Running Slow Today

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

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 kjm,

We understand that not having timely updates on our status page can be frustrating and lead to unnecessary investigations on your end.

We do share information and updates through our status hub page, which is our main channel for communicating such issues to both our internal team members and customers. You can subscribe to receive notifications by clicking the subscribe button on the status hub page to stay updated on any MYOB incidents.

Cheers,

MYOB

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.

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

same. It appears to be up now. I undertsnd down time is part of online systems but I do wish MYOB would be a little faster in acknowledging there is a problem. My users are coming to me saying there is a problem. As I can not find anything on MYOB status.myob.com to indicate that there is aproblem I go ahead and start an investigation. I end up wasting time, energy and effort when I strongly suspect it is a MYOB outage but I have nothing to send to my users to confirm this. 

Like I said, outages are aprt of online life. Everyone understands that and accepts it. If you could be a little more proactive and let us know that "you know there is an issue and it is being looked into" then I can send that to my users and everyone settles down. You might also find that you would receive less abuse.

Can you give any reason why this should not a SOP? Princess_R 

Unsure how clearing out a local cache would have any impact on a third-party API call?  This is clearly in relation to the performance of the API which is at best, terrible.  Need some answers on why certain calls are so slow or timing out.  One of the main issues we have noticed is that any query that involves text search of a field such as a customer PO on an Order GetRange call has terrible performance.  Perhaps an index issue with the MYOB datastore? 

It does appear to have improved for us now - no errors in the last hour - from about 2:30pm AEST

Hi everyone, 

Earlier today, we had a login disruption incident that has since been resolved by our dedicated team. To ensure optimal performance, please clear your AccountRight cache or your browser cache.

If you are still experiencing timeouts, please reach out to our support team directly. This will help us collect information on how many users are affected and provide further assistance. Sorry for the inconvenience caused, and thank you for your patience and understanding.

Cheers,

Princess

Still having constant communication issues (Gateway Timeouts) - MYOB where are you?