OpenERP: El ERP de software libre
Archivo categoría Noticias, Publicaciones, Notas, Anuncios Openerp
Nuevo interfaz táctil Punto de Venta OpenERP
Por Ana Juaristi Olalde - Funcionalidad OpenERP - 30 Enero 2012
Sé que este es un tema que interesa a todo el mundo por lo que me he permitido la licencia de traducir el artículo original de OpenERP que podeis leer íntegro en este link:
El Nuevo interfaz táctil Punto de Venta OpenERP
disponible para 6.1 te permite gestionar tus ventas de una forma muy sencilla. Está completamente basado en Web por lo que no necestias instalar o lanzar ningún software y todas las tiendas de venta pueden ser fácilmente consolidadas. Permite trabajar con y sin conexión por lo que puede seguir vendiendo aunque pierda su conexión a Internet.

Aquí os ponemos un resumen de su funcionalidad más importante y sus beneficios:
100% basado en WEB
- Disponible para cualquier dispositivo táctil (ipod, ipad, cualquier tablet)
- móvil (con dispositivos portátiles)
- no requiere instalación
Empaquetado como un módulo standar de OpenERP
- no requiere installacion, fácil implementación
- Permite personalización y se adapta a distintas necesidades
Integrado con OpenERP
- no requiere sincronización, completamente integrado.
- Todo OpenERP disponible, utiliza OpenERP como backend/administrador
- Consolida tiendas casi en tiempo real
Trabaja offline, sin conexión al servidor
- Continúe trabajando incluso cuando su conexión se cae
- Si cierra el navegador, los datos no se perderán.
Sexy & fácil de usar
- Completamente basado en Web con interfaz limpio.
- Interfaz sencillo y amigable.
Tiene distintas opciones para seleccionar productos. Puede hacerlo a través del lector de código de barras, justo navegue por las categorías que ha definido (p.e. bebidas, snacs, comidas, etc.) , o realice búsquedas de texto en caso de que las opciones anteriores no le sean válidas.
Si necesita usar el TPV / POS para su restaurante, por ejemplo, sus empleados pueden grabar al mismo tiempo múltiples tickets sin tener que esperar a realizar una transacción al mismo tiempo. Así mismo, para facilitar los pagos, la aplicación permite múltiples métodos de pago.
El TPV es tan simple y accesible para su uso que su tienda o restaurante no necesitará ninguna otra herramienta para gestionar pedidos. Debido a su sencillo y amigable interfaz no necesitará formación para aprender cómo se usa. El objetivo de ello es una solución empaquetada para mejorar la productividad de su negocio.
Esperando sea de vuestro interés…
Nuevo módulo para localización española l10n_es_prev_tesoreria
Por Ana Juaristi Olalde - Comunidad Española OpenERP, Funcionalidad OpenERP - 27 Enero 2012
Buenas…
En un par de días subiremos un nuevo módulo l10n_es_prev_tesoreria a la localización española.
Permite hacer previsiones de tesorería sencillas para saber el saldo a futuro de una cuenta o diario utilizando una mezcla de plantillas de posibles pagos a futuro y facturas reales registradas en el sistema.
Como una imagen vale más que 1000 palabras, os paso el link a la demo del módulo por si quisierais echarle un vistazo:
http://www.openerpsite.com/wp-content/uploads/Demo_Prev_tesoreria.htm
Se agradecen opiniones y sugerencias al respecto.
Edito:
Os paso también un par de links a otro módulo de previsión de tesorería realizado por Pexego de cual Omar nos ha remitido un par links. Este módulo es más completo, más complejo de configurar y linka con analítica en caso de ser necesario. El módulo fue desarrollado para OpenERP 5.2 que nunca llegó a publicarse y por tanto, para su utilización en 6.0 o 6.1 debería ser portado a dicha versión. Aquí van los links:
http://www.pexego.es/pub/openerp_media/asistente-previsiones-lotes-v2.avi
http://www.pexego.es/pub/openerp_media/milestones-previsiones.avi
Cordiales saludos!!
Ana
OpenERP 6.1 Release Candidate (RC1) ya está disponible
Por Ana Juaristi Olalde - Nuevas versiones OpenERP - 12 Enero 2012
Acabamos de recibir la noticia de que la RC1 de la nueva versión de OpenERP 6.1 ya está disponible aquí: Download
Incluye más de 50 nuevos módulos y funcionalidad cuya lista “resumida” os paso traducida a continuación.
- Más fácil de aprender
- Buzzy ERP: Social, Viral y Mobile
- Be Social: Permite colaborar y compartir información con clientes y proveedores
- Compartir documentos
- Incluir contenido en su Website
- Se ha mejorado el motor de gestión de Emails
- Envío de notificaciones por email, por defecto.
- OpenERP Mobile: Nuevo interfaz para móviles.
- Nuevos módulos
- TPV táctil
- Nuevo motor de nóminas Generico
- Activos y amortizaciones
- Portal
- La revolución del Nuevo cliente web
- Rápido
- Nueva vista Kanban (arrastrar y soltar)
- Tableros personalizables
- Gráficos Gantt Dinámicos
- Modularidad
- Nueva arquitectura (sin reinventar la rueda)
- Facilidades para el debugging
- Mejoras en el framework
- Mejora de velocidad
- Mejora de productividad en proyectos y tareas
- Mejora de productividad en CRM
- Pantallas mejoradas en selección de personal
- Gestión de contratos desde contabilidad analítica
- Mejoras en la gestión de precios de envíos
- Nuevo plugin con Outlook
OpenERP nos invita a probarlo y dar feedback a todos… aquí os paso la invitación:
How can you help?
- Download OpenERP 6.1 RC1 (available as a Windows installer, Debian/Ubuntu package, RPM package and source tarball)
- Send us your feedback by reporting any issues you find via our Launchpad bug tracker.
- Please suggest translations via Launchpad translations for areas that are not translated in your language (click View All Languages at the bottom of the list). See also our guide to learn mode about translating OpenERP.
Que lo disfruteis!!!
Gestionar incidencias en proyectos
Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 12 Diciembre 2011
Como ya todos sabeis existen 2 módulos en el CRM de OpenERP que nos permiten registrar incidencias: crm_claim(reclamaciones) y crm_helpdesk(incidencias). Una limitación de estos módulos es que para controlar el tiempo dedicado a la resolución del caso, es requerido crear una tarea asociada al mismo en el área de proyectos. En el caso se registra el historial de interacciones con el cliente y en la tarea se registra el tiempo dedicado a su resolución, por lo tanto, de alguna manera se duplica la información, aunque esta forma de trabajar es totalmente válida y permite tener centralizadas todas las tareas de un proyecto, sean del tipo que sean.
Si queremos simplificar la gestión de casos de incidencias, además de estos 2 módulos, también también contamos con los siguientes en el área de proyectos.
project_issue –> Permite registrar incidencias con la misma estructura, estados y campos que en los módulos mencionados anteriormente con el añadido de que podemos directamente asociar el caso a un proyecto y si fuese necesario, desde el propio caso crear la tarea en proyectos.
project_issue_sheet –> Añade la posibilidad de imputar contra una cuenta analítica, el tiempo dedicado a la resolución del caso, directamente en el propio caso, sin tener que acceder a la tarea asociada.
Utilizando estos 2 módulos evitamos por tanto la necesidad de generar específicamente una tarea para la resolución de una incidencia puesto que la imputación de tiempo se puede realizar directamente en el caso.
Muy útiles para empresas de servicios que deseen controlar costes por tiempo dedicado o facturar por dicho concepto.
Facturación periódica en OpenERP
Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 7 Diciembre 2011
Este es otro tema recurrente sobre el que recibimos también muchas consultas. En este post intentaré aclarar las posibles soluciones que existen al respecto.
OpenERP de base, trae el módulo Suscriptions que permite de forma sencilla emitir facturas periódicas. Se crea una suscripción y para cada una, el sistema creará una copia de la factura del mes anterior.
Como alternativa y con una funcionalidad más potente, el año pasado KnDati / Sraps de Alistek publicó el módulo periodical_invoicing para OpenERP5.0 que permitía:
- Configurar cuotas periódicas mediante metodologías de facturación (alquieres, cuotas mensuales de mantenimiento, cuotas periódicas como suscripciones a revistas… etc)
- Parametrizar periodicidad de cobro de las cuotas (trimestral, anual, mensual) en contratos ilimitados y/o con fecha fija de baja.
- Incluía un nuevo concepto “contrato” donde se establecían las condiciones de facturación para un determinado cliente en función de los servicios contratados y su metodología de facturación.
- Se controla también parciales de un mes. Es decir, si son 30 días del mes y se da de alta el día 15, facturará medio mes.
- Mejora de la generación automática de facturas desde contabilidad analítica, ampliando el asistente incluido el standar de OpenERP.
Viendo la potencia del módulo y dada la necesidad de uno de nuestros clientes, decidimos migrarlo a 6.0 y extenderlo incluyendo además nueva funcionalidad requerida por dicho cliente.
La versión actual del módulo para 6.0, además de lo ya mencionado permite:
- Incluir en una única misma factura, conceptos periódicos y no periódicos realizados en una o varias ventas.
- Permite definir en la ficha de producto cómo lo vamos a facturar, bien sean servicios o bien sean materiales. Hemos incluido los tipos de facturación “pago único”, “pago a plazos”, “facturación recurrente” y “no pago”
- Para aquellos productos marcados como “facturación recurrente” se crea automáticamente el contrato al confirmar el pedido. En la línea de pedido podemos establecer las fechas en que se iniciará la facturación y su periodicidad.
- Para aquellos productos marcados como facturación única, creará su correspondiente línea de facturación en analítica una vez se confirma el pedido.
- Para los productos marcados como “a plazos”, se puede establecer la fecha de inicio de facturación y el número de plazos en la propia línea del pedido. El sistema generará en su fecha correspondiente tantas líneas en analítica como plazos de pago se establezcan.
Es decir, creamos un enlace desde ventas a analítica, de tal forma que se van “apuntando” todos los conceptos que son necesarios facturar, independientemente del momento en que se emita la factura.
Las líneas llevan una fecha. En el momento en que se ejecuta el proceso de facturación, estableceremos qué periodo deseamos facturar indicando 2 fechas. Para cada cliente/cuenta analítica, todas las líneas facturables de analítica cuya fecha esté entre dichas 2 fechas serán incluidas en la misma factura, tanto si son cuotas creadas automáticamente , como materiales, como horas dedicadas a una tarea, como otros conceptos, como si se incluyen las líneas manualmente en analítica sin provenir de ningún pedido…
Ejemplo:
- Vendemos a un cliente en uno o varios pedidos los siguientes conceptos:
- Un servicio que consta de un único pago por alta de servicio
- Un equipo informático a pagar en 3 plazos.
- Un contrato de mantenimiento con un importe mensual
- En la primera factura, se incluirán:
- El alta del servicio
- El primer plazo del equipo
- La primera cuota mensual por adelantado. Si el alta se da a mediados de mes, contará los días correspondientes y facturará dichos días.
- La segunda factura y la tercera incluirán:
- Segundo plazo del equipo
- Cuota mensual completa
- La cuarta factura incluirá únicamente la cuota mensual.
Aquí el link al proyecto, donde podeis descargaros los módulos, reportar bugs, hacer sugerencias o incluso subir mejoras si os animais:
https://launchpad.net/openerp-invoicing
Esperando os sea de utilidad.
Edito a 12/12/2011: A raiz de la publicación de este post, hace unos días Kaspars de Alistek inició un hilo en sus foros donde muestra su disconformidad por la forma en que la comunidad evoluciona o según él hace “un fork” de sus módulos. Os invito a participar ya que se ha convertido en un interesante debate. Por nuestra parte tenemos la conciencia totalmente tranquila al respecto. Como ya me venís conociendo hace bastante tiempo, el objetivo principal de esta Web es informar y siempre intentamos dar atribuciones a quien ha escrito el post, ha realizado los módulos o publica sus formaciones. También me causa cierto orgullo que la gente dé tanta importancia a la forma de informar en un simple post, de un simple blog y que éste sea mío.
Aprovecho la edición para incluir en el post los links que se me solicitan.
Saludos de nuevo:
Ana
Configuración multicompañía en OpenERP 6.0
Por Ana Juaristi Olalde - Funcionalidad OpenERP, Manuales técnicos OpenERP, Tutorial OpenERP, modulos openerp - 5 Diciembre 2011
Ultimamente me están llegando algunos correos donde nos preguntan si la multicompañía en OpenERP 6.0 funciona y en caso de que sí, cómo se configura.
Tenemos un par de clientes que arrancarán en Enero con multicompañía y por las pruebas que llevamos hechas, en principio, funciona y es usable. Ahora bien… hay que tener en cuenta algunas cosas y seguir una guía estricta para su configuración. También nos preguntan exactamente en qué consiste y cuándo es mejor opción poner una base de datos en multicompañía o una base de datos independiente para cada compañía. En cuanto a esto último, os pongo la claves para tomar la decisión.
- Se hace todo en una única base de datos por lo que posteriormente es más fácil sacar informes globales tomando de datos de todas las compañías.
- Se puede “compartir” la tabla de clientes/proveedores y la de productos por todas las compañías.
- Se puede especificar que un cliente/proveedor o un producto concreto sólo sea visible y utilizabe por una única compañía
- No se permite que un cliente/proveedor o producto sea asignado a más de una compañía. Es decir, será visible por todas o sólo por una por defecto. Si jugamos con la configuración de compañías padres e hijas, se puede hacer que un cliente / producto sea visible en el padre y todas sus hijas por ejemplo.
- Cada compañía tiene sus usuarios.
- Los datos de operativa de una compañía no los ve la otra, si no se permite. Es decir, un usuario que tiene acceso a pedidos, albaranes, facturas de una compañía, no verá por defecto los de otra compañía.
- Se puede definir un superusuario de una compañía “padre” que vea todo de todas las compañías. Esta compañía padre, solo vale para visualizar datos conjuntos de todas pero no vale para operar, es decir, para crear pedidos, facturas y demás… Esta compañía “padre” no existe legalmente, solo es una compañía ficticia, que se usa para configurar los maestros de todo el resto de compañías y para ver informes globales de todas.
- Cada compañía puede tener sus propios precios por los productos “compartidos”, sus impuestos, su propia tabla de cuentas contables. Cada cliente “compartido” también tendrá una cuenta contable propia en cada compañía.
Es decir, un usuario que entre a ver un producto en la compañía A verá un precio y un usuario que entre a ver el mismo producto en la compañía B verá otro precio (si lo tienen distinto). Igual pasa cuando ves un cliente. - Cada compañía también tiene sus propios almacenes.
- Seguro que me dejo muchas otras cosas pero básicamente esto os puede hacer tener una idea de si poner una multicompañía o hacer cada compañía en una base de datos independiente.
A continuación os pongo una lista de las tareas que hay que llevar a cabo para configurar una multicompañía en OpenERP 6.0
- Crear la nueva compañía en administración / compañías. Esto crea el cliente asociado a la compañía. Completar los datos básicos de cada una, incluido logo y datos básicos para informes, moneda… etc.
- Completar direcciones, sedes y contactos del cliente asociado a cada compañía.
- En contabilidad / configuración / configuración financiera / ejecutar asistente configuración financiera para nueva compañía. Siguiendo los datos del asistente crear la nueva configuración financiera, teniendo en cuenta haber instalado previamente los módulos de localización de cada país.
- Hasta aquí, lo más básico… Curiosamente cuando instalamos una monocompañía, el sistema de base nos carga una serie de datos de configuración que no se incluyen cuando creamos una nueva compañía. Entre ellos:
- Ventas: Crear la/s tienda/s de ventas para cada compañía
- Almacén: Crear la/s ubicación/es y almacén/es de cada compañía.
- Usuarios: Crear los usuarios de cada compañía
- Secuencias: Hay que duplicar manualmente todas las secuencias de la compañía “muestra” creando y asociando al menos las mismas para cada compañía. Cuidado con los nombres ya que posteriormente utilizaremos dichas secuencias para que sean asociadas a los diarios contables. Si no marcamos con un tag o un nombre distinto cada país/compañía, luego nos será complicado asociar la secuencia correcta.
- Diarios: Igual que con las secuencias, hay que crear manualmente muchos de los diarios. Algunos ya se crean durante la ejecución del asistente de configuración financiera pero otros no. Cuidado al asignar las secuencias. Coged en cada diario asociado a cada pais/compañía, las que correspondan. Si no, dará errores al operar. En España, tanto para multicompañía como para monocompañía, es requerido instalar nan_account_invoice_sequence. En los diarios de compra, venta y devolución de facturas, asignar la secuencia de factura correcta a cada tipo de diario.
- Configuración de divisas:
- Si requerimos además de multicompañía, que sea multidivisa, será necesario establecer una base de moneda para cada compañía. Es decir, en España la base monetaria será el Euro pero en USA será el dolar. Por lo tanto, debemos configurar cada moneda con su propia base para cada compañía. El resto de monedas serán calculadas como divisa con respecto a esta base.
- Recomendable instalar el módulo currency_rate_update. Permite que openERP se conecte a un Webservice para la actualización automática de los cambios de divisa. Puede ser ejecutado manualmente o puede establecerse una periodicidad para su ejecución, de forma desatendida.
- Configuración de tarifas:
- Cuidado aquí. Las tarifas de venta y compra deben ser creadas para cada compañía. Cada tarifa Base, debe llevar asignada la moneda base de dicha compañía.
- Se pueden establecer tarifas en otra moneda distinta a la de la compañía, basadas en la tarifa base, de tal forma que se mostrará la moneda en la que se compra o vende, durante todo el ciclo hasta la factura. Sin embargo, al realizar el asiento contable de la factura de compra o venta realizará la conversión a la moneda base en el asiento contable y marcará el importe en divisa. Cuidado también aquí con la moneda base establecida en el diario en que se hace el apunte. Debe ser igual que el de la compañía, si queremos contabilizar todo en moneda única.
- Precios de productos:
- Si se requiere establecer un precio base para cada producto en cada país/moneda, recomendamos instalar product_multi_company. Esto convierte el campo precio en un campo property, lo cual nos permite tener un precio base del producto para cada compañía.
Y creo que es todo. Con esto, hemos conseguido configurar una base de datos multicompañía, con los elementos básicos para funcionar en las áreas de gestión (ventas, compras, almacén, facturación y contabilidad)
Esperando sea de vuestro interés, cordiales saludos:
Ana
Curso de Camptocamp sobre webkit_report
Por Ana Juaristi Olalde - Cursos Online OpenERP, Funcionalidad OpenERP, General, Informes en OpenERP - 17 Noviembre 2011
Importante e interesante anuncio de camptocamp quien impartirá próximamente 3 sesiones de formación sobre su novedoso motor de informes Webkit_report. Paso a traducir íntegramente el anuncio.
Podeis ver el original en su blog:
OpenERP WebKit Report Webinars: descubre un poderoso motor para crear fácilmente PDFs
Para profesionales interesados en aprender más sobre el motor de informes para OpenERP OpenERP WebKit Report engine, el equipo de Camptocamp Business Solutions’ team os anuncia 3 nuevos webinars en diciembre 2011 y enero 2012
Totalmente compatible con OpenERP, WebKit report es una revolucionaria herramienta que permite a los usuarios de OpenERP crear informes PDF de una forma intuitiva, limpia y sofisticada.
Presentacion: http://files.me.com/nbessi/06n92k.mov
Titulos y fechas de las sesiones:
1. OpenERP WebKit Report Webinar 1: Startup training (Beginner Level)
Tuesday, December 13th from 10:30AM to 12:00PM (CET)
Más información here
2. OpenERP WebKit Report Webinar 2: How to easily create reports? (Intermediate Level)
Tuesday, December 20th from 10:30AM to 12:00PM (CET)
Más información here
3. OpenERP WebKit Report Webinar 3: How to get most of this report engine? (Advanced Level)
Tuesday, January 10th from 10:30AM to 12:00PM (CET)
Más información here
El precio de cada sesión es de 40€.- ; el registro a todas las sesiones de formación (3 webinars) te permite tener 20% de descuento. El precio para poder asistir a los 3 webinars es de 100€.- ; Para más información y registro ve here!
Los webinars serán presentados por Nicolas Bessi, Business Solutions Technical Manager en Camptocamp y OpenERP top contributor. La duración de cada sesión será de 1.5horas
Las sesiones se impartirán en Inglés. Bajo demanda, podemos programar nuevas fechas y lanzar los Webinars en Francés!
Esperamos verte pronto!
En Avanzosc hemos querido ser los primeros en apuntarnos. ¿A qué esperas?
Nueva solución para la Migración entre versiones de OpenERP
Por Ana Juaristi Olalde - Comunidad Española OpenERP, Kettle - OpenERP, Nuevas versiones OpenERP - 7 Noviembre 2011
Como siempre… Albert Cervera de Nan-tic, nos sorprende con esta buenísima noticia. Os paso íntegro el post en castellano, que creo que merece la pena. Aquí el link original al artículo. Incluyo también links a las traducciones en inglés y catalán.
Castellano: http://www.nan-tic.com/es/presentando-kafkadb
Inglés: http://www.nan-tic.com/en/presenting-kafkadb
Catalá: http://www.nan-tic.com/ca/presentant-kafkadb
Presentando KafkaDB
Hoy queremos presentaros KafkaDB, nuestra nueva criatura que acabamos de publicar en bitbucket. KafkaDB es una herramienta que simplificará la tarea de migrar bases de datos entre versiones de OpenERP, pero también se podría extender para permitir la migración entre versiones entre otras aplicaciones basadas en PostgreSQL. En la página principal del proyecto, podéis encontrar información detallada sobre el diseño y como utilitzarla, pero ahora quería haceros cinco céntimos de cómo hemos llegado hasta aquí.
Los requerimientos
Desde que OpenERP SA anunció que las herramientas de migración no formarían parte del software público empezamos a dar vueltas en cómo podríamos implementarlas de forma reutilizable. Algunas empresas buscaron soluciones a corto plazo, simplemente mirando de solucionar el problema para uno o dos clientes que querían pasar de la 4.2 o la 5.0 a la 6.0 y posponiendo la búsqueda de una solución real. Nosotros estábamos convencidos que de la misma manera que la herencia había permitido a OpenERP tener centenares de módulos hechos y liberados por muchos desarrolladores, podríamos conseguir lo mismo con las migraciones.
Así que básicamente teníamos que implementar algo que solucionara los siguientes requerimientos:
- Modular: tenía que proveer un mecanismo mediante el cual se pudieran reutilizar las transformaciones de datos de una base de datos a otra.
- Rápido: dada la medida de las bases de datos de algunos de nuestros clientes, sabíamos que tendríamos que mover la información a nivel de base de datos.
- Fácil de compartir: además de ser modular, queríamos asegurarnos que sería sencillo para todo el mundo compartir sus transformadas. Dado que la información sobre la migración no estaría incluida en los módulos, necesitábamos que fuera sencillo de compartir, así cómo de encontrar qué transformadas había disponibles.
Búsqueda y desarrollo
Nos ha costado un cierto tiempo hasta llegar al diseño actual de KafkaDB. El proceso empezó con una pequeña prueba de concepto utilizando Python y openetl, un ETL creado por OpenERP SA, pero abandonado este mes de junio. Descartamos esta opción, no tan sólo porqué estaba abandonado, sino también porqué la API no era intuitivo. Además, a pesar de que no llegamos a hacer pruebas, parecía que podía ser relativamente lento.
La primera alternativa fue buscar otro ETL basado en python. Esta vez el candidato fue el Brewery. Éste tenía una API bastante mejor pero no disponía de algunas funcionalidades básicas que necesitábamos y a pesar de que habríamos podido contribuir al proyecto, necesitábamos centrarnos en solucionar los problemas que teníamos, no a implementar un ETL desde cero.
Habríamos querido que fuera en python, especialmente para hacer más sencillo que la gente contribuyera, pero empezamos a buscar alternativas en otros lenguajes. Scriptella fue el primer candidato y éste basa su configuración en un fichero XML, así que nos pareció atractivo. Ya sabíamos que el sistema que escogiéramos acabaría teniendo un fichero de configuración, así que a primer vistazo parecía que esta podía ser una buena opción porque el sistema ya dependía de uno. A pesar de esto, no nos convenció el comportamiento por defecto de algunas opciones del sistema, además del hecho que el XML parecía que podría ser poco práctico puesto que fácilmente podíamos llegar a las 400 tablas.
Así que Àngel, uno de mis socios y nuestro experto en Kettle y grandes migraciones de datos, empezó a jugar con la API de Kettle y mirar a ver qué se podía hacer con transformadas manuales y algunos automatismos. Pronto se dio cuenta, que no tan sólo podía cumplir todos los requerimientos que teníamos, sino que además, permitíamos que personas que no fueran desarrolladores también se podían migrar su base de datos. Por ejemplo, varios de nuestros clientes se lo podrían hacer ellos mismos si lo desearan!
Además, Kettle es probablemente el ETL estándar de facto y especialmente entre la comunidad OpenERP (gracias a Terminatooor, un conector para Kettle creado por Akretion, especialmente diseñado para funcionar con OpenERP).
En resumen, a pesar de que KafkaDB no está acabado del todo todavía, estamos convencidos que constituye una buena base para el sistema de migraciones flexible que necesitamos, no tan sólo para migrar información entre versiones de OpenERP, sino también entre aplicaciones diferentes siempre y cuando se necesite reutilizar el proceso para diferentes bases de datos con estructuras parecidas.
Nuevo módulo de Activos mejorado disponible para OpenERP 6.0
Por Ana Juaristi Olalde - Funcionalidad OpenERP, Noticias, Publicaciones, Notas, Anuncios Openerp - 6 Noviembre 2011
De nuevo la comunidad de OpenERP soluciona el tema de activos que venía coleando desde hace bastante tiempo. Hace unas pocas semanas recibimos este correo de Wilson Arias Chasqui de Colombia, en la lista de localización española. Os lo posteo tal cual:
- Crear categorías de activos para diferenciar los activos fijos (maquinaria y equipo, construcciones y edificaciones, equipo de oficina, equipo de cómputo y comunicación, etc.), intangibles y diferidos.
- Configurar métodos de depreciación o amortización, según se necesitara.
- Hacer la asignación de cuentas.
- Crear los activos con su jerarquía, su cuadro de depreciación (o amortización), aplicar los asientos contables.
- Tener una opción de análisis de activos.
Vamos a probarlo un poco más en profundidad pero en principio, estupendo.
Muchísimas gracias Wilson por la aportación!!
Ana
Liberado el primer módulo de OpenERP para la gestión de Ayuntamientos
Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 27 Octubre 2011
Nos congratula anunciaros que el primer módulo de OpenERP para ayuntamientos ha sido liberado.
Rama de launchpad para su descarga:
https://code.launchpad.net/~ting/ting-addons/ting_fee_management
Entre otra funcionalidad incluye la siguiente:
- Callejero, con la información legal exacta del municipio
- Terceros, normalmente la información del padrón del municipio completada con los datos de no empadronados. Todos los terceros tienen asociados los conceptos y subconceptos que les son aplicables.
- Conceptos y subconceptos de tasas municipales, incluyendo diferentes tipo de cálculos para la correcta definición de las mismas.
- Creación de expedientes y liquidación de los mismos, siguiendo con la emisión de tasas correspondientes.
- Modelo 060 de recibo bancario para el cobro de los importes de la tasa emitida.
Os paso link a la noticia completa publicada por Carlos de Ting en Twitter:
