A Dijous, 11 d'agost de 2011 11:59:56, Cédric Krier va escriure: > On 11/08/11 11:50 +0200, Albert Cervera i Areny wrote: > > A Dijous, 11 d'agost de 2011 11:39:31, Albert Cervera i Areny va escriure: > > > > First of all, let me say that for me it's perfectly ok to implement > > > > that with a python expression and I'm ok with it. At the same time, > > > > however, I'm a bit surprised that you expect end users to use those > > > > things. Maybe it's not a problem for current Tryton audience but it > > > > certainly is for many of the users I meet daily. > > > > > > I don't think it is too complicate to ask to the user to enter > > > something > > > > > > like: > > > months=2, days=15, day=-1 > > > > > > As soon as there is a good help message and/or a documentation (that > > > could link to the dateutil one). > > > > Well, thinking of several of our customers I'd say some of them would be > > calling quite frequently if they had something like this. However, we > > (NaN or whoever is interested) can create a new module to simplify the > > interface for those customers and most frequent Spanish market needs. > > Have you a better UI idea?
Not to cover all cases. For me the approach of adding the functionalities I added with another module was ok. But doing as you suggest is ok for me too because we will end up having two modules anyway. Of course an easy to use UI would not cover everything that is possible with python expressions but regarding dates in our case what we would do is (always thinking on Spanish market needs): - Add a payment_days field in account.invoice.payment_term which can accept zero, one or more days of the months (that is from 1 to 31). This is necessary due to the payment days issue we have in Spain and exposed in another thread. - Remove current delay field. - Add a days field. - Add a months field (months added first and days later). With this, we can get similar functionality because end of the month would be achieved by setting '31' on account.invoice.payment_term but prevents from having two payment terms one on day 5 and the other one at the end of the month but have never met the requirement here. Of course, others may have different experiences and needs. > I think it is always better to find a global solution for every needs and > in fallback having custom modules. For me the most important think is that the API is clean as it is. Then I see two approaches: - Create a simple interface that does not have everything and extra things are created using new modules. - Create a powerful interface that does almost everything maybe for non-newbie users and create newbie-ready modules. I think both have pros and cons. By the way, thinking about the API I'd like to add a new parameter with the total amount requested to get_value(). Currently the definition looks like this: def get_value(self, line, amount, currency): and It'd look like this: def get_value(self, line, reminder, currency, total_amount): The total_amount can be interesting for some exotic calculations but mainly it would allow for the division (or another percent concept) to be calculated over the total amount. For example, with the patch if you need to divide the amount in three equal amounts you must create: - Line 1: divisor = 3 - Line 2: divisor = 2 - Line 3: reminder With the total_amount you can create: - Line 1: divisor = 3 - Line 2: divisor = 3 - Line 3: reminder We think that is easier to understand for our users and and has the results they expect too, because accountants usually expect that the last payment have the reminder (the different value) while with current approach the one with a different value may be the second or third payments depending on decimals. Comments? -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
