Move account category in Account

I feel there is no a unique way to define the account for each operation in Tryton.
I saw a mix of journal type (eg. account_statement), standalone field for each standard module (eg. party for defining accounting default, or my module: association).
Doesn’t mean this approach is the incorrect one, but feels a bit inconsistent.

I propose to move, or re-implement “account type” in the account module. so all the module that need it can benefit from it.

Yes each case has its own need.

I do not understand what is inconsistent?

I do not understand what is the proposal? Account Type is already defined in the account module.

Technically it’s implemented in the account_product module that extends the Category model from product. So accounting categories are mixed with product category right now (but you can filter them via the accounting Boolean field).

It’s inconsistent because for defining an account for a product you have the “product/accounting categories” design pattern(a very nice one BTW), and for other thing you have account defined in a Journal, like account_statement, where you need to define a new journal if the statement use different accounts.
I agree my request is a bit vague, but this started because i want use the account categories concept in other modules.

And right so, but maybe each module can implement his “category”, but if you need to define an account for a module configuration, you can define it by selecting a “accounting category” in a many2one field and add some other field were necessary.

For now i want to gather feedback about this first step and if it is a good idea, or just a delusional dream :slight_smile:

Ops afreudian slip… i mean account category and not type(edited the post above)

What are you calling “accounting types”?

What is actually the problem?
For accounting configuration made by accountant like a journal, it is normal to ask to the accountant an account.

Why would you do that?
If it is an accounting module, it should use accounts and if it is a non-accounting module, it should use product.

Sorry i flipped category with type in my mind, fixed above. I meant to say “account category”

Maybe the example is not a good one. But i made in the light of get rid of journal all-together. If the change is made, were the configuration will be stored? This can be a solution (not The solution).

There are some module that don’t use product, but instead use accounting… The example is the association module, were it was decided to not define a new product for the membership, so now there is a “membership type” that define a revenue account.

Those journal (like statement journal) will not be removed.

Well maybe it should use product. But this is a special case because association are not standard companies.
I said we do not need to use product because we do not need the taxes etc. But using a account category is also useless because we still do not need taxes.