Activity log for bug #740596

Date Who What changed Old value New value Message
2011-03-22 23:43:46 Raphaël Valyi - http://www.akretion.com bug added bug
2011-03-22 23:44:10 Raphaël Valyi - http://www.akretion.com summary [6.0.1][account] payment term line need at least 4 to 5 [6.0.1][account] payment term line need at least 5 to 6 digits
2011-03-22 23:44:21 Raphaël Valyi - http://www.akretion.com summary [6.0.1][account] payment term line need at least 5 to 6 digits [6.0.1][account] payment term line need at least 5 to 6 digits precision
2011-03-22 23:44:50 Raphaël Valyi - http://www.akretion.com description Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payment condition of 0.33 that will instead to 2 payment at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision. Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payment condition of 0.33 that will instead to 2 payment at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits instead of 2. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision.
2011-03-22 23:46:39 Raphaël Valyi - http://www.akretion.com description Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payment condition of 0.33 that will instead to 2 payment at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits instead of 2. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision. Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payments condition of 0.33 that will instead to 2 payment at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits instead of 2. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision.
2011-03-22 23:46:51 Raphaël Valyi - http://www.akretion.com description Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payments condition of 0.33 that will instead to 2 payment at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits instead of 2. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision. Today OpenERP payment term line has only 2 digits. Today we had a case where the supplier imposed 3 payments of a third of the value that was 1350. So he expects exactly 3 payments of 450. But with OpenERP you have to enter a payment condition of 0.33 that will instead to 2 payments at 445.5 and the last payment with the remaining amount, that is 459. Unfortunately this is not what the customer will expect! So I propose to have here a precision of 5 to 6 digits instead of 2. I would prefer 6 or even more. Please increase the number of digits here and make sure there is no premature rounding of the precision.
2011-03-23 09:57:32 Amit Parik openobject-addons: importance Undecided Low
2011-03-23 09:57:32 Amit Parik openobject-addons: status New Confirmed
2011-03-23 09:57:32 Amit Parik openobject-addons: assignee OpenERP R&D Addons Team 3 (openerp-dev-addons3)
2011-03-25 09:35:44 Ashvin Rathod (OpenERP) openobject-addons: status Confirmed In Progress
2011-03-25 09:50:30 Launchpad Janitor branch linked lp:~openerp-dev/openobject-addons/trunk-bug-740596-ara
2011-03-25 09:58:14 Ashvin Rathod (OpenERP) openobject-addons: status In Progress Fix Committed
2011-04-06 05:18:54 Mustufa Rangwala (Open ERP) openobject-addons: status Fix Committed Confirmed
2011-04-26 13:29:59 Mustufa Rangwala (Open ERP) openobject-addons: milestone 6.1
2011-04-27 05:01:58 Ashvin Rathod (OpenERP) openobject-addons: status Confirmed In Progress
2011-04-27 07:11:52 Ashvin Rathod (OpenERP) openobject-addons: status In Progress Fix Committed
2011-05-18 15:35:12 qdp (OpenERP) openobject-addons: status Fix Committed Fix Released