When FA tax system is right configured it should be no problem with purchase invoice entry. VAT based tax systems are simple enough to enable automatic tax calculation without need for additional tax edition fields in entry form. Tax editable fields would lower entry performance and would give additional risk for entry errors.
Regarding rounding errors: in VAT based tax system there are only two ways of tax calculations: you can calculate tax from brutto price (i.e. price including VAT) or calculate it from net price. Both types of calculations are supported in FA by selecting supplier pricelist type, so no rounding errors (or differences between supplier document and FA entry) should appear when right method is selected.
When you do not need full inventory control on all items, you can define a couple of 'service' type items with editable description. This way you can make use of FA tax system, while no constraints and administrative burden is introduced, just because stock quantity control is switched off for service items, and editable description enables single definition reuse for various real items.
On the other hand old type purchase invoice user interface containing GL lines is still supported in FA, just because it is mature, and we do not want completely switch to the new one until we are sure all problems solved by additional GL lines can be solved by proper FA configuration.
Last but not least generic journal entry interface can be used to entry purchases in those rare cases (if any), when normal purchase interface is not flexible enough.
So as you see we have in fact three methods of purchase entry in FA. For the reasons explained above we will not complicate user interface adding special tax input fields.
First thing which you should do to successfully use FA is to read, understand and configure your tax system. This is explained on wiki and in a couple of other tax related threads on forum. Without this you can have tax calculation problems not only in purchase but also in sales module.
Janusz
