Merge lp://staging/~inddiana/sisb/jose_l10n_ve_withholding_islr_final into lp://staging/sisb

Pregunta:

Por que no hacen estos cambios en el core bug a bug, éstos no estñan en la localización y si te fijas el branch de la localización se testea automático aqui:

http://runbot.openerp.com/openerp-venezuela.html

A mejorarse pronto la cosa visual.

Grandes cambios SIEMPRE generan grandes problemas difíciles de corregir, y si pensamos a futuro contar con plataformas complejas de testing que automaticen los casos éstos branches y grandes cambios darán muchísimo consumos de tiempo mis panas.

Por otra parte:

A nivel técnico:

51 + def create(self,cr,uid,values,context=None):
52 + if values.get('type',False) == 'consu':
53 + raise osv.except_osv(('Error !'), ('No puede crear un producto como consumible !'))
54 + if values['purchase_requisition'] == True:
55 + raise osv.except_osv(('Error !'), ('Debe marcar la opcion solicitud de compra !'))
56 + return super(product_product, self).create(cr,uid,values,context=None)

Esto es una mala práctica, los raise se deben _evitar_ en los creates al menos que estés validando errores de consistencia, es SIEMPRE preferible un contraint para lo que estás evaluando acá.

Otro punto:

Por que copias tooooodo el módulo y simplemente no heredan del original nuestro..... recuerden que nosotros lo tenemos corriendo en varios sitios que le vamos encontrando bugs día a día, creo que es mejor de esa manera o que bombardeen la localizacion con bugs + patchs, así creamos uno más fuerte y documentado, el copy tu pasteo es pan para hoy hambre para mañana (ya nos ha pasado.)

Propongo_ crear en SISB un módulo que se llame igual con sufijo: EXT (de extendido) para poder estabilizarlo y portar lo s cambios poco a poco si quieren mantener uno propio o:

HAcer tantas propuestas de merge como cambios requieran, si se fijan:

Toda nuestra localización pasa cliente a cliente por una lista como ésta de validaciones:

http://yfrog.com/h4au2ebj

Si ustedes comparten una extensión de ñesta antes o despues de probar, avanzaríamos más rápido.

Saludos y disculpen lo largo.....

Sobre la Revisión:

195. By [SISB] Jose Moreno 12 hours ago

    [IMP] Se agrego la dependencia del modulo bank_management al archivo __openerp__.py

Esto es una malísima práctica, incluso haciendo que las retenciones sean desde los pagos como entiendo necesitamos y que actualemente ustedes están mejorando, lo correcto es:

Hacerlo depender de account_voucher (El concepto de la retención desde pago se hará automático en los runbots), hacer un módulo intermedio que casa islr con bank-management (QUe por ahora solo lo requerirán ustedes y que pronto podremos probar en los tests.)

Así se logra que el concepto no explote en producción y la operatividad que DEBEN entiendo agregar desde el pago, sea la única no probada.

SObre la revisión :

194. By [SISB] Jose Moreno 13 hours ago

    [FIX] Se mejora la validacion en el proceso de retenciones, se agrega la validacion al signal del workflow

Segun el commit solo agregas una validación, pero agregas muuuuchas más cosas incluyendo un sequence con next number cableado.... hay que revisar eso creo.

http://bazaar.launchpad.net/~inddiana/sisb/jose_l10n_ve_withholding_islr_final/revision/191

Esta revno esta interesante, por que no la mergeamos al core si me gusto!

Cuentenme y la hacemos.

> Por otra parte:
>
> A nivel técnico:
>
> 51 + def create(self,cr,uid,values,context=None):
> 52 + if values.get('type',False) == 'consu':
> 53 + raise osv.except_osv(('Error !'), ('No puede crear un producto como
> consumible !'))
> 54 + if values['purchase_requisition'] == True:
> 55 + raise osv.except_osv(('Error !'), ('Debe marcar la opcion solicitud
> de compra !'))
> 56 + return super(product_product,
> self).create(cr,uid,values,context=None)
>
> Esto es una mala práctica, los raise se deben _evitar_ en los creates al menos
> que estés validando errores de consistencia, es SIEMPRE preferible un
> contraint para lo que estás evaluando acá.
>

En este punto tienes toda la razón.

> Otro punto:
>
> Por que copias tooooodo el módulo y simplemente no heredan del original
> nuestro..... recuerden que nosotros lo tenemos corriendo en varios sitios que
> le vamos encontrando bugs día a día, creo que es mejor de esa manera o que
> bombardeen la localizacion con bugs + patchs, así creamos uno más fuerte y
> documentado, el copy tu pasteo es pan para hoy hambre para mañana (ya nos ha
> pasado.)
>
>

Simple, nuestro módulo de retención va a tomar otro enfoque muy distinto al que actualmente tiene el módulo de ustedes. En estos tres meses de experiencias con el módulo hemos conseguido muchas diferencias que tienen mas que ver a que sin duda ustedes partieron de las necesidades y procedimientos muy particulares de una empresa, asumiendo siempre los mejores escenario posibles. Al final la ley es una sola y la matemática es la misma.

> Propongo_ crear en SISB un módulo que se llame igual con sufijo: EXT (de

NO

> extendido) para poder estabilizarlo y portar lo s cambios poco a poco si
> quieren mantener uno propio o:
>
> HAcer tantas propuestas de merge como cambios requieran, si se fijan:
>
> Toda nuestra localización pasa cliente a cliente por una lista como ésta de
> validaciones:
>
> http://yfrog.com/h4au2ebj
>
> Si ustedes comparten una extensión de ñesta antes o despues de probar,
> avanzaríamos más rápido.
>
> Saludos y disculpen lo largo.....

Yo propongo que se fortalezca un solo modulo que contenga las. "múltiples"
variantes, porque sino vamos a terminar con dos fotos del mismo módulo y
eso si me preocupa

Saludos
On Mar 31, 2012 10:57 AM, "[SISB] Aristóbulo Meneses" <email address hidden>
wrote:

> > Por otra parte:
> >
> > A nivel técnico:
> >
> > 51 + def create(self,cr,uid,values,context=None):
> > 52 + if values.get('type',False) == 'consu':
> > 53 + raise osv.except_osv(('Error !'), ('No puede crear un producto
> como
> > consumible !'))
> > 54 + if values['purchase_requisition'] == True:
> > 55 + raise osv.except_osv(('Error !'), ('Debe marcar la opcion
> solicitud
> > de compra !'))
> > 56 + return super(product_product,
> > self).create(cr,uid,values,context=None)
> >
> > Esto es una mala práctica, los raise se deben _evitar_ en los creates al
> menos
> > que estés validando errores de consistencia, es SIEMPRE preferible un
> > contraint para lo que estás evaluando acá.
> >
>
> En este punto tienes toda la razón.
>
> > Otro punto:
> >
> > Por que copias tooooodo el módulo y simplemente no heredan del original
> > nuestro..... recuerden que nosotros lo tenemos corriendo en varios
> sitios que
> > le vamos encontrando bugs día a día, creo que es mejor de esa manera o
> que
> > bombardeen la localizacion con bugs + patchs, así creamos uno más fuerte
> y
> > documentado, el copy tu pasteo es pan para hoy hambre para mañana (ya
> nos ha
> > pasado.)
> >
> >
>
> Simple, nuestro módulo de retención va a tomar otro enfoque muy distinto
> al que actualmente tiene el módulo de ustedes. En estos tres meses de
> experiencias con el módulo hemos conseguido muchas diferencias que tienen
> mas que ver a que sin duda ustedes partieron de las necesidades y
> procedimientos muy particulares de una empresa, asumiendo siempre los
> mejores escenario posibles. Al final la ley es una sola y la matemática es
> la misma.
>
> > Propongo_ crear en SISB un módulo que se llame igual con sufijo: EXT (de
>
> NO
>
> > extendido) para poder estabilizarlo y portar lo s cambios poco a poco si
> > quieren mantener uno propio o:
> >
> > HAcer tantas propuestas de merge como cambios requieran, si se fijan:
> >
> > Toda nuestra localización pasa cliente a cliente por una lista como ésta
> de
> > validaciones:
> >
> > http://yfrog.com/h4au2ebj
> >
> > Si ustedes comparten una extensión de ñesta antes o despues de probar,
> > avanzaríamos más rápido.
> >
> > Saludos y disculpen lo largo.....
> --
>
> https://code.launchpad.net/~inddiana/sisb/jose_l10n_ve_withholding_islr_final/+merge/100228
> Your team Industrias Diana is subscribed to branch lp:sisb.
>

El 31 de marzo de 2012 10:57, [SISB] Aristóbulo Meneses <
<email address hidden>> escribió:

> > Por otra parte:
> >
> > A nivel técnico:
> >
> > 51 + def create(self,cr,uid,values,context=None):
> > 52 + if values.get('type',False) == 'consu':
> > 53 + raise osv.except_osv(('Error !'), ('No puede crear un producto
> como
> > consumible !'))
> > 54 + if values['purchase_requisition'] == True:
> > 55 + raise osv.except_osv(('Error !'), ('Debe marcar la opcion
> solicitud
> > de compra !'))
> > 56 + return super(product_product,
> > self).create(cr,uid,values,context=None)
> >
> > Esto es una mala práctica, los raise se deben _evitar_ en los creates al
> menos
> > que estés validando errores de consistencia, es SIEMPRE preferible un
> > contraint para lo que estás evaluando acá.
> >
>
> En este punto tienes toda la razón.
>
> > Otro punto:
> >
> > Por que copias tooooodo el módulo y simplemente no heredan del original
> > nuestro..... recuerden que nosotros lo tenemos corriendo en varios
> sitios que
> > le vamos encontrando bugs día a día, creo que es mejor de esa manera o
> que
> > bombardeen la localizacion con bugs + patchs, así creamos uno más fuerte
> y
> > documentado, el copy tu pasteo es pan para hoy hambre para mañana (ya
> nos ha
> > pasado.)
> >
> >
>
> Simple, nuestro módulo de retención va a tomar otro enfoque muy distinto
> al que actualmente tiene el módulo de ustedes. En estos tres meses de
> experiencias con el módulo hemos conseguido muchas diferencias que tienen
> mas que ver a que sin duda ustedes partieron de las necesidades y
> procedimientos muy particulares de una empresa, asumiendo siempre los
> mejores escenario posibles. Al final la ley es una sola y la matemática es
> la misma.
>

Pero si no explicas TU enfoque no sabremos que tenemos mal nosotros, y no
sumas para acá y restas para allá, por que forkear algo que tiene ya
aplicado VARIOS años de experiencia, y reescrito 3 veces dicho sea de paso,
con 3 meses de revisiones no continuas, me parece que estarás cometiendo un
error.

Te doy un ejemplo de nuestra experiencia:

Nosotros forkeamos VOUCHER en nuestra primera implementación, por
EXACTAMENTE la misma razon que me estás dando _supuestamente_ nosotros
teníamos razones para hacerlo, pero jamás las publicamos.

Cuando salió la versión 6 tuvimos que reescribir TOOOOOODO nuestro módulo y
unirlo al trunk por que TODAS las decisiones que tomamos en arquitectura,
estabas REPETIDAS en el nuevo módulo de OpenERP, entonces, conclusión,
Nosotros perdimos el trabajo, ganamos experiencia, y OpenERP siguió su
camino por separado avanzando 50x más rápido que nosotros.

Hoy: Cuando NO entendemos o NO estamos de acuerdo con OpenERP, invertimos
en propuestas de merge al core y discutir públicamente MIS por ques, en el
90% de los casos hemos ganado, o el resultado ha sido un módulo 100%
compatible con futuras versiones.

Ésto es lo que intenta decir Humberto, creo que la decisión es demasiado
viceral solo forkear por que le darás OTRO enfoque -sin explicar el
enfoque- escribiendolo, en unos meses, -decidido o no- tendremos sustentos
más sólidos-

No cometas errores del pasado , los forks son siempre malo...

El 31 de marzo de 2012 12:34, Nhomar Hernandez (Vauxoo)
<email address hidden>escribió:

> El 31 de marzo de 2012 10:57, [SISB] Aristóbulo Meneses <
> <email address hidden>> escribió:
>
> > > Por otra parte:
> > >
> > > A nivel técnico:
> > >
> > > 51 + def create(self,cr,uid,values,context=None):
> > > 52 + if values.get('type',False) == 'consu':
> > > 53 + raise osv.except_osv(('Error !'), ('No puede crear un
> producto
> > como
> > > consumible !'))
> > > 54 + if values['purchase_requisition'] == True:
> > > 55 + raise osv.except_osv(('Error !'), ('Debe marcar la opcion
> > solicitud
> > > de compra !'))
> > > 56 + return super(product_product,
> > > self).create(cr,uid,values,context=None)
> > >
> > > Esto es una mala práctica, los raise se deben _evitar_ en los creates
> al
> > menos
> > > que estés validando errores de consistencia, es SIEMPRE preferible un
> > > contraint para lo que estás evaluando acá.
> > >
> >
> > En este punto tienes toda la razón.
> >
> > > Otro punto:
> > >
> > > Por que copias tooooodo el módulo y simplemente no heredan del original
> > > nuestro..... recuerden que nosotros lo tenemos corriendo en varios
> > sitios que
> > > le vamos encontrando bugs día a día, creo que es mejor de esa manera o
> > que
> > > bombardeen la localizacion con bugs + patchs, así creamos uno más
> fuerte
> > y
> > > documentado, el copy tu pasteo es pan para hoy hambre para mañana (ya
> > nos ha
> > > pasado.)
> > >
> > >
> >
> > Simple, nuestro módulo de retención va a tomar otro enfoque muy distinto
> > al que actualmente tiene el módulo de ustedes. En estos tres meses de
> > experiencias con el módulo hemos conseguido muchas diferencias que tienen
> > mas que ver a que sin duda ustedes partieron de las necesidades y
> > procedimientos muy particulares de una empresa, asumiendo siempre los
> > mejores escenario posibles. Al final la ley es una sola y la matemática
> es
> > la misma.
> >
>
> Pero si no explicas TU enfoque no sabremos que tenemos mal nosotros, y no
> sumas para acá y restas para allá, por que forkear algo que tiene ya
> aplicado VARIOS años de experiencia, y reescrito 3 veces dicho sea de paso,
> con 3 meses de revisiones no continuas, me parece que estarás cometiendo un
> error.
>
>
El volumen de data que manejamos en 3 meses nos da suficiente base para
analizarlo y decidir que el proceso debe cambiar.

> Te doy un ejemplo de nuestra experiencia:
>
> Nosotros forkeamos VOUCHER en nuestra primera implementación, por
> EXACTAMENTE la misma razon que me estás dando _supuestamente_ nosotros
> teníamos razones para hacerlo, pero jamás las publicamos.
>

Cuando salió la versión 6 tuvimos que reescribir TOOOOOODO nuestro módulo y
> unirlo al trunk por que TODAS las decisiones que tomamos en arquitectura,
> estabas REPETIDAS en el nuevo módulo de OpenERP, entonces, conclusión,
> Nosotros perdimos el trabajo, ganamos experiencia, y OpenERP siguió su
> camino por separado avanzando 50x más rápido que nosotros.
>
> Hoy: Cuando NO entendemos o NO estamos de acuerdo con OpenERP, invertimos
> en propuestas de merge al core y discutir públicamente MIS por ques, en el
> 90% de los casos hemos ganado, o el ...