Payment term changes
Albert Cervera i Areny
Hi,
although at TUL we discussed a little bit about payment terms with the german guys, and it seems that is not much of a problem for them, I'd like to explain a little bit the improvements we're working on, and which we already discussed with B2CK.
The idea is to remove "PaymentTermLineDelay" (which lets the user choose between netdays and end of the month). And replace it with three fields: "months", "days" and "day". Note that months is not the same as 30 days as with months with more or less than exactly 30 days, the due date is different, and that is important in Spain. For the "day" it will be possible to set "31" as a replacement for "end of the month".
"PaymentTermLineType" is also replaced by a selection field which will allow four options. The existing "fixed", "percent" and "remainder" as well as the new "division" option. The latter is more intuitive as allows users to say that the amount is divided by 3 instead of setting the "33.333333" percent.
Another important change is that the whole invoice amount will be passed to payment term lines for calculation instead of the remainder. This means that if an invoice is splitted in three payments, you currently must configure:
first => 33.33333 percent
second => 50 percent
third => remainder
With this change:
first => 33.33333 percent
second => 33.33333 percent
third => remainder
This makes amounts more predictable (apart from being able use the division option).
Out of the standard account_invoice module we're working on two new modules: account_payment_days and account_payment_holidays.
*account_payment_days* will add a new field to party's where one ore more payment days can be configured. That is, if the party has days 10 and 20 as payment days, and after applying the party's payment term the due date is the 5th, it will be moved to the 10th. If the due date is the 11th it will be moved to the 20th (if it's in the 21th, it will be moved to the 10th of next month).
*account_payment_holidays* will depend on account_payment_days and will allow to configure per party payment holidays. That is, periods in which the party will not pay and the due date will automatically be moved after the holidays.
Regarding this module I hesitate how to do it. Should we have a party_holidays module in which we could set when the party closes for holidays? Also, in many companies, those holiday are recurring each year. Any idea on how to make that smart so users do not need to input the holidays each year?
Then, the account_payment_holidays module could add the "does not pay on holidays" checkbox. Opinions?
--
Albert Cervera i Areny
Tel: +34 93 553 18 03
Cédric Krier
> Regarding this module I hesitate how to do it. Should we have a party_holidays
> module in which we could set when the party closes for holidays? Also, in many
> companies, those holiday are recurring each year. Any idea on how to make that
> smart so users do not need to input the holidays each year?
Why not using a calendar to store it. You will get all the power of
recurrent events.
> Then, the account_payment_holidays module could add the "does not pay on
> holidays" checkbox. Opinions?
Just a link to the calendar :-)
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Albert Cervera i Areny
A Dimarts, 29 de novembre de 2011 10:29:19, C�dric Krier va escriure:
> On 29/11/11 09:44 +0100, Albert Cervera i Areny wrote:
> > Regarding this module I hesitate how to do it. Should we have a
> > party_holidays module in which we could set when the party closes for
> > holidays? Also, in many companies, those holiday are recurring each
> > year. Any idea on how to make that smart so users do not need to input
> > the holidays each year?
>
> Why not using a calendar to store it. You will get all the power of
> recurrent events.
Thanks, will take a look at the calendar stuff. Don't know anything about it yet!
>
> > Then, the account_payment_holidays module could add the "does not pay on
> > holidays" checkbox. Opinions?
>
> Just a link to the calendar :-)
--
Albert Cervera i Areny
Mathias Behrle
> although at TUL we discussed a little bit about payment terms with the german
> guys, and it seems that is not much of a problem for them, I'd like to
> explain a little bit the improvements we're working on, and which we already
> discussed with B2CK.
>
> The idea is to remove "PaymentTermLineDelay" (which lets the user choose
> between netdays and end of the month). And replace it with three fields:
> "months", "days" and "day". Note that months is not the same as 30 days as
> with months with more or less than exactly 30 days, the due date is
> different, and that is important in Spain. For the "day" it will be possible
> to set "31" as a replacement for "end of the month".
What do you think about options
month
fixed days
day of month
to be a little bit more clear about the meaning of the options?
end of month should rather be an option on month.
> "PaymentTermLineType" is also replaced by a selection field which will allow
> four options. The existing "fixed", "percent" and "remainder" as well as the
> new "division" option. The latter is more intuitive as allows users to say
> that the amount is divided by 3 instead of setting the "33.333333" percent.
Division is nevertheless the same option as percentage, just in another
representation. For me it should be done like Factor and Rate on UOM, which
depend on each other.
> Another important change is that the whole invoice amount will be passed to
> payment term lines for calculation instead of the remainder. This means that
> if an invoice is splitted in three payments, you currently must configure:
>
> first => 33.33333 percent
> second => 50 percent
> third => remainder
>
> With this change:
>
> first => 33.33333 percent
> second => 33.33333 percent
> third => remainder
Great!
> This makes amounts more predictable (apart from being able use the division
> option).
>
> Out of the standard account_invoice module we're working on two new modules:
> account_payment_days and account_payment_holidays.
>
> *account_payment_days* will add a new field to party's where one ore more
> payment days can be configured. That is, if the party has days 10 and 20 as
> payment days, and after applying the party's payment term the due date is the
> 5th, it will be moved to the 10th. If the due date is the 11th it will be
> moved to the 20th (if it's in the 21th, it will be moved to the 10th of next
> month).
>
> *account_payment_holidays* will depend on account_payment_days and will allow
> to configure per party payment holidays. That is, periods in which the party
> will not pay and the due date will automatically be moved after the holidays.
>
> Regarding this module I hesitate how to do it. Should we have a
> party_holidays module in which we could set when the party closes for
> holidays? Also, in many companies, those holiday are recurring each year. Any
> idea on how to make that smart so users do not need to input the holidays
> each year?
>
> Then, the account_payment_holidays module could add the "does not pay on
> holidays" checkbox. Opinions?
We had similar requirements (to update a common calendar with holidays of for
the country and even more specific for the region), which we solved with
calendar_templates. I just talked with timitos and udono and we will upload the
modules to bitbucket within a short time.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Cédric Krier
> * Betr.: " [tryton-dev] Payment term changes" (Tue, 29 Nov 2011 09:44:20 +0100):
>
> > although at TUL we discussed a little bit about payment terms with the german
> > guys, and it seems that is not much of a problem for them, I'd like to
> > explain a little bit the improvements we're working on, and which we already
> > discussed with B2CK.
> >
> > The idea is to remove "PaymentTermLineDelay" (which lets the user choose
> > between netdays and end of the month). And replace it with three fields:
> > "months", "days" and "day". Note that months is not the same as 30 days as
> > with months with more or less than exactly 30 days, the due date is
> > different, and that is important in Spain. For the "day" it will be possible
> > to set "31" as a replacement for "end of the month".
>
> What do you think about options
>
> month
> fixed days
> day of month
>
> to be a little bit more clear about the meaning of the options?
>
> end of month should rather be an option on month.
The idea is to be close to the API of dateutil [1]
[1]
http://labix.org/python-dateutil#head-ba5ffd4df8111d1b83fc194b97ebecf837add454
Mathias Behrle
+0100):
> On 29/11/11 11:25 +0100, Mathias Behrle wrote:
> > * Betr.: " [tryton-dev] Payment term changes" (Tue, 29 Nov 2011 09:44:20
> > +0100):
> >
> > > although at TUL we discussed a little bit about payment terms with the
> > > german guys, and it seems that is not much of a problem for them, I'd
> > > like to explain a little bit the improvements we're working on, and which
> > > we already discussed with B2CK.
> > >
> > > The idea is to remove "PaymentTermLineDelay" (which lets the user choose
> > > between netdays and end of the month). And replace it with three fields:
> > > "months", "days" and "day". Note that months is not the same as 30 days
> > > as with months with more or less than exactly 30 days, the due date is
> > > different, and that is important in Spain. For the "day" it will be
> > > possible to set "31" as a replacement for "end of the month".
> >
> > What do you think about options
> >
> > month
> > fixed days
> > day of month
> >
> > to be a little bit more clear about the meaning of the options?
> >
> > end of month should rather be an option on month.
>
> The idea is to be close to the API of dateutil [1]
>
> [1]
> http://labix.org/python-dateutil#head-ba5ffd4df8111d1b83fc194b97ebecf837add454
I see. But APIs are for programmers, interfaces for users.
"months", "days" and "day" for me is just a little bit confusing in this
short notation.
"day 31" as a replacement for "end of the month" will be a rather hidden
feature. I think the average user will search this option under month.
Udo Spallek
schrieb Mathias Behrle <mbe...@m9s.biz>:
> * Betr.: " [tryton-dev] Payment term changes" (Tue, 29 Nov 2011
> 09:44:20 +0100):
> > pay on holidays" checkbox. Opinions?
> We had similar requirements (to update a common calendar with
> holidays of for the country and even more specific for the region),
> which we solved with calendar_templates. I just talked with timitos
> and udono and we will upload the modules to bitbucket within a short
> time.
* https://bitbucket.org/ukoma/calendar_template
* https://bitbucket.org/ukoma/calendar_holiday_de
* https://bitbucket.org/ukoma/calendar_holiday_de_by
The modules are just migrated to 2.2, so expect the unexpected ;-)
If you find issues, please use the issue trackers for each module on
bitbucket.
Regards Udo
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen
Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
Albert Cervera i Areny
A Dimarts, 29 de novembre de 2011 11:25:19, Mathias Behrle va escriure:
> > The idea is to remove "PaymentTermLineDelay" (which lets the user choose�
> > between netdays and end of the month). And replace it with three fields:�
> > "months", "days" and "day". Note that months is not the same as 30 days
> > as� with months with more or less than exactly 30 days, the due date is
> > different, and that is important in Spain. For the "day" it will be
> > possible to set "31" as a replacement for "end of the month".
>
> What do you think about options
>
> month
> fixed days
> day of month
>
> to be a little bit more clear about the meaning of the options?
If you set 1 to "months" it will add two months to the invoice date. That is:
Invoice date: 2nd February of 2011
Due date: 2nd March of 2011
If you set 30 to "days" it will add 30 days to the invoice date. That is:
Invoice date: 2nd February of 2011
Due date: 4th March of 2011
If you set 1 to "months" and 25 to "day of month":
Invoice date: 2nd February of 2011
Due date: 25th March of 2011
So the system first adds the number of months, then adds the number of days, and eventually computes the next day of the month.
> end of month should rather be an option on month.
What I've done is create a Checkbox that will set the "day of the month" to 31. I think this way we can keep being user-friendly.
Albert Cervera i Areny
A Dissabte, 3 de desembre de 2011 12:44:37, Albert Cervera i Areny va escriure:
> If you set 1 to "months" it will add two months to the invoice date. That
> is:
Sorry, of course, I meant "one month"
Mathias Behrle
+0100):
> A Dimarts, 29 de novembre de 2011 11:25:19, Mathias Behrle va escriure:
> > > The idea is to remove "PaymentTermLineDelay" (which lets the user choose
> > > between netdays and end of the month). And replace it with three fields:
> > > "months", "days" and "day". Note that months is not the same as 30 days
> > > as with months with more or less than exactly 30 days, the due date is
> > > different, and that is important in Spain. For the "day" it will be
> > > possible to set "31" as a replacement for "end of the month".
> >
> > What do you think about options
> >
> > month
> > fixed days
> > day of month
> >
> > to be a little bit more clear about the meaning of the options?
>
> If you set 1 to "months" it will add one month to the invoice date. That is:
>
> Invoice date: 2nd February of 2011
> Due date: 2nd March of 2011
>
> If you set 30 to "days" it will add 30 days to the invoice date. That is:
>
> Invoice date: 2nd February of 2011
> Due date: 4th March of 2011
>
> If you set 1 to "months" and 25 to "day of month":
>
> Invoice date: 2nd February of 2011
> Due date: 25th March of 2011
>
> So the system first adds the number of months, then adds the number of days,
> and eventually computes the next day of the month.
I didn't have in mind, that those fields will be combined rather than mutual
exclusive. Sounds good.
So I see, that "months", "days" and "day" are reasonable field names, if they
get explanatory help strings.
> > end of month should rather be an option on month.
>
> What I've done is create a Checkbox that will set the "day of the month" to
> 31. I think this way we can keep being user-friendly.
Great.
Jordi Esteve
-- Jordi Esteve Consultor Zikzakmedia SL jes...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL Dr. Fleming, 28, baixos 08720 Vilafranca del Penedès Tel 93 890 2108
Albert Cervera i Areny
A Dimarts, 29 de novembre de 2011 12:29:16, Udo Spallek va escriure:
> Am Tue, 29 Nov 2011 11:25:19 +0100
>
> schrieb Mathias Behrle <mbe...@m9s.biz>:
> > * Betr.: " [tryton-dev] Payment term changes" (Tue, 29 Nov 2011
> >
> > 09:44:20 +0100):
> > > Then, the account_payment_holidays module could add the "does not
> > > pay on holidays" checkbox. Opinions?
> >
> > We had similar requirements (to update a common calendar with
> > holidays of for the country and even more specific for the region),
> > which we solved with calendar_templates. I just talked with timitos
> > and udono and we will upload the modules to bitbucket within a short
> > time.
>
> Done.
>
> * https://bitbucket.org/ukoma/calendar_template
> * https://bitbucket.org/ukoma/calendar_holiday_de
> * https://bitbucket.org/ukoma/calendar_holiday_de_by
>
> The modules are just migrated to 2.2, so expect the unexpected ;-)
> If you find issues, please use the issue trackers for each module on
> bitbucket.
Thank you very much for publishing those modules. That is not exactly what we need for the payment term improvements but they're interesting. However, have some comments which I'll send you in a new thread.
>
> Regards Udo