Liqua
Level 1

Other questions

Hi there,

 

Yes, I understand the rounding strategy, however I'm not talking about rounding per-se, I'm talking about the round-trip Quickbooks does to figure out the unit price when, in fact, that is given by the product.

 

  • First of all, unit price shouldn't be mandatory in the API when creating an invoice. If the API consumer is feeding in the product id and the quantity. Quickbooks should figure out the rest, using the same strategy on rounding that the front end does, therefore the problem would be solved.
  • Second, if we are forced to feed in the price, think about this: first we have to find out the unit price from the product by its id, but not forgetting we have to find the tax, which are two different enpoints to find out the type of tax to apply and how to the unit price. So the base price to make calculations is the price given by the product and it shouldn't change, however you do change it and when dumping the invoice JSON, the unit price has a value that IT IS NOT the value that the product has saved in the product itself. Simple as that.
  • Third, on the point of the round trip to find out the price that I already have... the consumer is forced to make one call for the product to find the price, another one for the tax code, another one for the tax rate and then the final one to save the invoice. There are three calls per line that are not needed and you guys, Quickbooks, by forcing the consumer to do that, are wasting money as the user has to hit your API and servers 3 times per line on an invoice unnecessarily. It's in your own benefict not to force people to do this round trip.
  • And fourth, since Quickbooks is the accounting tool, the third party tool shouldn't be forced to do this kind of calculations, that's Quickbooks job and not messing with prices and taxes is what keeps separation of concerns in check.

 

Hopefully I made the issue clear. Please, by all means, feel free to escalate this issue to developers if that's what you feel as, anyone could agree, this is clearly a flaw in design (or, at least, a very arguable choice, unless anybody can explain what's the reasoning behind doing it this way).

 

Thank you for your time!