Un módulo impresionante: poweremail para OpenERP

Diciembre 30th, 2009

Buenas… creo que merece la pena comentaros la existencia de un módulo impresionante: poweremail. El módulo ha sido desarrollado por Sharoon Thomas y podeis ver su funcionalidad aquí:

http://sharoonthomas.blogspot.com/2009/09/poweremail-for-open-erp.html

Resumiendo mucho, permite.

  • Definir plantillas de e-mails tanto en texto plano como en Html que pueden ser asociadas para envío de mails desde cualquier punto de la aplicación, bien sea de forma automática asociado a un evento y/o acción de servidor (requiere formación técnica) o bien manualmente, mediante un botón que se genera automáticamente en la pantalla que definas en su configuración. Ejemplos.
  1. Envíos Manuales de e-mail: Definir que aparezca un botón en los formularios de pedido, albarán o factura y que al pulsar el botón se envíe el correspondiente documento en formato pdf.
  2. Envíos automáticos de e-mail: Definir que se envíe automáticamente un e-mail a Cliente cuando su pedido cambie de un estado a otro, o cuando su albarán sea realizado… o en cualquier otro caso o evento controlable dentro de la aplicación.

Adicionalmente tanto si el envío de e-mail es automático como manual puedes asociar a cada caso plantillas del tipo:

Estimado [Nombre de cliente] :

Remitimos su pedido en las condiciones acordadas por Tfono a fin de verificar su conformidad.

  • Puedes asociar una cuenta de correo a power e-mail de tal forma que los correos que lleguen a dicha cuenta sean recibidos directamente en openerp.

Os invito a instalarlo y probarlo. Si al instalar en un servidor debian o Ubuntu os da un error sobre mako template, quiere decir que el módulo utiliza esta librería para funcionat. La teneis que instalar en el servidor con esta sentencia:

sudo apt-get install python-mako

Esperando os sea de utilidad, cordiales saludos!!!

Ana

¿Qué tendrá la nueva versión 5.2 de OpenERP?

Diciembre 17th, 2009

Mucha gente últimamente me está preguntando si se sabe algo de la nueva versión 5.2 que se espera sea publicada durante el primer trimestre de 2010 y sobre qué es lo que tendrá de nuevo, por lo tanto, he encontrado este post en el blog de Fabien aquí:

http://fptiny.blogspot.com/2009/11/v52-is-approaching.html

donde podemos encontrar un link a laumchpad donde nos dan la lista de nueva funcionalidad que incorporará esta nueva versión:

https://launchpad.net/openobject-addons/+milestone/v5.2 que paso a traducir a continuación:

En la próxima versión estable. Es el mínimo para ser implementado en la V5.2

Server/Addons:

- Ocultar la lista de bases de datos por seguridad (opción)

- Revisión del portal de clientes: proyectos, bugs, reuniones, ventas, facturas, etc.

- Mejora  de módulo de gestión documental (links)

- Integrar nueva funcionalidad del CRM de Axelor (webmail, alertas, invitaciones, etc.) –> Aun esperando su módulo.

- Simplificar menús y desarrollar una vista de búsqueda para cada módulo

- Mejor manejo de traducciones acordes a las guías de launchpad. (+merge/traducciones francesas completas)

- Mejor multi-compañía (no como módulos separados, sino en cada módulo. Multicompañía configurado por defecto)

- Revisar vistas detodos los procesos (mejores explicaciones, …)

- certificar más módulos (l10n_…)

- Integrar más módulos en addons (módulos de formación, nueva TPV, I10n_)

- Mejor ergonomía(Botones en listas, formularios revisados, etc)

- llamadas de conexión  HTTP  (merge propuestas desde xrg)

- Sistema genérico de encuestas (para CRM, tareas, evaluación de RRHH… etc)

eTiny:

- modularidad !
- Mejoras en ergonomía: Vistas de búsqueda, manejo de menús…
- no poder listar dbs, cajas de texto para escribir el nombre de la bbdd
- Calendarios multi-objeto (ver reuniones/vacaciones en calendario de tareas) calendar)
- Revisar diseño y ergonomía

GTK;

- No listar bbdd, textbos para escribir nombre de la bbdd
- Mejora en ergonomía: Vistas de búsqueda, manejo menus, botones en lista

Chequeo y control de mantenimiento/migraciones

Revisión/desarrollo de plugins de integración con outlook, caldav, thunderbird, openoffice.

Como siempre, la estabilidad y la ausencia de errores es nuestra primera prioridad

Esperando os haya sido de interés!!

Ana

Publicado módulo para obras de Ingeniería civil

Diciembre 16th, 2009

Buenas… os anuncio la publicación de un nuevo módulo para obras de ingeniería civil (Vertical para el sector de la construcción, inmobiliaria y arquitectura).

Aquí va el detalle de lo que contiene:

Civil engineering work (Obras de ingeniería civil) es un módulo para la gestión de proyectos de ingeniería civil. Se ha publicado en launchpad, en la rama addons-extra

  • Añade un nuevo menú para gestionar obras de ingeniería civil: Localización, agentes y otros consultores, datos de la obra, datos estructurales y asignaciones a proyectos.
  • Nuevas entidades para las obras de ingeniería civil (todas estas entidades tienen una estructura jerárquica y una vista en árbol, las obras de ingeniería civil pueden ser filtradas desde la vista en árbol)
    • Clase de encargo
    • Uso de la obra
    • Tipo de estructura
    • Tipo de cementación
    • Abstracción del modelo estructural
    • Software de modelizado estructural
  • Añade una nueva pestaña en los formularios de proyectos, ventas y compras para relacionarlos con las obras de ingeniería civil

Este módulo ha sido desarrollado por zikzakmedia para la empresa FSEstructuras, Diseño y Cálculo de Estructuras de Edificación. Se encuentra actualmente con la localización de inglés, español y catalán.

Obras de enginiería civil

Publicado módulo para la impresión de CONTRATOS de VENTA

Diciembre 13th, 2009

De nuevo gracias Ting, contamos con un módulo para la impresión de contratos complejos, en OpenERP. El módulo consta de un apartado en la empresa, donde se pueden definir condiciones generales y condiciones particulares de contratación.

El módulo permite incluir en el contrato, la planificación y el personal asociado al proyecto relacionado con la venta de forma automática. Muy útil sobre todo en las empresas de servicios, donde realizar un contrato personalizado a cada cliente cuesta normalmente mucho tiempo y esfuerzo.

El módulo ha sido publicado en la rama trunk de addons-community

https://code.launchpad.net/~openerp-community/openobject-addons/trunk-addons-community/

Cordiales saludos!!!

Ana

Publicado módulo para la contabilización de NOMINAS

Diciembre 13th, 2009

Me congratula anunciaros que ya tenemos un módulo que permite realizar automáticamente asientos contables de nóminas.

l10nES_hr_nomina

El módulo ha sido realizado por el equipo de www.ting.com (Carlos Liébana, Hugo y Leo). Aquí os paso la descripción del módulo y lo que hace.

Recursos Humanos: Gestión de Nóminas
Este módulo permite automatizar la creación de los asientos contables para las nóminas de los empleados.

Uso del módulo:
- El primer paso es configurar las cuentas y el diario en el que se van a contabilizar las nóminas para ello hay que ir a Administración -> Usuarios -> Arbol de la compañia -> Compañias y dentro de la página configuración de compañias configurar estas cuentas.
- Se deben poner los datos de la nómina en la ficha del empleado en recursos humanos dentro de la pestaña salario
- Para generar las nóminas se usa el wizard definido dentro de Recursos Humanos -> Nóminas -> Generar Nóminas
- Para confirmar y pagar las nóminas se debe ir al menú Recursos Humanos -> Nóminas -> Ver Todas las Nóminas
- Existen wizards para crear anticipos y pagas extras.
- Para pagar los anticipos se debe ir al menú Recursos Humanos -> Nóminas -> Ver los anticipos

La semana entrante será incluido en la rama de localización Española, y se podrá descargar junto con el resto de módulos de localización. Gracias a Ting por su aportación.

Cordiales saludos!!!

Ana

Guía de estilo para programar en python módulos de Open ERP

Diciembre 12th, 2009

Buenas…

Os posteo aquí una guía de estilo traducida que ha publicado Sharoon Tomas en su blog aquí. Por favor, todos los comentarios, mejoras y sugerencias que se os ocurran, posteadlas directamente en el post origial de Sharoon para que no se pierda niguna y se vaya completando la guía:

My first proposals for framework team (Updated with community feedback)

Mi primera proposición para el grupo Framework (actualizado con la opinión de la comunidad)

A. Strict PEP style guide compliance (http://www.python.org/dev/peps/pep-0008/)

* El código se lee mucho más a menudo de lo que se escribe. Por lo que debemos poner el foco en su legibilidad

  • Indentación: Usa espacios. No tabuladores. Cada indentación deben ser cuatro espacios.
  • Líneas en blanco: Las definiciones de métodos dentro de una clase deben ser separadas por una línea en blanco.
  • Separación de código y longitud de línea: La longitud de línea debe ser menos de 80 caracteres (=79) . En el contexto de Open ERP separa las tuplas de los campos de selección en varias líneas. (esto también ayuda con el control de versiones)
  • Importación: Las sentencias de importación (imports) deben estar en líneas separadas. Los imports siempre deben estar al principio del archivo, justo después de cualquier comentario de módulos y strings de documentación y antes de las constantes y variables globales del módulo. Los imports deben estar agrupados en el siguiente orden.
  1. imports librerías standar(time, datetime, os etc)
  2. imports de librerías adicionales relacionadas (mako, relatario etc)
  3. imports específicos y librerías locales (osv, fields, external_osv etc)
  • Los comentarios que contradicen el código son peor que el que no haya comentarios. Siempre prioriza la actualización de comentarios cuando cambie el código.
  • Los comentarios deberían ser sentencias completas. Si un comentario es una frase o sentencia, su primera palabra debería ser capitalizada, a menos que sea un identificador que se inicia con minúsculas (nunca alterar la forma de los identificadores )

Para los strings de documentación deberíamos seguir esto http://www.python.org/dev/peps/pep-0257/

  • Guion bajo: _single_leading_underscore: Para métodos on_change, métodos o campos de función, métodos para asignar campos de selección y métodos en botones de vistas. También para métodos que no deberían ser llamados directamente. (Indicador de uso interno.  p.e. “from M import *” no importa objetos cuyo nombre comienza por guión bajo)
  • Guión bajo al final: – single_trailing_underscore_: usado por convención para evitar conflictos con palabras reservadas de python. Eg: Tkinter.Toplevel(master, class_=’ClassName’)
  • Doble guion al principio: – __double_leading_underscore: al nombrar un atributo de clase, invoca al nombre del “padre”  (dentro de la clase class FooBar, __boo se convierte en _FooBar__boo; ver abajo).
  • Guion doble al principio y al final: __double_leading_and_trailing_underscore__: objetos “magic” objetos o atributos que viven en espacios de nombres controlados por el usuario E.g.           __init__,  __import__ or __file__.  Nunca te inventes estos nombres. Solo utilizalos como se ha documentado.
  • Nombres de módulos de Open ERP: Los módulos deben ser cortos, en minúsculas. Los guiones puden ser utilizados en el nombre del módulo si aporta legibilidad.
  • Versiones de módulos de Open ERP : <<Por favor, alguien que lo sepa que lo explique>>
  • Nombres de excepción: Porque las excepciones deberían ser clases. Las convenciones de nombrar las clases aplican aquí. De todas formas, deberíais usar el sufijo “Error” en vuestros nombres de la excepción (si la excepción, es un error)

Nota: Open ERP tiene mucho de esto: Line 880 in orm.py : raise _(‘The read method is not implemented on this object !’) está mal. devuelve un string al método por _ in tools.translate return string. Las excepciones string están prohibidas en en py 2.6 and posteriores.
Al enviar una excepción, usar “raise osv_except(name,value,exception_type)” en vez de la antigua forma “raise ValueError, ‘message’”

  • Los nombres de funciones deberían ser minúsculas, con palabras separadas por guiones si fuese necesario para mejorar la legibilidad.
  • Constantes: Son declaradas a nivel de modulo y escritas en mayúsculas con guiones separando palabras. Ejemplos include MAX_OVERFLOW y TOTAL.
  • Diseño para herencia: Decide si los atributos de clase deben ser públicos o no. Si no estás seguro márcalos como no públicos con guiones al principio. En Open ERP a los métodos de contexto los puedes llamar por self.pool.get(‘xyz’).method no deberían tener guiones al principio. Eg. method en un campo función puede ser una función no pública _get_prod_price y llamar a una función pública get_price
  • El código debería ser escrito de una forma que no ponga en desventaja otras implementaciones de python. Eg. Evita usar mx datetime (ha estado retrasando el proyecto  oo_jython project por bastante tiempo. ) Teneis una lista de lo qeu debemos usar y lo que no? –C. Simonis . Creo que la comunidad necesita proponer módulos que ellos saben que no funcionan con jython etc. — Sharoon
  • Comparaciones con tonos simples como None deberían hacerse siempre con ‘is’ o ‘is not’, nunca con operadores igual. Por lo que if x==None está mal, usa x is None

B) codificación xml

* escribe commentarios !!!

* Difice los módulos complejos en varios archivos xml

* usar  xmllint – solo una pregunta – IMHO 2 es mejor que 4 por legibilidad.

–formateo

Reformatear and reindentar la salida. La variable de entorno XMLLINT_INDENT controla la indentación. El valor por defecto son 2 espacios “  “).

* structure (1. try)

** tree

** form

** graph

** calendar

* menu

* action

Comunidad: Por favor, añadir/modificar/sugerir más convenciones
Referencia:

Python Style Guide essay: GVR: http://wiki.laptop.org/go/Python_Style_Guide

PEP8

Publicado módulo de Renumeración de asientos.

Diciembre 2nd, 2009

Hola:

importante este anuncio de Borja López de Pexego en los foros oficiales de OpenERP:

* Añadido al repositorio de la localización española (https://code.launchpad.net/~openerp-spain-team/openerp-spain/5.0) el módulo account_renumber para la renumeración de asientos contables.
* Características:

- Soporta tanto una secuencia única (lo típico en España) como secuencias individuales por diario.
- Se pueden renumerar diarios y periodos individualmente, y se puede especificar el número inicial (por tanto es fácil por ejemplo reenumerar sólo el último trimestre).
- Soporta uso de prefijos y sufijos basados en la fecha del movimiento contable (esto es, cosas como “%(month)s” en el prefijo o sufijo de la secuencia serán correctamente sustituidos por el mes del asiento contable)
- Renumerar 10.000 asientos en un Core2Duo 4400@2Ghz lleva algo menos de 4 minutos.

* Nota: es posible que pronto movamos tanto este módulo, como el motor de informes tipo balance, a extra_addons o addons (ambos son usables en otros países y están internacionalizados)
_________________
Borja López Soilán
Pexego – www.pexego.es

Carga de archivos AEB 43 en OpenERP

Diciembre 2nd, 2009

Hasta hoy no se me había ocurrido probar con mi propia instalación una carga de un archivo AEB 43 con los movimientos bancarios, para poder realizar tanto la conciliación manual como la automática. Y creo que es una funcionalidad sumamente útil por lo que paso a contaros qué pasos hay que dar para usarla. Habrá contables a los que esta funcionalidad les sea muy conocida y otros a quienes una gestoría les lleva la contabilidad, ni siquiera sabrán de lo que les estoy hablando. Por lo que lo explico en detalle.

Hoy día casi todos los bancos por no decir todos, tienen la posibilidad de que el usuario desde su página de banca online se pueda descargar un fichero en formato AEB 43 que contiene todos los movimientos bancarios realizados en una cuenta bancaria desde una fecha. OpenERP tiene la posibilidad de cargar automáticamente dicho fichero, y utilizar estos movimientos para dar por pagadas, es decir, conciliadas las facturas que generaron la mayoría de esos movimientos. Bien sean facturas a cobrar o a pagar, si el cobro o el pago se hizo por banco, los movimientos correspondientes estarán en dicho archivo. Ahora bien, además de estos, puede haber muchos más movimientos, como son los pagos de nóminas, los pagos a hacienda, las comisiones del propio banco… etc.

Para cargar un archivo AEB 43 seguid los siguientes pasos:

  1. En Gestión financiera / Configuración / Plantillas –> Ejecutad el asistente “asistente de importación de conceptos extractos” . Esto os genera las cuentas por defecto asociadas a los códigos C43: Los podeis ver en Gestión Financiera / Configuración / Extractos bancarios C43 / Cuentas por defecto asociadas a los códigos C43. Si a algún contable le gustasen más otras cuentas, puede modificarlas en ese punto.
  2. Una vez cargados los códigos, podemos cargar el archivo del banco. Para ello ir a Gestión financiera / codificación de asientos / asientos por extractos bancarios / nuevo extracto bancario. Vereis que en la parte derecha arriba teneis la opción importar extractos bancarios.
  3. Vereis que cuando realiza la carga, automáticamente detecta las cuentas bancarias de clientes y proveedores. Solo teneis que revisar que las cuentas son correctas. En los casos de otro tipo de cobros o pagos, como hemos mencionado antes (nóminas, hacienda, comisiones.. etc) coge las cuentas establecidas en el punto 1.

Si vuestro banco no os da la opción de exportar extractos en formato AEB 43, tendréis que cargar los extractos a mano en esta misma pantalla.

El siguiente paso sería conciliar el asiento factura con el de cobro o pago pero esto ya es otra historia. Por cierto, teneis un videotutorial de todo este proceso en el curso de contabilidad de aulaerp

Esperando os haya sido de utilida… cordiales saludos:

Ana