Received: by 10.66.79.233 with SMTP id m9mr68167pax.37.1352188850432;
        Tue, 06 Nov 2012 00:00:50 -0800 (PST)
X-BeenThere: tryton@googlegroups.com
Received: by 10.68.75.70 with SMTP id a6ls710289pbw.5.gmail; Tue, 06 Nov 2012
 00:00:49 -0800 (PST)
Received: by 10.66.83.161 with SMTP id r1mr75586pay.28.1352188848630;
        Tue, 06 Nov 2012 00:00:48 -0800 (PST)
Received: by 10.66.83.161 with SMTP id r1mr75585pay.28.1352188848619;
        Tue, 06 Nov 2012 00:00:48 -0800 (PST)
Return-Path: <3sMOYUAYOBiUUSZUPOHPPHMFDPEF.DPNUSZUPOHPPHMFHSPVQT....@codesite.bounces.google.com>
Received: from mail-pb0-f75.google.com (mail-pb0-f75.google.com [209.85.160.75])
        by gmr-mx.google.com with ESMTPS id r4si4475912paz.1.2012.11.06.00.00.48
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 06 Nov 2012 00:00:48 -0800 (PST)
Received-SPF: pass (google.com: domain of 3sMOYUAYOBiUUSZUPOHPPHMFDPEF.DPNUSZUPOHPPHMFHSPVQT....@codesite.bounces.google.com designates 209.85.160.75 as permitted sender) client-ip=209.85.160.75;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of 3sMOYUAYOBiUUSZUPOHPPHMFDPEF.DPNUSZUPOHPPHMFHSPVQT....@codesite.bounces.google.com designates 209.85.160.75 as permitted sender) smtp.mail=3sMOYUAYOBiUUSZUPOHPPHMFDPEF.DPNUSZUPOHPPHMFHSPVQT....@codesite.bounces.google.com
Received: by mail-pb0-f75.google.com with SMTP id rp2so22452pbb.2
        for <tryton@googlegroups.com>; Tue, 06 Nov 2012 00:00:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.78.40 with SMTP id y8mr102561paw.9.1352188848537; Tue, 06
 Nov 2012 00:00:48 -0800 (PST)
Reply-To: codesite-nore...@google.com
X-Generated-By: Google Code
X-GoogleCode-Project: tryton
References: <2-12783229591991143270-2401919592064544624-tryton=googlecode.com@googlecode.com>
 <0-12783229591991143270-2401919592064544624-tryton=googlecode.com@googlecode.com>
In-Reply-To: <2-12783229591991143270-2401919592064544624-tryton=googlecode.com@googlecode.com>
Message-ID: <3-12783229591991143270-2401919592064544624-tryton=googlecode.com@googlecode.com>
Date: Tue, 06 Nov 2012 08:00:48 +0000
Subject: Re: Comment on DunningModule in tryton
From: try...@googlecode.com
To: tryton@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

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.

For more information:
http://code.google.com/p/tryton/wiki/DunningModule