Accounting mailing list archives
Re: No validity dates on taxes in odoo. Why ?by
Meanwhile I have made some tests and I think I'll proceed with the workaround I have proposed in an earlier posting (in the lack of a sustainable and well-thought-out solution):
At the turn of the year I will duplicate the current tax codes and rename them to "Old tax code description". Then I will amend the existing tax codes to the new settings.
Pros: everything keeps going as expected, no additional actions necessary for the current business. Manual assigning of the old tax codes is only necessary for sales/purchase orders not invoiced until the end of the year. Retrospectively all postings and accounting entries remain correct as they base on the the tax lines where the tax information at the accounting date are saved. Retrospectively printed invoices are also correct.
Cons: The online view of a past invoice shows the actual tax name
in the invoice line (but the proper tax name in the advanced tab)
@eric : for most customer I do not have any 'domestic' fp (ie: France for french customer) but yes you are right.
2017-11-09 10:17 GMT+01:00 Eric Caudal <email@example.com>:
I do not intend to create new fp, just add validity dates in fp lines.
Depending on the validity date you use one tax or another in the replacement method:
Tax |from |to |Replacement
TAX1 |2016/01/01 |2016/12/31 |TAX2
TAX2 |2017/01/01 |2017/12/31 |TAX3
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore)
Odoo Gold Partner // Best Odoo Partner APAC 2014 and 2016On 11/09/2017 04:02 PM, Frédéric Clementi wrote:<blockquote type="cite" cite="mid:CAFW=zNjbFDPMc4NnvTr
MpzBdRObwxRPwodDqoDbrhhi9jESMt"> firstname.lastname@example.orgFiscal position rule is the best solution today but the idea of creating a temporary fiscal position is really not ideal.I would be curious to know Odoo position on this. I add Quentin in copy.
2017-11-09 1:02 GMT+01:00 Eric Caudal <email@example.com>:
+1 (for the idea)
IMO a good and simpler direction: validity dates on the replacement taxes in fiscal position.
You just have 2 fields to add and "one method" to consider modifying (the one taking care of the replacement). Never that simple but looks much easier than validity dates in taxes
I am not completely certain fiscal positions are universal in Odoo though but that should cover most cases.
On 11/08/2017 09:32 PM, Raphaël Valyi wrote:<blockquote type="cite" cite="mid:CAByrsx3rf_4wiPttqRe
fC3cjAe=VNPUEReei3mOSAseaNtd0o Q@mail.gmail.com">Hello Frederic,you may also consider the https://github.com/OCA/acc ount-fiscal-rule/tree/10.0OCA project. The decision table rules allow to select the right fiscal position and hence the taxes to apply. In the base rule structure there are start and end dates https://github.com/OCA/a ccount-fiscal-rule/blob/10.0/afor the rule matcher, but eventually the table and the matcher can be extended much the way you need. ccount_fiscal_position_rule/mo dels/account_fiscal_position_r ule.py#L41I'm not sure if that could fit your use case but may be. Regards.On Wed, Nov 8, 2017 at 2:17 PM, Frédéric Clementi <frederic.clementi@camptocamp. com> wrote:
After analysing the code it seems that there is no clean method for tax calculation where we could have validity dates ... so we will not be able to create a module :\Such a shame !@Ermin : There is no pricelist on invoicesThanks for your input guys
2017-11-07 10:41 GMT+01:00 Ermin Trevisan <firstname.lastname@example.org>:
This is a true pity...
It is not only 2 tax rates, but 6 to be precise:
- regular rate (sales and purchase)
- accomodation rate (sales and purchase)
- reverse charge - "Impôt sur les acquisitions" (regular rate and (theoretically) accomodation rate)
What about adding default taxes to pricelists?
-- twanda AG Ermin Trevisan Artherstrasse 19 CH-6318 Walchwil T +41 41 758 1515 M +41 79 208 7373 E email@example.com www.twanda.ch www.gastrosoftware.chOn 11/7/17 10:02 AM, Frédéric Clementi wrote:Dear all,I have questions about the VAT rate change management in Odoo.In Switzerland, 2 VAT rates will be modified 1st of January and handling such a change in Odoo is never simple.- First, you have to create new taxes, news tags, adapt the VAT report and change fiscal position. It could be more automatised I think but ok.- Then, and this is my concern, you have to change default taxes on accounts and products.Ok but When exactly? Should I spend my new year eve checking that my csv import,script or cron works properly? because in case of errors it might be complex to do corrections.So my question is simple: first, why don't we have validity dates on taxes in odoo.And this lead me to a second question : Why don't we prefer managing default taxes at account level rather at product level?I know the feature exists but it does not work on Sale order because there is no account on so line :\It would be much easier If you set a VAT by default on account, then most cases can be handled with default account at product category level or property level and you would just manage default vat at product level in some specific case.I am sure some of you have explored this point. I was hoping for some feedback on these points.Thank you guys.FredericCamptocamp--
Post to: mailto:accounting@odoo-communi
Post to: mailto:accounting@odoo-communi
Post to: mailto:firstname.lastname@example.org
-- twanda AG Ermin Trevisan Artherstrasse 19 CH-6318 Walchwil T +41 41 758 1515 M +41 79 208 7373 E email@example.com www.twanda.ch www.gastrosoftware.ch