Missing account mapping rules in parties and invoices
Jordi Esteve
rules. But I don't know how to set account mapping rules, I think this
is a missing feature in Tryton.
Account mapping rules are implemented in OpenERP inside the fiscal
position object. They allow change some accounts to other accounts in
an account move created from an invoice for a party using this account
mapping rules. This feature is very important for some countries, like
Spain.
Also the concept of "Fiscal position" make things easier for the
accountants, because it is easier to set a fiscal position to a party
(fiscal position as a customer and fiscal position as a supplier) than
a set of tax mapping rules and a set of account mapping rules for
customer and supplier.
The questions are: Is planned to add this feature in next Tryton
versions? When? It is better to be added in the core (account module)
or in a new module? If it is not planned to be included in the core of
Tryton maybe some Spanish people will try to implement in a separated
module, but we think other localizations will need it also.
Jordi
Cédric Krier
> In current version of Tryton you can set customer and supplier tax
> rules. But I don't know how to set account mapping rules, I think this
> is a missing feature in Tryton.
>
> Account mapping rules are implemented in OpenERP inside the fiscal
> position object. They allow change some accounts to other accounts in
> an account move created from an invoice for a party using this account
> mapping rules. This feature is very important for some countries, like
> Spain.
Could you explain exactly what is it? With an example/scenario/use case.
> Also the concept of "Fiscal position" make things easier for the
> accountants, because it is easier to set a fiscal position to a party
> (fiscal position as a customer and fiscal position as a supplier) than
> a set of tax mapping rules and a set of account mapping rules for
> customer and supplier.
For me, it is the same except the names are different.
> The questions are: Is planned to add this feature in next Tryton
> versions?
Don't know. Explain first why is it needed.
> When?
Idem.
> It is better to be added in the core (account module)
> or in a new module?
Idem.
> If it is not planned to be included in the core of
> Tryton maybe some Spanish people will try to implement in a separated
> module, but we think other localizations will need it also.
Why people always think their country is different?
You should almost never create a module for a country.
You must create a module for a feature.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Korbinian Preisler
We have 2 modules for this and we will publish them as soon as possible.
If Cedric agrees we could integrate the functionality into the core. But
we need to discuss if it should be a module or if it should be
integrated into account module or any other way you like it.
--
Korbinian Preisler
____________________________________
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
Jordi Esteve
On 15/09/11 03:06 -0700, Jordi Esteve wrote:In current version of Tryton you can set customer and supplier tax rules. But I don't know how to set account mapping rules, I think this is a missing feature in Tryton. Account mapping rules are implemented in OpenERP inside the fiscal position object. They allow change some accounts to other accounts in an account move created from an invoice for a party using this account mapping rules. This feature is very important for some countries, like Spain.Could you explain exactly what is it? With an example/scenario/use case.
For example, in Spain we have these 3 main "Fiscal positions":
National: For Spain parties.
Intra-community: For European Union parties.
Extra-community: For the other parties (no EU countries).
For sales of National parties we must use 7000, 7010, 7020, 7030, 7040, 7050 accounts. They are defined in product or product category.
For sales of Intra-community parties we must use 7001, 7011, 7021, 7031, 7041, 7051 accounts. So we need this mapping when we add invoice lines:
7000 -> 7001
7010 -> 7011
7020 -> 7021
7030 -> 7031
7040 -> 7041
7050 -> 7051
For sales of Extra-community parties we must use 7002, 7012, 7022, 7032, 7042, 7052 accounts. So we need this mapping when we add invoice lines:
7000 -> 7002
7010 -> 7012
7020 -> 7022
7030 -> 7032
7040 -> 7042
7050 -> 7052
Also the concept of "Fiscal position" make things easier for the accountants, because it is easier to set a fiscal position to a party (fiscal position as a customer and fiscal position as a supplier) than a set of tax mapping rules and a set of account mapping rules for customer and supplier.For me, it is the same except the names are different.
The questions are: Is planned to add this feature in next Tryton versions?
When?
It is better to be added in the core (account module) or in a new module?
If it is not planned to be included in the core of Tryton maybe some Spanish people will try to implement in a separated module, but we think other localizations will need it also.
Why people always think their country is different? You should almost never create a module for a country. You must create a module for a feature.
Jordi
-- Jordi Esteve Consultor Zikzakmedia SL jes...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL Dr. Fleming, 28, baixos 08720 Vilafranca del Penedès Tel 93 890 2108
Cédric Krier
Ok I see it.
Indeed I doubt about the fact that it is a requirement.
Let me explain how this concept comes in OpenERP:
Once upon a time in a tiny Belgium company, a programmer wanted to import
chart of accounts for many countries in his software. For that he wrote a
script that converted the chart of accounts from an other software (don't
remember if it was Sage, Ciel, Bob or an other).
So the Belgium chart of account got many 70x accounts which was splitted by
type of products, destination countries (in Belgium, in Europe and others)
etc. (I guess it is the same of other countries)
This did not work well with the design of the software and then they added
rules to substitude accounts depending of some parameters.
When I started to implement the Belgium chart of account for Tryton, I look at
it but I found it was really strange to have this split. I read books about
accounting and in Belgium there is an official published minimal account
chart. This chart doesn't make the split indeed it just says that you can use
the accounts from 700 to 707 (and create any number of child-accounts in it).
That's why there is no substitude functionnality in the base of Tryton because
it is not needed.
Indeed I suspect that this split comes from a time where accounting was done
by hand (or spreadsheet) and not with relational database.
Because the main goal for this is just reporting, in Belgium you have the VAT
report to generate (like in any Europe countries) for which you must give
exactly the amount of sale splitted like in the account.
Strange? No, I guess most of the softwares use the accounts for this report but
in Tryton (and also in OpenERP), there is the tax code chart which works like
accounts but is specialy design for taxes reporting and you can get this sale
values from there (using the base tax amount code).
In conclusion, my question is:
Is it really a requirements?
Or is it just because other softwares (or accountants) do this way?
Albert Cervera i Areny
A Dijous, 15 de setembre de 2011 12:47:48, Jordi Esteve va escriure:
> Why people always think their country is different?
> You should almost never create a module for a country.
> You must create a module for a feature.
>
> I agree, so I write this post to know if it is a common need. IMHO it is
> useful for others, so a general module must be done, but the best solution
> is to include this feature in the account module like openerp does.
It may also be worth considering (although maybe in an extension and probably hard to do without a knowledgeable person in the area) the needs for other countries with complex tax rules such as Brazil. I met Renato from Akretion and he explained me some of the things they had to change to adapt it to OpenERP. Even if we didn't implement those needs, maybe understanding them could make the design more flexible for future needs.
They have fiscal positions depending on the address of the company emiting the invoice and the customer receiving it and things like that...
--
Albert Cervera i Areny
Tel: +34 93 553 18 03
Jordi Esteve
> In conclusion, my question is:
>
> Is it really a requirements?
> Or is it just because other softwares (or accountants) do this way?
>
>
Yes, you could say to the accountants: "Tryton does not support it, so
you must change the way you work". But they don't want to change, so it
is a requirement for them that the software must have.
It seems that it is also needed in Germany and Preisler & Spallek GbR
has developed 2 modules to solve it. Is this feature enough important to
be included in the core?
--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
M�bil 679 170 693
Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Pened�s
Tel 93 890 2108
Albert Cervera i Areny
A Dijous, 15 de setembre de 2011 13:51:09, C�dric Krier va escriure:
> In conclusion, my question is:
>
> ����Is it really a requirements?
> ����Or is it just because other softwares (or accountants) do this way?
AFAIK it is indeed a requirement and it is defined by both official charts of accounts defined in Spain. In fact, the Spanish chart of accounts is really huge compared to those of other countries (~760 accounts if I'm not mistaken).
Cédric Krier
> A Dijous, 15 de setembre de 2011 13:51:09, Cédric Krier va escriure:
> > In conclusion, my question is:
> >
> > Is it really a requirements?
> > Or is it just because other softwares (or accountants) do this way?
>
> AFAIK it is indeed a requirement and it is defined by both official charts of
> accounts defined in Spain. In fact, the Spanish chart of accounts is really
> huge compared to those of other countries (~760 accounts if I'm not mistaken).
Have you a link?
Cédric Krier
> A Dijous, 15 de setembre de 2011 12:47:48, Jordi Esteve va escriure:
> > Why people always think their country is different?
> > You should almost never create a module for a country.
> > You must create a module for a feature.
> >
> > I agree, so I write this post to know if it is a common need. IMHO it is
> > useful for others, so a general module must be done, but the best solution
> > is to include this feature in the account module like openerp does.
>
> It may also be worth considering (although maybe in an extension and probably
> hard to do without a knowledgeable person in the area) the needs for other
> countries with complex tax rules such as Brazil. I met Renato from Akretion
> and he explained me some of the things they had to change to adapt it to
> OpenERP. Even if we didn't implement those needs, maybe understanding them
> could make the design more flexible for future needs.
>
> They have fiscal positions depending on the address of the company emiting the
> invoice and the customer receiving it and things like that...
The tax rules are designed to be flexible so you can add any kind of extra
conditional fields.
Cédric Krier
> En/na Cédric Krier ha escrit:
> >In conclusion, my question is:
> >
> > Is it really a requirements?
> > Or is it just because other softwares (or accountants) do this way?
> >
> In Spain the accountants do this way, so it is a requirement for them.
Why do they do this way? What is the purpose?
> Yes, you could say to the accountants: "Tryton does not support it,
> so you must change the way you work".
It doesn't change the way they work because they want to have it automaticly.
> It seems that it is also needed in Germany and Preisler & Spallek
> GbR has developed 2 modules to solve it. Is this feature enough
> important to be included in the core?
Don't know yet as it is unsure that it is a real requirement nor what is the
purpose of this.
Albert Cervera i Areny
A Dijous, 15 de setembre de 2011 14:17:56, C�dric Krier va escriure:
> On 15/09/11 14:08 +0200, Albert Cervera i Areny wrote:
> > A Dijous, 15 de setembre de 2011 13:51:09, C�dric Krier va escriure:
> > > In conclusion, my question is:
> > > Is it really a requirements?
> > > Or is it just because other softwares (or accountants) do this way?
> >
> > AFAIK it is indeed a requirement and it is defined by both official
> > charts of accounts defined in Spain. In fact, the Spanish chart of
> > accounts is really huge compared to those of other countries (~760
> > accounts if I'm not mistaken).
>
> Have you a link?
Hey! You were right! It's not in the official account plan! I was looking at default OpenERP one (which I didn't create myself) and thought it had the official accounts only. So it's not a requirement from a legal point of view.
Several of our customers are certainly using this, though, but I'm unsure their purpose. Probably, as you said, it's simply because they're used to it and they want to see all the sales they did to countries outside Spain, for example.
IMHO we could try to give them an alternative if it's better. At the same time I must say that we have not managed to convince some customers to use a single partner account and they have insisted a lot in using an account per partner. So it's not always easy to make users understand that they do not need to work as they have always done, so non-legal needs become as important as legal ones.
Cédric Krier
> A Dijous, 15 de setembre de 2011 14:17:56, Cédric Krier va escriure:
> > On 15/09/11 14:08 +0200, Albert Cervera i Areny wrote:
> > > > In conclusion, my question is:
> > > > Is it really a requirements?
> > > > Or is it just because other softwares (or accountants) do this way?
> > >
> > > AFAIK it is indeed a requirement and it is defined by both official
> > > charts of accounts defined in Spain. In fact, the Spanish chart of
> > > accounts is really huge compared to those of other countries (~760
> > > accounts if I'm not mistaken).
> >
> > Have you a link?
>
> Hey! You were right! It's not in the official account plan! I was looking at
> default OpenERP one (which I didn't create myself) and thought it had the
> official accounts only. So it's not a requirement from a legal point of view.
:-)
Will be good to know the German guys.
> Several of our customers are certainly using this, though, but I'm unsure
> their purpose. Probably, as you said, it's simply because they're used to it
> and they want to see all the sales they did to countries outside Spain, for
> example.
It will be good to know.
If it is for reporting, it is far from the best solution because you could ask
for per countries, per continent etc.
> IMHO we could try to give them an alternative if it's better. At the same time
> I must say that we have not managed to convince some customers to use a single
> partner account and they have insisted a lot in using an account per partner.
But that's a understandable request even if it generates more work and he not
required to have a working accounting on relation database.
> So it's not always easy to make users understand that they do not need to work
> as they have always done, so non-legal needs become as important as legal
> ones.
Except if there is no real usage of it or there is replacement :-)
Korbinian Preisler
> On 15/09/11 16:49 +0200, Albert Cervera i Areny wrote:
> > A Dijous, 15 de setembre de 2011 14:17:56, Cédric Krier va escriure:
> > > On 15/09/11 14:08 +0200, Albert Cervera i Areny wrote:
> > > > A Dijous, 15 de setembre de 2011 13:51:09, Cédric Krier va escriure:
> > > > > In conclusion, my question is:
> > > > > Is it really a requirements?
> > > > > Or is it just because other softwares (or accountants) do this way?
> > > >
> > > > AFAIK it is indeed a requirement and it is defined by both official
> > > > charts of accounts defined in Spain. In fact, the Spanish chart of
> > > > accounts is really huge compared to those of other countries (~760
> > > > accounts if I'm not mistaken).
> > >
> > > Have you a link?
> >
> > Hey! You were right! It's not in the official account plan! I was looking at
> > default OpenERP one (which I didn't create myself) and thought it had the
> > official accounts only. So it's not a requirement from a legal point of view.
>
> :-)
>
> Will be good to know the German guys.
In Germany there is no 'official account chart'. You are free to choose
your account chart. There are some provided by companies or institutions
and some of them are widely used. More than one of them is strutured
like the spanish chart and divides the revenues and expenses by origin
of the customer (or to be more precise, by the tax used on the invoice
for the customer). As for this chart there is a very often used
Import-Export-API we absolutely need to match the requirements of this
account chart to create a competitive software solution for the german
market. So in Germany it is not a requirement from a legal point of
view, too. But it is an requirement to be able to make business with
Tryton accounting here. So if it will not be done in an core module we
will do it in an custom module. We are open to share this development
with others as i stated in a former post.
>
> > Several of our customers are certainly using this, though, but I'm unsure
> > their purpose. Probably, as you said, it's simply because they're used to it
> > and they want to see all the sales they did to countries outside Spain, for
> > example.
>
> It will be good to know.
> If it is for reporting, it is far from the best solution because you could ask
> for per countries, per continent etc.
There is one thing that might be as difficult as convincing Cedric to
put something into the core: To convince an accountant to change his way
of working.
Please consider this to be meant as a joke ;-)
But it is my experience. In many countries there are ways to do
accounting that has been evolved in many decades and it works good since
many decades. And many people will not be open to change their way of
work. Especially on the accounting topic.
>
> > IMHO we could try to give them an alternative if it's better. At the same time
> > I must say that we have not managed to convince some customers to use a single
> > partner account and they have insisted a lot in using an account per partner.
>
> But that's a understandable request even if it generates more work and he not
> required to have a working accounting on relation database.
>
> > So it's not always easy to make users understand that they do not need to work
> > as they have always done, so non-legal needs become as important as legal
> > ones.
>
> Except if there is no real usage of it or there is replacement :-)
>
Especially when you want to provide a working import-export-api for the
chart i mentioned above there is no replacement. The only acceptable way
it to do it this way.
Cédric Krier
I don't see why you need to implement the same unuseful behavior to allow
import/export.
The import/export process could take care of it without bloated Tryton.
The easy way is to look at the invoice for the moves in those accounts.
Jordi Esteve
So we will glad if we could share and improve the development done to implement this feature.
Jordi
-- Jordi Esteve Consultor Zikzakmedia SL jes...@zikzakmedia.com
Mòbil 679 170 693 Zikzakmedia SL Dr. Fleming, 28, baixos 08720 Vilafranca del Penedès Tel 93 890 2108
Korbinian Preisler
Here they are: https://bitbucket.org/ukoma
They are available for 1.8 for the moment.
Suggestions for improvements are welcome.
Cédric Krier
> > In Germany there is no 'official account chart'. You are free to choose
> > your account chart. There are some provided by companies or institutions
> > and some of them are widely used. More than one of them is strutured
> > like the spanish chart and divides the revenues and expenses by origin
> > of the customer (or to be more precise, by the tax used on the invoice
> > for the customer). As for this chart there is a very often used
> > Import-Export-API we absolutely need to match the requirements of this
> > account chart to create a competitive software solution for the german
> > market.
>
> I don't see why you need to implement the same unuseful behavior to allow
> import/export.
> The import/export process could take care of it without bloated Tryton.
> The easy way is to look at the invoice for the moves in those accounts.
Or better look at the tax code of the move.