Tryton - Issues



Title Account type per balance sign
Priority feature Status chatting
Superseder Nosy List Timitos, ced, pokoli, risto3
Type feature request Components account, account_es
Assigned To Keywords

Created on 2017-06-25.20:29:03 by ced, last changed by ced.

msg53328 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-11-18.17:55:55
I do not know what you are talking about, but there is no party_required on account 42:
Any way, this is off-topic.
msg53327 (view) Author: [hidden] (risto3) Date: 2019-11-18.17:52:00
since 2012 these have been using parties, just like 42x
msg53326 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-11-18.17:48:19
Such case should not use party_required but a new account must be created for each party if it is the willing to keep track for each party.
msg53324 (view) Author: [hidden] (risto3) Date: 2019-11-18.17:35:10
In the French plan, although for many accounts with parties have a movement needed to treat correctly the balance, unfortunately there are others that are not(such as for class 45).
msg53312 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-11-18.13:48:24
Account type is used balance sheet and profit and Loss. Both report agregateall information about all parties into a single type. So it does not affect the party_required flag.
msg53235 (view) Author: [hidden] (risto3) Date: 2019-11-15.22:22:23
balance for an account with party required is on a party basis not on a global account basis... by definition... otherwise there would be no party.
msg53214 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-11-15.14:55:00
> how will this issue take into consideration accounts with party_required?

What do you mean? I do not see any change should be done on accounts with party required.
msg53213 (view) Author: [hidden] (risto3) Date: 2019-11-15.14:47:23
BTW, how will this issue take into consideration accounts with party_required?
msg53132 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-11-11.09:31:27
Once implemented the Spanish chart of accounts should be updated to use this feature. See:
msg34298 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-06-27.14:43:03
This issue is about implementing (and/or improving) msg34227. This is not a place for general discussion.
msg34293 (view) Author: [hidden] (risto3) Date: 2017-06-27.14:11:48
? I made no compete proposal for reports, only to try to alleviate the misrepresentation of the account type (at least as noticed in the French plan) and a suggestion for a filter to simplify a reporting need.

The reports themselves will need to be revisited, naturally, and they *should* be conformant to national standards.

If for example a bank account is 'creditor' (or overdrawn) then the report should have it under liabilities as its current value implies a debt. Otherwise it is a liquid 'asset'. Similar for third-party or auxilliary (partner) accounts.

This doesn't appear to be the case for at least the French plan
and as such presents inexact reports.

I tried creating a new base with a company using simply the minimal account plan and I noticed similar difficulties as with the French plan, hence my suggestion/observation.

Noticing now in the account plan that 'kind' is already there (which is more or less a superset of what I suggested earlier). The difficulty seems to stem from the required secondary 'type' which simply cannot be static for all account types (or rather, 'kinds').

Trial balance and GL *are* static reports and naturally don't normally even refer to these 'types'. (pm: view accounts are still problematic)

From the initial issue problem statement, I believe I read that you maintain that this is an exceptionnal case in a some country (France). 

Can you cite perhaps at least one country where the issue is *not* exhibited? As is logical, it does seems rather pervasive from my limited research.
msg34268 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-06-27.11:46:54
If you do not make required to put all accounts in the report tree, you will miss some. So the current design ensure that every account is places somewhere in the report tree. Your proposal does not ensure that.
msg34267 (view) Author: [hidden] (risto3) Date: 2017-06-27.11:15:19
? best design ? missing accounts ? qu├ęsaco ?
msg34264 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-06-27.10:45:49
It is the best design to have reports with missing accounts.
msg34260 (view) Author: [hidden] (risto3) Date: 2017-06-27.10:22:41
I'm curious as to whether the 'type' should not simply limited to:
- Balance sheet accounts
- Profit and loss accounts
and perhaps
- Special Accounts

Individual accounting plans can then break these types down
into classes for their particular account heirarchy (whether
developed or simplified)

Perhaps it is best left to the various reports to be able to 
then select the accounts into the various sections and eventually 
detailed by specific account balance criteria such as:
 * debitor balance (only take if balance is debitor)
 * creditor balance ("                    " creditor)
 * both debitor or creditor (which is probably the general case)

there may be need for some reports to access as well:
* debit moves (only take the sum of the debit moves)
* credit moves ("                     " credit moves)

this is because the 'type' doesn't change, at least not without
perhaps somewhat radical consequences.
msg34227 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-06-25.20:29:03
Some country has a balance sheet for which the type of account change depending on the balance sign.
I think the best is to add a second type Many2One on account that will be used for negative balance. This new field can stay empty to have the same behavior than now.
Date User Action Args
2019-11-18 17:55:55cedsetmessages: + msg53328
2019-11-18 17:52:01risto3setmessages: + msg53327
2019-11-18 17:48:19cedsetmessages: + msg53326
2019-11-18 17:35:11risto3setmessages: + msg53324
2019-11-18 13:48:25pokolisetmessages: + msg53312
2019-11-15 22:22:23risto3setmessages: + msg53235
2019-11-15 14:55:00pokolisetmessages: + msg53214
2019-11-15 14:47:23risto3setmessages: + msg53213
2019-11-11 09:31:28pokolisetcomponent: + account_es
messages: + msg53132
2017-06-27 14:43:03cedsetmessages: + msg34298

Showing 10 items. Show all history (warning: this could be VERY long)