Thanks Cedrick for your answer. 
It is good to know the feature is it being thought before its devolpment. 
My experience is short and i trust in yours recommendations (about how to 
face the feature). 
Can I ask if is already open a blueprint or a issue for the development of 
this feature? How can i follow the subjet o contribute in any case??

Regards! 
Agustín 

El viernes, 18 de diciembre de 2015, 21:10:06 (UTC-3), Cédric Krier 
escribió:
>
> On 2015-12-17 05:58, Agustín Montagna wrote: 
> > Hi everyone, 
> > 
> > In the last time we have been working with different clients in 
> Argentina 
> > that evidences the need of a improve or a new tool in the analytics 
> > modules. Specifically, a feature that allows distribute a cost/revenue 
> line 
> > (in a sale/purchase) over diferents analytics accounts. I've found 
> others 
> > post about this subjet [1]. <https://bugs.tryton.org/issue3620> 
> > 
> > I tried to list the main reasons of this need: 
> > 
> >    - Several Cost are Direct and easily assignable to a cost centre, in 
> >    that cases there is no problem cause the complete line is related or 
> >    imputed to a one cost-centre. 
> >    - Many Cost are indirects, i mean, it is no possible to assign 
> >    completely to a cost-centre (machine, departament, employee, area...) 
> but 
> >    is neceesary to distribute it in a group of annalytics lines. 
> >    - Sometimes, the distribution is proportional, for example, 120$ in 
> >    three annalytics acoounts corresponding 40$ each. Other times the 
> >    distribution is no proportional and its based in diferents criteria. 
> Other 
> >    tipycal example is the distribution of the rent cost in relation with 
> the 
> >    space each cost centre is using. 
> >    - A typical example is the electricity tax. The tax is one ammount, 
> and 
> >    we need to distribute it beetween several areas or departaments, 
> eache one 
> >    with one %. 
> >    - Sometime we need to allocate indirect revenues to one or more cost 
> >    centers in diferents portions. 
> >     
> > SAP uses three kink of distributions rules for example: 
> > 
> > 
> >    - 
> >     
> >    Distribution rules that has a one-to-one relationship with the 
> >    corresponding cost centers. (the one in Tryton) 
> >    - 
> >     
> >    Distribution rules that you create as master data. This kind of 
> >    distribution rule is the most common one. You create it to allocate 
> direct 
> >    and indirect expenses and revenues to one or more cost centers. 
> >    - 
> >     
> >    Distribution rules that you create manually for individual 
> transactions. 
> >    This kind of distribution rule is defined for particular transactions 
> and 
> >    does not affect the distribution rule master data. 
> >     
> > I wonder how can we create a blueprint or a path to design and develop 
> (i 
> > imagine someone maybe could have the develop started...) this features 
> for 
> > the next tryton releases. 
>
> Here is a copy of an answer I made recently about similar question: 
>
> """ 
> As you said the usual need for accounting is on the P&L and not on the 
> Balance. 
> So I think in the base module, we should only have support for this 
> usage and it is what we currently have with the analytic_* modules. 
> For me, the "mandatory" flag on analytic root is only for P&L (maybe we 
> should rename or add an help) (customize module could add on for 
> Balance). And it should be used to only enforce the data to fill on 
> higher document like the sale, purchase and invoice (maybe more if there 
> is need). But it should not prevent to create/post accounting moves. 
>
> Indeed I think we need a report/wizard (probably similar to the new 
> reconciliation) that search for accounting move lines (from P&L) which 
> doesn't respect the mandatory flag and which doesn't have a correct 
> amount (compared to the line debit/credit). The wizard will allow the 
> user to fix those error and so ensure that the analytic chart gives 
> correct values. 
> This wizard should be written to allow to extend the non-valid rule (for 
> example: add Balance check, make mandatory per journal etc.) 
> Finally for performance, we need to have a valid/checked flag on the 
> analytic line (similar to the account.move.line) to be able to check 
> only new/invalid lines. This flag should be reset if new rules are 
> append (those rule should have a date range and idem for mandatory 
> flags). 
>
> Finally, I'm not strictly against having a MatchMixin rule system to 
> fill the analytic of moves but I think it is a complex task to support 
> all cases. 
> Also I think analytic should be used to put more information in the 
> system while with a rule system no information is created and so it is 
> just most of the case a matter of writing the good report (which is less 
> expensive than a good rule system). 
> As you can see for the project_revenue where most of the other system 
> will use analytic, I really think we should use straight link when they 
> are clearly defined. 
> """ 
>
> I could add that for the case of electricity bill, we could imagine to 
> have one temporary analytic account per chart to use on document when 
> the repartition is too much complex. In this case the wizard, I told, 
> could also consider such line as non-valid and request for a correct 
> repartition. 
> Also we could have a wizard that stores repartition schema, a little bit 
> like the move template, that we could apply on any move line. 
>
> Long story short: 
>
> So I think the first step will be to clarify the do/module about the 
> required analytic root. 
> The second will to create the checking wizard. 
> And the third will be to create the repartition template wizard. 
>
> -- 
> Cédric Krier - B2CK SPRL 
> Email/Jabber: [email protected] <javascript:> 
> Tel: +32 472 54 46 59 
> Website: http://www.b2ck.com/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/0a44318b-81e1-4aee-9f07-965fca0f492f%40googlegroups.com.

Reply via email to