Zikzakmedia

En la entrada del 2012, deberemos personalizar nuestro OpenERP estos dos configuraciones extras:

Creación del nuevo ejercicio fiscal y nuevos períodos

Para poder emitir facturas, debemos crear los nuevos períodos para el 2012. Para su generación accederemos al menú Contabilidad/Configuración/Contabilidad financiera/Ejercicio fiscal. Deberemos crear los períodos (mensuales o trimestrales) y los períodos de apertura, cierre y Perdidas y ganancias.

Cambio del número de secuencias.

Para la numeración de sus pedidos, facturas de cliente o de proveedor, si utiliza una secuencia personalizada con referencia al año, esta, la deberá actualizar. Este paso es muy importante hacerlo cuando decida ya no facturar 2010 (ni forzando la fecha de factura y período) ya que a partir de su configuración hará uso de esta secuencia.

Para personalizar las secuencias iremos a Administración/Configuración/Secuencias/. Si el prefijo lo tenéis configurado con la expresión %(year)s/ automáticamente ya aparece el año en cuestión. En el caso que lo tenga configurado como 2011/ deberá cambiar por 2012/ o utilizando la expresión %(year)s/. Véase en la leyenda con las opciones que se disponen.
En el caso de utilizar expresiones, no genere facturas 2010 forzando fecha o período.

Las códigos de factura en OpenERP se llaman:

• Account Invoice Out
• Account Invoice In
• Account Refund Out
• Account Refund In

Recuerde que si no está seguro de hacer esta configuración, lo puede probar en la base de datos de copia para ser testeado.

¿Dónde conseguir más documentación?

• aulaerp.com
• - Conceptos básicos de OpenERP
• - Gestión de una pyme con OpenERP. Ventas, compras, almacenes y logística
• - Contabilidad con OpenERP
• En el canal Twitter

Se ha migrado el modulo de variantes de producto de la versión 5 a la versión 6 de OpenERP. Esta nueva versión las dimensiones y tipos, por ejemplo, tallas, colores, etc, ya no son fijas por cada plantilla de producto y se convierten en valores globales. De esta forma, las plantillas de productos que usen la misma tipología de atributos (dimensiones) podemos crearlas globalmente para que otras plantillas de producto hagan uso de ellas sin volver a definir.

Para la actualización se ha realizado mediante comandos SQL directamente a la base de datos. En nuestra área de documentación técnica encontrará más información al respeto.

Conocer la estructura de la base de datos de OpenERP o Tryton es necesario cuando entras en el mundo de terceras aplicaciones como tiendas virtuales o business inteligent. También os puede ser de ayuda en la importación de datos en massa como documentamos en el artículo Importar/Exportar datos maestros en OpenERP.

Tanto OpenERP como Tryton los modelos son clases. Dentro de estas clases definimos los campos del modelo (columns en el caso de OpenERP y atributos de la clase en el caso de Tryton). La comparación entre esta terminología y de la base de datos es:

• Modelo/Objecto: Tabla base de datos
• Atributos/Columns (dicc): Campos de la base de datos

Todo programador que trabaja con python sabe que cualquier clase la podemos heredar y ampliar/modificar su comportamiento. Por tanto, dependiendo de nuestros módulos instalados, cada modelo/objeto (tabla de la base de datos) variará los campos que disponemos. No existe un OpenERP o Tryton igual. Según los módulos, tendremos menos o más campos.

Para saber que campos disponemos, lo podemos consultar gráficamente a nuestro OpenERP o Tryton. Tan fácil como ir a Administración -> Personalización -> Estructura de la base de datos -> Objetos o Campos. Para saber que modelo debemos consultar, ya es conocer un poco la nomenclatura en inglés. Por ejemplo, si busco un pedido de venta, sabré que el modelo es sale.order. Y si busco una linea del pedido de venta, el modelo es sale.order.line. En el caso de la factura, similar. El nombre de la factura es account.invoice y las lineas de las facturas account.invoice.line. Para saber si esta factura es de venta o de compra, o abono, lo dispondremos esta información en el campo tipo de account.invoice:

• out_invoice: Factura de cliente
• in_invoice: Factura de proveedor
• out_refund: Factura de cliente abono
• in_refund: Factura de proveedor abono

Para conocer más a fondo la relación de los modelos/objetos es mirar el código fuente de cada módulo que campos contiene o revisar la documentación de diagramas de los objetos.

Modelos básicos

A continuación se listan los modelos básicos de OpenERP o Tryton:

• res.partner / party.party: Las empresas. La diferencia si es cliente o proveedor es el campo supplier o customer (boleano)
• res.company / company.company: La compañía. Nosotros. Todos los modelos que trabajen en multicompañía, contendrán el campo company_id que relaciona la compañía
• product.product y product.template: Los productos. El modelo product.product hereda de product.template. A nivel de la base de datos en modelo product.product tiene el campo product_tmpl_id que relaciona con la plantilla. Esta diseñado de esta forma para las variantes de productos. Los campos generales, los encontraremos en la plantilla. En los campos concretos de la variante del producto, los encontraremos en product.product. Por ejemplo, una Camiseta Tux, el precio es común en todas las variantes. El color, es por producto. Para trabajar con variantes debemos activar el módulo product_variant_multi que cambia completamente la manera de gestionar los productos.
• sale.order: Pedidos de venta
• purchase.order: Pedidos de compra
• stock.warehouse: Almacenes. Relacionado con una compañía y una dirección
• stock.picking: Albarán. Hay de tres tipos (campo type): entrada, interno y de salida
• stock.move: Movimiento de albarán
• account.invoice: Facturas (el campo tipo diferencia cliente o proveedor y abono). Una factura está relacionado con una cuenta (account.account), dispone varias lineas de impuestos (account.invoice.tax), un diario (account.journal) y movimientos (account.move)

Magento Connect es un conector entre el canal de venta de Magento y OpenERP. Las operaciones básicas de este modulo es la integración del catálogo y los pedidos de Magento a OpenERP. De esta forma el usuario tiene a su disposición toda la gestión en un ERP en una sola aplicación (toda la gestión la realiza en OpenERP): los clientes, pedidos, contabilidad, relaciones con el cliente, proyectos, … un sin fin de adaptaciones en una sola aplicación, y el canal de venta de Magento, el escaparate on-line de su comercio.  Y a día de hoy, una realizad con los productos configurables y variantes para esas compañías que trabajen con multitud de variantes de productos.

El modulo magento_connect_product_variant permite la integración de Plantillas de productos y variantes de OpenERP con el sistema de productos configurables de Magento y ser gestionado únicamente en una sola herramienta: OpenERP.

La idea es sencilla: Disponer un cliente para Android conectado a OpenERP para la consulta/gestión de la asistencia de comedores escolares. El proyecto ha sido llevado a cabo para un Consell Comarcal de Catalunya y permite la gestión de comedores escolares de centros públicos. Mediante tabletas táctiles con Android, los monitores pasan lista de los alumnos que se quedan a comer, pudiendo consultar si también tenían previsto venir, además de sus datos personales por si hay que llamar a su tutor.
Aunque parezca todavía increíble, a no todos los pueblos les llega internet con suficiente calidad. Para evitar cortes en el acceso al servidor OpenERP, los dispositivos Android pueden trabajar fuera de linea, pudiendo mas tarde sincronizar los datos de escuelas, grupos, alumnos y asistencias al servidor OpenERP.
Además del cliente Android conectado a OpenERP, el proyecto ha requerido diseñar la gestión de un comedor escolar con OpenERP: centros eductivos, ediciones, sesiones, alumnos, inscripciones y asistencias, incluyendo la facturación con gestión de becas y partición de la facturación entre varios agentes.
Toda la gestión se basa en OpenERP y varios módulos training, su código fuente disponible a Launchpad y un cliente hecho a medida para Android 2.3 (compatible con versiones superiores).