Good Day,
In Manager API Inbuilt Tax codes do not expose value or type of tax.
Inbuilt Tax codes have an empty json {}
It would be beneficial if they could expose the total tax and components as below.
Custom tax codes have a very clear json as below.
{
“Name”: “SGST”,
“Components”: [
{
“Name”: “SGST”,
“Rate”: 9.0
},
{
“Name”: “CGST”,
“Rate”: 9.0
}
],
“TaxRate”: “CustomRate”,
“TaxRateType”: “MultiRate”
}
Is there a question here?
It’s a bug report / change request. There are two types of objects that he’s referring to:
TaxCode - This holds all custom created tax codes.
This is what a custom 1% tax rate looks like:
{
"Name": "Custom Tax Code",
"Components": [
{},
{}
],
"Rate": 1.0,
"TaxRate": "CustomRate"
}
InBuiltTaxCode - Pretty self explanatory, these are the in-built ones that have been enabled.
This is what Australian GST 10% looks like:
{}
Instead of just being an empty object, there should at least be some basic details:
It really depends on what @lubos has stored in the database, for what can be shown. But it probably shouldn’t be empty. It prevents us from being able to generate a list of the in-built tax codes automatically from the API.
That said, maybe this has something to do with InBuiltTaxCode being a read-only object. There may be a technical reason for why no fields are shown, and only lubos can clarify that.
In-built tax codes are actually hard-coded in the source code so database doesn’t hold any information for it.
I think API as it stands is really about feeding new data or updating existing data. It’s not to be used to get reports. To get reports, there will be different approach. Perhaps Manager will be able to dump normalized SQL database for querying or something similar.
Fair enough. Is there a way to at least label them on the HTML page, though? Something other than “Manager.Model.InBuiltTaxCode”:
If not, that is also fine. Having access to a list of UUIDs is helpful enough, because we can work out manually what each one is (as a workaround). I’d rather have what we have now, than to not have access to the InBuiltTaxCode object at all.
@keegan - do you have enough information to achieve what you’ve set out to do? If not, please let us know. I might be able to assist in some way. On my end, I’ve set up a hard-coded array in my application to work around this limitation (it maps the readable name to the relevant UUID so I can easily assign it to a transaction).
Yes Shane,
Although I have noticed that the object collections are fixed for the inbuilt tax objects.
Eg.
Yes. Thank you. I also have Mapped the Codes to Tax details. Just wanted confirmation that the codes will not change in the future. Since Lubos has confimed, its good enough for me.