Una localización y mucha intención
569 views
Skip to first unread message
Lopez Ignacio
Jun 30, 2014, 1:04:36 PM6/30/14
to odoo-localizacion-argentina
Colegas y amigos,
después de charlar con varios de ustedes y habiendo llegado a esta
situacion tan particular me veo obligado en aclara lo que acordamos y
ampliarlo para que consensuemos nuevamente.
- Nos regimos por la democracia del consenso de la mayorías. Lo que
dicte la mayoría es el camino a seguir.
- En el foro y dentro de la comunidad solo hablamos de conocimiento. De
negocio se charla en forma privada. Esto es porque todos tenemos el
mismo derecho de hacer propaganda y este es un lugar comunal donde
compartimos y buscamos ayuda en conocimiento. Llenarlo de propaganda no
tiene sentido. Ya existen otros espacios donde hacerlo. El tratamiento
es similar al que usan en las universidades donde tambien tienen
intereses comunes algunas empresas. Incluso colaboran con dinero sin que
se pretenda egemonia, ni permanencia.
- Nos regimos por la meritocracia. "Vale mas la mas pequeña accion que
la mejor mayor intención" (Henry Ford). Aún asi todas las voces son
escuchadas y analizadas.
- Lo que consensuamos en las jornadas es que "El primero que comparte
impone su modelo". Esto es para evitar que una empresa o un/varios
programador/es que tiene la localizacion andando para la version nueva,
no espere mucho tiempo para compartirla porque otro puede tomar su
lugar. Porque esto: paso al comienzo de la localización que una empresa
tenia una localización avanzada pero no la compartia para poder vender
mas y acaparar mercado. A la vez esa empresa decia que ya prácticamente
tenia la localización andando y que pronto la sacaria a luz... asi
pasaron los meses hasta que alguien saco su version de la localización
para esa version.
Creo que esta incompleta la regla despues de haber hablado con varios de
ustedes. Debería ser "El primero que comparte impone su modelo, dando a
publicidad el repositorio publico donde se ubica el código compartido".
Es imposible saber que esta haciendo alguien si no lo publica. Habría
que estar entrando todo el tiempo a un repositorios ajenos para ver si
una persona en particular ha avanzado o no en algún tema... es muy
pretencioso.
Estas son las únicas reglas que consensuamos y que hasta ahora nos había
solucionado las mayores controversias.
Como el modelo de Odoo impone que de una versión a otra, hay que hacer
una transformación, pasar de un modelo a otro NO implicaría neseriamente
un problema. Mucho menos para los nuevos... el punto esta en los que ya
vienen usando la localización oficial. Cambiar de modelo tiene varios
puntos buenos y malos:
Lo malo de pasar de modelo:
- Uno ya esta acostumbrado al modelo que traía y sabe lo que se puede y
lo que no. Puede seguir avanzando desde lo que ya anda. Cambiar de
modelo implica adaptarse.
Lo bueno de pasar de modelo:
- Si el nuevo modelo es mas completo, aumenta rápidamente los servicios
que puede brindarnos.
- La empresa que impuso su modelo en la version anterior intentara
adaptar su modelo rapidamente a la nueva para que sea selecionada como
localizacion oficial. Esto impone una dinamica positiva a la localización.
- Se hace mas dificil que una empresa se enquiste y tome el contro de
cuando surja o no la nueva localizacion. La desicion esta en manos de la
comunidad. Esto no quita que alguien tome los módulos que venían y los
adapte sin que sea la propia empresa o los mismo programadores los que
publicaron inicialmente. Despues de la publicación son de dominio público.
- La documentacion de los modulos publicados y subidos debe ser
obligatoria. Tantos los técnicos como los funcionales porque se hace muy
dificil y poco practico estudiar todo el codigo para saber que hace un
modulo y tener en cuenta las restricciones para los usuarios.
Despues de lo dicho llegamos a esta situacion en la que estamos. En un
periodo de transision donde teneiendo una nueva version de Odoo aun
publicada oficialmente y varias localizaciones posibles en versión BETA.
En particular la de Cristian y otra de Juan.
Cristian impuso su localizacion en la version 6 y 7 (la 6 no se concreto
totalmente) y comento que estaba trabajando en la 8. Ahora juan es el
que publica los repositorios donde están los módulos de la version 8.
Entonces surge el dilema que debemos solucionar como comunidad.
Quisiera que las partes expongan sus puntos y que sea la comunidad la
que defina cual modelo tomar ya que ninguno de los dos modelos entiendo
que están completos.
Buena Vida!
Ignacio López
PD: Yo tengo mi opinión que reservo hasta que alla una buena cantidad de
opiniones.
después de charlar con varios de ustedes y habiendo llegado a esta
situacion tan particular me veo obligado en aclara lo que acordamos y
ampliarlo para que consensuemos nuevamente.
- Nos regimos por la democracia del consenso de la mayorías. Lo que
dicte la mayoría es el camino a seguir.
- En el foro y dentro de la comunidad solo hablamos de conocimiento. De
negocio se charla en forma privada. Esto es porque todos tenemos el
mismo derecho de hacer propaganda y este es un lugar comunal donde
compartimos y buscamos ayuda en conocimiento. Llenarlo de propaganda no
tiene sentido. Ya existen otros espacios donde hacerlo. El tratamiento
es similar al que usan en las universidades donde tambien tienen
intereses comunes algunas empresas. Incluso colaboran con dinero sin que
se pretenda egemonia, ni permanencia.
- Nos regimos por la meritocracia. "Vale mas la mas pequeña accion que
la mejor mayor intención" (Henry Ford). Aún asi todas las voces son
escuchadas y analizadas.
- Lo que consensuamos en las jornadas es que "El primero que comparte
impone su modelo". Esto es para evitar que una empresa o un/varios
programador/es que tiene la localizacion andando para la version nueva,
no espere mucho tiempo para compartirla porque otro puede tomar su
lugar. Porque esto: paso al comienzo de la localización que una empresa
tenia una localización avanzada pero no la compartia para poder vender
mas y acaparar mercado. A la vez esa empresa decia que ya prácticamente
tenia la localización andando y que pronto la sacaria a luz... asi
pasaron los meses hasta que alguien saco su version de la localización
para esa version.
Creo que esta incompleta la regla despues de haber hablado con varios de
ustedes. Debería ser "El primero que comparte impone su modelo, dando a
publicidad el repositorio publico donde se ubica el código compartido".
Es imposible saber que esta haciendo alguien si no lo publica. Habría
que estar entrando todo el tiempo a un repositorios ajenos para ver si
una persona en particular ha avanzado o no en algún tema... es muy
pretencioso.
Estas son las únicas reglas que consensuamos y que hasta ahora nos había
solucionado las mayores controversias.
Como el modelo de Odoo impone que de una versión a otra, hay que hacer
una transformación, pasar de un modelo a otro NO implicaría neseriamente
un problema. Mucho menos para los nuevos... el punto esta en los que ya
vienen usando la localización oficial. Cambiar de modelo tiene varios
puntos buenos y malos:
Lo malo de pasar de modelo:
- Uno ya esta acostumbrado al modelo que traía y sabe lo que se puede y
lo que no. Puede seguir avanzando desde lo que ya anda. Cambiar de
modelo implica adaptarse.
Lo bueno de pasar de modelo:
- Si el nuevo modelo es mas completo, aumenta rápidamente los servicios
que puede brindarnos.
- La empresa que impuso su modelo en la version anterior intentara
adaptar su modelo rapidamente a la nueva para que sea selecionada como
localizacion oficial. Esto impone una dinamica positiva a la localización.
- Se hace mas dificil que una empresa se enquiste y tome el contro de
cuando surja o no la nueva localizacion. La desicion esta en manos de la
comunidad. Esto no quita que alguien tome los módulos que venían y los
adapte sin que sea la propia empresa o los mismo programadores los que
publicaron inicialmente. Despues de la publicación son de dominio público.
- La documentacion de los modulos publicados y subidos debe ser
obligatoria. Tantos los técnicos como los funcionales porque se hace muy
dificil y poco practico estudiar todo el codigo para saber que hace un
modulo y tener en cuenta las restricciones para los usuarios.
Despues de lo dicho llegamos a esta situacion en la que estamos. En un
periodo de transision donde teneiendo una nueva version de Odoo aun
publicada oficialmente y varias localizaciones posibles en versión BETA.
En particular la de Cristian y otra de Juan.
Cristian impuso su localizacion en la version 6 y 7 (la 6 no se concreto
totalmente) y comento que estaba trabajando en la 8. Ahora juan es el
que publica los repositorios donde están los módulos de la version 8.
Entonces surge el dilema que debemos solucionar como comunidad.
Quisiera que las partes expongan sus puntos y que sea la comunidad la
que defina cual modelo tomar ya que ninguno de los dos modelos entiendo
que están completos.
Buena Vida!
Ignacio López
PD: Yo tengo mi opinión que reservo hasta que alla una buena cantidad de
opiniones.
Mariano Ruiz
Jun 30, 2014, 4:06:29 PM6/30/14
to odoo-localiza...@googlegroups.com
Antes de empezar a intentar consensuar, y teniendo en cuenta lo posteado por Ignacio acerca del código, ¿podrían Cristian y Juan publicar o darnos el link de los correspondientes códigos en Github? Porque es difícil elegir sin saber donde está el código, se que Juan lo publicó en otro post, no se el caso de Cristian que tal vez lo posteó en algún otro hilo hablando de algún otro tema en particular.
Sería bueno que ambos repos estén identificados inequívocamente en este hilo para poder discutir. En cuanto a la votación que sugerí en el post anterior, fue solo una sugerencia, no tengo creo el mérito como para imponer una votación, yo solo estoy contribuyendo en lo que es el foro, en los repos colaboré creo con bastante código de OpenERP pero que no es de la localización, así que organizar una votación sobre eso tal vez no sea lo más adecuado que lo plantee yo, mejor hablemos de votar luego de tener los repos visibles para todos para poder hacer una evaluación antes de decidir.
Sería bueno que ambos repos estén identificados inequívocamente en este hilo para poder discutir. En cuanto a la votación que sugerí en el post anterior, fue solo una sugerencia, no tengo creo el mérito como para imponer una votación, yo solo estoy contribuyendo en lo que es el foro, en los repos colaboré creo con bastante código de OpenERP pero que no es de la localización, así que organizar una votación sobre eso tal vez no sea lo más adecuado que lo plantee yo, mejor hablemos de votar luego de tener los repos visibles para todos para poder hacer una evaluación antes de decidir.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para obtener más opciones, visita https://groups.google.com/d/optout.
--
Cristian Sebastian Rocha
Jun 30, 2014, 4:14:52 PM6/30/14
to odoo-localiza...@googlegroups.com
Mariano,
aquí está mi versión 8.0
Saludos,
Cristian.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Coop. de Trab. Moldeo Interactive Lmt.
Cristian Sebastian Rocha
Consultor Analista.
Bonpland 2363 Of 303
(C1425FWE) CABA, Argentina.
(+54-9-11).6800.0269
http://interactive.moldeo.coop
Cristian Sebastian Rocha
Consultor Analista.
Bonpland 2363 Of 303
(C1425FWE) CABA, Argentina.
(+54-9-11).6800.0269
http://interactive.moldeo.coop
Juan José Scarafía (ADHOC)
Jun 30, 2014, 6:55:07 PM6/30/14
to odoo-localiza...@googlegroups.com
Acá esta el código de la propuesta (ahora directamente en el branch master)
y el video donde lo mostramos
Saludos!
Ing. Juan José Scarafía
(+54 9 341)153 278039
skype: jjscarafia
twitter: @jjscarafia
github: @jjscarafia
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Laureano Kloss
Jun 30, 2014, 7:33:32 PM6/30/14
to odoo-localiza...@googlegroups.com
Gente, muy buenas las discusiones y los aportes que se están armando, les dejamos un enlace a los módulos del Proyecto Aconcagua para ver si se puede aprovechar o utilizar alguna funcionalidad
https://github.com/ProyectoAconcagua
el canal de youtube donde encontrar videos con algunas funcionalidades explicadas
https://github.com/ProyectoAconcagua
el canal de youtube donde encontrar videos con algunas funcionalidades explicadas
https://www.youtube.com/user/ProyectoAconcagua
más información para la instalación
http://eynes.com.ar/proyecto-aconcagua-instalacion-de-los-modulos-del-proyecto-aconcagua/
http://eynes.com.ar/proyecto-aconcagua-instalacion-de-los-modulos-del-proyecto-aconcagua/
http://www.proyectoaconcagua.com.ar/
--
Director de proyectos
www.eynes.com.ar
www.proyectoaconcagua.com.ar
Skype eynes_ar
Tel. +54 11 4730 1870 - Mov. 15 62625425
Francia 4091 - Vicente Lopez
Buenos Aires - Argentina
--
--
Director de proyectos
www.eynes.com.ar
www.proyectoaconcagua.com.ar
Skype eynes_ar
Tel. +54 11 4730 1870 - Mov. 15 62625425
Francia 4091 - Vicente Lopez
Buenos Aires - Argentina
Director de proyectos
www.eynes.com.ar
www.proyectoaconcagua.com.ar
Skype eynes_ar
Tel. +54 11 4730 1870 - Mov. 15 62625425
Francia 4091 - Vicente Lopez
Buenos Aires - Argentina
Juan José Scarafía (ADHOC)
Jul 1, 2014, 10:00:59 AM7/1/14
to odoo-localiza...@googlegroups.com
Bueno, la verdad es que me perdí un poco y ya no sé ni donde estamos parados.
Coincido con intentar decidir en los dos temas que sugirió Mariano:
1. Primero resolver si estamos dispuestos a trabajar con "sabores"
2. Si no se está dispuesto, profundizar sobre las propuestas y luego definir porque camino seguimos.
Nuevamente, me parece que lo que nos está faltando es un criterio para poder tomar decisiones ágiles. Al respecto, me parece que podríamos definir algo como:
- Cual es el canal y forma para hacer una votación
- Quienes son los que pueden votar: por ejemplo, se me ocurre que contar un voto de alguien que recién se suma o que no demostró cierto conocimiento o participación, no debería ser tenido en cuenta (o al menos ponderado de igual forma) porque pone en riesgo la calidad y además facilita que se haga lobby.
- Que quorum es necesario para que se apruebe algo.
Saludos!
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsubs...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para obtener más opciones, visita https://groups.google.com/d/optout.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Gustavo Orrillo
Jul 1, 2014, 10:02:35 AM7/1/14
to odoo-localiza...@googlegroups.com
gente, voy por la parte de los sabores. Es lo único practicable. Puede ser confuso para los usuarios o para la gente que se acerca a OpenERP? Y si... pero necesitamos agilidad de desarrollo y me parece que de esa manera vamos a tener una comunidad y codigo más solido
My two cents,
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Gustavo Marino
Jul 1, 2014, 10:25:33 AM7/1/14
to odoo-localiza...@googlegroups.com
Si existen sabores, cual es el objetivo de una votación? Simplemente cada uno toma el sabor que más le convenza. No hay nada que elegir
Por otro lado, sin sabores, entonces sí habría que elegir un camino.
Puesto en estos términos, pareciera que lo primero a decidir es si va a haber sabores o no.
Desde ya, para mi debe haber sabores
Saludos
Guillermo Bisheimer
Jul 1, 2014, 1:48:13 PM7/1/14
to odoo-localiza...@googlegroups.com
Gente,
Lo más práctico va a ser que armemos el respositorio por sabores y trabajemos desde ahí. Una vez que esté todo en la misma plataforma GitHub los módulos van a ir creciendo y madurando con el tiempo, y tal vez hasta se pueda proponer un merge entre los módulos en un futuro para sacar un sabor "oficial" de la localización más adelante.
Lo único que me parece indispensable para poder colaborar en el código es la documentación técnica y funcional pertinente a cada módulo. Se que es un embole documentar el código porque quien lo escribió sabe bien lo que hace y en este sentido es una "pérdida de tiempo". Pero a los fines de la comunidad no creo que haya otra forma de poder colaborar en un desarrollo sin la documentación.
Para esto hay que buscar una plataforma adecuada para que todos los interesados puedan documentar. Desconozco si en GitHub se puede hacer esto de manera ágil y colaborativa, pero hay otras alternativas que llegado el caso podríamos debatir acerca de su uso.
Propongo lo siguiente:
1) Subimos los módulos que anden a las vueltas ordenados por sabores como se propuso
2) Armamos una estructura tipo esqueleto de documentación con las cosas que hagan falta documentar en todos los casos para que vayamos completando
3) Armar algo en la Wiki o en la página odoo-ar que explique a modo de tutorial la forma de utilización de cada módulo por sabor
4) Armamos una forma rápida de bajarse el Odoo y TODOS los modulos del reposotorio (mediante Docker, Vagrant, scripts, etc.) y que sirva como plataforma base de desarrollo desde la que un principiante pueda arrancar, sin tener que estudiar de donde sacar cada cosa ni qué dependencias instalar ni nada.
Los módulos no precisan estar terminados ni funcionales siquiera para poder subirlos al repositorio, siempre que se indique esto en la documentación. De esta forma, y con la colaboración de todos algún día se terminarán, cosa que no veo posible si toda esta información y código esta desparramado por todos lados.
¿Qué opinan?
Ing. Guillermo Bisheimer
B&S Sistemas de Control y Equipamientos
Av. de los Constituyentes 1172
(E3116CIX) Crespo, Entre Ríos
Tel/Fax: (0343) 4950289
Cel: (0343) 154679052
e-mail: gbish...@bys-control.com.ar
skype: guillermo.bisheimer
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Maximiliano Fochi
Jul 1, 2014, 3:11:31 PM7/1/14
to odoo-localiza...@googlegroups.com
Buenas a todos.
Doy mi opinion como desarrollador que recien empieza incursionar con odoo y quiere sumarse a la comunidad y comenzar a aportar tanto en el desarrollo de modulos como en lo que sea posible, coincidiendo con la propuesta de Guillermo.
Saludos!!
Doy mi opinion como desarrollador que recien empieza incursionar con odoo y quiere sumarse a la comunidad y comenzar a aportar tanto en el desarrollo de modulos como en lo que sea posible, coincidiendo con la propuesta de Guillermo.
Saludos!!
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Cristian Sebastian Rocha
Jul 1, 2014, 3:59:29 PM7/1/14
to odoo-localiza...@googlegroups.com
Gente,
Ignacio realizó estas preguntas en un thread alternativo (por no decir equivocado) pero que tiene mucho contenido.
1) Quien administra los sabores.
Lo administra quien propone el sabor. Se tiene que hacer cargo, no otro. Y debe hacerse cargo de encontrar un nuevo administrador si el no puede.
2) Quien decide que un sabor se puso obsoleto.
Desaparece el administración, desaparece el sabor en el momento de la falta de soporte (Le pondría un año de gracia de no ser actualizada a la nueva versión de Odoo)
3) Tener 15 sabores es practico... incluso útil?
Puff! Recien estamos hablando de 2. Quizás lleguemos a 15... pero es poco probable. Esto se puede pensar en el momento en que lleguemos a 5.
3b) es necesario tener todo en el mismo lugar?
Si, porque hay muchos módulos que no van a tener diferentes sabores, hasta que no se proponga uno. En el momento que un sabor se separe de todos los módulos de la localización se pensará en otra cosa. Pero hay dependencias, eso seguro.
4) Que sabor es el que anda.
Todos deberían de andar. Si no anda es un beta.
5) Pregunta al grupo: Che ¿Porque no juntan los sabores en uno?, la verdad es muy confuso.
Juntar sabores es un tema administración. Prefiero ver como se crean los sabores, y una ves al año hacernos esta pregunta. Los sabores A y B se pueden juntar? Porque no? Se puede centrar el esfuerzo en un módulo C común a los sabores? Eso se puede hacer en las uniones.
6) Se detecta que la mayoría usa un sabor como el mas estable... ¿para que están los demás?.
Para los que no están usando el sabor más usado. Si yo le instalo el sabor A porque creo que es mejor al cliente C, y C paga por su soporte entonces es suficiente para que exista.
6a) que sea el mas estable significa que es el mas completo?
No, más estable y completo son dos conceptos diferentes. Igual los sabores yo los pensaba para las funcionalidades / módulos, por lo tanto los módulos deberían estar medianamente completos ya que son funcionalidades.
6b) que se el mas completo significa que es que hace las cosas bien?
De nuevo, hacer las cosas bien y completo son conceptos diferentes. Quizás debamos hondar en esto, pero no tiene nada que ver con la localización y sus sabores. No es la idea justificar la existencia de los sabores por esto.
7) Si subo un sabor al branch de otro sabor ¿me sancionan?.
No! Porque? Y el SL donde está? Generar tantos branchs como uno quiera no es un problema. De nuevo, el tema se resuelve con la administración.
8) Quien admite un sabor o cualquiera puede hacer un sabor?
Cualquiera debería poder hacer un sabor, lo que debería existir es una normativa clara de como subir un nuevo sabor.
9) A donde reporto un bug?
Un módulo es una (funcionalidad x sabor). Y la propuesta original es dividir los módulos en repositorios diferentes. Por lo tanto cada módulo tendrá su propio sistema de administración de bugs. Simple?
Abrazo,
Cristian.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Lopez Ignacio
Jul 1, 2014, 4:06:51 PM7/1/14
to odoo-localiza...@googlegroups.com
Algo que usas mucho es la palabra
administración... ¿Va a haber un administrador?
Algo que hay que notar... las demás localizaciones no tienen este dilema... veamos como hacen para resolver esto... porque este tema es interesante pero no con este enfoque de distintas localizaciones en una sola... solo con decirlo hay una contradicción.
Buena Vida!
Ignacio López
El 01/07/14 16:59, Cristian Sebastian Rocha escribió:
Algo que hay que notar... las demás localizaciones no tienen este dilema... veamos como hacen para resolver esto... porque este tema es interesante pero no con este enfoque de distintas localizaciones en una sola... solo con decirlo hay una contradicción.
Buena Vida!
Ignacio López
El 01/07/14 16:59, Cristian Sebastian Rocha escribió:
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para obtener más opciones, visita https://groups.google.com/d/optout.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Cristian Sebastian Rocha
Jul 1, 2014, 4:11:57 PM7/1/14
to odoo-localiza...@googlegroups.com
Ignacio,
cada repositorio tiene un Owner o administrador. De ese estoy hablando.
las demás localizaciones tienen otros dilemas. Porque no nos concentramos con los nuestros?
Saludos,
Cristian.
Mariano Ruiz
Jul 1, 2014, 4:34:42 PM7/1/14
to odoo-localiza...@googlegroups.com
Cristian, pernoname pero me estoy mareando, si no me equivoco el que propuso el tema de los sabores sos vos.. ¿y ahora estás diciendo que no lo hagamos? Está bien si cambiaste de opinión, pero vale la aclaración para que se entienda.
En el hilo anterior comenté sobre el tema haciendo la propuesta de la votación y por eso evité dar mi opinión en ese momento hasta que se decida que hacer. Pero ya que estamos definiendo posturas en la misma lista, digo la mía:Maximiliano Fochi
Jul 1, 2014, 4:46:08 PM7/1/14
to odoo-localiza...@googlegroups.com
Hola Mariano.
Cristian copio lo que Ignacio coloco en otro thread y fue contestando entre lineas.
Cristian copio lo que Ignacio coloco en otro thread y fue contestando entre lineas.
...
Mariano Ruiz
Jul 1, 2014, 4:56:48 PM7/1/14
to odoo-localiza...@googlegroups.com
UPS ! Como en el copy & paste se perdió el formato no me di cuenta, pensé que se le había salido la cadena a Crsitian jaja, bueno, igual vale mi opinión del mail je.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Lopez Ignacio
Jul 1, 2014, 6:12:11 PM7/1/14
to odoo-localiza...@googlegroups.com
Yo volvi a dar un paso a tras, porque
se habia generado mucho ruido para ver de donde se origino la
disyuntiva.
Creo entender que surge en un modulo que hizo Juan. El punto es que Cristian objeto esa modificacion dando un argumento. Aun no se contesto esa objecion con conceptos por lo tanto aun no surgió una localización alternativa porque es la misma a excepción de este modulo que termina por modificar otros.
De los mails que se enviaron creo entender que este lío se resolvería si nos ponemos de acurdo en ese modulo.
Copio una parte del mail que mando cristian contestando a Juan que propone hacer una modificación en n10l_ar_invoice:
---------------------
Aun no se rebatieron estas objeciones en forma publica por lo tanto aun esta en disidencia esta modificación de la localización Argentina que traíamos. Osea no es otra es la misma!
Esto pone a luz algo de lo que dice Juan. Aunque alguna vez lo charlamos es mejor ponerlo en letra. "Si alguien propone algo y nadie objeta, está aceptado para ser incorporado/modificado". Lo que no dijimos es como solucionar una objeción porque esta es la primera vez que nos pasa.
Lamentablemente no vimos esto antes sino se hubiera resuelto mas rápidamente. Ahora solo tenemos que debatir esto.
A mi punto de vista, cristian tiene razon en no usar reference para guardar datos, menos números de factura. Me gustaria escuchar mas opiniones respecto de esta controversia y así resolvemos.
Buena Vida!
Ignacio López
El 01/07/14 11:00, Juan José Scarafía (ADHOC) escribió:
Creo entender que surge en un modulo que hizo Juan. El punto es que Cristian objeto esa modificacion dando un argumento. Aun no se contesto esa objecion con conceptos por lo tanto aun no surgió una localización alternativa porque es la misma a excepción de este modulo que termina por modificar otros.
De los mails que se enviaron creo entender que este lío se resolvería si nos ponemos de acurdo en ese modulo.
Copio una parte del mail que mando cristian contestando a Juan que propone hacer una modificación en n10l_ar_invoice:
---------------------
Este punto supongo que se refiere a la utilización del campo
"reference". Si es así, creo que hay un pequeño punto que no se
tuvo en cuenta.
El campo "reference" es de uso libre por implementación, y no
por desarrollo global, o así lo entiendo yo. Quien implementa
debería tener la libertar de elegir para que sirve ese campo. El
uso de ese campo en un módulo que se va a aplicar en varias
implementaciones es ser invasivo. Es mucho más conveniente crear
un nuevo campo y dejar liberado a "reference" para cualquier
implementación.
Aquí hay un concepto que me parece peligroso. Liberar un
campo para aceptar el número de factura de forma libre me parece
que va en contra del concepto numeración. Esto es, prevenir que
se salteen los números, por lo tanto prevenir fraudes (con o sin
mala fe, no importa). Se que es un requerimiento deseado por los
usuarios, pero no por eso significa que sea correcto.
--------------------Aun no se rebatieron estas objeciones en forma publica por lo tanto aun esta en disidencia esta modificación de la localización Argentina que traíamos. Osea no es otra es la misma!
Esto pone a luz algo de lo que dice Juan. Aunque alguna vez lo charlamos es mejor ponerlo en letra. "Si alguien propone algo y nadie objeta, está aceptado para ser incorporado/modificado". Lo que no dijimos es como solucionar una objeción porque esta es la primera vez que nos pasa.
Lamentablemente no vimos esto antes sino se hubiera resuelto mas rápidamente. Ahora solo tenemos que debatir esto.
A mi punto de vista, cristian tiene razon en no usar reference para guardar datos, menos números de factura. Me gustaria escuchar mas opiniones respecto de esta controversia y así resolvemos.
Buena Vida!
Ignacio López
El 01/07/14 11:00, Juan José Scarafía (ADHOC) escribió:
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Laureano Kloss
Jul 1, 2014, 6:41:13 PM7/1/14
to odoo-localiza...@googlegroups.com
En mi opinión iría un poco más allá, ¿Porque Juan tuvo la necesidad de hacer ese desarrollo?
Cristian Sebastian Rocha
Jul 1, 2014, 7:15:12 PM7/1/14
to odoo-localiza...@googlegroups.com
Si, muy buena pregunta.
Por lo que entendí es porque considera el módulo muy complejo, y que es invasivo sobre la base Odoo.
Hay un punto que opino igual: hay que eliminar el código sql.
El resto considero discutible.
Saludos,
Cristian.
Laureano Kloss
Jul 1, 2014, 7:57:24 PM7/1/14
to odoo-localiza...@googlegroups.com
Lo pregunto enlazado con aquello que se discutía de los sabores.
Nuestra experiencia sobre el Proyecto Aconcagua nos indica que los desarrollos los marcan las urgencias y necesidades de los clientes que implementamos, con esto quiero decir que quizás Juan se vio obligado a realizar ese desarrollo por alguna cuestión requerida por un cliente suyo. En la misma línea, pregunto, de las empresas que tenemos implementaciones con lo realizado por Cristian, Juan o el Proyecto Aconcagua, en el caso de realizarse una votación, ¿Dejarán sus implementaciones y desarrollos porque su opción no fue la más votada? La respuesta parece bastante obvia.La cuestión de la votación es otro tema a tratar, sin pretender dejar de lado aquello que opine la mayoría ni querer que solo voten aquellos "cualificados", estamos hablando de sistemas que tocan aspectos legales, jurídicos e impositivos, amparados por leyes y buenas practicas. Más allá de "saber" programar y realizar un módulo eficaz y eficiente, es preponderante cumplir aquello que dicen las leyes, normativas, etc., entonces, ¿Es suficientemente relevante que voten aquellos que no tienen conocimientos de este tipo? Lo cuestiono desde el respeto.
Es crucial comprender la diferencia entre el software libre en general y el software libre que representa OpenERP/ODOO como sistema con módulos contables e impositivos, un módulo eficiente y eficaz, pero que no cumple una normativa, es un módulo que no tiene utilidad.
Desde hace cuatro años hacia aquí, hay gente que ha entrado, salido y permanecido en OpenERP/ODOO, ¿Se contará con el voto de todos por igual? Han pasado muchos correos por las listas diciendo: "Quiero ayudar, me encanta OpenERP.... etc etc etc" ¿Cuantas de esas personas aportaron algo? ¿Con cuantas se puedo contar?
Nosotros no hemos participado desde el aspecto técnico ya que no trabajamos con los módulos desarrollados por Cristian, como saben desde el año 2011 y después de liberar funcionalidades en launchpad que hasta ese momento no existían, muchas de las personas que participan en esta lista eligieron otro camino y nosotros aquel que derivo en el Proyecto Aconcagua, por lo tanto es imposible que participemos en módulos que no utilizamos, por ultimo, cabría preguntarse si estamos cualificados para votar debido a nuestra participación en la lista. Nuestro rumbo, y lo repito como experiencia para este momento donde se plantean bifurcaciones en desarrollos, lo marcaron siempre los clientes.
En resumen, debería analizarse profundamente como se elige el camino a seguir y si es necesario optar por uno u otro camino.
Cristian Sebastian Rocha
Jul 1, 2014, 8:47:18 PM7/1/14
to odoo-localiza...@googlegroups.com
El jul 1, 2014 8:57 PM, "Laureano Kloss" <klo...@gmail.com> escribió:
>
> Lo pregunto enlazado con aquello que se discutía de los sabores.
>
> Nuestra experiencia sobre el Proyecto Aconcagua nos indica que los desarrollos los marcan las urgencias y necesidades de los clientes que implementamos, con esto quiero decir que quizás Juan se vio obligado a realizar ese desarrollo por alguna cuestión requerida por un cliente suyo. En la misma línea, pregunto, de las empresas que tenemos implementaciones con lo realizado por Cristian, Juan o el Proyecto Aconcagua, en el caso de realizarse una votación, ¿Dejarán sus implementaciones y desarrollos porque su opción no fue la más votada? La respuesta parece bastante obvia.
Este es uno de los puntos que se planteo en el documento de la Wiki. Exactamente, la ventaja de sabores permite resolver este punto.
>
> La cuestión de la votación es otro tema a tratar, sin pretender dejar de lado aquello que opine la mayoría ni querer que solo voten aquellos "cualificados", estamos hablando de sistemas que tocan aspectos legales, jurídicos e impositivos, amparados por leyes y buenas practicas. Más allá de "saber" programar y realizar un módulo eficaz y eficiente, es preponderante cumplir aquello que dicen las leyes, normativas, etc., entonces, ¿Es suficientemente relevante que voten aquellos que no tienen conocimientos de este tipo? Lo cuestiono desde el respeto.
Esto no es cuestionable. Lo que hay en la localización cumple con las normativas vigentes. Y seguro que se seguirá cumpliendo.
> Es crucial comprender la diferencia entre el software libre en general y el software libre que representa OpenERP/ODOO como sistema con módulos contables e impositivos, un módulo eficiente y eficaz, pero que no cumple una normativa, es un módulo que no tiene utilidad.
Perdón? No entendí la diferencia entre el SL y el SL de Odoo. Podrías detallar más?
>
> Desde hace cuatro años hacia aquí, hay gente que ha entrado, salido y permanecido en OpenERP/ODOO, ¿Se contará con el voto de todos por igual? Han pasado muchos correos por las listas diciendo: "Quiero ayudar, me encanta OpenERP.... etc etc etc" ¿Cuantas de esas personas aportaron algo? ¿Con cuantas se puedo contar?
Es una discusión actual entre los integrantes del grupo. Democracia? Meritocracia? No son lo mismo, no? Tampoco es bueno una meritocracia ciega. Cómo se resuelve esto? Qué pregunta filósófica! Esta claro que la dictadura no es una opción. Ni la dictadura del mercado como tampoco la dictadura del genio.
Es raro. No me gustan las preguntas filosóficas en este contexto de trabajo. Prefiero los hechos, lo concreto y lo medible.
Como ya dije en otro mail, con respecto al mismos tema, prefiero abrir puertas de forma ordenada para que todos participen y no cerrar puertas porque no se de que trata un tema u otro. Prefiero una votación por ese lado, administrativa, que una votación de que código es mas efectivo, operativa.
>
> Nosotros no hemos participado desde el aspecto técnico ya que no trabajamos con los módulos desarrollados por Cristian, como saben desde el año 2011 y después de liberar funcionalidades en launchpad que hasta ese momento no existían, muchas de las personas que participan en esta lista eligieron otro camino y nosotros aquel que derivo en el Proyecto Aconcagua, por lo tanto es imposible que participemos en módulos que no utilizamos, por ultimo, cabría preguntarse si estamos cualificados para votar debido a nuestra participación en la lista. Nuestro rumbo, y lo repito como experiencia para este momento donde se plantean bifurcaciones en desarrollos, lo marcaron siempre los clientes.
Pueden opinar. Me parece positivo, aunque eso no es lo que se esta discutiendo aquí, vuestra opinión. Si creen que no deberían hacerlo no voten. Si alguien vota consientemente perjudicando al grupo estan actuando de mala fe, solo pido por favor que no lo hagan. Si alguien esta convencido del voto y daña al grupo esa acción. .. y bue, esas cosas siempre pasan.
>
> En resumen, debería analizarse profundamente como se elige el camino a seguir y si es necesario optar por uno u otro camino.
Yo creo que el grupo existe ya desde hace varios años, avanzando y cada ves mas seguro de lo que hace. El camino que estamos tomando es el correcto: escuchar, aceptar, experimentar y aprender. Así es como ahora tenemos un proyecto maduro, complejo, abierto y responsable.
Gracias por tu aporte Laureano.
Cristian.
>>>>>>>> Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
>>>>>>>> Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
>>>>>>>> Para obtener más opciones, visita https://groups.google.com/d/optout.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mariano Ruiz
>>>>>>> Software Architect & Web Developer
>>>>>>> http://www.mrdev.com.ar
>>>>>>>
>>>>>>> --
>>>>>>> Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Laureano Kloss
Jul 1, 2014, 9:35:45 PM7/1/14
to odoo-localiza...@googlegroups.com
Quiero explicar una situación que se da frecuentemente en muchas personas que desarrollamos o escribimos código, para eso voy a utilizar un ejemplo.
-Desarrollar software libre que comprima archivos con un ratio de compresión mayor puede ser eficaz y eficiente.Juan José Scarafía (ADHOC)
Jul 1, 2014, 10:50:39 PM7/1/14
to odoo-localiza...@googlegroups.com
Porque tuvimos que hacer esta nueva propuesta:
1. Porque teniamos que soportar distintas sucursales y restringir acesos a diarios, entonces vimos que para cada sucursal teniamos que crear varios diarios y además limitarlos
2. porque varios wizards de selección de diarios deberían ser modificados para que sea lógico lo que se muestra, esto requiere armar varios módulos que se instalen automáticamente con cada módulo que agrega un wizard de selección de journal
3. porque en tpv se configura una sesión sobre un usuario, pero luego el ticket puede ser A o B según las condiciones frente al IVA (vimos mucho para sobre escribir)
4. Porque de esta manera nos quedó andando sin agregar nada raro:
- Notas de débito
- Otros tipo de comprobantes (comprobantes de importación, extractos bancarios, etc)
5. Porque hasta donde probamos, no hace falta adaptar ni modificar nada más, en este esquema es compatible con lo que trae open por otros lugares.
6. Porque también vimos que el número de asiento no nos servía para número de comprobante en otros casos. Ejemplo: en el módulo que hicimos de "multi pay", se crean n vouchers (cada uno un asiento con su numero) y luego todo eso se agrupa en un comprobante que llamamos "recibo", luego, el numero del voucher no nos sirve, necistamos otro campo/lugar donde tener el número de comprobante. Entonces decidimos ir por un nuevo campo para el número de comprobante: nos da mas flexibilidad, nos parece menos invasivo, nos resultó más sensillo a nivel de código.
7. La menor de las razones fue el tema de facilidad de configuración, pero bueno, fue una razón tmb.
Bueno, no recuerdo más, pero hubo alguna otra dando vueltas. Bueno, esa fue nuestra opinión.
Por otro lado, cuando se lo llevamos a los clientes para que lo prueben y opinen, les gusto más.
Bueno, espeor que haya esclarecido algo. Dudas, críticas, opiniones?
saludos!
Ing. Juan José Scarafía
(+54 9 341)153 278039
skype: jjscarafia
twitter: @jjscarafia
github: @jjscarafia
Cristian Sebastian Rocha
Jul 2, 2014, 12:39:49 AM7/2/14
to odoo-localiza...@googlegroups.com
Ok Laureano,
entiendo a que te refieres a los diferentes niveles de experiencia y capacidades que se involucran en un proceso de desarrollo de software.
Igual no entiendo a lo que apuntas, pero haré un esfuerzo. Hablas de que un diseñador no puede tener ingerencia en la toma de decisiones
de la adquisición de requerimientos? Osea, la toma de decisiones debe ser acorde a un rol e independientes a otros roles?
Si eso planteas, lamento decir que disiento. Tengo muchos casos de experiencia donde el tester redefine el diseño de software replanteando la posición del cliente. Un buen diseño es una relación de compromiso.
Pero también es verdad lo que dices. No se puede escribir código sin saber de que trata la funcionalidad que implementa. Creo que eso no ocurre aquí y si es así preferiría que seas asertivo y detalles un módulo de la localización que sufre de dichos problemas.
Si el ejemplo es el módulo de retenciones para mi esta claro que va en buen camino el propuesto. Es más, tenemos varios contadores que ya usan la versión no estable y están contentos con lo que tienen. En otras palabras cumplen con las normativas legales.
Que por cierto, quien tiene que cumplir con las normativas legales es la empresa que adopta un software y no el software. Voy a buscar la ley que afirma este punto para que no sea más una controversia.
Saludos,
Cristian.
Cristian Sebastian Rocha
Jul 2, 2014, 12:52:43 AM7/2/14
to odoo-localiza...@googlegroups.com
Gracias Juan por refrescar estos puntos.
Creo que ya esta todo sobre la mesa. No creo necesario ondar, excepto que se quiera hacer una pregunta que no se haya respondido aún. En otras palabras, lean los mensajes dejados durante estas semanas antes de preguntar.
Vamos a las preguntas ya planteada.
Se rechaza o se acepta el módulo de Juan?
Debe aceptarse.
Entonces reemplaza este módulo al modulo de la localización?
Mi respuesta es No!
Hay un conflicto a las normativas tradicionales de la localización?
Claramente si.
Como se resuelve el conflicto?
Aceptando sabores.
Puede cambiarse las normativas de la localización?
Si, si hay consenso si.
Con esto termino mi exposición.
Saludos,
Cristian.
Lopez Ignacio
Jul 2, 2014, 9:00:48 AM7/2/14
to odoo-localiza...@googlegroups.com
Cristian, veo que lo escribiste muy
tarde en la noche... o no pudiste dormir o soñaste con este tema...
(lo digo chistosamente)
Ahora hablemos seriamente... estas modificaciones en este modulo planteadas por Juan hace 15 días aun se están discutiendo. Es posible que esa urgencia que dice Laureano haya dictado el camino para hacer este modulo, ahora, esta bastante claro que torcer las practicas normales que traemos para resolver una funcionalidad, por mas que ande, no es una practica que se vea correcta. Por mi parte no veo aceptable que en la localizacion pongamos herramientas para hacer mas simple falsear datos... claramente esta mal, mas allá de que alguien lo use o no. Como politica de grupo creo que esto tiene que quedar claro que no puede ser aceptable. Nos ceñimos a las normas del país y las respetamos.
No me parece correcto que tengamos que emparchar y enmarañar nuestra localización por una divergencia en un modulo, metiendo sabores de localizaciones. Para ello cada uno tiene su repo y ademas, no se está agregando una funcionalidad o una mejora o algo nuevo a la localización... osea no aporta.
Hago mi meaculpa de no haber visto esta modificación antes para devolver el feedback solicitado. Lo que se ve es que hasta ahora no se ve que alguien apoye esta modificación del modulo invoice en su totalidad. En cambio si hay cosas que se pueden incorporar de esta propuesta grande.
Estaría bien que charlemos de lo que Si esta bueno incorporar de toda esta modificación.
Por mi parte me parece muy recomendable toda la parte de los wizards de configuración... hace mucho mas fácil la instalación y achica mucho la ventana de los errores humanos.
Buena Vida!
Ignacio López
El 02/07/14 01:52, Cristian Sebastian Rocha escribió:
Ahora hablemos seriamente... estas modificaciones en este modulo planteadas por Juan hace 15 días aun se están discutiendo. Es posible que esa urgencia que dice Laureano haya dictado el camino para hacer este modulo, ahora, esta bastante claro que torcer las practicas normales que traemos para resolver una funcionalidad, por mas que ande, no es una practica que se vea correcta. Por mi parte no veo aceptable que en la localizacion pongamos herramientas para hacer mas simple falsear datos... claramente esta mal, mas allá de que alguien lo use o no. Como politica de grupo creo que esto tiene que quedar claro que no puede ser aceptable. Nos ceñimos a las normas del país y las respetamos.
No me parece correcto que tengamos que emparchar y enmarañar nuestra localización por una divergencia en un modulo, metiendo sabores de localizaciones. Para ello cada uno tiene su repo y ademas, no se está agregando una funcionalidad o una mejora o algo nuevo a la localización... osea no aporta.
Hago mi meaculpa de no haber visto esta modificación antes para devolver el feedback solicitado. Lo que se ve es que hasta ahora no se ve que alguien apoye esta modificación del modulo invoice en su totalidad. En cambio si hay cosas que se pueden incorporar de esta propuesta grande.
Estaría bien que charlemos de lo que Si esta bueno incorporar de toda esta modificación.
Por mi parte me parece muy recomendable toda la parte de los wizards de configuración... hace mucho mas fácil la instalación y achica mucho la ventana de los errores humanos.
Buena Vida!
Ignacio López
El 02/07/14 01:52, Cristian Sebastian Rocha escribió:
--
Laureano Kloss
Jul 2, 2014, 11:27:18 AM7/2/14
to odoo-localiza...@googlegroups.com
¿Como seguiría todo este proceso?
¿Eliminando la posibilidad de subir el aporte de Juan? ¿Que lo mantenga en su github o el de su empresa?Juan José Scarafía (ADHOC)
Jul 2, 2014, 2:35:41 PM7/2/14
to odoo-localiza...@googlegroups.com
+ 1 para Laureano y Cristian. Entiendo tu planteo Ignacio, pero tambien concuerdo que para tomar una decisión buena para saber si una propuesta es mejor que la otra, se requiere caminar un buen trecho. De hecho, me gustaría que el "sabor de Cristian" siga adalente porque tal vez dentro de unos meses, después de tener varias empresas en producción, nos demos que cuenta que ese sabor era mejor o que tal vez haya que generar uno nuevo o lo que fuese.
Me parece que de cierta manera, los sabores, nos van a permitir generar más propuestas para no morir en opiniones complicadas para evaluarlas. Creo que, para propuestas medianamente logicas y aprobadas, dar lugar a un sabor, nos va a permitir implementarlas y ver en la "cancha" si son buenas y hasta tal vez mejores o no que otra.
Creo que el tema de los "sabores" o como quieran llamar, nos puede ayudar a que Aconcagua y estos proyectos se unan bajo un mismo techo y empiecen a ser, de a poco, más compatibles el uno con el otro y hasta ir convergiendo en un proyecto en comun.
Vamos que esto se está moviendo como nunca! vamos por buen camino!
Ing. Juan José Scarafía
(+54 9 341)153 278039
skype: jjscarafia
twitter: @jjscarafia
github: @jjscarafia
Sebastián Gurpegui
Jul 2, 2014, 5:04:44 PM7/2/14
to odoo-localiza...@googlegroups.com
Creo que es interesante el último punto de Juan respecto a la unión, y comparto la filosofía de kloss sobre demo/merito-cracia desde aspectos no sólo informáticos.
Por otro lado, sin comprender por completo el framework de OpenERP (debido a mi reciente incorporación al grupo), al parecer la solución propuesta por Juan es válida de ser incluida como una opcional a la realizada por Cristian. Y, como dijo Juan anteriormente, habrá que ver cómo evolucionan los 2 módulos porque, tal vez, en un tiempo nos demos cuenta de que se pueden fusionar para terminar siendo un módulo único, como al principio.
También adhiero al concepto de diversidad que expuso Cristian, entendiéndolo como una de las ventajas de que sea un código Open Source con la licencia correspondiente. Creo que, en este caso, donde un software es visto de distintas maneras por muchos actores (implementadores, desarrolladores, usuarios finales -cada uno con un perfil profesional distinto), es de vital importancia que se permita que cada uno desarrolle e incorpore sus cambios, siempre y cuando los mismos cumplan ciertos requisitos.
Y tal vez sea eso lo que falte en esta etapa: definir requisitos. Y se me ocurren algunas incógnitas sueltas, tal vez incluso ya respondidas:
A nivel código, ¿qué debe cumplirse para proponer una variante? ¿Código limpio? ¿Código comentado? ¿Mantener mismas variables cuando se hace alguna referencia a otro módulo?
A nivel funcional, ¿qué regla se usará para medir el grado de diferenciación? ¿Alcanza sólo con modificar la forma de hacer algo a nivel código? ¿Debe tener sí o sí cambios en las vistas? ¿Debe proponer un cambio en el workflow/forma de trabajo?
A nivel legal no debería analizarse porque se asume que el desarrollo cumple, aunque puede surgir una propuesta que tenga zonas grises o que se le haya escapado alguna cuestión obligatoria.
Creo que para que la localización argentina, entendida como una serie de ajustes realizados al software base y no como el nombre de un proyecto en particular, logre crecer saludablemente, debe ser capaz de cambiar en función de los nuevos paradigmas. Hasta ahora, la forma de establecer los módulos funcionó bien y no tuvo mayores inconvenientes (al menos así lo identifico yo desde el histórico de mensajes del grupo). Tal vez sea hora de cambiar un poco las reglas de juego, pero no desde el libertinaje, sino desde la libertad. Libertad a abrir el juego, basándose en reglas claras de aporte y compromiso (al soporte, por ejemplo), de manera tal de llevar un desarrollo lo más completo posible.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
----
Director de proyectos
www.eynes.com.ar
www.proyectoaconcagua.com.ar
Skype eynes_ar
Tel. +54 11 4730 1870 - Mov. 15 62625425
Francia 4091 - Vicente Lopez
Buenos Aires - Argentina
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Lopez Ignacio
Jul 2, 2014, 6:01:49 PM7/2/14
to odoo-localiza...@googlegroups.com
Laureano, por favor, armate otro hilo
para estas preguntas que te haces, porque ya no son parte de la
charla de este hilo.... al menos por el momento. Se corta la
lógica de la conversasión. Estamos hablando de lo que SI esta
bueno de la modificación de juan para ser incorporado en la actual
Localización Argentina.
Gracias! Buena Vida!
Ignacio López
El 02/07/14 12:27, Laureano Kloss escribió:
Gracias! Buena Vida!
Ignacio López
El 02/07/14 12:27, Laureano Kloss escribió:
Maximiliano Fochi
Jul 2, 2014, 6:52:48 PM7/2/14
to odoo-localiza...@googlegroups.com, lopezi...@gmail.com
Hola a todos.
Con respecto a que puntos estan buenos de la propuesta de Juan, no voy a dar mi opinion en cuanto a cuestiones técnicas, codificacion etc, ya que me considero nuevo en el grupo y sin la experiencia necesaria como para poder evaluar las mencionas custiones.
Sin embargo, tuve la posibilidad de reunirme con varios contadores de diversas empresas que estan utilizando sistemas erp licenciados de algunos que hay en el mercado. Hago la aclaracion para que se den cuenta del contexto, ya que diferente seria la opinion de una empresa que jamas utilizo un sistema de erp o utilizaba un enlatado.
Les mostré el funcionamiento de ambos modulos, la version anterior del modulo de facturacion y el actual que propuso Juan, y algo que me llamo la atencion fue que todos optaron por la propuesta de juan por el siguiente motivo:
Es simplemente un feedback que pude obtener de varios contadores de empresas diferentes y queria compartirlo ya que creo que les puede ser útil.
Saludos a todos.
Con respecto a que puntos estan buenos de la propuesta de Juan, no voy a dar mi opinion en cuanto a cuestiones técnicas, codificacion etc, ya que me considero nuevo en el grupo y sin la experiencia necesaria como para poder evaluar las mencionas custiones.
Sin embargo, tuve la posibilidad de reunirme con varios contadores de diversas empresas que estan utilizando sistemas erp licenciados de algunos que hay en el mercado. Hago la aclaracion para que se den cuenta del contexto, ya que diferente seria la opinion de una empresa que jamas utilizo un sistema de erp o utilizaba un enlatado.
Les mostré el funcionamiento de ambos modulos, la version anterior del modulo de facturacion y el actual que propuso Juan, y algo que me llamo la atencion fue que todos optaron por la propuesta de juan por el siguiente motivo:
Utiliza un solo diario por ejemplo ventas y adentro discrimina por tipo de documento.
A ninguno de los contadores le "gustó " la idea de tener cada tipo de comprobante separado en un diario distinto.
Vuelvo a recalcar, esto no quiere decir que uno esté mal, y el otro bien, lejos esta de eso.A ninguno de los contadores le "gustó " la idea de tener cada tipo de comprobante separado en un diario distinto.
Es simplemente un feedback que pude obtener de varios contadores de empresas diferentes y queria compartirlo ya que creo que les puede ser útil.
Saludos a todos.
Mariano Ruiz
Jul 2, 2014, 7:07:12 PM7/2/14
to odoo-localiza...@googlegroups.com
Maximiliano, te lo planteo así: ¿Para que tener un solo diario de ventas si para clasificar las facturas de si son de ventas, compras, NC de compra, NC de venta, ya hay un campo en el objeto "invoice" que te descrimina si es de venta o de compra? De echo el objeto journal también tiene un campo que indica que tipo de diario es...
O te lo planteo más funcional para los contadores: ¿Para qué querés un campo selección que solo te va a mostrar una opción? Lo digo por que a nivel pantalla Odoo no te muestra en el mismo listado facturas de compra con las de venta ni las NCs (justamente por este campito que te digo), tampoco te lo muestra junto con las notas de crédito (por este mismo campo también), entonces repito.. ¿para qué repetimos esa información en el campo Diario y que solo va a terminar dándote una opción en la pantalla?
O te lo planteo más funcional para los contadores: ¿Para qué querés un campo selección que solo te va a mostrar una opción? Lo digo por que a nivel pantalla Odoo no te muestra en el mismo listado facturas de compra con las de venta ni las NCs (justamente por este campito que te digo), tampoco te lo muestra junto con las notas de crédito (por este mismo campo también), entonces repito.. ¿para qué repetimos esa información en el campo Diario y que solo va a terminar dándote una opción en la pantalla?
Para acceder a más opciones, visita https://groups.google.com/d/optout.--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
--
Mariano Ruiz
Jul 2, 2014, 7:14:10 PM7/2/14
to odoo-localiza...@googlegroups.com
Se entiende mi planteo, Odoo actualmente tiene cuatro pantallas: Facturas de cliente, Notas de crédito de Clientes, Facturas de Proveedores, Notas de crédito de Proveedores, pero todas esas pantallas en realidad apuntan a la misma tabla de la BBDD, y el soft sabe que registros poner en cada pantalla según el campo "type", que es invisible al usuario y que se setea automáticamente al crear una FC según en qué pantalla estamos parados, entonces.. para que duplicar esa misma info en el campo diario, usemos el campo diario para algo más, y que esté funcionalmente ligado a eso, de ahí que pienso que usar ese campo para descriminar el tipo de factura (A, B,..) o mejor dicho el talonario, es la mejor utilidad que se le puede dar, y es lo que hace el módulo actual de Cristian.
Alternativas hay, pero creo que esta es la mejor, lo que pasa es que estamos tratando de atacar un problema complejo y engorroso como puede ser el tema de los tipos de facturas y talonarios moviéndolo de lugar como si el problema desapareciera, pero en realidad solo la complicamos más, según mi visión al menos.
Alternativas hay, pero creo que esta es la mejor, lo que pasa es que estamos tratando de atacar un problema complejo y engorroso como puede ser el tema de los tipos de facturas y talonarios moviéndolo de lugar como si el problema desapareciera, pero en realidad solo la complicamos más, según mi visión al menos.
Maximiliano Fochi
Jul 2, 2014, 7:22:45 PM7/2/14
to odoo-localiza...@googlegroups.com
Mariano, quizas no fui demasiado explicito o puede ser que este probando una version erronea de los modulos-
Yo quise hacer referencia a que:
Cuando me refiero a la version actual, estoy probando el modulo que descargue del repositoria de la locazacion y que genera:
El de Juan esta claro de donde descargarlo.
Pero cuando hacen referencia a que modificaciones de juan estan buenas para incoporar al modulo de la localizacion, a que modulo se estan refiriendo?
Disculpas desde ya si comparé erroneamente versiones que no lo eran.
Yo quise hacer referencia a que:
Cuando me refiero a la version actual, estoy probando el modulo que descargue del repositoria de la locazacion y que genera:
diario facturas a
diario facturas b
diario facturas c
En cambio en el modulo propuesto por juan para el caso de ventas genera:diario facturas b
diario facturas c
diario ventas y dentro de este diario tengo todas las facturas realizadas independientemente del tipo de comprobante.
Por lo que me contas deduzco que meti la pata y comparé versiones de modulos que no tenia que comparar??El de Juan esta claro de donde descargarlo.
Pero cuando hacen referencia a que modificaciones de juan estan buenas para incoporar al modulo de la localizacion, a que modulo se estan refiriendo?
Disculpas desde ya si comparé erroneamente versiones que no lo eran.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Mariano Ruiz
Jul 2, 2014, 7:35:17 PM7/2/14
to odoo-localiza...@googlegroups.com
No no, estamos hablando de lo mismo, de que el de Juan crea un solo diario de ventas ¿para qué? si querés ver todas las facturas de venta, simplemente andá a la pantalla "Facturas de cliente" y ahí están, sin mezclarse justamente con la de compra y NCs, a eso me refiero. Está bien que podemos (y el módulo de Juan lo hace) mover el tema del talonario a otro campo, ¿pero para qué? ¿Dónde está la innovación? si querés ver todas las facturas juntas repito, simplemente andá a la pantalla "Facturas de venta", y si querés ver todas juntas las de compras andá a "Facturas de compra", eso es algo que ya es así en Odoo sin tener que instalar localizaciones.
Con el nuevo módulo de Juan no vas a evitar que el usuario tenga que elegir el diario al armar la factura moviendo el campo de lugar, solo lo movés de lugar, pero si estamos hablando de una localización, el usuario tiene que indicar sí o sí que tipo de factura es (A, B..), y si tiene varias sucursales, que talonario. Después por supuesto se puede dar el caso donde sabés que un usuario por ejemplo solo puede hacer facturas A, o de solo tal sucursal... pero eso es algo funcional que escapa a la localización, y que lo podés programar en un módulo adicional que se acople perfectamente y sin cambiar nada al módulo de la localización, porque ese es un tema de visibilidad, no de localización, y se soluciona realmente muy fácil como para plantear que se necesita re-inventar la rueda para lograrlo, no hay ninguna incompatibilidad ni complicación en el módulo actual en ese sentido. Si Juan hizo algo en ese sentido (automatizar el tipo de factura o sucursal según el usuario), eso se puede mergear o re-codificar en la localización actual sin problemas, no porque surgan necesidades nuevas vamos a reescribir todo, a no ser que lo amerite.Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Juan José Scarafía (ADHOC)
Jul 2, 2014, 8:19:34 PM7/2/14
to odoo-localiza...@googlegroups.com
Mariano, no se si entendí bien, pero por lo que entiendo, eso es lo que veo:
- el campo type de invoice (que viene de la mano del campo type de journal), sirve para diferenciar dentro del mismo objeto "account.invoice" comprobantes que tiene comportamientos muy distintos en como se debe confeccionar el asiento, no recuerdo los nombres tecnicos pero sería "out" "in" "refund out" "refund in". Funcionalmente, una nota de crédito y una factura son distintas, ahora por ejemplo, una nota de debito y una factura no. Por eso creo que no hace falta, a priori, agregar un tipo para notas de debito
- a lo que apunto con el primer punto, es que no le veo relación a esa discrimijnación con la de tipos de comprobante "A, B, C, despacho de importación, etc". Creo que son completamente complementarios y que la primera no aporta nada a la segunda.
Ing. Juan José Scarafía
(+54 9 341)153 278039
skype: jjscarafia
twitter: @jjscarafia
github: @jjscarafia
Maximiliano Fochi
Jul 2, 2014, 8:21:19 PM7/2/14
to odoo-localiza...@googlegroups.com
Bien, entiendo a lo que haces referencia y coincido cuando decis vas a la pantalla de facturas compras o ventas y listo.
Ahora los contadores dieron esa opinion basado en que prefieren contablemente tener todas las facturas de venta por ejemplo A,B... en un solo diario.
No les parecio agradable contablemente separar esa informacion en diarios diferentes ya que a la hora de emitir por ejemplo un informe "Diario compra/venta" con la version actual, tendrian en caso de manejar facturas A y B, dos informes diarios uno para el diario facturas A y otro para el diario facturas B, cada uno con sus totales.
Cuando en realidad ellos prefieren tener todas las operaciones de venta en un unico diario. Esto les permite al emitir un informe diario, directamente en el diario ventas, obtener los totales de todas las operaciones independientemente del tipo de comprobante.
Les parecio una separacion innecesaria la de crear un tipo de diario por cada tipo de comprobante.
Te vuelvo a repetir fue la opinion de estos contadores, y quizas otros opinen que la mejor forma sea separar en diarios diferentes los diferentes tipos de comprobantes, y termine siendo una cuestion de "gustos".
Lo que si puedo decirte tambien es que la mayoria de los sistema contables que vi funcionando ninguno crea diarios diferentes para cada tipo de comprobante A,B...
Tambien cabe destacar que mis conocimientos contables no son de lo mejor, soy ing. en informatica, y cuando me dieron su opinion solo la escuche y se las transmito a ustedes para poder debatirla, ya que considero que siempre hay alguien que tiene mas experiencia y conocimientos que uno mismo.
Como te decia quizas puede ser una cuestion de "gustos" y que realmente crear un diario por cada tipo de comprobante, no complique la contabilidad.
Alguien con mayores conocimientos que los que poseo en materia contable quizas pueda sacarnos esta duda.
Ahora los contadores dieron esa opinion basado en que prefieren contablemente tener todas las facturas de venta por ejemplo A,B... en un solo diario.
No les parecio agradable contablemente separar esa informacion en diarios diferentes ya que a la hora de emitir por ejemplo un informe "Diario compra/venta" con la version actual, tendrian en caso de manejar facturas A y B, dos informes diarios uno para el diario facturas A y otro para el diario facturas B, cada uno con sus totales.
Cuando en realidad ellos prefieren tener todas las operaciones de venta en un unico diario. Esto les permite al emitir un informe diario, directamente en el diario ventas, obtener los totales de todas las operaciones independientemente del tipo de comprobante.
Les parecio una separacion innecesaria la de crear un tipo de diario por cada tipo de comprobante.
Te vuelvo a repetir fue la opinion de estos contadores, y quizas otros opinen que la mejor forma sea separar en diarios diferentes los diferentes tipos de comprobantes, y termine siendo una cuestion de "gustos".
Lo que si puedo decirte tambien es que la mayoria de los sistema contables que vi funcionando ninguno crea diarios diferentes para cada tipo de comprobante A,B...
Tambien cabe destacar que mis conocimientos contables no son de lo mejor, soy ing. en informatica, y cuando me dieron su opinion solo la escuche y se las transmito a ustedes para poder debatirla, ya que considero que siempre hay alguien que tiene mas experiencia y conocimientos que uno mismo.
Como te decia quizas puede ser una cuestion de "gustos" y que realmente crear un diario por cada tipo de comprobante, no complique la contabilidad.
Alguien con mayores conocimientos que los que poseo en materia contable quizas pueda sacarnos esta duda.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsubs...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Has recibido este mensaje porque estás suscrito al grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-argentina+unsub...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Lopez Ignacio
Jul 2, 2014, 8:43:42 PM7/2/14
to odoo-localiza...@googlegroups.com
Excelente... muchas gracias y te animo
a seguir opinando, es lo que hace fuerte a esta comunidad.
Buena Vida!
Ignacio López
El 02/07/14 19:52, Maximiliano Fochi escribió:
Buena Vida!
Ignacio López
El 02/07/14 19:52, Maximiliano Fochi escribió:
Mariano Ruiz
Jul 2, 2014, 9:36:36 PM7/2/14
to odoo-localiza...@googlegroups.com
Si todas las opiniones son respetables, te cuento, yo tengo una experiencia parecida con un contador, el problema es una cuestión de "terminología", porque por lo que hablé una vez, para ellos existe un único diario, que es donde metés todos los asientos, sean incluso compras, ventas, pagos de impuestos, conciliaciones... lo que sea ellos llevan en un libro de tapa dura real asentando todo lo que sucede que impacte en la contabilidad.
Lo de la separación a la hora de los reportes como decís, insisto con lo mismo, no estás separando, si de echo si hablamos de la implementación, de una u otra manera en el ERP todo termina en la misma tabla, se mezclan incluso las facturas de compra con las de venta, que se descriminan con el campo oculto "type". Que quiero decir con esto bajado a funcional: que un reporte es eso, una manera de ver los datos, a la hora de imprimir un Libro IVA si querés podés programarlo para que te meta en el informe todas juntas o no, un reporte es justamente una manera de ver los datos distinta a la de las pantallas de carga, incluso como decís sumarizando, y hablando puntualmente del Libro IVA, si o si tenes que también reportar en la lista de facturas no solo los totales con y sin IVA, sino número y tipo de factura, esto se puede hacer perfectamente con el modelo actual. Pero la información que estamos hablando de cargar el tipo de factura, y el talonario en caso de multiples facturas, y si es una nota de crédito, débito los vas a tener que estar sí o sí, sino no estamos hablando de una localización que se adapta a la Argentina, y la localización mete todo esa información en un solo campo, más simple imposible.Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/odoo-localizacion-argentina.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Mariano Ruiz
Jul 2, 2014, 10:05:37 PM7/2/14
to odoo-localiza...@googlegroups.com
Juan, respondo entre líneas en azul, y volviendo a aclarar que respeto mucho tu trabajo y dedicación, solo estamos teniendo diferencias a la hora de implementar, pero esto de llamar la localización "de Juan" o "la de Cristian" puede sonar por momentos peyorativo, podrían ir asignándoles "codenames" ya que ambos van por la idea de los sabores (de la cual yo disiento, pero esa es otra discusión).
- el campo type de invoice (que viene de la mano del campo type de journal), sirve para diferenciar dentro del mismo objeto "account.invoice" comprobantes que tiene comportamientos muy distintos en como se debe confeccionar el asiento, no recuerdo los nombres tecnicos pero sería "out" "in" "refund out" "refund in". Funcionalmente, una nota de crédito y una factura son distintas, ahora por ejemplo, una nota de debito y una factura no. Por eso creo que no hace falta, a priori, agregar un tipo para notas de debito
Tenés razón con lo primero que decís de los tipos, pero la localización actual no agrega un tipo para las notas de débito, agrega un diario más que no es lo mismo, no se a que te referís exactamente con eso.
- a lo que apunto con el primer punto, es que no le veo relación a esa discrimijnación con la de tipos de comprobante "A, B, C, despacho de importación, etc". Creo que son completamente complementarios y que la primera no aporta nada a la segunda.
Creo que tampoco entiendo esto y sería importante para poder discutir con vos el tema. ¿Te referís a que se están agregando un diario de NC por tipo de talonario? Si es eso, puede sonar engorroso pero tiene que ser así dependiendo de como el negocio lo implementa: o sea, en la realidad vos podés tener talonarios físicos y numerados para hacer las NC, o el caso más común sobre todo en PyMES es que uses el mismo talonario de FC, en ese caso yo borro esos diarios de más, y uso el diario de ventas, para que use la misma secuencia numera y sea un reflejo fiel del talonario real. En todo caso se podría preguntar en el wizard de si crear o no estos diarios, pero en el código no se necesitaría cambiar nada, es solo poner como opcional la creación de ciertos datos en la base de datos.
En este punto sería bueno si Cristian está leyendo que aporte su visión del tema también.
Sebastián Gurpegui
Jul 2, 2014, 10:18:09 PM7/2/14
to odoo-localiza...@googlegroups.com
Excelente explicación de Mariano, a mi entender.
Efectivamente, las modalidades de trabajo de las empresas suelen ser esas 2 respecto a las NC y ND. Y esto es así porque la AFIP establece dichas posibilidades: usar la misma numeración o cambiar de talonario.
En el caso del módulo desarrollado por Cristian, el punto de venta está asociado al diario, no? Es decir, habrá un diario Factura A-001, otro diario Factura A-002, y lo mismo con el resto?
En cuanto al desarrollo de Juan, el punto de venta responde igual que en el de Cristian?
--
Has recibido este mensaje porque estás suscrito a un tema del grupo "odoo - Localización Argentina" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/odoo-localizacion-argentina/lmxfpD9Pr0A/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a odoo-localizacion-a...@googlegroups.com.
Juan José Scarafía (ADHOC)
Jul 3, 2014, 8:59:53 AM7/3/14
to odoo-localiza...@googlegroups.com
Jejje, que dificil que se hace expresarse, desafíos de la comunicación...
Mariano, creo que había interpretado mal tu comentario
"Se entiende mi planteo, Odoo actualmente tiene cuatro pantallas: Facturas de cliente, Notas de crédito de Clientes, Facturas de Proveedores, Notas de crédito de Proveedores, pero todas esas pantallas en realidad apuntan a la misma tabla de la BBDD, y el soft sabe que registros poner en cada pantalla según el campo "type", que es invisible al usuario y que se setea automáticamente al crear una FC según en qué pantalla estamos parados, entonces.. para que duplicar esa misma info en el campo diario, usemos el campo diario para algo más, y que esté funcionalmente ligado a eso, de ahí que pienso que usar ese campo para descriminar el tipo de factura (A, B,..) o mejor dicho el talonario, es la mejor utilidad que se le puede dar, y es lo que hace el módulo actual de Cristian."
"En realidad no termine de entendr el punto "entonces... para que duplicar esa mismo info en el campo diario" Porque entiendo que en la propuesta no estamos duplicando ninguna info. Lo que quería decir nomás, es que los tipos de factura y de diario, no tienen nada en relación a los tipos de comprobante. Ahora bien, entiendo que se le pueda agregar al diario toda la lógica de tipo de comrpobante (Que es lo que veníamos haciendo).
Mando un videito donde muestro y resumo lo que considero son algunas de las ventajas: https://www.youtube.com/watch?v=DY8KL6vsCIY&feature=youtu.be&hd=1
Saludos!
Ing. Juan José Scarafía
(+54 9 341)153 278039
skype: jjscarafia
twitter: @jjscarafia
github: @jjscarafia
Reply all
Reply to author
Forward
0 new messages