Problem with orderby on JobRegister query
I use the .NET SDK in a custom reporting application. The client using it makes extensive use of Jobs in the MYOB usage, and there are a small number of top-level jobs that represent their operational departments. Most of these have a number of sub-Jobs down to 2 or 3 levels deep. Every transaction is assigned to a Job. I recently had to make a query to the JobRegister endpoint, and I wanted to order the results by Account/DisplayID and then Job/Number. My filter string looks like this: $filter=Year eq 2024 and Activity ne 0&$orderby=Account/DisplayID,Job/Number This is rejected by MYOB with Bad Request. I have not been able to come up with a syntax that MYOB will accept, so I am obviously missing something here. If I remove the orderby part, it works fine. I have used orderby in many other queries, but I have not had to specify the field in a nested way as above. So, what am I doing wrong here? Thanks.Developer Update March 2025
Developer Update March 2025 AccountRight 2025.2 has now been released. Please update your app to the latest version. You can find out more about the new version of AccountRight 2025.2 at our blog here. As new versions of AccountRight are released, we also decommission older versions. If you are currently on version 2025.1, you will need to update by March 25 2025**. You can find out more about updating to the latest versions here. ** All dates are indicative only and subject to change.Issue with MYOB Business API: 409 Conflict when sending multiple POST requests
This is not a support request, it is more like an issue I recently encountered, and since I could not find any documentation about it in the API docs, I thought I'd post it here to save other developers time in the future. Undocumented limitation with MYOB Business API: 409 Conflict on sending multiple POST requests in parallel Issue Summary While integrating with the MYOB AccountRight API, I encountered an issue when creating new Bills via the API. When submitting multiple POST requests in quick succession, some of them intermittently fail with a 409 Conflict error. The error message returned is: "An Update operation requires the latest RowVersion for each of the existing entities being modified." This is unexpected behavior since this error message is typically associated with PUT requests (updates), not POST requests (new record creation). Expected vs. Actual Behavior Expected Behavior: Each POST request should successfully create a new Bill, returning the newly created Bill’s details. Actual Behavior: Some POST requests fail with a 409 Conflict error, while others succeed. Resubmitting the same failed request later often results in a successful response, without any changes to the request payload. Steps to Reproduce Send multiple POST requests to create Bills in rapid succession (e.g., five requests in parallel). Observe that some requests fail with a 409 Conflict error while others succeed. Resubmit the failed request later - it may succeed without any modifications. Analysis The error message suggests that MYOB is incorrectly treating some POST requests as PUT requests, possibly due to an internal concurrency issue. This behavior is undocumented, and no clear explanation is provided in the API documentation. Possible causes include: Concurrency limitations within the MYOB API when processing multiple requests simultaneously. Internal caching or sync delays causing some transactions to be misclassified as updates. Thread safety issues where parallel requests interfere with each other. MYOB API Support Response After raising this issue with MYOB API support, it was confirmed that the API does not handle multiple simultaneous POST requests to the same database correctly. Their recommendation was to add a delay between each request to ensure successful processing. "We have had requests to open this up, but we would need some significant updates to be able to do so. Going forward, you will need to provide space between each call." Workaround To avoid encountering this issue, implement the following workaround: Send requests sequentially, ensuring each request completes before sending the next. Introduce a delay of a few seconds between consecutive POST requests. Implement automatic retries with exponential backoff when encountering a 409 Conflict error. For example, in a microservices-based architecture, detecting this specific error and retrying after a short delay can help mitigate the issue. Conclusion This undocumented limitation can cause unexpected failures when batch submitting Bills via the MYOB API. Until MYOB updates their API to handle parallel requests correctly, developers should implement sequential request processing or introduce delays to ensure reliability. Hopefully, this post saves others time troubleshooting similar issues!
AR 2025 converting Order to Invoice via API
Hi Folks I have just, yesterday, been asked to add another component to my integrator (web - integrator - myob file ). I think I know the answer i.e. the API doesn't permit patch updates but there might be a component I haven't forseen. My integrator takes Orders from a web cart - processes them and sends them to MYOB as a double component. Sales order - either on an account or paid for by a guest account by credit card. An order which uses the components from the inventory system ( an in house admin component) - if there aren't enough inventory it will create a B Order - and will check inventory before each new orders to see if any B Orders can be filled - if so it DELETES the B Order and lodges a Sales invoice for the in house - component use. ( complex - but it works beautifully) This was all set in place because human admin staff were dropping the ball in the factory and Orders/BOrders/inventory was a shambles. The latest ask - is again because human staff majorly DROPPING THE BALL. When an order is completed - the SALES ORDER for the client - which are mostly account customers - needs to be converted to an invoice and sent out to the customer - last month $170,000 of completed work NOT invoiced - yep!!!! I have been asked to add feature to do this. Questions I don't think there is a simple way via an API endpoint to convert an order to an invoice - I think I need to DELETE the ORDER and resend as an INVOICE ?? - no matter - I do this for a B Order anyway. You cannot DELETE an Order if a payment has been applied to that Order - ?? (MYOB has an awful way of applying a payment to an order that completely jams it so even if you delete the payment you cannot delete the order - the only way around this appears to be NEVER APPLY A PAYMENT to an ORDER - ( have done this successfully for another client this method) - you put the monies into a liability account ( or asset - doesn't matter - naming it correctly so it can be traced) - when an order is filled you convert the Order to a Sale - THEN apply payment as the ORDER has a NB: line - payment has been received etc. Thoughts, ideas? The Doc
MYOB AccountRight Enterprise v19 Upgrade Path to stay current and supported
Hi, I am looking at the following scenario:- Current Version: MYOB AccountRight Enterprise v19.5 in a network configuration Questions:- Upgrade path and requirements to the next closest MYOB AccountRight Enterprise product version. Upgrade path and requirements to MYOB Accounts Premiere? Is this the closest thing to the MYOB AccountRight Enterprise v19 (and path of least resistance to migrate the company files) Or, can we continue to pay for the annual support license? Should we upgrade/update to AccountRight Enterprise v19.16 first and then look to the next release or product version that will be supported? Maintain current installation on a client/server network or rather a peer-to-peer to network? NOTES: Tested MYOB Premier to see if it will upgrade / update the MYOB company file. Downloaded MYOB Premier to test. However, when attempting to open the company file based on MYOB AccountRight Enterprise v19.5, it complains / reports the following: "This file has been upgraded for use with a newer MYOB Product" (r.13.5)
Original software Accounting Plus/Premier Pro
I have been given a number of different conflicting answers to this question via OS call centre support personnel, so I thought here may be a better place to ask the question. I started using MYOB around 2004/2005. I still have the original software that I purchased. I understand that MYOB may no longer support the software but if I choose to use it, what chance is there of the data file being able to be read by the software, I would suggest very little chance. So in order to use the software, the datafile would need to be started again from scratch or at the very least imported manually. Correct? Apart from this and other obvious lack of features (single touch, etc). There is nothing stopping a person from using that software with the licence key that was purchased outright, correct?
Importing from Retail Manager - Trouble
Hi, I have been importing from Retail Manager to Account Right Desktop for a number of years and last week I have started to have problems. The import works but the pop box telling me that the import was successful does not go away and I cannot do anything. The only thing I can do is restart my laptop. Any suggestions as to what might be causing this to happen, have never had any issues in the past. Thanks Fifitzbank feeds deposit that has been refunded
Hi there, We received a payment that was incorrect, so we have refunded the funds back to the agent. However in bank feeds the amount is displayed, waiting to be allocated. The original invoice has been updated so the amount doesn't show anymore. How to go about this? Do i just recreate the incorrect invoice and match it even though the money has been refunded? Thank youDeveloper Update February 2025
Happy New Year to the MYOB API Developer Community! As we step into 2025, the MYOB API team is excited to welcome you back and share our enthusiasm for the year ahead. We hope you all had a restful break and are ready to dive into many amazing new opportunities. AccountRight 2025.1 has now been released. There are no changes to the MYOB Business/AccountRight API with this release. Please update your app to the latest version. You can find out more about the new version of AccountRight 2025.1 at our blog here. As new versions of AccountRight are released, we also decommission older versions. If you are currently on version 2024.11, you will need to update by February 25 2025. You can find out more about updating to the latest versions here.Web browser version inability to customise all forms
I have a client who needs to put the below also onto the invoice When are you going to allow the AccountRite cloud versions default customised invoices to able to be chosen for email purposes for emailing the invoices to clients. This is an urgent requested addition that HAS to be put into the web browser version. Someone using an APPLE computer has been told that they were told they can only use the Web Browser version of the MYOB Software, is this correct? or do the APPLE computers no longer have any ability to use any of the MYOB Software? Are there any limitations to Apple computers using the MYOB software? If the same data file is also used in the Cloud Version of software by say the accounting team, and the sales teams use APPLE to raise all of the sales invoices? what are the inherent issues with the 2 forms of computers using the same data file? Please adviseOpenSSH to remove DSA key type early 2025
OpenSSH (OpenSSH) is "the premier connectivity tool for remote login with the SSH protocol", including ssh, scp and sftp. I understand that they plan to remove support for the DSA signature algorithm from the first release after January 2025 (see release notes for v9.9 2024-09-19 OpenSSH: Release Notes). Support has only been provided at runtime since 2015. I have a couple of clients using our solutions to integrate to FTP servers, and it appears that both servers use DSA keys. I thought it might be worth putting this onto the forum in case others are affected. The solution requires FTP servers to be re-configured for alternative keys (eg RSA 2048-bit).
Account Premier v19.11 - Activation Code no longer working
Hi, I am running an old version of Account Premier v19.11 and have a data file which when I opened a couple of weeks ago and it launched trying to confirm the company file and then received a message saying "An invalid confirmation code has been entered" I have also tried to confirm the file in the Company by going online MYOB Company File Confirmation page. I receive a confirmation code however when I enter this number in the required field in MYOB I received the invalid confirmation code error message. Is anyone able to assist me in trying to sort this matter please. Kind regards, MyriamMyob File confirmation
Hi, I cannot confirm my MYOB file online (2013.5 version), and have been directed to MOCA to request a license file. I put in a support request on Tuesday 04/02/25 and still have not had a reply and it is now Friday 07/02/25. Businesses cannot be waiting that long for a response, especially when MYOB is essentially forcing us to confirm our files every 3 months for literally no reason other than trying to make us pay for subscription for software we purchased outright and have a legal right to use.Error trying to refresh token
Testing on POSTMAN a POST request to https://secure.myob.com/oauth2/v1/authorize with x-www-form-urlencoded data: client_id: ... client_secret: ... grant_type: refresh_token refresh_token: ... it is returning 400 bad request: { "error": "invalid_grant", "error_description": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client." } What is wrong?
Uh-oh! The numbers dont add up.
Hello all. Revisiting my C# SDK code after a long time, and upgrading it to net8, I ran into the issue described in this thread. I did not use webview2 but skipped to this part. When I run, I get an Error description The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. The 'redirect_uri' parameter does not match any of the OAuth 2.0 Client's pre-registered redirect urls
