The_Doc
Ultimate Cover User
Joined 15 years ago
User Profile
User Widgets
Contributions
Service Invoices Downloading doubling
Hi Folks Thought I would post as a head's up until I get an answer from API support. A client posted a query that a Job Costing package was giving errors on some jobs but not all. I wrote the package in MS Access in about 2013 for AccountRight 19.16 with ODBC - then 2016 ( or around there) - local file - then upgraded it to an online file. Most, if not all faults have long been ironed out and it works and I hear very little from them. Except mid Sept - suddenly I am getting a double up in $ figures on some invoices and some jobs. Whilst I ALWAYS work from the frontend back and never assume there isn't an odd code bug ( 99.9%) are removed. I am suddenly getting a double up in service invoices downloaded - I use page=1000. The download takes 2 pages - and there is a doubling up of some invoices - the OData extract is doubling up - grrr I captured to json page downloads and looked for a doubled up invoice and it was on both pages. UID for the record were identical so it is the same entry but grabbed twice. Awaiting MYOB's API support reply. - you may well ask why I haven't turned on a primary key ( no duplicates) - because sometimes duplicate invoices do exist for a reason. However, I do not capture UID - but I need to spin up a quick solution whilst MYOB ponder this problem. I will make this a primary (no duplicate key) and loop to the next entry so we can get around this apparent problem. Just giving a heads up to check folks. The DocRe: 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. ThanksRe: MYOB API Running Slow Today
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 DocRe: How to handle deleted invoices through the API
Hi dkarzon-pinch Have a look at the pointer from Mike_James - however, I have developed an app for a client that has now taken over backorders in their MYOB system - and invoices get added and deleted all the time especially SOrders. And I also delete them from my app. Each invoice has a URI - as does each SO - however, in my initial build of my app I struck this problem and built a copy in my app of all invoices in myob - and cross checked this everytime I updated - and produced an error code if an invoice had vanished - I think this is your simplest way - invoice id are not unique enough but uri are and are only accessible via the API. My system works ( actually if I get a duplication of an invoice/SO number it causes a problem but that is by design - not as a fault) - but for the MYOB API to delete an invoice or SO it is very easy - it just needs the uri - which for duplicate invoice numbers or SOs are unique. Hope this helps but it is a relatively easy solution to code. The DocRe: Update on 3rd Party App error connecting to MYOB AccountRight.
Hi UmeshP What problems arre still having - are you using the MYOB SDK in VB.NEt or VC#.NET. I posted some info and have been in constant comms with Tana - and I believe, as she has agreed, that the browser type was a red herring - i.e. MYOB just didn't know the problem, or understand it. I am mainly a MS Access database user - and developed ( as all MS Access developers do) our own code dispensing with the MYOB SDK. However, I am also a developer of apps ( which doesn't connect to MYOB) and I write in VB.Net and Vc#.Net. I dug out the old VB.NET code MYOB produced in 2013 to get new developers to MYOB APIs a leg-up on access to the API - i.e. it made it easy to 'get going' - but that utility is no longer available. I found an old copy dated 2013 on my server and actually got it going without any more that 2 lines of updated code. I couldn't find the VC#.Net version but coding is very similar. Steve_PP highlighted the VC#.Net solution. The summary to all of the above is that "The browser type didn't matter" and I suspect it never will - and I have no intention of paying the AntView2 fee for the wrapper version for MS Access. So if you are still having problem I suspect this is not because of MYOB ( not that I am letting them off the hook - they made a mess of the changes) - what I am saying the changes that did happen ( that MYOB didn't understand) - were actually relatively minor and simple code changes ( in the end) got us back on line. The future proofing is - knowing that MYOB drops bombshells without knowing their effect - aint that a developer's lot. The DocRe: JobRegister queries
Hi MarshallArts I work differently to you with Endpoints - why - because I don't use the MYOB SDK where all the data is extracted via Abstract Methods - you get to see whatever MYOB decides. I write my own extractions - so I use Endpoints to get me a page of JSON data - then I decide whether the info I need is in that endpoint - payroll is a good example - there is no payroll endpoint that will give you all payroll data - but mix and match different endpoint including GeneralLedger and it all comes together. Here is an extract of a JobRegister endpoint - but you would need a copy of theJobRegister from before the suspected change. Then you could compare them. You need to do a bit of Sherlock Holmesing to work out what has changed then work backwards into the SDK to see where it has changed. Sorry, I can't be more helpful - but the way I extract data from endpoints is coding more intensive but I remain fully in control of the data I need. The DocRe: Developer Communication - Issues Authenticating 3rd Party access to MYOB customer’s ledgers.
Hi Mike_James Yep have to agree with you both - a dismal mess by MYOB on the par with CrowdStrikes mess. I think @MikeJames is onto something regarding a 3rd party IAM taking over MYOB's security tokens - the addition of the prefix "ory...... to the codes and tokens seems to be the beginning of this mess. Like @Mike_James I am not a primary .Net user for access to MYOB's API so fixes from the API forum (mostly .Net based) aren't useful to us per se, however, since this mess rolled over us I have brought up to speed the old 2010/2013 VB.NET API SDK MYOB utility - updated and got it working so that I can now keep abreast of MS Access & VB.Net changes. However, in the end as @Julia alludes to the browser change was a red herring and in fact, in my opinion, MYOB darting up the wrong tributary for the source of the problem - it was the format of the returned payload that had changed AND the token format because it was either being created by a 3rd party IAM www.ory.sh or the change wasn't the browser but the whole internal token producing code - we will never know. The end result was simply us developers were treated as 2nd rate citizens and the changes were dumped on us without out due process, consideration or thought which suggests something deep within the bowels of MYOB went wrong and some collective rear-ends need re-assignment. See my separate post yesterday but in the end the fixes to MS Access code and VB/VC#.Net codes was simple and likely would have been worked out quickly by the collective brainpool that this forum provides. The failure was "WE WERE JUST NOT TOLD" and then lead on a wild goose chase regarding browser type - sure this might ultimately lead to some more adjusting of our code but it was NOT the critical change that brought the camel down. Wake up MYOB - we developers are a critical mass and such disasters do you a lot of damage. The DocRe: JobRegister queries
Hi MarshallArts I cannot directly answer this as I don't use the SDK to access their endpoints - for the reason that you are at their mercy to how the code works for accessing endpoints. I have a client using jobs, sub jobs etc - and I can have a look at a page extracted from the endpoint as post it to you - it should then give you perhaps a bit more info about your query. The other thing you can do - simply code up a simple form in VB.NET with the jobsregister endpoint to see the json payload you get back - it should help you further. Re my client - I may not extract the data to the depth you do from the jobs register but my client hasn't had any problem - and jobs are extremely important in my package. The DocMYOB API access crash - the fixes were simple.
Hi Folks I will try and keep this succinct - though the evolution of the problem that started with MYOB's back room server/token coders was anything but succinct. The fixes in the end turned out to be extra-ordinarily simple - easy in hindsight - I have just posted a big email to Tana in MYOB API Analyst - who asked to be kept update on any fixes I found. All my code to my clients uses MS Access 2019 - not 365 - and it "just works" and has since I built it in 2012 - in retrospective contemplation it was messy code but it worked and the adage "don't fix it if it aint broken" - kept we away from it. MYOB broke it the night of 7 Aug 24 - I temp got back online 12 -14 Aug and went offline until 26th Aug and had fixed all my clients by 29th. If anyone disagrees please say so - what I am trying to do is post a fix for both MS Access 2019 ( not 365 - which has an Edge Browser) and VB.NET VS 2022 MYOB SDK API utility that I got going lastnight. The Access fix was my own by trial and error the VB.NET fix was directly from a post by Steve_PP, though I modified Steve_PP fix re the extractString as the existing MYOB code worked with a slight mod to the parameters passed on the call. See below - the fixes are so simple. As I have outlined to Tana I think the single biggest problem was not advising us developers on the night of 7 August when it all went south and really went further south the following Wednesday when MYOB rolled out a fix to fix a fix ( as I am told - the exact details I have no idea as this was 3rd hand). The problem from my perspective - which then enabled the simple fixes below were My summary may have errors but I think the general gist is accurate: MYOB moderator I would love you to fill us in MYOB rolled out updated refresh_tokens the night of 7 August - these had changed in type, scope, length, look and format and not strangely our ExtractToken methods failed - refresh didn't work so we went offline. At this stage I just thought it was an MYOB token/Server blip and it would right itself before morning ( 2 weeks before my program had acted strangely - it couldn't get a refresh, access_token but by extending the attempts to 5 from 1-2 it fixed the problem - I suspect MYOB was already fiddling Monday morning 12th I noticed that if I did a browser open GET call using https://secure.myob.com/oauth2/account/authorize?client_id=35p................................sx72cft&redirect_uri=http://desktop&response_type=code&scope=CompanyFile I got back a legit code that was still in the format I was use to - however, I no longer got a json payload and always got an error page and the source code for the page no longer contained the embedded code ( this was the 1st big change) - I kept telling Tana ( who was confused over just this aspect) - that the returned payload had changed. I manually extracted the access_code - posted a POST to get legit (still accesstoken) the refresh_token didn't work. I was temporarily back online - but then MYOB rolled out the fix of all fixes and I was dead. The accesscode had now morphed into the new format code=ory........ &scope= .....[all scopes] not just CompanyFile. It was at this stage that the info was coming about Browser2 (Edgebrowser) Antview2 was being posted on the API forum and pushed to me by MYOB API analayst - yet the info didn't rock/add up - why then was the original open post for an access_code giving an error no matter whether used on Chrome/Edge/Opera/Fox or any other browser - I posted to Tana my confusion. I then went experimenting with my access code - what if I could extract the code returned from ( not the document returned payload, but the title returned URI??) - and I experimented with methods in MS Access - and hit gold in 15 minutes - I could get the returned URI with strbody = Me.WebView.Object.Document.documentElement.outerHTML 'old code for returned payload of formatted page to strbody = Me.WebView.Object.Document.URL 'new code 2 Sept 24 - no payload just returned url title - it was that simple Change the extracttoken code which was simple, 1 minute fix - and MS Access was back online. Yep that simple. Then I had to rewrite all my old code - was time anyway - I hadn't realised that the initial access_code post came with a 20 minute access_token & a 7 day refresh_token and kept using refresh_token straight away to get a new access_token and wondering why I couldn't get online - hmm - if it aint broke!!! - that is all fixed now - but now I have to say - if 20 minutes is expired in < 2mins refresh else I might get caught out. Anyways - lastnight I dug out my old VB.Net 2010/13 utility that is no longer available on MYOBs developers web - it was old - I downloaded the VC# version and VB version but in 2013 I was not anymore than a casual looker at VS 2013 VB & VC# - I got the VB.Net utility working - the code is not disimilar to VBA but VC# was double =dutch to me - the VB.NET utility ran, the VC# didn't - I deleted the VC# - it is gone - if someone has got a copy would appreciate please!! Since 2013 I am proficient in both languages write in both, have programs running in both but prefer by a mile VB.NET as it is so less demanding on format and really, it doesn't matter which you use. I dug out my old VB.Net utility from 2013 - updated it to 2022 - .NET framework 4.8 and the MYOB SDK to 6.2024 - and tried to run it - error! And last night using partly code that Steve_PP posted and a bit of my own got it going 100% - the fix was as simple as the MS Access fix. See attachement The 1st 2 yellow arrows WebB.Url.AbsoluteURi is Steve_PP fix - the passed parameter in ExtractString(.......,"code=", "&scope") - is mine - seems that works really nicely with modifying the extraction code. The 2nd yellow arrows just shuts the browser error page once the access_code is recovered so that you don't really see this page it goes quickly - pretty certain Steve_PP mentioned this as he wasn't sure why the error ( the error is the missing payload that MYOB has removed) - it is irrelevant now - not needed but a MYOB blue in removing I suspect. And that folks is as simple as it gets - the utility runs just fine - though there was another comms error but that may be a msgbox I left in there somewhere in trying to find a solution. All my clients online files showed - selected one of them - all the item invoices loaded - clicked an invoice and it desplayed perfectly. Tana in MYOB has been given this fix ( Steve_PP contribution advised as appropriate) and I have asked Tana to please keep us ( The developers) advised even if MYOB think they might changed something - hmm - wishful thinking. Finally, it is my opinion ( maybe wishful thinking, hope, dream) that when MYOB finally roll forward, again, the update for the Edgebrowser that it won't change anything and the above fixes will continue to work and we won't need Antview2 (at $350 plus Euro) or WebBrowser2. That this change was not the cause of all the problem - it was MYOB's lack of understanding of the changes that were created and not keeping us advised. The DocRe: C# WebBrowser -> WebView2 solution
Hi Steve_PP Yes thanks - just a lot of info to digest coming up for air after getting all my clients back on line - which, at that stage I was not talking VB/VC and have since loaded the old VB.NET MYOB utility and updated and have had time to concentrate on creating a test solution for all versions - with the view that when MYOB finally roll out the Edge viewer I suspect it won't matter. Thanks for your reminder - will save me a lot of soul searching - will post as I get success hoping to have VB/VC# and MS Access trial version in prep for any more wild updates by MYOB.
