openerp-l10n-ar-localization team mailing list archive

[Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>]

Gente,

encontré otro detalle, que dirán que boludes, pero me parece muy importante.

Según la GNU General Public License v3.0, Sección "How to Apply These
Terms to Your New Programs", los encabezados de los códigos
recomiendan que tengan la siguiente estructura:

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

Pero Ignacio la cambió un poquito. En vez de poner solo el año del
copyright puso un rango de años. Para tener la menor cantidad de
problemas de licencias voy a cambiar esos encabezados a lo recomendado
por la licencia GPL. Por favor, mantengan ese encabezado sin
modificaciones.

Otra... yo tengo un vicio y pido permiso por ello. Yo edito con VIM
(www.vim.org) y una forma fácil de manter la estructura de los
archivos python es agregarle un comentario que permite configurar ese
editor de forma diferente por archivo. Ese encabezado es:

# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4:

Como ven, el python lo entiende como un comentario, por lo que no
debería afectarles a nadie. Les agradecería que todos voten a favor a
dejar ese comentario :) Please! Por los usuarios y amantes del Vi.

2012/10/1 Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>:
> Hola Ignacio,
>
> estoy mergiando tu código y me encontré con algunos detalles que me
> gustaría discutir con vos:
>
> 1) vat en el objeto re.bank
>
> No hay ninguna parte de OpenERP que utilice vat excepto cuando
> correponde a un objeto res.partner. Si uno quisiera aprovechar esa
> información debería modificar mucho código. Yo llamaría ese tipo de
> columnas como columnas huerfanas, columnas que ningún código tiene
> pensado utilizar, y trataría de evitarlas todo lo posible.
>
> Pero seguro que en algún caso este dato puede ser útil. Cúando? Cuando
> queremos ser clientes o proveedores del banco. En el caso seguro que
> somos clientes, por lo tanto debería ir a la lista de clientes, no
> solo a la lista de bancos.
>
> Lo que me gustaría que ocurra es que el banco esté asociado a un
> partner, y que ese parter tenga el dato del VAT, así cuando generamos
> facturas de proveedor podemos asociar el banco rápidamente. Que
> opinas?
>
> 2) Campo update.
>
> Este campo va a ser un problema. Como te comenté en su momento,
> OpenERP trabaja con el campo 'active' para determinar si el objeto
> está activo o no (addons/base/res/bank.py). Yo preferiría trabajar con
> él y no con algo nuevo, porque la base de datos de OpenERP no está
> pensada como OLAP, sino como transaccional. A la hora de hacer un
> update desactivaría todos los bancos y luego la activaría de nuevo. Lo
> que si, hay que definir una clave primaria a la tabla de bancos para
> no repetirlos en el caso que no exista ningún update.
>
> En el caso de querer utilizar un campo tipo 'update' creo que primero
> deberías leer el siguiente artículo:
> http://en.wikipedia.org/wiki/Slowly_changing_dimension
>
> Eso por ahora.
>
> Abrazo,
> Cristian.