I am using QuickBooks. Somehow I am getting some weird error on creating one invoice.
{
"Fault": {
"Error": [
{
"Message": "Duplicate Document Number Error",
"Detail": "Duplicate Document Number Error : You must specify a different number. This number has already been used. DocNumber=O0010714 is assigned to TxnType=Invoice with TxnId=45823",
"code": "6140",
"element": ""
}
],
"type": "ValidationFault"
},
"time": "2020-12-15T04:54:25.476-08:00"
}
Why it is happening as there is no doc in the QuickBooks which says that doc number is a unique entity.
Short version: DocNumber should be unique in most cases. In some cases you can add include=allowduplicatedocnum arg in URL to allow that. Be aware that DocNumber can be automatically generated.
Long version: taken from DocNumber field documentation for Invoice
Reference number for the transaction. If not explicitly provided at
create time, this field is populated based on the setting of
Preferences:CustomTxnNumber as follows:
If Preferences:CustomTxnNumber is true a custom value can be provided.
If no value is supplied, the resulting DocNumber is null.
If Preferences:CustomTxnNumber is false, resulting DocNumber is system
generated by incrementing the last number by 1.
If Preferences:CustomTxnNumber is false then do not send a value as it
can lead to unwanted duplicates. If a DocNumber value is sent for an
Update operation, then it just updates that particular invoice and
does not alter the internal system DocNumber.
Note: DocNumber is an
optional field for all locales except France. For France locale if
Preferences:CustomTxnNumber is enabled it will not be automatically
generated and is a required field. If a duplicate DocNumber needs to
be supplied, add the query parameter name/value pair,
include=allowduplicatedocnum to the URI.
P.S. Late response, but may be useful for somebody in future.
UPD:
Looks like library from npm node quickbooks doesn't support that natively. Because method createBill doesn't allow to provide any params to URI. Even method module.create have just hardcoded url variable without ability to provide nothing extra.
In this case, if you still want to use include=allowduplicatedocnum, you have the following options:
monkey-patch this library;
make fork and do updates;
ask authors of that library to implement that instead of you;
find a library that will support that;
send raw requests to QBO from your code.
Related
I'm trying to change the value of a custom task using the Asana package for NodeJS. Sadly the official developer documentation appears to be out of date, because the updateCustomField method in the example is not valid anymore.
It looks like custom_fields can now be passed to the task.update method, but I run into 'Invalid request errors' when trying this.
Thanks!
It is indeed part of the task.update method. In the data for this method, you can set the custom_fields property to an object, where the key is the GID for the custom field you want to change and the value is the value you want to change to.
Which looks something like this:
client.tasks.update(taskID, {
custom_fields: {
"1234": "New value for field"
},
name
})
Suppose I have this type:
type User {
name: string!
}
But the resolver pack back that object:
{
"name": "john",
"topSecretPassword": "123456"
}
The graphql client doesn't know how to select the field topSecretPassword because It's out the schema. Is the field sent to client-side and dropped? Is the field ignored at the server-side?
A GraphQL service only returns the requested fields. If the field is not requested, it won't be in the response. If the field doesn't exist in the schema, then it cannot be requested.
This is true regardless of what's returned in the resolver. The value returned in the resolver is always coerced into the appropriate type. In the case of an object type, its individual fields are resolved according to their own resolvers.
For a detailed explanation of how execution works, please refer to the spec.
I am able to query active-directory/ldap to get the user information along with custom attributes. However I would to know the underlying DataType/attributeSyntax for each of those attribute returned.
Another the problem is that the query will not return the attribute itself if it does not contain any value.
So if can get fetch the attributes and their respective DataTypes then it provides me flexibility to set a default value basing on the DataType while preparing the final output object.
Eg:
1. I query AD to find foo user with attributes givenName, mail, myCustom1, myCustom2
{
givenName : "foo foo",
mail : "foo#boo.com",
myCustom1 : "TRUE"
}
but may not contain myCustom2 because it is not holding the value in AD.
get syntax for attributes givenName, mail, myCustom1, myCustom2
{
givenName : unistring,
mail : unistring,
myCustom1 : boolean,
myCustom2 : integer,
}
using above I can map the first result and prepare the final object as
{
givenName : "foo foo"
mail : "foo#boo.com"
myCustom1 : "TRUE"
myCustom2 : //usingHelperFunctionGetDefaultValueFor -> myCustom2
}
Active Director does not return attributes that do not have values, so that's not just the LDAPjs library, that's just how AD works.
Every object has an attribute called allowedAttributes that will show you every valid attribute that the object can potentially have.
If you need it, allowedAttributesEffective will list every attribute that the current user has permissions to modify.
These are both constructed attributes, meaning you have to ask for them specifically, or else you won't get them. For example, when searching, you have the option to specify the attributes you want to get back. If you specify nothing, you will get every non-constructed attribute that has a value. If you want any constructed attributes, you have to add it specifically to that list.
That's just a list of attributes. It won't tell you the type. You have to look to the schema for that, which is more difficult. You have to do a search using the base DN of CN=Schema,CN=Configuration,DC=domain,DC=com, where "domain.com" is the root domain of your forest, which may or may not be the same as the domain you're searching. You could look at the subSchemaSubEntry attribute of any object to find the location of the schema, although it will usually be CN=Aggregate,CN=Schema,CN=Configuration,DC=domain,DC=com (note the added CN=Aggregate).
But anyway, each object in there will have an attribute called ldapDisplayName, which is the name of the attribute as it appears on objects.
So if you want to find details on the givenName attribute, you would search the schema for (ldapDisplayName=givenName). Then the oMSyntax attribute is an enum that will tell you the type. The enum values are shown here. For givenName, that would be 64, which is a Unicode string.
The only benefit to looking up the types like this is if you are expecting your code to be run on any AD environment. If your code will only ever be run in one environment, then you can save coding time and run time by just hard-coding the attributes you are looking for and their types.
In Azure API Management, I need to check whether or not a query parameter is set. To achieve this, I'm trying to use context.Request.Url.Query.GetValueOrDefault(queryParameterName: string, defaultValue: string).
According to the documentation, this expression works as follows -
Returns comma separated query parameter values or defaultValue if the parameter is not found.
With that in mind, I used the example from the MS blog Policy Expressions in Azure API Management, to create the following <inbound> policy -
<set-variable name="uniqueId" value="#(context.Request.Url.Query.GetValueOrDefault("uniqueId", ""))" />
However, whenever I include this policy, execution fails with 404 Resource Not Found. Upon inspection of the trace, I can see that the execution was aborted without error before a single policy was evaluated (no matter where within <inbound> the above policy is placed.
This behavour results in the following <backend> trace, which explains the 404
"backend": [
{
"source": "configuration",
"timestamp": "2017-09-07T12:42:13.8974772Z",
"elapsed": "00:00:00.0003536",
"data": {
"message": "Unable to identify Api or Operation for this request. Responding to the caller with 404 Resource Not Found."
}
}
],
Given that the MS documentation seems to be inaccurate, how can I check whether or not a query parameter is set?
So the answer here is that there is (another) MS bug.
When the API operation was originally created, the uniqueId query parameter was set as required. I changed this so that it was not required before adding the policy described in my question, however a bug within the new Azure Portal means that when you uncheck the Required box adjacent to the query parameter and then save your changes, they are ignored.
I was able to work around this behaviour be editng the YAML template in the OpenAPPI specification view, removing the declaration required: true for the query parameter in question. The expresion within my policy now works as expected.
Please note: that this workaround sheds light on yet another bug, where saving the template results in your policies being deleted, so make sure you take a copy first.
Here is what RFC 5789 says:
The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI. The set of changes is represented in a format called a "patch document" identified by a media type. If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.
The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.
Let's say I have { "login": "x", "enabled": true }, and I want to disable it.
According to post "Please. Don't Patch Like An Idiot.", the proper PATCH request would be
[{ "op": "replace", "path": "/enabled", "value": false }]
However, let's take this request:
{ "enabled": false }
It also 'contains a set of instructions describing how a resource currently residing on the origin server should be modified', the only difference is that JSON property is used instead of JSON object.
It seems less powerful, but array changes can have some other special syntax if required (e.g. {"a":{"add":[], "remove":[]}}), and server logic might not be able to handle anything more powerful anyway.
Is it an improper PATCH request as per RFC? And if so, why?
And, on the other hand, would a { "op": "disable" } be a correct PATCH request?
the only difference is that JSON property is used instead of JSON object.
It's actually a bit deeper than that. The reference to RFC 6902 is important. The first request has a Content-Type of application/json-patch+json, but the second is application/json
The important thing is that you use a 'diff media type,' one that's useful for this purpose. You don't have to use JSON-PATCH, (I'm a big fan of json-merge-patch), but you can't just use anything you want. What you're asking about in the second part is basically 'can I make my own media type' and the answer is 'yes,' just please document it and register it with the IANA.