Hi Marek, hi all, what's your point of view to that: http://www.nabble.com/GST-VAT-on-invoiced-time-entries-tt18498937.html
If everyone only would selling goods through orders, nobody has a problem. But from a more general point of view, I think tax should be calculated independendly of the 'document type' used, in germany we have to include the tax calculations in every type i can think of: orders, invoices, quotes, credit note (on invoices and credit notes for tax auth. tasks; on orders and quotes for showing gros prices to customers) Is this of interest to others here, or do you mainly sell goods through orders? --Roland On Monday 14 July 2008 11:35, Marek Mosiewicz wrote: > I mean table where we can find geos definitions of tax type. > US - > US : SALES_TAX (id of tax in TaxAuthorityRateType) > US -> World : EXPORT_TAX > Poland -> Poland : VAT (or VAT_PL) > Poland -> EU : VAT (or VAT_PL or VAT_PL_EU) > Germany -> Germany : VAT or something more specialized > > In fact it can be table TaxAuthorityRateProduct, > but there must be fromGeo there. productStore > is not good to detect fromGeo for VAT (e.g. purchase). > > Then in TaxAuthorityRateType would be definitions of > tax calcluation service used for given tax. > > I think that this is the most basic step forward VAT. > The next step is the problem of Order and Invoice layout. > Global invoice adjustements must be calculated down > to line level becouse of possible different VAT rates > for different products (e.g. one line 22% and another line > 7%) > > If that would be done I see basic sales VAT support be ready to do.
