On 13/08/11 08:33 +0200, Albert Cervera i Areny wrote: > A Dijous, 11 d'agost de 2011 14:23:34, Cédric Krier va escriure: > > On 11/08/11 13:01 +0200, Albert Cervera i Areny wrote: > > > 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: > Well I think it's obvious that you'll never the same functionality and that > adding all those fields would make no sense. But in the end that's the > compromise one must face when creating a UI. If one considers creating a > friendly UI instead of a char field expression will always think in user
I don't think it is more friendly. Showing only the meaning information is more friendly than showing a lot of empty fields. > requirements and what are the chances a user needing a "years", "weekday", or > "yearday", etc. There are many options probably no user will ever use. So > years and months is probably enough. > > Another good thing to do in these cases is look at what other applications > do. > The applications I've seen let you introduce months, days and the payment > days It is good to be better than other applications. > > > 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. > > > > You will need to reimplement a relativedelta with less functionnality and > > border cases. I think it is better (KISS) to reuse dateutil > > functionnalities. > > Another problem with this in Spain is making some users write some words in > English. That wouldn't be very welcomed for some of them. Yet if you prefer > we > go for the dateutil expression I have no problem creating a module with a > simplified interface for those users. It is possible to translate those keywords. > > > 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. > > > > Yes for sure the cumulative computation is not easy to understand. > > If we change it for a static computation, it should be replaced not > > appended. Because we must not mix concepts otherwise it adds complexity > > for no advantage as you can the both computation are equivalent. > > Indeed the difficulty is to make the migration from one concept to this > > other but it is doable if we have a Python expression for the > > "precentage". > > Alright. If you agree on that will do it this way. Ok. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpPIkh0MZ3BC.pgp
Description: PGP signature
