2012/8/14 Jose R. Prieto <[email protected]>: > Creo que el problema está en que en OpenERP la localización se considera > tanto a la traducción de términos, como a la ADAPTACIÓN del ERP a la > Legislación Española. > > Si Tryton (u OpenERP, o el ERP que sea, tanto privativo como opensource), no > está adaptado a la legislación del país dónde se quiera utilizar, no lo > utilizará nadie.
Wl objetivo de tryton es ser un ERP si haces un sistema ERP suficientemente generico. Puede funcionar en cualquier pais. Todos usan el mismo proceso de ERP. Tryton y openerp son de europa y estan influenciados por europa Yo deje un tryton aqui(mexico) en una empresa ( http://vertiz-system.com/) pequeña hace un año Y ahora usan tryton como su sistema principal para toda la empresa. Siempre tuve al misma duda funcionaria tryton para mexico ? tryton ni se adapta a la legislacion mexicana. No tiene modulo especifico de impuestos, cotabilidad especifica para regimes, de echo ni tiene ni los campos completos para agregar 1 direccion completa ( aqui tenemos municipio/delegacion colonia). Pero tryton es lo suficientemente generico que la empresa pudo usar tryton. No resuelve todos sus problemas ( y eh aqui un oportunidad de negocio). Pero resuelve los mas comunes y genericos. > Por ello, creo que el punto de vista y la forma de trabajar de la > localización española de OpenERP es la adecuada; tanto traducción (que, > dicho sea de paso, es la parte MÁS sencilla), como la creación y / o > adaptación de módulos para funcionar de acuerdo a la legislación del país en > cuestión. Tryton != OpenERP Solo usa lo mejor del OpenERP > Igual es que el topic del mensaje no es lo bastante claro; hablo de la > localización española para España, exclusivamente; del resto de países, no > conozco sus legislaciones vigentes, con lo cual no puedo opinar. > > Todas las funcionalidades que menciono, no son "invención" mía; la tienen > muchos otros ERPs, y programas mucho más simples (de contabilidad pura y > dura); por eso las apunté como posibles mejoras para que Tryton pueda ser > una opción viable en España. > Lo mismo openerp!=tryton. Pues no creo que los core developers hagan modulos especiales para españa. Les interesa que tryton funcione y pueda funcionar para cualquier pais, por lo que es suficientemente generico. Ahora una oportunidad de negocio es desarrollar modulos para españa y venderlos o seguir el modelo de negocios de b2ck > Un saludo. > > El jueves, 2 de agosto de 2012 17:41:56 UTC+2, zodman escribió: >> >> 2012/8/2 Jose R. Prieto <[email protected]>: >> > Acabo de escribir un correo en la lista de OpenERP Spain, y considero >> > que >> > pueden ser casos de uso de interés para la localización española de >> > Tryton. >> > >> > Por tanto, adjunto aquí la parte que interesa para Tryton: >> > >> > ------------------------------------------------------------------------------------ >> > En otros ERPs / softwares contables, los impuestos, tienen propiedades >> > adicionales, y una de ellas es muy interesante; la VIGENCIA del mismo; >> > es >> > decir, defines el impuesto, y después puedes definir el tipo y desde >> > cuándo >> > está vigente ese tipo para ese impuesto. Lo podéis ver, por ejemplo, en >> > A3. >> > (Acabo de encontrar un enlace de otro ERP, dónde aplican algo parecido; >> > no >> > lo he probado, pero aparece la vigencia: >> > http://kriter.net/resources/novedades/Cambios%20IVA.pdf ) >> > >> > Esta funcionalidad supliría una carencia importante en OpenERP, ya que >> > así, >> > no serían necesarias nuevas posiciones fiscales; me explico. >> >> En realidad >> nunca eh instalado y echo andar el openerp. de echo revise el codigo y >> dije NO! >> >> Creo que en tryton los impuestos los manejan distintos. En tryton >> tienes lineas de impuestos. >> >> Y puedes asignar uno o mas impuestos a una factura y a los productos >> de la linea de factura >> http://i.imgur.com/p05lC.png >> http://i.imgur.com/J7Jge.png >> >> >> Ahora en tryton se puede crear un modulo que agregue un campo vigencia >> a impuestos y que la fecha de la factura solo se puedan agregar >> impuestos en la vigencia activa. >> >> > Ahora mismo, tenemos una posición fiscal que es "Régimen nacional", a >> > este >> > régimen le correspondería únicamente IVA. >> > >> > La posición "Retención 7 %", le corresponde IVA normal + IRPF 7 % >> > >> > etc >> > Bien; si definimos, por un lado, los impuestos de IVA así: >> > >> > IVA Normal >> > IVA Reducido >> > IVA Superreducido >> > >> Aqui puedes agregar a tu producto en tu factura un impuesto de >> retencion de 7% y otro de IVA NORMAL otro de reducido y otro de >> superreducido >> > >> > Y por otro, sus tipos >> > >> > >> > Para IVA Normal: >> > Tipo: Vigencia: Desde: Hasta: >> > 16 % 01/01/2003 30/06/2010 >> > 18 % 01/07/2010 31/08/2012 >> > 21 % 31/08/2012 -- >> > >> Como te decia un modulo especial que puedas seleccionar si la factura >> esta entre el 2003 y 10 solo el 16% >> >> Otro impuesto si la fecha de la factura es el 18% Solo te deje escoger >> el de 18%. >> >> > >> > Y sus correspondientes RE: >> > RE IVA Normal: >> > Tipo: Vigencia: Desde: Hasta: >> > 4 % 01/01/2003 31/08/2012 >> > 5,2 % 31/08/2012 -- >> > >> > >> > Está claro que NO habría que crear posiciones fiscales nuevas, sino >> > únicamente crear los nuevos tipos asociados a los impuestos. >> > Esto, además, creo que es de aplicación a CUALQUIER país, y cubriría (a >> > mi >> > entender), lo que yo veo como una carencia en OpenERP. Por que los tipos >> > -los %- de los impuestos, varían. >> >> Yo creo que aqui esta unas de las grandes diferencias de tryton con >> openerp. Tryton esta pensando y dan prioridad >> a que el ERP funcion para cualquier pais. >> >> > Cuando se da de alta una factura, por tanto, el OpenERP debería de saber >> > qué >> > tipo tiene que aplicar por defecto según la fecha de la factura. >> > >> >> Este seria parte de la factura, el modulo nuevo de impuesto hasta >> podria a un producto asignarle todos los impuestos. Al mismo tiempo >> modificar la factura para que solo tome impuestos vigentes. >> >> Ahora este modulo seria fuera del core y no creo que los tryton's core >> team hagan el modulo ... >> >> Por que ? por lo que decia arriba. Este feature solo funcionaria para >> españa. Tendria que desarrollarlo aparte o que algun proveedor te los >> haga. >> >> http://www.tryton.org/es/services.htmlç >> >> Ahora. Cuantos impuestos tendrian vigencia? 3,4 ? vale la pena hacer >> un modulo especial para vigencia de 3 o 4 impuestos ? >> >> Si son 100 o 200 impuesto la vdd si valdria la pena pero si son 10?. >> De echo se me haria mas facil hacer un calendario y ver cuales son los >> impuestos de cada dia. aparte en un pizarrron >> >> > >> > ¡OJO!; puede pasar que tengas una factura, en la cual aparezcan tipos de >> > IVA >> > diferentes; caso práctico; una rectificativa de varias facturas, o un >> > abono >> > de varias facturas; los abonos pueden ser de facturas ANTERIORES al >> > cambio >> > del tipo del impuesto, y también POSTERIORES, con lo cual tendríamos dos >> > tipos diferentes de IVA asociados al mismo impuesto, en el mismo >> > documento; >> > por tanto, el tipo debería de ser algo que, de forma automática OpenERP >> > cubra en el formulario correspondiente, pero que permita cambiar, para >> > poder >> > dar cabida a este caso de uso. >> > >> > >> > No se si alguien ha trabajado a este respecto ya; sino, estaría bastante >> > bien ponerlo como un Blueprint en Launchpad. >> > >> >> Lo mismo que arriba. >> >> De echo los chicos de http://www.tryton-erp.es/ podrian agregar un >> wiki y agregar el blueprint. De echo podrias aportar una cantidad de >> dinero para alguien que pueda desarrollarlo. Y resolver el problema >> >> > >> > En este tema de impuestos, creo que hay mucho margen de mejora, y que >> > debería de darse una buena vuelta para mejorar la localización; así >> > mismo, >> > también en el tema de cuentas contables y ejercicios fiscales. Lo he >> > comentado en otros correos, pero creo interesantes las siguientes >> > funcionalidades: >> >> A diferencia de OpenErp. La localizaciones de tryton es simplemente la >> traduccion. >> >> Los features de mejora o de adaptacion son modulos apartes y no tienen >> nada que ver con la localizacion. >> >> > >> > >> > - Que exista la entidad "Modelos AEAT", y asociar impuestos con sus >> > modelos; >> > p.ej., Retenciones Profesionales (por rendimientos del trabajo), al >> > modelo >> > 111, y al resumen anual 190; Retenciones por Arrendamientos, al modelo >> > 115, >> > y al resumen anual 180; de los mismos casos de uso que estoy poniendo, >> > se >> > advierte que debería de haber un "Modelo Resumen Anual", y un "Modelo >> > por >> > periodo". Lo de llevar las retenciones en diferentes cuentas contables, >> > y a >> > partir de ahí, calcular los modelos, personalmente, me parece una >> > guarrada; >> > por que tu puedes tener una cuenta 4751x genérica, de retenciones; y ahí >> > meter todas las retenciones, arrendamientos y por rendimientos del >> > trabajo; >> > por que la norma contable no te exige tener subcuentas por cada tipo de >> > retención, sino que esa funcionalidad viene dada por los MODELOS de la >> > AEAT, >> > no por los impuestos en sí (el impuesto es el IRPF >> > independientemente..); en >> > esto sí que con impuestos e impuestos hijos, se podría solucionar >> > (jerarquía >> > IRPF, hijos, IRPF por retenciones del trabajo, IRPF por arrendamientos, >> > etc) >> > >> > >> > - Las cuentas contables deberían de ser por ejercicio, y no globales; >> > ¿por >> > qué?; pongo varios casos de uso: >> > - De un ejercicio a otro, una empresa puede desaparecer; o varias (y >> > mucho más en estos tiempos..); por tanto, es una tontería que esas >> > cuentas >> > contables queden "desaprovechadas", haciendo que el árbol del plan >> > contable >> > se haga mucho más grande, innecesariamente; sí, las podemos ocultar; >> > pero no >> > me parece una buena solución. >> > - De un ejercicio a otro, puede que no me interese tener el mismo >> > número >> > de dígitos en cada cuenta; puede que empezase la contabilidad con 10 >> > dígitos, y ahora me de cuenta que con 6 dígitos me llega y me sobra; los >> > libros contables del ejercicio anterior, ya están presentados, con lo >> > cual, >> > no puedo variar esas cuentas en el plan de cuentas de OpenERP; y sigo >> > teniendo que tener cuentas con 10 dígitos, por que para este ejercicio, >> > son >> > las mismas... >> > - Hemos dado de alta una cuenta contable para un cliente que >> > creíamos >> > iba a ser habitual; pero vemos que ha sido una compra puntual (vale el >> > mismo >> > caso para un acreedor/proveedor); por tanto, pasaríamos ese cliente / >> > proveedor de una 430xx / 400xx, a la 4300000 / 4000000 en el ejercicio >> > siguiente (supongamos que nos debe dinero, o le debemos, con lo cual no >> > tenemos la cuenta saldada); otra vez lo mismo, tendríamos un plan de >> > cuentas >> > más grande de lo necesario, lo que hace que las búsquedas en el plan de >> > cuentas sean, como mínimo, más incómodas; serán más lentas, lógicamente; >> > y >> > más complicado de ver el árbol de cuentas. >> > >> >> La vdd aqui no entendi creo que por que no soy contador. Pero todos >> requerimientos podrian ir en el blueprint de tryton-erp.es >> >> > >> > Quizás estos casos de uso lleguen tarde para la localización española de >> > OpenERP, pero sí lleguen a tiempo para la localización de Tryton. >> > >> >> Lo mismo que arriba, localizacion es traduccion y features y >> adaptaciones son modulos apartes de la localizacion >> >> > >> > Eso sí, son casos de uso HABITUALES, y los programas comerciales que hay >> > en >> > el mercado, en la mayoría de los casos, cubren estas funcionalidades. >> > >> > >> > Ale, ya no doy más la chapa :P >> > >> > >> > Un saludo a todos. >> > >> > >> > PD: y que calor hace en Lugo, por dios.... >> > >> > ------------------------------------------------------------------------------------ >> > >> > Espero que sea de vuestro interés. >> > >> > Un saludo y disfrutad las vacaciones, los que tengáis ;) :P >> > >> > -- >> > [email protected] mailing list > > -- > [email protected] mailing list -- [email protected] mailing list
