One of our clients is unable to export an invoice to QuickBooks Online Harmony using the new v3 REST API. The error they get is "Business Validation Error: One or more transaction lines do not have a tax code associated with it. Please assign a tax code for those lines."
An example request and response are shown below.
I'm wondering:
Is this related to a sales tax setting that our client has set?
Which setting? (I'd like to be able to reproduce the setup on a test company)
Do we need to send additional data in the invoice add request to accommodate that setting?
For what it's worth, the client is based in Canada. Testing an invoice export with similar data for a non-Canadian company works fine. Thanks for the help.
EXAMPLE REQUEST:
<Invoice xmlns="http://schema.intuit.com/finance/v3" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<TxnDate>2014-03-12</TxnDate>
<PrivateNote>Some private note.</PrivateNote>
<Line>
<Description>My Description</Description>
<Amount>3333.33</Amount>
<DetailType>SalesItemLineDetail</DetailType>
<SalesItemLineDetail>
<ItemRef name="My Description">3</ItemRef>
<ClassRef name="3">3333</ClassRef>
</SalesItemLineDetail>
</Line>
<CustomerRef name="My Customer Name">33</CustomerRef>
<ClassRef name="3">3333</ClassRef>
</Invoice>
EXAMPLE RESPONSE:
<IntuitResponse xmlns="http://schema.intuit.com/finance/v3" time="2014-03-13T11:47:58.052-07:00">
<Fault type="ValidationFault">
<Error code="6000" element="">
<Message>A business validation error has occurred while processing your request</Message>
<Detail>Business Validation Error: One or more transaction lines do not have a tax code associated with it. Please assign a tax code for those lines.</Detail>
</Error>
</Fault>
</IntuitResponse>
I see that you have already enabled sales tax settings. The next thing you can do is create the invoice in the UI and then load it through the API as Matt suggested. Assign some tax to the invoice and Read it using API explorer.
THis will give you an idea as to what is expected in the lines. This will definitely help you out with the correct tags you need to set.
Alternately refer to the docs with example request here-
https://developer.intuit.com/docs/api/accounting#/complex-data-types
Global tax model-
https://developer.intuit.com/docs/0100_accounting/0300_developer_guides/global_tax_model
If you have sales tax enabled in QBO, then all line items in invoice need to have a TaxCodeRef, and there needs to be a TxnTaxDetail object on the invoice itself. You should be able to get the numerical values that need to go into these values from the TaxCode/TaxRate endpoints.
Your best bet is to create the invoice in the UI and then load it through the API so you can see what it's meant to look like.
I have run into this as well and while it took me forever to figure it out, the answer is simple.
If tax is enabled for the company, every line must have a tax code, whether there is tax applied or not. That means that there should be a tax code in the system for "no tax". (For Australia, this is called "OOS" or "Out Of Scope" - apparently which one you get depends on when you set up tax, so look for both!)
If there is $0 tax for a particular line, you must explicitly attach this no-tax tax code, and cannot leave it null.
Related
So i was integrating my app with paypal for express checkout and could not figure out how to add in my gst/hst number for Canada to the receipt.
it is mandatory if i am to charge taxes in Canadian shipment, that the gst/hst number be visible in the receipt, but cant seem to figure this out.
any help would be appreciated!
below is an example of my receipt but i want to add some additional content for the gst/hst number. where would i be able to and how.
references:
https://developer.paypal.com/docs/api/orders/v2
https://turbotax.intuit.ca/tips/self-employed-business-win-creating-cra-compliant-invoice-8827#:~:text=It%20is%20very%20important%20that,you%20cannot%20charge%20GST%2FHST.
ANSWER:
so this is just a trick around it since i couldnt find a proper solution, but i just add in another item with the GST/HST Number. i leave the cost of it to 0 so it does not affect the total price but the buyer is still able to get the gst/hst number on their receipt.
The amount key can include a breakdown key, which is an object of type amount_breakdown documented here: https://developer.paypal.com/docs/api/orders/v2/#definition-amount_breakdown
tax_total is the key name of one of the objects you can include in the breakdown.
The breakdown's subtotals must add up to the actual amount value.
I can access both the RSA REST and WSDL based APIs. Their documents refer to content and resourses. However, when logging into the actual tool I can access things like incident ticket and the like.
Incidents tickets will have INC-1234 which would be a string. But the API takes integer values for either content or resource when searching by ID.
self.wsdl['search'].service.SearchRecordsByReport(
sessionToken=self.token,
reportIdOrGuid=14,
pageNumber=1
)
If I don't provide an integer i get a 404 with a simple
"Message": "The request is invalid." in the REST
and something a little more complex if i pass a value like that in SOAP
So, Question 1. is there an RSA resource that correlates/demystifies the relationships of calls in the API with the actual names of things I'm dealing with the in the UI.
Question 2. Is there a code library were someone has created/modified rsa incident tickets before out there?
If you're talking about getting the record contentID you can get it two ways, in the GUI hover over your key field (the clickable link) and in the bottom left corner of archer it'll show something similar to "123456|100|17" where the first set is the contentID of that record.
If you're talking about getting a reportID (14 like you've shown above) you can do the same thing when you go to the master reports list, and it'll show in the bottom right corner of your browser.
If you want to do it all from code I usually piece it together like this:
Execute a search of a report; Get the field IDs from the report <FieldDefinition> (it's probably important to make sure your keyfield is included on the report GUI so you'll be able to identify which record you're dealing with); make another API call (probably REST since it really handles the metadata) to get the field name etc. (or you could make it all static and just hard-code the field names with the corresponding GUIDS)
Within the <Record> tag, you can snag the contentID attribute. Then take a step down and compare the field tag that matches your keyfield and you'll have the contentID of that record.
Make record updates, deletes, etc whatever you need to do.
If you're looking for a specific report ID, make a REST call to get all reports, and it'll return report names and IDs, and then go about your business making your other calls.
I've recently came across similar situation where I have to search for a field value (e.g. "INC-1234") using Archer's API.
So, for your Question 1:
The method that I found convenient to my requirements is "ExecuteQuickSearchWithModuleIds" which can search for a value and provides all ContentIDs that have those values (given the ModuleId).
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ExecuteQuickSearchWithModuleIds xmlns="http://archer-tech.com/webservices/">
<sessionToken>ABC123ABC123ABC123ABC123ABC1</sessionToken>
<moduleIds>123</moduleIds>
<keywords>INC-1234</keywords>
<pageNumber>9999999</pageNumber>
<pageSize>9999999</pageSize>
</ExecuteQuickSearchWithModuleIds>
</soap:Body>
</soap:Envelope>
And for your Question 2, I found a rich library for Python3 Archer RSA.
Hope this helps someone who lands on this question.
I was helping a customer figure out an issue and creating test invoices in the sandbox.
After the 4th one I started getting this error:
{
"name": "BUSINESS_ERROR",
"message": "Number is too long.",
"information_link":
"https://developer.paypal.com/docs/api/invoicing/#errors",
"debug_id": "2ca1d32e1fed3"
}
What number is too long? I've tried looking through all the info and nothing appears too long our out of spec.
Hopefully somoene at Paypal can use the debug ID to track this. This test program has worked without issue for months.
So, after dealing with PayPal support the number that is too long was the invoice number.
When I started my testing in the sandbox I always had PayPal auto-generate the invoice number. It gave something like:
INV2-UR7F-35N45-DGQZ-BYDE
So, after a few tests, the invoice number was incremented (by PayPal) and eventually reached:
INV2-UR7F-35N99-DGQZ-BYDE
Now, on one more call the invoice would be incremented to:
INV2-UR7F-35N100-DGQZ-BYDE
Which is 26 characters, and the maximum length for invoice number is 25.
The solution? I was told to use smaller invoice numbers. ;)
I feel this is a possible bug in the auto-incrementation of the PayPal Invoice, but I am posting this so when others run into this they know what to do.
What I did was in my sandbox account call the Create Invoice Draft API with an invoice number like "Test001" so that there will be plenty of increments left in the invoice number. After that call there should be no need to supply an invoice number, at least for a very long time.
Let's say I have an object, Widget, comprised of an Id and a Name. Let's say I expose an endpoint, /widget, where clients can POST new Widget objects. If I want the Id field to always be set by the server, not modifiable by the client, but still visible to clients, how can I declare that the Id field is not modifiable? I'm using RESTeasy if that makes any difference.
I can think of a few options.
First, are you sure you need to expose the ID as part of the representation? Or is it enough to respond with the location of the new posted resource?
Your client posts:
<Resource><Name>New Resource</Name></Resource>
And you respond:
HTTP/1.1 201 Created
...
Location: /resources/{new_resource_id}
Beyond that, I think it's OK to have some simple, well-understood conventions with your clients. I think most developers understand that an ID is likely to be system-generated (especially, since you're doing a POST and not a PUT). For less obvious cases, where you have arbitrary read-only fields (or other validation or display information), I think it may make sense to provide a link to metadata:
<NewPersonForm>
<atom:link href="/people/new/metadata" rel="/rels/metadata" />
<Name />
<Department>HR</Department>
</NewPersonForm>
What the metadata looks like is up to you, but something along these lines might work for you:
<Metadata>
<Element>
<Name>Department</Name>
<IsReadOnly>True</IsReadOnly>
</Element>
</Metadata>
That's a nice, format-neutral (it works well for both XML and JSON) way to provide information to the client, and if they really want to, they can program against it to build forms on the fly (I use it to provide validation information, language-specific labels, and data type information).
I hope this helps.
John
You write the code on the server that free to do whatever it wants. And that includes adding or changing data as needed. Check the AtomPub protocol section 9.2 that explicitly states:
Since the server is free to alter the
POSTed Entry, for example, by changing
the content of the atom:id element,
returning the Entry can be useful to
the client, enabling it to correlate
the client and server views of the new
Entry.
This is a follow up to Updating a value RESTfully with Post
How do I simply append to a resource's attribute using REST. Imagine I have customer.balance and balance is an int. Let' say I just want to tell the server to append 5 to whatever the current balance is. Can I do this restfully? If so, how?
Keep in mind that the client doesn't know the customer's existing balance, so it can't just
get customer
customer.balance += 5
post customer
(there would also be concurrency issues with the above.)
Simple, slightly ugly:
This is a simpler variation of my answer to your other question.
I think you're still within the constraints of REST if you do the following. However, I'm curious about what others think about this situation as well, so I hope to hear from others.
Your URI will be:
/customer/21/credits
You POST a credit resource (maybe <credit>5</credit>) to the URI, the server can then take the customer's balance and += it with the provided value. Additionally, you can support negative credits (e.g. <credit>-10</credit>);
Note that /customer/21/credits doesn't have to support all methods. Supporting POST only is perfectly acceptable.
However, this gets a little weird if credits aren't a true resource within your system. The HTTP spec says:
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
Technically you're not creating a resource here, you're appending to the customer's balance (which is really an aggregate of all previous credits in the system). Since you're not keeping the credit around (presumably), you wouldn't really be able to return a reference to the newly "created" credit resource. You could probably return the customer's balance, or the <customer> itself, but that's a bit unintuitive to clients. This is why I think treating each credit as a new resource in the system is easier to work with (see below).
My preferred solution:
This is adapted from my answer in your other question. Here I'll try to approach it from the perspective of what the client/server are doing:
Client:
Builds a new credit resource:
<credit>
<amount>5</amount>
</credit>
POSTs resource to /customer/21/credits
POSTing here means, "append this new <credit> I'm providing to the list of <credit>s for this customer.
Server:
Receives POST to /customer/21/credits
Takes the amount from the request and +=s it to the customer's balance
Saves the credit and its information for later retrieval
Sends response to client:
<credit href="/customer/21/credits/credit-id-4321234">
<amount>5</amount>
<date>2009-10-16 12:00:23</date>
<ending-balance>45.03</ending-balance>
</credit>
This gives you the following advantages:
Credits can be accessed at a later date by id (with GET /customer/21/credits/[id])
You have a complete audit trail of credit history
Clients can, if you support it, update or remove credits by id (with PUT or DELETE)
Clients can retrieve an ordered list of credits, if you support it; e.g. GET /customer/21/credits might return:
<credits href="/customer/21/credits">
<credit href="/customer/21/credits/credit-id-7382134">
<amount>13</amount>
...
</credit>
<credit href="/customer/21/credits/credit-id-134u482">
...
</credit>
...
</credits>
Makes sense, since the customer's balance is really the end result of all credits applied to that customer.
To think about this in a REST-ful way, you would need to think about the action itself as a resource. For example, if this was banking, and you wanted to update the balance on an account, you would create a deposit resource, and then add one of those. The consequence of this would be to update the customer's balance
This also helps deal with concurrency issues, because you would be submitting a +5 action rather than requiring prior knowledge of the customer's balance. And, you would also be able to recall that resource (say deposit/51 for deposit with an ID of 51) and see other details about it (ie. Reason for deposit, date of deposit etc.).
EDIT: Realised that using an id of 5 for the deposit actually confuses the issue, so changed it to 51.
Well, there is alternative other than #Rob-Hruska 's solution.
The fundamental idea is the same: to think each credit/debit operation as a standalone transaction. However I once used a backend which supports storing schema-less data in json, so that I end up with defining the API as PUT with dynamic field names. Something like this:
PUT /customer/21
{"transaction_yyyymmddHHMMSS": 5}
I know this is NOT appropriate in the "credit/debit" context because an active account could have growing transaction records. But in my context I am using such tactics to store finite data (actually I was storing different batches of GPS way points during a driving trip).
Cons: This api style has heavy dependence on backend behavior's schema-less feature.
Pros: At least my approach is fully RESTful from the semantic point of view.
By contrast, #Rob-Hruska 's "Simple, slightly ugly" solution 1 does not have a valid Location header to return in the "201 Created" response, which is not a common RESTful behavior. (Or perhaps, we can let #Rob-Hruska's solution 1 to also return a dummy Location header, which points to a "410 Gone" or "404 Not Found" page. Is this more RESTful? Comments are welcome!)