Comment on DunningModule in tryton
81 views
Skip to first unread message
try...@googlecode.com
Oct 25, 2012, 5:48:38 AM10/25/12
to try...@googlegroups.com
Comment by cedk...@gmail.com:
Here are some comments:
- I don't get the usage of dunning procedures?
- In account.dunning.level, what is the usage of level? The number of days
already give an order.
- In account.dunning.level instead of text, I will use a link to the report
to use.
- In account.dunning.dunning, why storing the dunning_level as it could be
computed, idem for date.
- I would prefer to not extend account.move.line and put all in the dunning
lines.
For more information:
https://code.google.com/p/tryton/wiki/DunningModule
Here are some comments:
- I don't get the usage of dunning procedures?
- In account.dunning.level, what is the usage of level? The number of days
already give an order.
- In account.dunning.level instead of text, I will use a link to the report
to use.
- In account.dunning.dunning, why storing the dunning_level as it could be
computed, idem for date.
- I would prefer to not extend account.move.line and put all in the dunning
lines.
For more information:
https://code.google.com/p/tryton/wiki/DunningModule
try...@googlecode.com
Oct 26, 2012, 5:32:19 PM10/26/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
Thanks for the feedback.
> I don't get the usage of dunning procedures?
Could you go into details about what is unclear?
> In account.dunning.level, what is the usage of level? The number of days
> already give an order.
Agreed, that's redundant and will be removed.
> In account.dunning.level instead of text, I will use a link to the report
> to use.
You mean a Many2One to "ir.action.report"?
> In account.dunning.dunning, why storing the dunning_level as it could be
> computed, idem for date.
Because it could be the case that the interval between two dunning runs is
longer than the time between to dunning levels. For example if no dunning
run is done for some time a receivable entry could be in the second dunning
level according to the days since the maturity date but you nevertheless
don't want to skip the first dunning level and politely remind the customer
before ultimately threaten with legal measures.
> I would prefer to not extend account.move.line and put all in the
> dunning lines.
But the dunning procedure to be applied to the receivable is a property of
the move line itself. What would be the advantage of having an additional
object mapping move lines to dunning procedures?
For more information:
http://code.google.com/p/tryton/wiki/DunningModule
Thanks for the feedback.
> I don't get the usage of dunning procedures?
> In account.dunning.level, what is the usage of level? The number of days
> already give an order.
> In account.dunning.level instead of text, I will use a link to the report
> to use.
> In account.dunning.dunning, why storing the dunning_level as it could be
> computed, idem for date.
longer than the time between to dunning levels. For example if no dunning
run is done for some time a receivable entry could be in the second dunning
level according to the days since the maturity date but you nevertheless
don't want to skip the first dunning level and politely remind the customer
before ultimately threaten with legal measures.
> I would prefer to not extend account.move.line and put all in the
> dunning lines.
the move line itself. What would be the advantage of having an additional
object mapping move lines to dunning procedures?
For more information:
http://code.google.com/p/tryton/wiki/DunningModule
try...@googlecode.com
Nov 5, 2012, 4:51:13 PM11/5/12
to try...@googlegroups.com
Comment by cedk...@gmail.com:
>> I don't get the usage of dunning procedures?
> Could you go into details about what is unclear?
I think it can be dropped and just be managed by level. And if some as
really specific usage case of it it could be added by an other module.
>> In account.dunning.level instead of text, I will use a link to the
>> report to use.
> You mean a Many2One? to "ir.action.report"?
Yes.
>> In account.dunning.dunning, why storing the dunning_level as it could be
>> computed, idem for date.
> Because it could be the case that the interval between two dunning runs
> is longer than the time between to dunning levels. For example if no
> dunning run is done for some time a receivable entry could be in the
> second dunning level according to the days since the maturity date but
> you nevertheless don't want to skip the first dunning level and politely
> remind the customer before ultimately threaten with legal measures.
Ok.
>> I would prefer to not extend account.move.line and put all in the
>> dunning lines.
> But the dunning procedure to be applied to the receivable is a property
> of the move line itself. What would be the advantage of having an
> additional object mapping move lines to dunning procedures?
It is to separate the accounting stuff which has some hard constraint and
the management stuffs.
Moreover, it will simplify the access right management because I don't
think the dunning user will need to have write access to accounting.
>> I don't get the usage of dunning procedures?
> Could you go into details about what is unclear?
really specific usage case of it it could be added by an other module.
>> In account.dunning.level instead of text, I will use a link to the
>> report to use.
Yes.
>> In account.dunning.dunning, why storing the dunning_level as it could be
>> computed, idem for date.
> Because it could be the case that the interval between two dunning runs
> is longer than the time between to dunning levels. For example if no
> dunning run is done for some time a receivable entry could be in the
> second dunning level according to the days since the maturity date but
> you nevertheless don't want to skip the first dunning level and politely
> remind the customer before ultimately threaten with legal measures.
>> I would prefer to not extend account.move.line and put all in the
>> dunning lines.
> But the dunning procedure to be applied to the receivable is a property
> of the move line itself. What would be the advantage of having an
> additional object mapping move lines to dunning procedures?
the management stuffs.
Moreover, it will simplify the access right management because I don't
think the dunning user will need to have write access to accounting.
try...@googlecode.com
Nov 6, 2012, 3:00:48 AM11/6/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
I've added some
[https://bitbucket.org/kantntreiber/trytond_account_dunning/src/d952c442a14503e5948e628a87c8dd63ce1bc1f2/doc/index.rst?at=default
module documentation].
> I think it can be dropped and just be managed by level. And if some as
> really specific usage case of it it could be added by an other module.
I don't think that is possible. It's not a special use case that needs the
definition of dunning procedures but the general one. Dunning procedures
are similar to payment terms. The analogue of dunning levels would be
payment term lines. You cannot get rid of payment terms and just use
payment term lines the same way you can't drop dunning procedures and just
use dunning levels.
The use case is that you have different types of customers you want to
treat differently during dunning. For example, there are some customers
that you want to remind frequently about open receivables and thread with
legal measures soon. There are others that you only politely remind after a
long period of time (e.g. because of their credit worthiness).
> > >You mean a Many2One?? to "ir.action.report"?
> >Yes.
O.K. And the report should be configurable per dunning procedure or per
dunning level? In the first case the report would contain some Relatorio
conditional with different texts for every dunning level which is very
flexible. In the second case the user would have to define 3 identical
reports with only the text being different. What I see as a problem in both
cases, compared to having a fields.Text(translate=True), is that it is
difficult for the user to define translatable texts. And the dunning text
should be translatable as it should match the language of the customer.
> It is to separate the accounting stuff which has some hard constraint and
> the management stuffs. Moreover, it will simplify the access right
> management because I don't think the dunning user will need to have write
> access to accounting.
IMO it *is* accounting stuff and not management stuff. In all companies
that I have seen, dunning is always done by accountants. Some bigger
companies have separate accountants for accounts receivables, accounts
payables and asset accounting etc. In that case it would be done by a
accounts receivable accountant.
I've added some
[https://bitbucket.org/kantntreiber/trytond_account_dunning/src/d952c442a14503e5948e628a87c8dd63ce1bc1f2/doc/index.rst?at=default
module documentation].
> I think it can be dropped and just be managed by level. And if some as
> really specific usage case of it it could be added by an other module.
definition of dunning procedures but the general one. Dunning procedures
are similar to payment terms. The analogue of dunning levels would be
payment term lines. You cannot get rid of payment terms and just use
payment term lines the same way you can't drop dunning procedures and just
use dunning levels.
The use case is that you have different types of customers you want to
treat differently during dunning. For example, there are some customers
that you want to remind frequently about open receivables and thread with
legal measures soon. There are others that you only politely remind after a
long period of time (e.g. because of their credit worthiness).
> > >You mean a Many2One?? to "ir.action.report"?
> >Yes.
O.K. And the report should be configurable per dunning procedure or per
dunning level? In the first case the report would contain some Relatorio
conditional with different texts for every dunning level which is very
flexible. In the second case the user would have to define 3 identical
reports with only the text being different. What I see as a problem in both
cases, compared to having a fields.Text(translate=True), is that it is
difficult for the user to define translatable texts. And the dunning text
should be translatable as it should match the language of the customer.
> It is to separate the accounting stuff which has some hard constraint and
> the management stuffs. Moreover, it will simplify the access right
> management because I don't think the dunning user will need to have write
> access to accounting.
that I have seen, dunning is always done by accountants. Some bigger
companies have separate accountants for accounts receivables, accounts
payables and asset accounting etc. In that case it would be done by a
accounts receivable accountant.
try...@googlecode.com
Nov 6, 2012, 3:37:23 AM11/6/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
Independently of this module, I would suggest adding a section to the
blueprints where we link some current implementations of other ERP systems.
Look at what the [https://live.gnome.org/Design/Apps/Web GNOME people do].
I think it would be beneficial if we discuss advantages and disadvantages
of implementations that already work and how we can improve them. Moreover
it gives the non-programmers a better idea of what we are actually talking
about and makes it easier for them to participate in the discussion.
Independently of this module, I would suggest adding a section to the
blueprints where we link some current implementations of other ERP systems.
Look at what the [https://live.gnome.org/Design/Apps/Web GNOME people do].
I think it would be beneficial if we discuss advantages and disadvantages
of implementations that already work and how we can improve them. Moreover
it gives the non-programmers a better idea of what we are actually talking
about and makes it easier for them to participate in the discussion.
try...@googlecode.com
Nov 6, 2012, 10:02:27 AM11/6/12
to try...@googlegroups.com
Comment by cedk...@gmail.com:
>> I think it can be dropped and just be managed by level. And if some as
>> really specific usage case of it it could be added by an other module.
> I don't think that is possible. It's not a special use case that needs
> the definition of dunning procedures but the general one. Dunning
> procedures are similar to payment terms. The analogue of dunning levels
> would be payment term lines. You cannot get rid of payment terms and just
> use payment term lines the same way you can't drop dunning procedures and
> just use dunning levels.
> The use case is that you have different types of customers you want to
> treat differently during dunning. For example, there are some customers
> that you want to remind frequently about open receivables and thread with
> legal measures soon. There are others that you only politely remind after
> a long period of time (e.g. because of their credit worthiness).
Ok. But naming schema doesn't reflect well the structure.
> > >You mean a Many2One??? to "ir.action.report"?
> >Yes.
> O.K. And the report should be configurable per dunning procedure or per
> dunning level? In the first case the report would contain some Relatorio
> conditional with different texts for every dunning level which is very
> flexible. In the second case the user would have to define 3 identical
> reports with only the text being different. What I see as a problem in
> both cases, compared to having a fields.Text(translate=True), is that it
> is difficult for the user to define translatable texts. And the dunning
> text should be translatable as it should match the language of the
> customer.
I think it should be possible to have different report per level using a
link but it doesn't force to have different reports. We could have a
default one which is using a text from the level.
>> It is to separate the accounting stuff which has some hard constraint
>> and the management stuffs. Moreover, it will simplify the access right
>> management because I don't think the dunning user will need to have
>> write access to accounting.
> IMO it is accounting stuff and not management stuff. In all companies
But there are advantages to not have it.
>> I think it can be dropped and just be managed by level. And if some as
>> really specific usage case of it it could be added by an other module.
> I don't think that is possible. It's not a special use case that needs
> the definition of dunning procedures but the general one. Dunning
> procedures are similar to payment terms. The analogue of dunning levels
> would be payment term lines. You cannot get rid of payment terms and just
> use payment term lines the same way you can't drop dunning procedures and
> just use dunning levels.
> The use case is that you have different types of customers you want to
> treat differently during dunning. For example, there are some customers
> that you want to remind frequently about open receivables and thread with
> legal measures soon. There are others that you only politely remind after
> a long period of time (e.g. because of their credit worthiness).
> > >You mean a Many2One??? to "ir.action.report"?
> >Yes.
> O.K. And the report should be configurable per dunning procedure or per
> dunning level? In the first case the report would contain some Relatorio
> conditional with different texts for every dunning level which is very
> flexible. In the second case the user would have to define 3 identical
> reports with only the text being different. What I see as a problem in
> both cases, compared to having a fields.Text(translate=True), is that it
> is difficult for the user to define translatable texts. And the dunning
> text should be translatable as it should match the language of the
> customer.
link but it doesn't force to have different reports. We could have a
default one which is using a text from the level.
>> It is to separate the accounting stuff which has some hard constraint
>> and the management stuffs. Moreover, it will simplify the access right
>> management because I don't think the dunning user will need to have
>> write access to accounting.
> that I have seen, dunning is always done by accountants. Some bigger
> companies have separate accountants for accounts receivables, accounts
> payables and asset accounting etc. In that case it would be done by a
> accounts receivable accountant.
Any way, I don't see any advantage to have it hard-linked to accounting.
> companies have separate accountants for accounts receivables, accounts
> payables and asset accounting etc. In that case it would be done by a
> accounts receivable accountant.
But there are advantages to not have it.
try...@googlecode.com
Nov 6, 2012, 1:06:57 PM11/6/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
> Ok. But naming schema doesn't reflect well the structure.
You mean ´account.dunning.level´ should be renamed to
´account.dunning.procedure.level´, or what do you propose?
> I think it should be possible to have different report per level using a
> link but it doesn't force to have different reports. We could have a
> default one which is using a text from the level.
O.K., that's the most flexible solution.
> Any way, I don't see any advantage to have it hard-linked to accounting.
> But there are advantages to not have it.
I.e. there should be two different objects, one that maps the move line to
the dunning procedure to be applied (and is automatically created during
the move line creation according to the partner default value) and one that
has all the level advancements?
> Ok. But naming schema doesn't reflect well the structure.
´account.dunning.procedure.level´, or what do you propose?
> I think it should be possible to have different report per level using a
> link but it doesn't force to have different reports. We could have a
> default one which is using a text from the level.
> Any way, I don't see any advantage to have it hard-linked to accounting.
> But there are advantages to not have it.
the dunning procedure to be applied (and is automatically created during
the move line creation according to the partner default value) and one that
has all the level advancements?
try...@googlecode.com
Nov 7, 2012, 4:57:48 PM11/7/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
If there is a report per dunning level, is it possible to print them all
after the last step of the dunning run wizard?
If there is a report per dunning level, is it possible to print them all
after the last step of the dunning run wizard?
try...@googlecode.com
Nov 28, 2012, 10:38:54 AM11/28/12
to try...@googlegroups.com
Comment by albert.n...@gmail.com:
According to [1], dunning may be used for other purposes apart from
demanding the payment of a dept and I think it could make sense for other
purposes. In fact, we currently have a use case for another purpose.
May proposal would be to create a generic module "dunning "
where "account.dunning.procedure" became "dunning.procedure"
and "account.dunning.level" became "dunning.procedure.level". Most of the
logic could be made account independent if necessary a specific
account_dunning module.
[1] http://en.wikipedia.org/wiki/Dunning_(process)
According to [1], dunning may be used for other purposes apart from
demanding the payment of a dept and I think it could make sense for other
purposes. In fact, we currently have a use case for another purpose.
May proposal would be to create a generic module "dunning "
where "account.dunning.procedure" became "dunning.procedure"
and "account.dunning.level" became "dunning.procedure.level". Most of the
logic could be made account independent if necessary a specific
account_dunning module.
[1] http://en.wikipedia.org/wiki/Dunning_(process)
try...@googlecode.com
Nov 29, 2012, 3:19:13 PM11/29/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
Thanks for your feedback.
You're right, the objects names should follow the common naming scheme in
Tryton. I'll change this.
I'm not sure whether it's worth the pain being overly generic because it
makes the code much more complicated.
What is the application you're thinking of?
Thanks for your feedback.
You're right, the objects names should follow the common naming scheme in
Tryton. I'll change this.
I'm not sure whether it's worth the pain being overly generic because it
makes the code much more complicated.
What is the application you're thinking of?
try...@googlecode.com
Dec 9, 2012, 6:19:19 AM12/9/12
to try...@googlegroups.com
Comment by albert.n...@gmail.com:
It is a company that makes discounts if the customer is unemployed. The
customer must send a certificate which is valid for three months, after
this time he would then have to pay the normal prices unless he presents
the unemployment certificate again. They remind the customer a couple of
times that the validity date has been reached.
If the code is too much complicated it may not be worth it, though.
It is a company that makes discounts if the customer is unemployed. The
customer must send a certificate which is valid for three months, after
this time he would then have to pay the normal prices unless he presents
the unemployment certificate again. They remind the customer a couple of
times that the validity date has been reached.
If the code is too much complicated it may not be worth it, though.
try...@googlecode.com
Dec 17, 2012, 1:31:03 AM12/17/12
to try...@googlegroups.com
Comment by kantntre...@gmail.com:
That's an interesting price model.
I want to implement the changes you and Cedric suggested. Refactoring the
dunning status from the move lines into a separate model would be the first
step. After that I'll port to 2.6 and push to codereview.tryton.org. In the
meantime you can have a look at the Bitbucket repository linked in
the "Links" section above.
That's an interesting price model.
I want to implement the changes you and Cedric suggested. Refactoring the
dunning status from the move lines into a separate model would be the first
step. After that I'll port to 2.6 and push to codereview.tryton.org. In the
meantime you can have a look at the Bitbucket repository linked in
the "Links" section above.
Reply all
Reply to author
Forward
0 new messages