On 8/19/15, Ossi Viljakainen <[email protected]> wrote: > > > On Tuesday, August 18, 2015 at 4:25:03 PM UTC+2, David Bruchmann wrote: >> >> Taxes are quite complicated. >> In Germany for common products are 2 different taxes on common products: >> either 7% or 19%. >> > > Yes, these are VAT. (MvSt.) There can be one, two or more VAT categories > depending on country.
Concerning Germany it's "Mehrwersteuer" / MwSt. that's right. Some stores advertise selling "without MwSt" but sure they have to pay taxes and just reduce the price by 19% and have to pay and calculate MwSt. from the reduced price. Concerning other countries I've no knowledge. > > Finland has 3 + tax free: > 1. Standard rate 24% (goods) > 2. Reduced rate I 14% (food & restaurants) > 3. Reduced rate II 10% (books, pharmaceuticals, public transport, cinema, > newspapers) > 4. VAT Free 0% (doctor, dentist, hospital, insurance, lottery) > Ok, that can be solved by tax categories I think. Concerning Germany I know that any store has to be able to calculate different categories depending on the product. So it should be possible to assign a default category and the option to change that to further categories. VAT Free could be solved by a dummy category with 0% taxes. > >> For some higher taxes like for Tobacco and Patrol Products I don't know >> how it's calculated at the POS. In general it's possible that it's >> calculated at the POS with 19% but with a different value at a B2B point - >> >> honestly I just don't know. >> > Furthermore there existed some special tax for salt which was abolished but > >> it had to be expected perhaps that resembling taxes still exist in other >> countries, >> > > Tobacco tax, alcohol tax, sugar tax etc taxes are not POS taxes. They are > not calculated at POS. They are added to the price at point of manufacture, > > and part of the product price throughout the retail chain. Only the > manufacturer pays the tax to the government. > Ok, that's not part of POS, clearly. > >> As long as you plan to include an option for different unlimited >> tax-classes I don't see a problem here, but concerning the abolished >> salt-tax I don't know if there have been even 2 taxes on one product. >> This point is still open, is there anywhere a requirement to assign 2 or more taxes to a product or service? > > In USA they have very weird and complex, illogical tax system, as mentioned > > earlier, tax depends on which product category, quantity of sale, in which > state you are located, whether on reservate or private land, on the street > widht, the house number, the strenght on wind, the tide and amount of > sunshine your shop gets :D > > >> As far as I see a configurable option would be nice, so even for US never >> >> had to be programmed anything extra. >> > > Most of the wold uses tax included prices. This is true specially in > counties using VAT. The logic of VAT is simple and similar in all countries > > using VAT. But the USA does not use VAT, it uses sales tax, with complex > rules varying from state to state. > > Question is if the US-Model could be solved with taxes and tax-categories, both in an own table each - in the same kind like the EU-Model. I never expect a pre-configuration for each state. I think even the name and the laws in background are different perhaps the facts keep the same: product -> price -> tax-class(es?) -> tax(es?) Display and Print can be solved by Templates where the general name for the tax can be adjusted (VAT, sales tax, whatever ...) or directly taken from the database. Talking about Templates, there is still the question if these should be optionally implemented in several languages. In some countries are several official languages (i.e. Tunesia: Arabic and French) and some like to offer an international version perhaps for foreigners (i.e. in English or Spanish). I admit about all the different taxes I've not much knowledge, but with the proposed database-model I suppose there could be implemented nearly every kind of tax. For the case that for one product exist several taxes like described above, tax-groups still could be added where these different taxes are grouped to required combinations. Sure it can't be expected from a programmer to include all taxes for many countries especially if it's complicated and very various. Nevertheless the most options have to be configurable anyway and concerning US I don't see a problem yet to make the configuration for any state. If there are modules which just load preconfigured taxes in the database then I don't mind about modules, but the general mechanism can be handled by only one modul I suppose. In the moment I don't see a reason for further functions yet. Best Regards, David
