Tryton - Issues

 

Issue6987

Title Hide party required for non-deferral accounts
Priority bug Status testing
Superseder Nosy List afibanez, ced, pokoli, reviewbot
Type behavior Components account
Assigned To pokoli Keywords easy, review
Reviews 39031002
View: 39031002

Created on 2017-12-04.16:17:32 by afibanez, last changed by reviewbot.

Messages
review39031002 updated at https://codereview.tryton.org/39031002/#ps20001
review39031002 updated at https://codereview.tryton.org/39031002/#ps1
msg37253 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2017-12-11.17:58:39
here is review39031002
msg37251 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-12-11.17:24:44
I agree the option should be disabled for non-deferral accounts.
msg37250 (view) Author: [hidden] (afibanez) Date: 2017-12-11.17:12:55
Yes, it's for reporting, and we are working on an special report to solve it.

But the bug still exists, so I am agree with pokoli in hide the party_required check for non-defarall accounts
msg37163 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2017-12-07.10:28:11
This is not a supported feature. Indeed, it will probably be too complex to support it. So I will prefer to hide the party_required check for non-defarall accounts. 

Indeed, if the separation is used for reporting purposes, you can probably extract the same information from invoices and show it to the user by using a table query. If you don't explain the requirements, we can not provide better advices.
msg37150 (view) Author: [hidden] (afibanez) Date: 2017-12-05.13:42:30
There is not a clear goal, our customer wants that separation and it's using it.

The point is that the system let you set party_required=True and deferred=False and then fails.

So we think it's a bug, or we don't let put that configuration or we have to fix the "Balance Non-Deferral' process
msg37149 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-12-04.17:16:39
What is the goal of having separate income/expense per party?
msg37148 (view) Author: [hidden] (afibanez) Date: 2017-12-04.16:40:58
When you make a Invoice, if party_required is True Tryton autoassign the party in the move line.
So when we need this configuration? With any account from incomes or expenses that the user needs to keep separated by party.
So that kind of accounts have party_required to True AND deferred to false, because incomes and expenses never are deferred
msg37147 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-12-04.16:24:22
Could you explain what kind of account would require such configuration?
msg37146 (view) Author: [hidden] (afibanez) Date: 2017-12-04.16:17:32
With the base account module you can mark any account with party_required boolean, and Tryton asserts that any movement in this account has a party.
You can set party_required to ANY account.
But if the same account has the boolean deferral set to False, there is a problem. When you try to execute the 'Balance Non-Deferral' wizard it fails because it tries to create a new move line of a party_required=True and it doesn't set the party.
History
Date User Action Args
2017-12-14 09:46:44reviewbotsetmessages: + msg37289
2017-12-11 18:18:08reviewbotsetnosy: + reviewbot
messages: + msg37255
2017-12-11 17:58:40pokolisetstatus: chatting -> testing
reviews: 39031002
messages: + msg37253
keyword: + review
assignedto: pokoli
2017-12-11 17:24:44cedsetpriority: feature -> bug
type: feature request -> behavior
messages: + msg37251
2017-12-11 17:15:09pokolisetstatus: need-eg -> chatting
keyword: + easy
title: Bug in account with party_required=True and deferral=False -> Hide party required for non-deferral accounts
2017-12-11 17:12:55afibanezsetmessages: + msg37250
2017-12-07 10:28:12pokolisetnosy: + pokoli
messages: + msg37163
2017-12-05 13:42:30afibanezsetmessages: + msg37150
2017-12-04 17:16:40cedsetstatus: chatting -> need-eg
messages: + msg37149
2017-12-04 16:40:59afibanezsetmessages: + msg37148

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