Hola Ana,

Pretendo cumplir 3 objetivos:

• Que queden claras todas las opciones de instalación de OpenERP (que creo causa bastante confusión, sobre todo a gente no técnica ) y en qué consiste cada una.
• Que se entienda en qué consiste cada una de las fases de implantación, permitiendo a cada empresa identificar que tipo de arranque es el  más apropiado para ellos. Nadie mejor que uno mismo conoce su propia empresa (creo… )
• Que la empresa que está pensando en contratar una implantación conozca qué servicios se ofrecen habitualmente y que tenga claro al contratar, lo que está contratando, identificando además si le serán necesarios todos y cada uno de dichos servicios o sólo necesita algunos.

Sin más… aquí va. Espero que os guste:

Aquí os  dejo un resumen con extractos de los párrafos más interesantes y una genial conclusión de Santi de Pexego y ahí paro, ya que la siguiente reflexión de Jose Prieto, tiene fácilísima solución y a mi entender no aporta demasiado. Si te falta algo NO PIDAS a otros que lo hagan. Busca clientes que lo financien y subcontrata lo que necesites o hazlo tú mismo. Fundamento del software libre. Repetimos por enésima vez en estos días que ninguno somos ninguna ONG.

Espero que a los recién llegados también les aclare ciertas dudas sobre la parte financiera/contable de OpenERP en España. También invito a nuestros clientes y a los de todos a leer en detalle este hilo al completo directamente en nuestra lista de correo de localización: openerp-spain@googlegroups.com

Cordiales saludos!!

Ana

JM: Hola a todos, Estoy interesado en utilizar la opción que ofrece OpenERP en la modalidad SaaS pero me preocupa los relativo a la localización española ya que en la modalidad SaaS no tienes acceso a instalar módulos. Me imagino que en el SaaS utilizarán el módulo estándar l10n_es, y no se si con eso es suficiente ya que no conozco las diferencias con el l10n_es_pyme_account.

RE: El módulo l10n_es sólo añade el pla contable español. Relativo a todo lo otro, debes añadir la larga lista de 20 módulos que empiezan por l10n_es. En www.aulaerp.com encontraràs documentación cada uno de ellos (o los más comunes)

Más información sobre módulos l10n_es: http://www.zzsaas.com/es/modulos

AJ: Es que el SAAS “oficial” de OpenERP no incluye ni módulos de localización, ni módulos a medida de los clientes. Solo tiene los módulos oficiales y por tanto sólo incluye el módulo básico de la localización l10n_es “certificado”. Como te dice Raimon, la localización española tiene más de 20 módulos l10n_es que no están “certificados” por Bélgica, ni se incluyen en la versión “oficial”.
No obstante tienes alternativas varias, entre ellas zzsaas, como te comenta Mario.

JM:Una cosa más: ¿veis viable en la práctica trabajar solo con el módulo básico de la localización española?
¿Se podrían presentar los impuestos telemáticamente solo con el módulo básico?

IB:Sinceramente, si utilizar solo el módulo básico pierdes gran parte de la funcionalidad que tiene la localización españoa. Este módulo solo carga el plan contable, posiciones fiscales e impuestos. Faltan módulos que en mi opinión son bastante necesarios para la contabilidad española: recibos 19,32,34 y 58, extractos con la norma 43, modelos 340,347 y 349, aunque el 340 de momento no es obligatorio para todas las empresas,
informes financieros y aunque no imprescidible pero muy util la base de datos de bancos y municipios.

La presentación telemática de impuestos no esta en el módulo básico. Son módulos a parte que te he comentado antes. Yo te recomendaria utilizar una empresa española para el servicio Saas o montar tu propio servidor en la nube con los módulos que precises.

Los modelos 340, 347 y 349, exportan a fichero de texto que es compatible con la presentación telemática de Hacienda

JM: Entonces ¿la función de OpenERP que permite exportar a fichero de texto para la presentación telemática del modelo 340 y demas no está?Lo digo porque como la presentación telemática de impuestos (con esos ficheros de texto) es obligatoria, si el modulo básico no permitegenerar estos ficheros entonces no es que se pierda funcionalidad si no usas la localización española, es que es directamente inviable trabajar solo con el módulo básico. ¿estoy en lo cierto?

Y TAMBIEN LA MIA… al 100%

Este tema ha sido uno de los más hablados, el que más discordia ha creado en la comunidad y el que más preocupados nos tenía a los partners.

Para aquellos que llegais ahora o no entendeis nada de lo que estoy diciendo, intento resumir.

• La mayoría de los editores de software que llegan al nivel de expansión de OpenERP en el mundo, deciden optar por un modelo mixto de módulos “licenciados” o de pago como estrategia de negocio. Lo que sería una versión comunidad sin coste de licencias y una versión “enterprise” con módulos de pago, o con una licencia particular. Por contra, OpenERP siempre ha defendido la publicación libre de todos sus módulos y por tanto, la diferencia entre la versión comunidad y la versión enterprise, es la contratación o no de la garantía de OpenERP, la cual incluye soporte a errores (bugs) y migración de versión.
• En su momento, OpenERP decidió NO publicar sus scripts de migración de datos, de una versión a otra, lo cual es totalmente lícito (cualquier empresa del mundo requiere definir sus líneas de negocio, si no, no serían empresas sino ONGs) pero trajo innumerables críticas tanto de partners como de la comunidad ya que la única forma de migrar OpenERP de una versión a otra, era contratando la garantía. Hasta aquí perfecto y sin problema siempre y cuando un cliente utilizase los módulos del core.

Pero se da el caso de que NINGUN cliente utiliza SOLO los módulos del core, sino que además, existen módulos no oficiales (denominados módulos de localización) que adaptan el sistema a los requerimientos fiscales de cada país y por tanto su instalación es imprescindible en cada uno de ellos. Así, en españa tenemos la localización española, en Venezuela la venezolana, en Suiza la Suiza…

Además de los módulos de localización, la mayoría de los clientes suele adaptar el sistema a sus necesidades específicas por lo que solicitan módulos a medida o también pueden requerir otros módulos publicados por la comunidad o por partners de OpenERP. Estos módulos al no ser parte del core, evidentemente, no se incluyen en el contrato de garantía.

No obstante era posible solicitar la migración de TODOS los módulos de una instalación, sea esta cual sea y tenga los módulos que tenga, siendo el precio de 800€ por cada 1000 líneas de código extra por CADA implantación. Cada cliente que solicitase el servicio debía pagar esta cantidad. Esto era comprensible para módulos específicos de un cliente que los haya mandado desarrollar pero no para los módulos de localización, ya que son requeridos en cada una de las implantaciones que hacemos. Casualmente, la localización española es una de las más maduras y fuertes que existen y el número de líneas es considerable, con lo cual el importe a pagar por cada uno de nuestros clientes en cada versión (cada 18 meses) no era asumible. Por tanto, determinamos que el servicio ofrecido por OpenERP, NO CUBRIA las necesidades de nuestros clientes y nos empezamos a preocupar.

Después de 2 años … innumerables emails, reuniones, skypes y todo lo habido y por haber… nuestra percepción era que OpenERP no nos escuchaba. La percepción de OpenERP era que nosotros íbamos por libre y a nuestro aire, sin contrubuir a su estrategia de negocio y sin apoyarles en su expansión, lo cual en bastantes ocasiones en los últimos meses nos ha llevado a situaciones tensas y malos ratos innecesarios.

Hasta aquí, el pasado… ahora… el futuro:

• El no liberar los scripts de migración es decisión de OpenERP, es su estrategia de negocio y están en su perfecto derecho de definir dicha estrategia
• OpenERP asume que los módulos de localización española son requeridos por todos los clientes españoles por lo tanto, se incluirán como módulos NO Extra en las migraciones. Es decir, no existirá coste extra en la garantía “oficial” para estos módulos. No obstante, en toda migración se requieren servicios extra para validar, testear y probar la migración con lo cual CADA PARTNER decidirá el coste extra que incluirá en la garantía oficial para asumir las horas de servicio para realizar la migración.
• Los módulos que sean específicos de un cliente podrán ser migrados de 2 formas:
  • El  partner asume la migración –> OpenERP no incluye coste extra para las líneas incluidas en estos módulos
  • OpenERP asume la migración de estos módulos –> El cliente deberá asumir el coste de 800€ por cada mil líneas de código en módulos personalizados.

• Si un partner demuestra que un módulo extra o desarrollado a medida es utilizado por más de 10 clientes con garantía, entonces el partner podrá proponer el módulo para que sea incluido dentro del contrato de garantía, con la migración incluida sin coste adicional (como hemos dicho antes, esto sólo sería necesario si el partner prefiere que openERP realice el trabajo de migración del módulo).
• EN TODOS ESTOS CASOS, tanto la garantía de soporte (bugs) de los módulos de localización como los que se desarrollen a medida deberá ser asumida por el partner y la inclusión de los módulos se refiere UNICAMENTE a la migración de datos. No al soporte técnico de los módulos.

Como veis el escenario cambia totalmente. En este caso, el contrato de mantenimiento con OpenERP pasa a ser una garantía real, requerida y necesaria. Por fin vamos a poder ofrecer a nuestros clientes OpenERP enterprise con garantía. Una vez resuelto el tema con OpenERP S.A, ahora solo hemos de ver si es necesario cambiar algo internamente en la forma de organizar la localización o el sistema actual sigue siendo válido, pero esto es ya otra historia distinta a definir entre nosotros.

Por último, daros una pincelada sobre cómo funciona técnicamente el servicio ofrecido por OpenERP porque lo cierto es que hasta ayer ninguno lo habiamos entendido bien. No entendíamos cómo en caso de no querer asumir el coste de 800€ por cada 1000 líneas de código podiamos asumir nosotros parte de una migración y OpenERP otra. Ahora sí lo entendemos. Aquí va:

Entendamos primero en qué consiste una migración de datos entre versiones:

• En una instancia a migrar tenemos 2 partes: módulos python + BBDD postgresql.
• En principio, supongamos módulos python de una versión y bbdd postgresql de la misma versión. Si por algún motivo hubiese cambios en la lógica de la aplicación sin cambios estructurales en la base de datos, no hay ningún problema ya que el sistema internamente provee de un proceso automático de actualización, es por esto que en la migración de versiones menores (6.0.1, 6.0.2), no existe ningún problema. Solo cambia la parte python, por lo con ejecutar un “actualizar todos” desde el propio interfaz, el sistema queda actualizado.
• El problema viene cuando hay cambios estructurales en la base lo cual es inevitable cuando se publica una versión mayor ( esto es 5.0 a 6.0, o en su caso 6.0 a 6.1 ). En este caso, es necesario transformar una estructura en la otra, sin perder los datos que previamente se hubiesen cargado. Esto es lo que ofrece el sistema de garantía de OpenERP.

Veamos ahora cómo sería el proceso a seguir:

• OpenERP provee una herramienta que nos permite “subir” una bbdd de una versión y devuelve la misma base de datos “migrada” a la nueva versión. SOLO las tablas correspondientes a los módulos del core serán migradas. Todo el resto de tablas, será mantenido exactamente igual que estaba. (Nota: A fin de proteger la confidencialidad de datos de los clientes, la base de datos se sube y se recibe encriptada)
• OpenERP migra SIEMPRE los módulos python oficiales a la nueva versión.
• Bien OpenERP(con el coste antes mencionado) o bien el partner migra los módulos python no oficiales, sean de localización o sean a medida, para que puedan ser instalados en la siguiente versión. (Para facilitar el trabajo al partner, OpenERP provee de una herramienta denominada runbot, donde el partner puede testear los módulos los cambios que serán necesarios realizar en el código python)
• El partner, realizará la instalación de la nueva versión con los módulos python migrados, desencripta la base de datos recibida y lo sube a la nueva instancia creada. Reinicia el servidor con Update==ALL.
• En este punto, la migración en sí, ya está realizada.
• Por último, el partner con su cliente testea los datos y cada uno de los procesos funcionales que utiliza para verificar que todo ha quedado correcto. Si hubiese algún problema o proceso que el sistema automático ha generado, se reporta a OpenERP como bug. El arreglo de este bug en el proceso de migración está incluido en el contrato de garantía.
• El proceso puede ser repetido tantas veces como sea necesario, es decir, el partner puede subir la base de datos encriptada de su clientes tantas veces como se requiera, hasta que se obtenga la validación de la migración por parte del cliente, hasta llegar al grado de depuración requerido.

Creo que estos son los puntos más importantes, aunque si los que estuvisteis en la reunión, veis que falta o me he equivocado en algo, por favor, no dudeis en ponerlo en los comentarios para que pueda rectificar o ampliar el post.

Por último, comentaros que muy en breve tendremos un post en el blog de OpenERP donde nos explicarán en detalle el proceso de migración y ampliarán la información que doy aquí de forma resumida. Prometo traducíroslo en cuanto se publique.

No me queda más que agradecer a OpenERP y en especial a Fabien y Marc el tiempo que nos dedicaron. Mención especial también a Rubén, por “meter caña”

A Nhomar de Vauxoo, por su apoyo y su valiosa intervención en la reunión. A Nacho de Alfa90, el haber expuesto con suma claridad el problema por parte del cliente, lo cual ayudó en gran medida a que OpenERP entendiera (por fin!) nuestra visión del tema. Y como no… a Santi de Pexego, figura imprescindible en la localización española con quien la mayor parte de las veces comparto la forma de ver las cosas.

Muchas gracias a todos:

Ana

P.D: Edito a 17/04/2012 para incluir el link que sobre el mismo tema ha escrito Santi en el blog de Pexego. Merece la pena:

http://www.pexego.es/blog/2012/04/15/openerp.-sobre-vision-y-modelo-de-negocio

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.

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

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.

1. 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.
2. Se puede “compartir” la tabla de clientes/proveedores y la de productos por todas las compañías.
3. Se puede especificar que un cliente/proveedor o un producto concreto sólo sea visible y utilizabe por una única compañía
4. 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.
5. Cada compañía tiene sus usuarios.
6. 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.
7. 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.
8. 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.
9. Cada compañía también tiene sus propios almacenes.
10. 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

Podeis ver el original en su blog:

http://www.camptocamp.com/fr/blog/2011/11/openerp-webkit-report-webinars-discover-a-powerful-engine-to-easily-create-pdfs/

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?

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:

http://www.ting.es/2011/10/27/openerp-ayuntamientos/

Aquí uno muy resumido para configurar el conector de Thunderbird. Hay 2 partes, por lo tanto, os paso los links a 2 videos.

PARTE1: Configurar módulo en OpenERP y guardar Plugin para su instalación posterior en Thunderbird (3 frames)

http://www.openerpsite.com/wp-content/uploads/conexion_openerp_thunderbird.htm

PARTE2: Instalar plugin en Thunderbird + asociar correos a partners + crear iniciativas con correos de Thunderbird + crear contactos en OpenERP desde Thunderbird

http://www.openerpsite.com/wp-content/uploads/Thunderbird2.htm

Esperando os sirva de algo:

Ana