Why so many API errors ?
Why are there so many API errors between 10 pm and 2 am every single night? This is from the logs that update Products and Pricing to AccountRight. Apart from the many errors 500 and 504 it's oft...
Forum Discussion
Hi Hannah_B
Whatever changes were waiting Friday night as indicated in a forum post this week, the issues of the 500/504 errors has been resolved.
We have gone from 50+ errors during the update of 5500 items every night for the past 10-14 days to none since Saturday. The only errors reported are 409's which is due to a known API BUG.
Hi AndrewStephen I logged all my errors - the gateway timeout happened when eftpos were clearing - but I don't refresh as often as you - I did once at the beginning refresh every 10 minutes but found no advantage in outcome for big resource gobbling. I haven't seen a timeout for ages. What bug is 409's - do you use the MYOB SDK or have you written your own from the ground up. I do not use their SDK - I started from scratch. Regards
Hi The_Doc
The 500/504 errors have been an issue as mentioned for the past couple of weeks when updating the ItemPriceMatrix between the hours of 11pm and 4am. My first post shows the error log from our API application. When updating the prices, we need to GET all 5500+ items
The 409 error is due to a duplicate key for the ItemPriceMatrix and when we do a GET the incorrect RowVersion is returned preventing the prices from being updated.
We see different issues depending on how we update prices.- 3rd Party App TransPost doesn't allow us to update prices at all. It causes all items to return an error 409
- MYOB File Import doesn't return any errors. If an item is affected by the duplicate key and you are importing new qty and/or price breaks it will import the prices as 0.00 (qty breaks are ok) or if there are existing prices they just don't update.
The API application we use (written in python) is the most reliable. We know exactly what was and wasn't updated and doesn't break the pricing for ALL items like TransPost or set prices to zero like the AccountRight file import.
If we see 409 errors in the logs, all we can do is update the prices manually and then ask support to run the "Item Price Matrix" script. Getting the script run is the issue. Forums post takes days to get the script run and live chat or phone you are on hold for hours sometimes. Please as we run the price updates at night its then 24 hours before the next update is run and we have prices between eCommerce and AccountRight that are out of sync.
This is the response we got from the API team on the issue
We had a discussion about this earlier in the morning.The issue is with our devs and have advised the issue is in two parts.
- The item price matrix has duplicate data "stuck" in the table
- The API is displaying the "stuck" incorrect data
We will have to wait for a couple updates and hopefully have something implemented to be permanent across the board.
Until then we only have the script that can fix any edits that come with this problem.What I don't understand is why there is NO importance to address the issue.
It has the potential, especially when using the AccountRight File Import to load a $0.00 price or not update a price at all, therefore, affecting a customer's business.- Hi @ AndrewStephen Interesting but I think the only solution is to write your own API access codes. I started to use the MYOB SDK in VB.Net & BV.Net (looked at Python) - but proficient in it - can read it. 20 years plus in VB and VBA MS Access - everyone kept saying - can't use VBA MSAccess - so I ignored. All my code in MSAcces VBA - and the reason - MSAccess comes with all the dbase capabilities that other languages don't pack. I am in the process of re-writing it all in VC.NET (but not priority as other projects on the table). Yes - and I have found a few bugs in the API that just takes a lot of grunt for the api developers to accept. Some are major - some minor. A major is you cannot post (I haven't tested whether they have fixed) - but you couldn't post an item price that calculated greater than EXACTLY 2 decimal places - it errored - and rejected. Had to build code that converted everything to a clean 2 decimal price - I haven't revisited as it just works faultlessly my work around. Then came the biggey - average price was being stuffed in the API calculation - and my updates were feeding new prices to the web 80% below cost - and further whenever an order was lodged for a product on the web in MYOB - and items were receipted in MYOB without a price - the API killed the average price - it went to zero or negative. That was fixed in 2021.6 (that got a priority). However, what the API guys have said aint their problem - and I posted to the forum - and has not been replied to is a major design fault. If you have an inventory item "XXXX" with QOH = 10 and current value = $100 then average price will be $10. I use the average price as a perpetual update to a web cart. However, if and item is ordered - say 10 of "XXXX" from supplier - this will be reflected in the inventory "Ordered" column. Now if the warehouse receives these 10 items (packing slip only) - and receipts this order in MYOB without a price. In MYOB for item "XXXX" you now have a QOH of 20 but the current value remains at $100 and hence the new average price = $5 and my system would now upload this price to the web for this item. That is a major clusterF!@!@@## and MYOB have yet to put up their hands on this silly feature. However, until 2021.6 update any receipted item caused the average price to go to zero or less - and luckily my system had a built in switched that turned this item off and it wasn't available. However the update 2021.6 means I now have a major problem. And the fix is to build a lookup table for items that if the average price alters downwards by greater than 10% or up by 100% - do not update the price. (yet to build). However, as per your suggestion - when we get an error of "Notsufficientquantity" - it happened majorly this week - because the staff ran some manual orders and suddenly plummeted a web items quantity (in reality) to zero - with major orders coming through for the item (by coincidence) - and these crashed. But a built in switch (which says if quantity from MYOB = 0 or less turnoff item) - this kicked in - the item was turned off - but orders existed for the product - and my code just said WTF!!!! Hmm - I convinced the client to let me add code as per your suggestion - if "Notsufficientquantity" occurs - create inventory adjustment 5 items ) or a purchase - and rerun order from web - if accepted send email to client of adjustment. The Doc
