Hi Goran,
Having a constraint at SQL centralizes and secures the control (for
additional modules etc) and maintenance is easier.
Duplication of data in aml would allow to avoid cross table SQL
constraint actually. Besides it would log the storno moves inside the
aml (In case at some point a journal is switched on/off storno)
I am not sure as well about performance impacts: I would say the SQL
constraint tends to be much quicker than Python code.
Eric CAUDAL
Elico Corp
On 04/11/2013 12:14 AM, Goran Kliska wrote:
> Hi Eric,
> I think OpenERP application constraints are reliable - under transaction control if orm is used.
> _check_contra_minus() is not complex - only 5 lines.
> Storno check box at account_move_line would be duplication of data - something we tend to avoid.
> SQL constraints across tables are not standard SQL.
> IMO Application constraint is best option.
> Thanks.
Hi Goran,
Having a constraint at SQL centralizes and secures the control (for
additional modules etc) and maintenance is easier.
Duplication of data in aml would allow to avoid cross table SQL
constraint actually. Besides it would log the storno moves inside the
aml (In case at some point a journal is switched on/off storno)
I am not sure as well about performance impacts: I would say the SQL
constraint tends to be much quicker than Python code.
Eric CAUDAL
Eric Caudal www.elico- corp.com
/CEO/
--
*Elico Corporation, Shanghai branch
/OpenERP Premium Certified Training Partner/ *
Cell: + 86 186 2136 1670
Office: + 86 21 6211 8017/27/37
Skype: elico.corp
<email address hidden> <mailto:<email address hidden>>
http://
Elico Corp contra_ minus() is not complex - only 5 lines.
On 04/11/2013 12:14 AM, Goran Kliska wrote:
> Hi Eric,
> I think OpenERP application constraints are reliable - under transaction control if orm is used.
> _check_
> Storno check box at account_move_line would be duplication of data - something we tend to avoid.
> SQL constraints across tables are not standard SQL.
> IMO Application constraint is best option.
> Thanks.