Retención de impuestos!

Puedes mandar impresión de pantalla de de cada uno de los documentos que
mencionas:
*Configuración de impuestos.
*Factura
*PDF
*XML

El 3 de marzo de 2014, 6:31, Felipe Flores <
<email address hidden>> escribió:

> New question #244886 on openerp-mexico-localization:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Hola antes que todo gracias por lo que hacen.
>
> Tengo un cliente el cual hace retencion de isr e iva, bueno pues me dirijo
> a este menu
> Contabilidad/Configuración/Cuentas/Plantillas/Impuestos/Plantillas
> impuestos
> y especifico que la retencion de iva e isr tambien sea para ventas.
>
> y a la hora de facturar al producto le selecciono lo que es iva, retencion
> de isr y retencion de iva, le doy actualizar.
> ahi en la pantalla de la factura no aparece nada de las retenciones, pero
> le doy validar.
> me manda a validar la factura, me la timbra, me genera el pdf.
>
> y en el PDF si me aparece todo lo seleccionado, lo que es el IVA,
> Retencion de ISR, Retencion de IVA, y todo el calculo y el proceso me lo
> hace excelente.
>
> mi pregunta es la siguiente.
> Porque en el XML no me agrega esos dos impuestos, la Retencion del IVA e
> ISR?
>
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

si.

aqui esta el enlaze

https://drive.google.com/folderview?id=0B0OshsGf-GMPWmZCUXhHQWdlSzA&usp=sharing

espero comentarios, gracias :D

Te falta configurar este dato (ver imagen)
https://drive.google.com/file/d/0BwPeHBuUYqNsekh6SDhPYlpRNWM/edit?usp=sharing

Configura ese campo con los que son IVA's, Retenciones de IVA, ISR,
Retenciones de ISR y el XML los podrá detectar y poner en donde deben de ir.

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

Hola, gracias por tu respuesta, pero aun sigue sin agregarlo al XML, no se, si eso deba de ir en el XML!!!

Seguire investigando. saludos...

Buenas Felipe, acabo de proponer unos cambios a la función que genera el archivo XML para corregir este problema que estás experimentando y que nosotros también hemos experimentado.

La tenemos funcionando correctamente en producción con un cliente, pero es una revisión anterior por lo que algo puede no funcionar correctamente. Te agradecería si la pudieras probar y reportarnos cualquier problema.

Aquí te dejo el link al merge request: https://code.launchpad.net/~atin81/openerp-mexico-localization/fix-retenciones/+merge/211602

Y directamente a la rama donde están los cambios: https://code.launchpad.net/~atin81/openerp-mexico-localization/fix-retenciones

Que tal Felipe,

En la revno 364 de openerp-mexico-localization/7.0 ya esta la corrección sobre esta tema.

Saludos.

También en Vauxoo sufren del síndrome NDH?

Disculpen mi ausencia.

Claro que si los empezare a probar Agustín, les reportare cualquier problema!!

una duda, que es el síndrome de NDH??

Saludos :D

El síndrome de NDH (Not Done Here) significa que los desarrolladores no aceptan ninguna revisión ni corrección al código que no haya sido desarrollado por ellos.

Es algo de lo que sufre OpenERP SA y que en mi opinión limita el crecimiento de la herramienta, y que por lo que veo también lo padecen aquí las personas de Vauxoo.

Es una lástima

Agustín,
Lo que sufrimos nosotros es del sindrome de LCNRLPDM:
La Comunidad No Revisa Las Propuestas de Merge
Si te fijas en las fechas, notarás que ya estaba hecha la propuesta de merge, probada en runbot antes.

No quiero abrir un debate al respecto, porque se que lo que haces son con buenas intenciones.
Sin embargo, nos gustaría quitarnos de todo sindrome habido y por haber, con su colaboración.

Entre más colaboración mejor para todos.

Respecto a OpenERP, nosotros tenemos varios merges aprobados. (Como muchos
otros contribuidores)
Ojo, cumpliendo con las guidelines de la comunidad.
Y muchos otros rechazados.
Y muchas otras mejoradas por ellos mismos (Lo cual a mi me encanta).
Si fundamentara en solo las mp que me han rechazado o las que me han
mejorado, mi fundamento sería inválido.

Para muestra un botón.
Si haces dentro de tu carpeta openerp/7.0/addons
bzr log --include-merged | grep vauxoo
Veras que OpenERP sí acepta merge desarrollado por terceros.

Y en la oml, no es la excepción.

No hay razón alguna para bloquear esta participación.
La cual agradezco.
Agradezco que se reporten bugs, que se generen MP, que se generen parches,
que se hagan preguntas.
Eso contribuyen en mucho a la comunidad de la OML
(OpenERP-Mexico-Localization).

El 9 de abril de 2014, 11:26, Moisés López - http://www.vauxoo.com <
<email address hidden>> escribió:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Moisés López - http://www.vauxoo.com proposed the following answer:
> Agustín,
> Lo que sufrimos nosotros es del sindrome de LCNRLPDM:
> La Comunidad No Revisa Las Propuestas de Merge
> Si te fijas en las fechas, notarás que ya estaba hecha la propuesta de
> merge, probada en runbot antes.
>
> No quiero abrir un debate al respecto, porque se que lo que haces son con
> buenas intenciones.
> Sin embargo, nos gustaría quitarnos de todo sindrome habido y por haber,
> con su colaboración.
>
> Entre más colaboración mejor para todos.
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

@Agustin,
Para hacer esta conversación más productiva, que destructiva, te propongo
algo.
Estoy por hacer un test-yaml para que no vuelva a ocurrir este error, sin
que marque rojo runbot.
Es decir, que después de generado el xml, se valide su estructura, sobre
los productos, cantidades, impuestos... que sean consistentes con la
factura, usando un producto de retenciones, otro de iva, otro sin
impuestos, otro con exentos...

La pregunta es, quieres crear tu propia propuesta de merge, de esto.
Si aceptas, detengo este desarrollo, y quedo en espera de la MP a un tiempo
considerable.
Si no aceptas, no hay problema, sigo con este desarrollo por mi cuenta.

Así contribuimos, aparece tu nombre en la oml, se acepta tu mp desarrollada
por tí...
Te propones como parte del team manager de esta localización.

¿Como ves?

El 9 de abril de 2014, 11:41, Moisés López - http://www.vauxoo.com <
<email address hidden>> escribió:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Moisés López - http://www.vauxoo.com proposed the following answer:
> Respecto a OpenERP, nosotros tenemos varios merges aprobados. (Como muchos
> otros contribuidores)
> Ojo, cumpliendo con las guidelines de la comunidad.
> Y muchos otros rechazados.
> Y muchas otras mejoradas por ellos mismos (Lo cual a mi me encanta).
> Si fundamentara en solo las mp que me han rechazado o las que me han
> mejorado, mi fundamento sería inválido.
>
> Para muestra un botón.
> Si haces dentro de tu carpeta openerp/7.0/addons
> bzr log --include-merged | grep vauxoo
> Veras que OpenERP sí acepta merge desarrollado por terceros.
>
> Y en la oml, no es la excepción.
>
> No hay razón alguna para bloquear esta participación.
> La cual agradezco.
> Agradezco que se reporten bugs, que se generen MP, que se generen parches,
> que se hagan preguntas.
> Eso contribuyen en mucho a la comunidad de la OML
> (OpenERP-Mexico-Localization).
>
>
> El 9 de abril de 2014, 11:26, Moisés López - http://www.vauxoo.com <
> <email address hidden>> escribió:
>
> > Question #244886 on openerp-mexico-localization changed:
> >
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
> >
> > Moisés López - http://www.vauxoo.com proposed the following answer:
> > Agustín,
> > Lo que sufrimos nosotros es del sindrome de LCNRLPDM:
> > La Comunidad No Revisa Las Propuestas de Merge
> > Si te fijas en las fechas, notarás que ya estaba hecha la propuesta de
> > merge, probada en runbot antes.
> >
> > No quiero abrir un debate al respecto, porque se que lo que haces son con
> > buenas intenciones.
> > Sin embargo, nos gustaría quitarnos de todo sindrome habido y por haber,
> > con su colaboración.
> >
> > Entre más colaboración mejor para todos.
> >
> > --
> > You received this question notification because you are an answer
> > contact for openerp-mexico-localization.
> >
>
>
> --
> Moisés López Calderón
> Vauxoo - OpenERP's Gold Partner
> Mobile: (+521) 477-752-22-30
> Office: (+52) 477-773-33-46
> web: http://www.vauxoo.com
> twitter: @vauxoo
> @moylop260
> hangout: <email address hidden>
>
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

Primero que nada, me parece importantísimo aclarar que en ningún momento fue mi intención atacar u ofender, me disculpo si ese sentido tiene mi comentario!

Ahora bien, hablando de este caso único particular, a las pruebas me remito, ve la fecha de mi comentario, 2014-03-18, ve la fecha de creación de la rama de desarrollo de Juan Carlos con la corrección (https://code.launchpad.net/~vauxoo/openerp-mexico-localization/improve-taxes-ret-dev-jc) 2014-03-19.

No digo que ni uds ni OpenERP SA nunca acepten MP de la comunidad, pero de que tienen tendencia a hacer todo de nuevo en casa la tienen, incluso en la lista oficial hace poco se creó un hilo donde uno de los desarrolladores de OpenERP SA daba las razones de porque actuaban de esta manera.

Sólo creo que estando más abiertos a la colaboración de la comunidad, incluso a la hora de crear nuevas características y/o funcionalidades el proyecto podría avanzar más rápido.

De muestra pongo el caso del proyecto de Gitlab(www.gitlab.org) que empezó hace sólo tres años y a la fecha puede ser usado sin problemas como reemplazo para Github y está administrado por un equipo de desarrollo de sólo 5 personas de base, varias de las cuales no estaban presentes al principio del proyecto. Puedes ver sus estadísticas en github: https://github.com/gitlabhq/gitlabhq

Nosotros en la empresa lo usamos hace un año y hemos visto como un alto porcentaje de las funcionalidades han sido contribuciones de programadores ajenos al grupo de trabajo principal.

Con respecto a tu propuesta, que tiempo consideras considerable para crear el test?

Disclaimer: No estoy buscando que mi nombre aparezca en oml, sino apalancar las ventajas de trabajar con software libre para lograr un mejor producto. Si crees que puedo aportar valor a la oml como parte del team manager estoy dispuesto a colaborar, con o sin MP.

@Agustin,
En este caso si tienes razón. Yo estaba revisando otra MP que fue la
situación tal cual la planteo.

Estamos alineados en muchas cosas positivas y son las que me gustaría que
explotáramos.

Hay mucha gente expectadora, y pocos comprometidos, y los comprometidos
debemos de trabajar en equipo.
Hay promesas de apoyo y de subir módulos y se quedan solo en eso.
En la medida que cada vez mas personas nos activemos en esta comunidad, mas
se iran sumando.

Si tu objetivo es apalancar, vamos haciendo esta prueba de concepto, que te
propongo.

Respecto al tiempo, es muy subjetivo, lo unico que quiero evitar es:
Detener mi sprint, y además que se sigan quedando como un bonito sueño los
features. Como ya me ha pasado antes, y atrasar las mejoras debido a esto.
Viendose perjudicada la comunidad.

Y esto es en lo que necesito me apoyes a definir, por ejemplo, no poner un
tiempo fijo a la mejora, pero que no sea que un año después no haya nada.
Mantener una conversación viva en un periodo corto de tiempo (propongo cada
2 semanas), solo para mencionar el estatus de la mejora por launchpad y
saber que no ha quedado al saco roto.

Cosas tan "sencillas" como esas.
Déjame ver como va el sprint en mi equipo, pero si no es este feature,
puede ser cualquier otro, que incluso tu mismo propongas.
 El abr 9, 2014 12:50 PM, "Agustín" <email address hidden>
escribió:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Agustín posted a new comment:
> Primero que nada, me parece importantísimo aclarar que en ningún momento
> fue mi intención atacar u ofender, me disculpo si ese sentido tiene mi
> comentario!
>
> Ahora bien, hablando de este caso único particular, a las pruebas me
> remito, ve la fecha de mi comentario, 2014-03-18, ve la fecha de
> creación de la rama de desarrollo de Juan Carlos con la corrección
> (https://code.launchpad.net/~vauxoo/openerp-mexico-localization/improve-
> taxes-ret-dev-jc) 2014-03-19.
>
> No digo que ni uds ni OpenERP SA nunca acepten MP de la comunidad, pero
> de que tienen tendencia a hacer todo de nuevo en casa la tienen, incluso
> en la lista oficial hace poco se creó un hilo donde uno de los
> desarrolladores de OpenERP SA daba las razones de porque actuaban de
> esta manera.
>
> Sólo creo que estando más abiertos a la colaboración de la comunidad,
> incluso a la hora de crear nuevas características y/o funcionalidades el
> proyecto podría avanzar más rápido.
>
> De muestra pongo el caso del proyecto de Gitlab(www.gitlab.org) que
> empezó hace sólo tres años y a la fecha puede ser usado sin problemas
> como reemplazo para Github y está administrado por un equipo de
> desarrollo de sólo 5 personas de base, varias de las cuales no estaban
> presentes al principio del proyecto. Puedes ver sus estadísticas en
> github: https://github.com/gitlabhq/gitlabhq
>
> Nosotros en la empresa lo usamos hace un año y hemos visto como un alto
> porcentaje de las funcionalidades han sido contribuciones de
> programadores ajenos al grupo de trabajo principal.
>
> Con respecto a tu propuesta, que tiempo consideras considerable para
> crear el test?
>
> Disclaimer: No estoy buscando que mi nombre aparezca en oml, sino
> apalancar las ventajas de trabajar con software libre para lograr un
> mejor producto. Si crees que puedo aportar valor a la oml como parte del
> team manager estoy dispuesto a colaborar, con o sin MP.
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

@Moisés, entonces quedo a la espera de tu respuesta sobre ponerme a trabajar o no con los test, todavía no los he aprendido a hacer, por eso no había subido las actualizaciones que hemos hecho a nuestro módulo de facturación, pero ya es hora de que lo haga.

Puedes irte basando en los test-yaml de la oml, que están actualmente.
Están en formato *.yml

Y para probarlos,
Corres el servidor con el siguiente comando
python -d base_de_datos --log-level=test --test-enable -u
modulo_que_tiene_el_yaml

O lo puedes revisar directamente en runbot
Por ejemplo, aquí apareció tu propuesta de merge del pac.
http://runbot.vauxoo.com/openerp-mexico-maintainer.html#7_0-oml-all-mp-198988

Si gustas, adéntrate a los test-yaml de esta propuesta de merge, y
revísalas en runbot, y cuando te sientas más cómodo, escribes por aquí,
para ver en que estatus vamos en el test de retención de impuestos.

¿Te parece?

2014-04-09 18:21 GMT-05:00 Agustín <email address hidden>:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Agustín posted a new comment:
> @Moisés, entonces quedo a la espera de tu respuesta sobre ponerme a
> trabajar o no con los test, todavía no los he aprendido a hacer, por eso
> no había subido las actualizaciones que hemos hecho a nuestro módulo de
> facturación, pero ya es hora de que lo haga.
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

Ok, entonces yo empiezo a trabajar en los test y te voy reportando con un máximo de 2 semanas de acuerdo a como lo propusiste.

Seguimos en contacto!

Ok, estamos en contacto.
Saludos!

2014-04-10 11:41 GMT-05:00 Agustín <email address hidden>:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Agustín posted a new comment:
> Ok, entonces yo empiezo a trabajar en los test y te voy reportando con
> un máximo de 2 semanas de acuerdo a como lo propusiste.
>
> Seguimos en contacto!
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>

Saludos Moy, he estado aprendiendo sobre TDD en general y sobre el desarrollos de pruebas para OpenERP en particular para poder empezar con los desarrollos que habíamos acordado para esta pregunta.

Considerando que las pruebas deben de realizarse para una sóla unidad o pieza del software encuentro dos aproximaciones diferentes, cada una con sus pros y sus contras, y que marcan dos hojas de ruta diferentes tanto en desarrollo como en ejecución y que además creo que tendrían un serio impacto en el desarrollo a largo plazo de la localización, por eso quiero someterlo a su consideración.

==> Aproximación funcional
Desde el punto de vista funcional, se puede tomar una unidad al proceso de generación del archivo XML con base a una factura capturada en el sistema.

* Ventajas: Sería la aproximación más simple de implementar.

* Desventajas: De acuerdo al código actual, la generación del archivo XML no solamente implica la participación de varias funciones sino también de varios módulos (l10n_mx_facturae y l10n_mx_facturae_pac) a qué módulo se deberían de agregar los test? Si se colocan los test en el modulo de l10n_mx_facturae_pac y se realizan cambios en l10n_mx_facturae que hagan que fallen las pruebas puede llegar a causar confusiones a futuro.

Un mentor me dijo en una ocasión, "lo que no se puede medir no se puede mejorar", de qué manera se puede medir el porcentaje de código cubierto por pruebas unitarias de esta forma?

* Consideraciones adicionales: Evaluar la posible depreciación del módulo l10n_mx_facturae_pac para concentrar toda la funcionalidad en l10n_mx_facturae y evitar confusiones a futuro.

==> Aproximación técnica
Desde el punto de vista del código fuente, se tendría que considerar cada una de las funciones como una entidad separada y escribir una prueba que valide el resultado de cada una. Desde mi punto de vista sería una mejor aproximación a las mejores prácticas de programación actualmente aceptadas.

* Ventajas: Permitiría tener una métrica para medir el avance del desarrollo de pruebas unitarias en la localización. Ayudaría a realizar una sana revisión del proyecto para detectar oportunidades de mejora.
* Desventajas: Sería más difícil y costos de implementar.
Requeriría la refactorización de una importante cantidad del código de la localización ya que actualmente muchas funciones están altamente ligadas entre si.

Hasta aquí mis consideraciones, aclaro que nunca antes he trabajado en base a desarrollo TTD, así que espero la retroalimentación de uds que tiene mayor experiencia.

Hola Agustin,
Una opinion muy personal, es que, es complicado hacer una prueba de solo
validar la funcion que sube al pac, sin contemplar los pasos anteriores.
Tendrias que crear un xml sellado antes, y con fecha reciente cada vez, sin
embargo, si sigues el flujo ya lo tienes.

Por lo cual, estos test son unitarios + integración.
Si falla una pieza de software, ya no podrán avanzar en las demas, tal cual
el flujo lo dicta.

Por lo que, para mi es suficiente con que se pruebe funcion a funcion, con
el resultado de la funcion anterior.

Y considerar todas la casuistica posible, para asegurarse de que esta
pasando por cada ramificación de los ifs.

Saludos

El jueves, 1 de mayo de 2014, Agustín <email address hidden>
escribió:

> Question #244886 on openerp-mexico-localization changed:
> https://answers.launchpad.net/openerp-mexico-localization/+question/244886
>
> Agustín posted a new comment:
> Saludos Moy, he estado aprendiendo sobre TDD en general y sobre el
> desarrollos de pruebas para OpenERP en particular para poder empezar con
> los desarrollos que habíamos acordado para esta pregunta.
>
> Considerando que las pruebas deben de realizarse para una sóla unidad o
> pieza del software encuentro dos aproximaciones diferentes, cada una con
> sus pros y sus contras, y que marcan dos hojas de ruta diferentes tanto
> en desarrollo como en ejecución y que además creo que tendrían un serio
> impacto en el desarrollo a largo plazo de la localización, por eso
> quiero someterlo a su consideración.
>
> ==> Aproximación funcional
> Desde el punto de vista funcional, se puede tomar una unidad al proceso de
> generación del archivo XML con base a una factura capturada en el sistema.
>
> * Ventajas: Sería la aproximación más simple de implementar.
>
> * Desventajas: De acuerdo al código actual, la generación del archivo
> XML no solamente implica la participación de varias funciones sino
> también de varios módulos (l10n_mx_facturae y l10n_mx_facturae_pac) a
> qué módulo se deberían de agregar los test? Si se colocan los test en el
> modulo de l10n_mx_facturae_pac y se realizan cambios en l10n_mx_facturae
> que hagan que fallen las pruebas puede llegar a causar confusiones a
> futuro.
>
> Un mentor me dijo en una ocasión, "lo que no se puede medir no se puede
> mejorar", de qué manera se puede medir el porcentaje de código cubierto
> por pruebas unitarias de esta forma?
>
> * Consideraciones adicionales: Evaluar la posible depreciación del
> módulo l10n_mx_facturae_pac para concentrar toda la funcionalidad en
> l10n_mx_facturae y evitar confusiones a futuro.
>
> ==> Aproximación técnica
> Desde el punto de vista del código fuente, se tendría que considerar cada
> una de las funciones como una entidad separada y escribir una prueba que
> valide el resultado de cada una. Desde mi punto de vista sería una mejor
> aproximación a las mejores prácticas de programación actualmente aceptadas.
>
> * Ventajas: Permitiría tener una métrica para medir el avance del
> desarrollo de pruebas unitarias en la localización. Ayudaría a realizar una
> sana revisión del proyecto para detectar oportunidades de mejora.
> * Desventajas: Sería más difícil y costos de implementar.
> Requeriría la refactorización de una importante cantidad del código de la
> localización ya que actualmente muchas funciones están altamente ligadas
> entre si.
>
> Hasta aquí mis consideraciones, aclaro que nunca antes he trabajado en
> base a desarrollo TTD, así que espero la retroalimentación de uds que
> tiene mayor experiencia.
>
> --
> You received this question notification because you are an answer
> contact for openerp-mexico-localization.
>

--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260
hangout: <email address hidden>