Zero-price items
Brian Dunnette
Nicolas Évrard
>Greetings-
Hello,
>We're working to get Tryton set up for our local non-profit, and we're
>running into a problem: we frequently take in donations as well as give
>things away - we'd like to track these as "purchases" and "sales", but by
>default, neither sales nor purchases allow items with a price of zero (at
>least in 1.8.x).
>
>Is there a way to work around this limitation?
What you could do it the following:
- add a boolean field that mark the line as free
- override the function field of sale.line ('get_amount' I think)
that when this boolean field is ticked will return 0
- I guess that for purchase line, it will work the same way
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: nicolas...@b2ck.com
Website: http://www.b2ck.com/
Cédric Krier
> Greetings-
>
> We're working to get Tryton set up for our local non-profit, and we're
> running into a problem: we frequently take in donations as well as give
> things away - we'd like to track these as "purchases" and "sales", but by
> default, neither sales nor purchases allow items with a price of zero (at
> least in 1.8.x).
>
> Is there a way to work around this limitation?
I think it is something we should discuss to improve in the trunk.
Because the required was there to prevent encoding error for line without
price. Perhaps it could be replace with a user warning as we had it now.
For now, you can remove the required states on sale line (and invoice line) it
should work.
--
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/
Brian Dunnette
> We're working to get Tryton set up for our local non-profit, and we'reI think it is something we should discuss to improve in the trunk.
> running into a problem: we frequently take in donations as well as give
> things away - we'd like to track these as "purchases" and "sales", but by
> default, neither sales nor purchases allow items with a price of zero (at
> least in 1.8.x).
>
> Is there a way to work around this limitation?
Because the required was there to prevent encoding error for line without
price. Perhaps it could be replace with a user warning as we had it now.
For now, you can remove the required states on sale line (and invoice line) it
should work.
Ah, okay -- is there a way to change the "required" state of unit_price through the GUI, or is this something that has to be done in the Python files themselves? I looked briefly at sale.py, but the only thing relating to the state of unit_price was this, which didn't give me a clear indication of how the "required" state is set:
887 unit_price = fields.Numeric('Unit Price', digits=(16, 4),888 states={889 'invisible': Not(Equal(Eval('type'), 'line')),890 'required': Equal(Eval('type'), 'line'),891 })
-Brian Dunnette
Paul J Stevens
> sale.py#l888> states={
> sale.py#l889> 'invisible': Not(Equal(Eval('type'), 'line')),
> sale.py#l890> 'required': Equal(Eval('type'), 'line'),
> sale.py#l891> })
Brian,
afaik, you need to override the unit_price field by writing a small
tryton module with a sale.py along these lines:
class SaleLine(ModelSQL, ModelView):
_name = 'sale.line'
_rec_name = 'description'
_description = __doc__
unit_price = fields.Numeric('Unit Price', digits=(16, 4),
states={
'invisible': Not(Equal(Eval('type'), 'line')),
})
SaleLine()
basically dropping the required-ness for unit-price.
However, I feel that this may not be enough - or even completely valid
in the end.
I too find myself in need of being able to add zero-priced invoice lines
to invoices from time to time - which is not supported by tryton
out-of-the-box.
This makes me wonder if perhaps the whole required state machinery needs
to be able to allow zero values on numeric fields to satisfy the
requirement. I'm well aware of where this comes from: in python numeric
values of zero evaluate to False. However, is a business context an
explicit zero-amount is *not* the same as an unspecified amount, or in
other words: 0 is not False, only False is False.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
NFG Net Facilities Group BV___________________________Utrecht_NL
Rob Martin
from Cédric and Nicolas on your question. I've starting reading this
list because I'm considering moving from OpenERP for our customers and
want to get a feel for the software and community, and I'm already
pleased and impressed.
Can I suggest you might want to track the values of your sales and
donations? If the organization is not already tax-exempt under your
country's laws, it may be a future consideration. Retaining a record
of donations (either through a sale or a purchase) might be useful. I
can see where it might be good to track these in product costs, or
analytic accounts (does Tryton do analytic accounts?)
I'd be interested in hearing more about your application if you're
willing to share how you are using Tryton in a non-profit.
Rob Martin
Cédric Krier
> > sale.py#l887> unit_price = fields.Numeric('Unit Price', digits=(16, 4),
> > sale.py#l888> states={
> > sale.py#l889> 'invisible': Not(Equal(Eval('type'), 'line')),
> > sale.py#l890> 'required': Equal(Eval('type'), 'line'),
> > sale.py#l891> })
>
> Brian,
>
> afaik, you need to override the unit_price field by writing a small
> tryton module with a sale.py along these lines:
>
> class SaleLine(ModelSQL, ModelView):
> _name = 'sale.line'
> _rec_name = 'description'
> _description = __doc__
>
> unit_price = fields.Numeric('Unit Price', digits=(16, 4),
> states={
> 'invisible': Not(Equal(Eval('type'), 'line')),
> })
>
> SaleLine()
>
> basically dropping the required-ness for unit-price.
This is not the rigth way. You must modify the states attribute of unit_price
in the __init__ method.
Here you are smashing any other extentions from other modules.
Cédric Krier
> to be able to allow zero values on numeric fields to satisfy the
> requirement. I'm well aware of where this comes from: in python numeric
> values of zero evaluate to False. However, is a business context an
> explicit zero-amount is *not* the same as an unspecified amount, or in
> other words: 0 is not False, only False is False.
Have you ideas about how we could be sure to not have zero-amount per error?
Nicolas Évrard
>> sale.py#l888> states={
>> sale.py#l889> 'invisible': Not(Equal(Eval('type'), 'line')),
>> sale.py#l890> 'required': Equal(Eval('type'), 'line'),
>> sale.py#l891> })
>
>Brian,
>
>afaik, you need to override the unit_price field by writing a small
>tryton module with a sale.py along these lines:
>
>class SaleLine(ModelSQL, ModelView):
> _name = 'sale.line'
> _rec_name = 'description'
> _description = __doc__
>
> unit_price = fields.Numeric('Unit Price', digits=(16, 4),
> states={
> 'invisible': Not(Equal(Eval('type'), 'line')),
> })
>
>SaleLine()
>
>basically dropping the required-ness for unit-price.
Take a look at
http://hg2.tryton.org/2.0/modules/sale/file/5b251acf9448/sale.py#l1328
for a better solution. This will not redefine states globally and is
also better for modularity.
>I too find myself in need of being able to add zero-priced invoice lines
>to invoices from time to time - which is not supported by tryton
>out-of-the-box.
>
>This makes me wonder if perhaps the whole required state machinery needs
>to be able to allow zero values on numeric fields to satisfy the
>requirement. I'm well aware of where this comes from: in python numeric
>values of zero evaluate to False. However, is a business context an
>explicit zero-amount is *not* the same as an unspecified amount, or in
>other words: 0 is not False, only False is False.
I am a strong supporter of this idea.
We are discussing it right now in fact. ;)
I will let Cédric explain his view on this subject but I think that
there is a difference between not having the information and knowing
that this information is 0.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Nicolas Évrard
>> This makes me wonder if perhaps the whole required state machinery needs
>> to be able to allow zero values on numeric fields to satisfy the
>> requirement. I'm well aware of where this comes from: in python numeric
>> values of zero evaluate to False. However, is a business context an
>> explicit zero-amount is *not* the same as an unspecified amount, or in
>> other words: 0 is not False, only False is False.
>
>Have you ideas about how we could be sure to not have zero-amount per error?
You can have a sql constraint and a boolean field.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> >I too find myself in need of being able to add zero-priced invoice lines
> >to invoices from time to time - which is not supported by tryton
> >out-of-the-box.
> >
> >This makes me wonder if perhaps the whole required state machinery needs
> >to be able to allow zero values on numeric fields to satisfy the
> >requirement. I'm well aware of where this comes from: in python numeric
> >values of zero evaluate to False. However, is a business context an
> >explicit zero-amount is *not* the same as an unspecified amount, or in
> >other words: 0 is not False, only False is False.
>
> I am a strong supporter of this idea.
> We are discussing it right now in fact. ;)
>
> I will let Cédric explain his view on this subject but I think that
> there is a difference between not having the information and knowing
> that this information is 0.
We designed the application in the way that if you use a Float (Integer,
Numeric) field you are sure to have a float value (not False).
In other terms, all numeric value are "not null" in the database.
We did this because we thought it makes the development easier and also
because we did not find clear way in the client interface to distinct both
cases.
I think the problem is bigger than that there is some kind of fields where it
will be possible to get a null value (which mean I don't know) and others not.
Possible fields which can handle unknow values:
- Date/DateTime
- Integer/Float/Numeric (if we change it)
Others:
- Char/Text (no difference to display between '' and False/None)
- Many2One (not possible to have unknow value as False/None is no link)
- One2Many
- Many2Many
- Boolean
- Binary
- Selection (we need to put a empty value in the list)
There is many more type of fields where the "unknown" value is not supported.
So for me, there is no problem to implement the "unknown" value in Float
fields but we need to keep the "not zero" mechanism and perhaps keep the
default value for required True.
But as we already need to keep the "unknow" information about a many other
kind of fields into an other field. For me I don't see the need to make this
change. We can always fix the (not so often) cases of "unknown" value for
Float with a Boolean field that will show/hide the field.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> * Cédric Krier [2011-05-12 10:13 +0200]:
> >On 12/05/11 09:45 +0200, Paul J Stevens wrote:
> >>This makes me wonder if perhaps the whole required state machinery needs
> >>to be able to allow zero values on numeric fields to satisfy the
> >>requirement. I'm well aware of where this comes from: in python numeric
> >>values of zero evaluate to False. However, is a business context an
> >>explicit zero-amount is *not* the same as an unspecified amount, or in
> >>other words: 0 is not False, only False is False.
> >
> >Have you ideas about how we could be sure to not have zero-amount per error?
>
> You can have a sql constraint and a boolean field.
Having a checkbox if checked it allow zero amount as unit price.
Like that the user should explicitly says that he want a zero amount price.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Mathias Behrle
> On 12/05/11 09:45 +0200, Paul J Stevens wrote:
> > This makes me wonder if perhaps the whole required state machinery needs
> > to be able to allow zero values on numeric fields to satisfy the
> > requirement. I'm well aware of where this comes from: in python numeric
> > values of zero evaluate to False. However, is a business context an
> > explicit zero-amount is *not* the same as an unspecified amount, or in
> > other words: 0 is not False, only False is False.
>
> Have you ideas about how we could be sure to not have zero-amount per error?
Don't know if it is feasible, but if the validation of required could be made
on type string instead of integer, the difference between 0 and False could be
evaluated:
>>> False == 0
True
>>> 'False' == '0'
False
--
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.: " Re: [tryton] Zero-price items" (Thu, 12 May 2011 10:13:08 +0200):
>
> > On 12/05/11 09:45 +0200, Paul J Stevens wrote:
> > > This makes me wonder if perhaps the whole required state machinery needs
> > > to be able to allow zero values on numeric fields to satisfy the
> > > requirement. I'm well aware of where this comes from: in python numeric
> > > values of zero evaluate to False. However, is a business context an
> > > explicit zero-amount is *not* the same as an unspecified amount, or in
> > > other words: 0 is not False, only False is False.
> >
> > Have you ideas about how we could be sure to not have zero-amount per error?
>
> Don't know if it is feasible, but if the validation of required could be made
> on type string instead of integer, the difference between 0 and False could be
This is the same than dropping the required state
Nicolas Évrard
>> >I too find myself in need of being able to add zero-priced invoice
>> >lines to invoices from time to time - which is not supported by
>> >tryton out-of-the-box.
>> >
>> >This makes me wonder if perhaps the whole required state machinery
>> >needs to be able to allow zero values on numeric fields to satisfy
>> >the requirement. I'm well aware of where this comes from: in
>> >python numeric values of zero evaluate to False. However, is a
>> >business context an explicit zero-amount is *not* the same as an
>> >unspecified amount, or in other words: 0 is not False, only False
>> >is False.
>>
>> I am a strong supporter of this idea. We are discussing it right
>> now in fact. ;)
>>
>> I will let Cédric explain his view on this subject but I think that
>> there is a difference between not having the information and
>> knowing that this information is 0.
>
>We designed the application in the way that if you use a Float
>(Integer, Numeric) field you are sure to have a float value (not
>False). In other terms, all numeric value are "not null" in the
>database. We did this because we thought it makes the development
>easier and also because we did not find clear way in the client
>interface to distinct both cases.
It makes it easier to (sometimes) use a wrong value. I would rather
having a ValueError because I am trying to use None in a numerical
context (and thus displaying a problem in my code) than silently pass
this error and having a computation with no meaning what so ever.
A way to make the distinction in the client would be an empty field
which means "I don't know".
>I think the problem is bigger than that there is some kind of fields
>where it will be possible to get a null value (which mean I don't
>know) and others not.
>
>Possible fields which can handle unknow values:
>
> - Date/DateTime
> - Integer/Float/Numeric (if we change it)
>
>Others:
>
> - Char/Text (no difference to display between '' and False/None)
> - Many2One (not possible to have unknow value as False/None is no
> link)
An empty values means either means that you don't know or that there
is no value. It is the same ambiguity there is currently with the 0 in
numeric fields.
> - One2Many
> - Many2Many
> - Boolean
> - Binary
> - Selection (we need to put a empty value in the list)
But I am overall ok with this list.
>There is many more type of fields where the "unknown" value is not
>supported.
>
>So for me, there is no problem to implement the "unknown" value in
>Float fields but we need to keep the "not zero" mechanism and perhaps
>keep the default value for required True.
I don't think this is a good idea. If a numeric field is required then
people have to input a value. There might be a good default defined in
the module but we don't know which value this is and we should not
choose one from one of the א0 value available in integer or (א1 if
we're talking about floats).
>But as we already need to keep the "unknow" information about a many
>other kind of fields into an other field. For me I don't see the need
>to make this change. We can always fix the (not so often) cases of
>"unknown" value for Float with a Boolean field that will show/hide
>the field.
The unknown value is problematic only when the field is required. In
this case we must have a way to discriminate between "unkwown" values
and any other valid values, otherwise not knowing the value of a field
is not problem.
Choosing not to reduce the ambiguity is in my opinion more error prone
than the other way around
Remember:
>>> import this
>>> The Zen of Python, by Tim Peters
>>>
>>> Beautiful is better than ugly.
>>> Explicit is better than implicit.
>>> Simple is better than complex.
>>> Complex is better than complicated.
>>> Flat is better than nested.
>>> Sparse is better than dense.
>>> Readability counts.
>>> Special cases aren't special enough to break the rules.
>>> Although practicality beats purity.
>>> Errors should never pass silently.
>>> Unless explicitly silenced.
>>> In the face of ambiguity, refuse the temptation to guess.
>>> There should be one-- and preferably only one --obvious way to do
>>> it.
>>> Although that way may not be obvious at first unless you're Dutch.
>>> Now is better than never.
>>> Although never is often better than *right* now.
>>> If the implementation is hard to explain, it's a bad idea.
>>> If the implementation is easy to explain, it may be a good idea.
>>> Namespaces are one honking great idea -- let's do more of those!
In the face of ambiguity, refuse the temptation to guess ...
Which is not what we are doing when 0 has two meaning.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Nicolas Évrard
>> * Cédric Krier [2011-05-12 10:13 +0200]:
>> >On 12/05/11 09:45 +0200, Paul J Stevens wrote:
>> >>This makes me wonder if perhaps the whole required state machinery needs
>> >>to be able to allow zero values on numeric fields to satisfy the
>> >>requirement. I'm well aware of where this comes from: in python numeric
>> >>values of zero evaluate to False. However, is a business context an
>> >>explicit zero-amount is *not* the same as an unspecified amount, or in
>> >>other words: 0 is not False, only False is False.
>> >
>> >Have you ideas about how we could be sure to not have zero-amount per error?
>>
>> You can have a sql constraint and a boolean field.
>
>Having a checkbox if checked it allow zero amount as unit price.
>Like that the user should explicitly says that he want a zero amount price.
That's what I said.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> * Cédric Krier [2011-05-12 11:03 +0200]:
> >supported.
> >
> >So for me, there is no problem to implement the "unknown" value in
> >Float fields but we need to keep the "not zero" mechanism and perhaps
> >keep the default value for required True.
>
> I don't think this is a good idea. If a numeric field is required then
> people have to input a value. There might be a good default defined in
> the module but we don't know which value this is and we should not
> choose one from one of the א0 value available in integer or (א1 if
> we're talking about floats).
You did not understand.
I mean the current "required" parameter on Float fields means "!= 0".
And in this possible migration we will replace the meaning of "required" by a
new parameter "nonzero". And I think it will be a good idea to have as default
value for the new "required" parameter "True" like that we keep the same
behavior by default.
> >But as we already need to keep the "unknow" information about a many
> >other kind of fields into an other field. For me I don't see the need
> >to make this change. We can always fix the (not so often) cases of
> >"unknown" value for Float with a Boolean field that will show/hide
> >the field.
>
> The unknown value is problematic only when the field is required. In
> this case we must have a way to discriminate between "unkwown" values
> and any other valid values, otherwise not knowing the value of a field
> is not problem.
>
> Choosing not to reduce the ambiguity is in my opinion more error prone
> than the other way around
In the explicit case of the sale line, there is no unknown value possible.
The user must enter a value in the field and when I write the module I was
thinking that it is good the prevent the user to forget to enter a price.
For me, there is no ambiguity once you accept that a Float field will always
have a float value. Indeed I remember to have to fix a lot of error in OpenERP
where this is not the case (but the GUI doesn't allow "unknown" values) and
most of the time the fix was simply "value or 0.0". So I think I prefer a
framework where the common cases are handle by default.
In the business application world, I really think there are few places where
we need to deal with "unknown" values.
That is why I say that we could extend the Float behavior but the default
should stay as it is now.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Nicolas Évrard
>> * Cédric Krier [2011-05-12 11:03 +0200]:
>> >There is many more type of fields where the "unknown" value is not
>> >supported.
>> >
>> >So for me, there is no problem to implement the "unknown" value in
>> >Float fields but we need to keep the "not zero" mechanism and perhaps
>> >keep the default value for required True.
>>
>> I don't think this is a good idea. If a numeric field is required then
>> people have to input a value. There might be a good default defined in
>> the module but we don't know which value this is and we should not
>> choose one from one of the א0 value available in integer or (א1 if
>> we're talking about floats).
>
>You did not understand.
>I mean the current "required" parameter on Float fields means "!= 0".
>And in this possible migration we will replace the meaning of "required" by a
>new parameter "nonzero". And I think it will be a good idea to have as default
>value for the new "required" parameter "True" like that we keep the same
>behavior by default.
You're not clear. What do you mean ?
You want to rename "required" to "nonzero" for numerical fields ?
If so then this will no settle the situation.
Or maybe you want to add a nonzero parameter. Which does not seems
useful to me.
>> >But as we already need to keep the "unknow" information about a many
>> >other kind of fields into an other field. For me I don't see the need
>> >to make this change. We can always fix the (not so often) cases of
>> >"unknown" value for Float with a Boolean field that will show/hide
>> >the field.
>>
>> The unknown value is problematic only when the field is required. In
>> this case we must have a way to discriminate between "unkwown" values
>> and any other valid values, otherwise not knowing the value of a field
>> is not problem.
>>
>> Choosing not to reduce the ambiguity is in my opinion more error prone
>> than the other way around
>
>In the explicit case of the sale line, there is no unknown value possible.
>The user must enter a value in the field and when I write the module I was
>thinking that it is good the prevent the user to forget to enter a price.
Yes there is no unknown value allowed, thus the field should be
required. If the user want this value to be 0, so be it. Right now
this use case does not work.
By having the unit_price field required with a default value of
unknow (thus leaving the field empty) would have trigger validation of
the form and the user would then have the opportunity to insert the
right value.
Adding a checkbox so that the user agree to let the value to zero is
another problem.
>For me, there is no ambiguity once you accept that a Float field will always
>have a float value.
A Float field should only have a numerical value if it is required to
do so. Do you expect Date Field to always have a date value so that
you can do all kind of date operation on them ? Do you expect Many2One
field to have a non NULL value ? No, unless those fields are required.
I think that it should work the same way for numerical fields.
>Indeed I remember to have to fix a lot of error in OpenERP
>where this is not the case (but the GUI doesn't allow "unknown" values) and
>most of the time the fix was simply "value or 0.0". So I think I prefer a
>framework where the common cases are handle by default.
Invoking the big bad wolf ;).
I am more incline to think that those fixes displayed more a bad
design in openerp modules than the need to always have numerical value
for numerical fields.
>In the business application world, I really think there are few places where
>we need to deal with "unknown" values.
Every non required field could be "unknownable". If you want them to
have a value (whatever it is) then the field must become required.
>That is why I say that we could extend the Float behavior but the default
>should stay as it is now.
This might be a compromise. But I prefer that we implement client side
validation (with the domain inversion like we talked about earlier)
and using this mechanism.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Nicolas Évrard
>Hi Brian,
Hello Rob,
>I'd like to say I'm thrilled with responses you've gotten
>from Cédric and Nicolas on your question. I've starting reading this
>list because I'm considering moving from OpenERP for our customers and
>want to get a feel for the software and community, and I'm already
>pleased and impressed.
Good to ear that ! :D
Thanks.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
Again, required attribute on Float fields doesn't mean "not null". It means
"non zero". And this feature is important because we used in many places (I
counted 45 fields using this feature) where we don't allow zero as value.
So we can rename it into nonzero if we add a required attribute that means
"not null".
> >For me, there is no ambiguity once you accept that a Float field will always
> >have a float value.
>
> A Float field should only have a numerical value if it is required to
> do so. Do you expect Date Field to always have a date value so that
> you can do all kind of date operation on them ? Do you expect Many2One
> field to have a non NULL value ? No, unless those fields are required.
>
> I think that it should work the same way for numerical fields.
There is also a big issue when accepting null in float field, it is that SQL
doesn't SUM (or other operation) between float and NULL.
> >In the business application world, I really think there are few places where
> >we need to deal with "unknown" values.
>
> Every non required field could be "unknownable". If you want them to
> have a value (whatever it is) then the field must become required.
But this is not possible for almost all the fields (see the list).
What I want to say is that it is a feature not very important and compared to
the time it will take to implement/test, there is really a lot of other stuffs
to do.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Nicolas Évrard
>> >You did not understand.
>> >I mean the current "required" parameter on Float fields means "!=
>> >0". And in this possible migration we will replace the meaning of
>> >"required" by a new parameter "nonzero". And I think it will be a
>> >good idea to have as default value for the new "required"
>> >parameter "True" like that we keep the same behavior by default.
>>
>> You're not clear. What do you mean ? You want to rename "required"
>> to "nonzero" for numerical fields ? If so then this will no settle
>> the situation.
>>
>> Or maybe you want to add a nonzero parameter. Which does not seems
>> useful to me.
>
>Again, required attribute on Float fields doesn't mean "not null". It
>means "non zero". And this feature is important because we used in
>many places (I counted 45 fields using this feature) where we don't
>allow zero as value.
I know this is not the right name.
>So we can rename it into nonzero if we add a required attribute that
>means "not null".
That's what I understood. As I said only renaming will not change the
situation, only make it worse. I like the idea of having the required
attribute having the usual meaning and adding the client side
validation.
>> >For me, there is no ambiguity once you accept that a Float field
>> >will always have a float value.
>>
>> A Float field should only have a numerical value if it is required
>> to do so. Do you expect Date Field to always have a date value so
>> that you can do all kind of date operation on them ? Do you expect
>> Many2One field to have a non NULL value ? No, unless those fields
>> are required.
>>
>> I think that it should work the same way for numerical fields.
>
>There is also a big issue when accepting null in float field, it is
>that SQL doesn't SUM (or other operation) between float and NULL.
Indeed.
But this could be fix in numerous way.
>> >In the business application world, I really think there are few
>> >places where we need to deal with "unknown" values.
>>
>> Every non required field could be "unknownable".
>
>But this is not possible for almost all the fields (see the list).
The goal of this change is to remove one ambiguity. I know that it is
not possible to do it for all fields.
>> If you want them to have a value (whatever it is) then the field
>> must become required.
>
>What I want to say is that it is a feature not very important and
>compared to the time it will take to implement/test, there is really
>a lot of other stuffs to do.
Maybe it is not the most important, but there is a small conceptual
problem there.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Dominique Chabord
is what you propose compatible with the following idea, or is my
question idiot ? :
A future module implements a kind of sale packaging. Sale price is the
summ of components.
product A is priced 100.00
product B is bonus of -100.00
summ is 0
will product C=package(A+B) correct ?
for sure C is not free from the accounting standpoint.
thx
--
Dominique Chabord - SISalp
Logiciel libre pour l'entreprise : Gestion (ERP) et applications web2
18 avenue Beauregard 74960 Cran Gevrier
145A rue Alexandre Borrely 83000 Toulon
t�l +33(0)950274960 fax +33(0)955274960 mob +33(0)622616438
http://sisalp.fr - http://sisalp.org - http://bdll.fr
Brian Dunnette
> Can I suggest you might want to track the values of your sales and
> donations? If the organization is not already tax-exempt under your
> country's laws, it may be a future consideration. Retaining a record
> of donations (either through a sale or a purchase) might be useful. I
> can see where it might be good to track these in product costs, or
> analytic accounts (does Tryton do analytic accounts?)
ERP system: to keep records of these in-flows and out-flows, even though
things might not have an explicit "price" (and, even more so, for the
things that *do* have prices!)
Other Free Geek affiliates have used home-brewed software to do this,
but when I noticed that Tryton already tracked most of what we needed
(finance, inventory, scheduling/timesheets), I lobbied for us to use it,
instead (why reinvent the wheel, no?)
We're still in the early stages, but I'll try to keep everyone posted on
our experience...
Brian Dunnette
> On 12/05/11 10:30 +0200, Nicolas �vrard wrote:
>> * C�dric Krier [2011-05-12 10:13 +0200]:
>>> On 12/05/11 09:45 +0200, Paul J Stevens wrote:
>>>> This makes me wonder if perhaps the whole required state machinery needs
>>>> to be able to allow zero values on numeric fields to satisfy the
>>>> requirement. I'm well aware of where this comes from: in python numeric
>>>> values of zero evaluate to False. However, is a business context an
>>>> explicit zero-amount is *not* the same as an unspecified amount, or in
>>>> other words: 0 is not False, only False is False.
>>> Have you ideas about how we could be sure to not have zero-amount per error?
>> You can have a sql constraint and a boolean field.
> Having a checkbox if checked it allow zero amount as unit price.
> Like that the user should explicitly says that he want a zero amount price.
>
explicitly set unit_price_required (or whatever) to False for donated
items, seems like we'd be set!
Rob Martin
Brian, just looked at your VCF. Minneapolis? We're in Milwaukee - practically neighbors ;-)
Cédric Krier
> hello
>
> is what you propose compatible with the following idea, or is my
> question idiot ? :
>
> A future module implements a kind of sale packaging. Sale price is the
> summ of components.
> product A is priced 100.00
> product B is bonus of -100.00
> summ is 0
> will product C=package(A+B) correct ?
> for sure C is not free from the accounting standpoint.
For the record, the discussion took place at
http://www.tryton.org/~irclog/fr/2011-05-12.log.html#t2011-05-12_14:49
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Mathias Behrle
Whether small or not, I think it is important;). JFTR: we had to eliminate the
'required' on unit_price already long time ago, because for us (in Germany)
there are many use cases for invoice lines with amount 0.
I like very much the idea to have 'required' and 'nonzero'.
Brian Dunnette
> Whether small or not, I think it is important;). JFTR: we had to eliminate the
> 'required' on unit_price already long time ago, because for us (in Germany)
> there are many use cases for invoice lines with amount 0.
"required"?
Brian Dunnette
Mathias Behrle
You must define in a module depending on account_invoice something like:
def __init__(self):
super(InvoiceLine, self).__init__()
self.unit_price = copy.copy(self.unit_price)
if self.unit_price.states is None:
self.unit_price.states = {
'invisible': Not(Equal(Eval('type'), 'line')),
}
elif 'required' in self.unit_price.states:
del self.unit_price.states['required']
self._reset_columns()
This will not remove the NOT NULL constraint in the database, which for us is
not a problem in this case, but wished behavior.
Paul J Stevens
> You must define in a module depending on account_invoice something like:
Given your original post you will most likely need to follow this
pattern for InvoiceLine, SaleLine and PurchaseLine and depend your
module on account_invoice, sale and purchase.
Cédric Krier
> > >What I want to say is that it is a feature not very important and
> > >compared to the time it will take to implement/test, there is really
> > >a lot of other stuffs to do.
> >
> > Maybe it is not the most important, but there is a small conceptual
> > problem there.
>
> Whether small or not, I think it is important;).
We talk here about the split of required and nonzero, not about the zero unit
price issue.
> JFTR: we had to eliminate the
> 'required' on unit_price already long time ago, because for us (in Germany)
> there are many use cases for invoice lines with amount 0.
It would have been good to talk about this at this time.
I have create the issue2022 [1] for this.
> I like very much the idea to have 'required' and 'nonzero'.
I think we all agree that it will be good but not absolutly required.
So patch is welcome :-)
[1] https://bugs.tryton.org/roundup/issue2022
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Mathias Behrle
> On 12/05/11 18:29 +0200, Mathias Behrle wrote:
> > > >What I want to say is that it is a feature not very important and
> > > >compared to the time it will take to implement/test, there is really
> > > >a lot of other stuffs to do.
> > >
> > > Maybe it is not the most important, but there is a small conceptual
> > > problem there.
> >
> > Whether small or not, I think it is important;).
>
> We talk here about the split of required and nonzero, not about the zero unit
> price issue.
I am talking about this, too.
> > JFTR: we had to eliminate the
> > 'required' on unit_price already long time ago, because for us (in Germany)
> > there are many use cases for invoice lines with amount 0.
>
> It would have been good to talk about this at this time.
Open answer: there were times in the past being very painful for those
discussions. And IIRC we had some discussion in IRC at the time.
> I have create the issue2022 [1] for this.
Good.
> > I like very much the idea to have 'required' and 'nonzero'.
>
> I think we all agree that it will be good but not absolutly required.
> So patch is welcome :-)
Hmm. For me it would be more important to have a real 'required' instead of
'nonzero' for numbers, because the latter can be checked easily...;)
lists.j...@symetrie.com
Le 11 mai 2011 à 21:27, Nicolas Évrard a écrit :
> What you could do it the following:
>
> - add a boolean field that mark the line as free
> - override the function field of sale.line ('get_amount' I think)
> that when this boolean field is ticked will return 0
> - I guess that for purchase line, it will work the same way
I proposed myself to try to solve this issue.
Would it be an acceptable solution :
— add a boolean "Givable" on product to tell it can be given for free
— add a "Free" checkbox next to the list_price field on the sale_line_view_form
— set unit_price to 0.0 when "Free" checkbox is checked on the sale_line_view_form
— set unit_price to readonly state when "Free" checkbox is checked on the sale_line_view_form
— change SaleLine required state for unit_price to accept a 0.0 value when "Free" checkbox is checked
Jean-Christophe Michel
--
Symétrie
livres et partitions, édition multimédia
30 rue Jean-Baptiste Say
69001 LYON (FRANCE)
tél +33 (0)478 29 52 14
fax +33 (0)478 30 01 11
web www.symetrie.com