Blog

OpenERP. Sobre visión y modelo de negocio

santiago — Sun, 15 Apr 2012 21:40:00 +0200

Desde luego estos tres días en Bélgica han sido sumamente intensos, por múltiples asuntos, pero me voy a centrar en cuestiones un poco generales y siempre abiertas a debate que incluye el modelos de negocio de OpenERP sa y cómo eso afecta a nuestra localización y servicios.

Los que habéis estado conmigo en Beǵica sabréis que no estuve especialmente participativo en las reuniones aunque sí en las conversaciones previas. Cuando no estoy completamente seguro sobre algo, perfiero escuchar y reflexionar sobre lo que se cuenta antes que entrar en un debate estéril, Las caminos se recorren paso a paso y al comenzar prefiero tener un mapa.

Ana ha publicado ya un estupendo post (como siempre) referente a las jornadas y especialmente a la migración de versiones. Tal vez un poco precipitado de más, ya que nos falta algo de confirmación sobre todo esto, pero los que ya conocemos a Ana sabemos que le puede el corazón. Os recomiendo su lectura http://www.openerpsite.com/migraciones-de-version-en-openerp/2693.html, especialmente a los que no conozcáis demasiado bien la situación.

Coincido con Albert de NaN y con Raimon de Zikzakmedia en prácticamente todo el diagnostico que exponen en sus comentarios al post de Ana. Creo que saben que siento por ellos algo más que respeto y admiración, que la localización española no existiría sin ellos, su conocimiento y su esfuerzo, pero quiero plantear las lineas siguientes sobre lo que puede ser un modelo de negocio acertado o no, pero que es el planteado hasta ahora por OpenERP sa.

Sobre el modelo de negocio de OpenERP sa

No me voy a centrar en si nos gusta al 100% la propuesta para llevar a cabo las migraciones o el soporte , si no, si compartimos o no el modelo de negocio que plantea OpenERP sa. Así que hablaré un poco sobre ello

Me gustaría en primer lugar defender la política desarrollada por ellos:

* Liberación de todo el código desarrollado.

De todas las aplicaciones open source orientadas a gestión de negocios existentes a día de hoy en el mercado y con una implantación más o menos grande¿hay alguna que haga esto? Esto es un valor inmenso que permite que puedas realizar lo que te dé la gana con el software sin ningun tipo de exigencia y que se pueda desarrolar una herramienta de migrar versiones en paralelo a la oficial. Entiendo que esto no les dé derecho a todo, pero sí a mucho.

* Un gran trabajo de promoción de la herramienta

Puede ser discutible, pero de una forma u otra, es posiblemente el ERP de código abierto más usado del mundo, y esto no es fácil de conseguir. Si sabéis cómo me pongo a ello y hago uno nuevo.

* Son una empresa. Necesitan ingresos.

Lógicamente, deben priorizar esto. Podríamos hablar sobre si sería mejor que fuese una fundación o algo similar, pero no lo son. Ellos han desarrollado el software, han tenido la idea y, en mi opinión, es mejor tener una empresa fuerte detrás tanto desde el punto de vista del mercado - cliente final, como de la evolución de la herramienta (discutible, pero es mi impresión y es mi post).

* Ingresos obtenidos solo de migraciones, soporte y formación.

Un modelo tradicional, basado en servicios, pero que necesita a su red de partners. Sin partners sería imposible de mantener. ¿Somos conscientes de eso?

Voy a a hacer también ciertas críticas para que no me saltéis demasiado al cuello y digáis que me han lavado el cerebro en Bélgica (como ya dije, es solo una reflexión y no trata de ser dogmática ni mucho menos)

* Han cometido errores

Probablemente muchos, tal vez demasiados, no es cuestión de enumerarlos, También creo que en algunos casos han simplemente corregido el rumbo y que, en ocasiones, ha habido también fallos nuestros como comunidad o como partners. Os invito a la reflexión en este punto, especialmente viendo a OpenERP sa como una empresa y no como a una ONG que publica software. Además, ¿podemos pensar que es fácil gestionar una empresa con este crecimiento?

* La comunicación con los partner y la comunidad no es la más correcta.

Tienen mucho camino por recorrer aquí. Tengo la percepción de que ellos lo ven como que la comunidad haga lo que quiera y como quiera y los partners que apoyen y, por favor no olvidemos que un partner es básicamente un reseller, un socio comercial que debe apoyar a su casa matriz, con acuerdos y desacuerdo y todo tipo de desavenencias, pero en útimo caso apoyando,

* El control de Fabien Pinckaers sobre la compañía

Esto sí que no está sujeto a discusión. Se hace lo que el dice para bien o para mal, lo cual creo que a veces lleva a la improvisación, pero es así.

Sobre el modelo de negocio de los que prestamos servicios con OenERP

Y al fin creo que llego a dónde quería llegar (posiblemente dando alguna vueltas) y a la reflexión que me gustaría plantear.

Pexego lleva años trabajando con la herramienta y solo un año y algo como partner. Hemos tratado de contribuir en lo posible desde los inicios, sin embargo como partners hemos contribuido más bien poco en la venta de sevcios de OpenERP sa, Así que la reflexión viene en lo siguiente:

Decidir un apuesta de verdad por los servicios prestados por OpenERP sa, saber si somos capaces de trasnmitir a nuestros clientes las necesidad de contrratar un OpenERP Enterprise (OE) o incluirlo conjuntamente en nuestra oferta de soporte.

* Es cierto que gran parte del soporte no está cubierto por el OE ya que el análisis, la cualificación del bug y su posterior aplicación son responsabilidad del partner, pero no es menos cierto que no hablamos solo de módulos, que también hablamos de servidor y clientes, De cualquier manera es como una garantía adicional para gran parte del software (no olvidemos que casi todos nuestros desarrollos heredan de aquí) y que debería evitar que mantuviésemos ramas duplicadas en launchpad como estamos haciendo ahora (he dicho debería, que conste).

No me he puesto todavía a hacer cálculos sobre el soporte con OE pero creo que no es malo considerarlo.

* En cuanto a las migraciones. Es evidente que el modelo anterior no era del todo apropiado ( o a lo mejor sí y no lo habíamos entendido del todo bien).

Uno de los graves problemas era asumir el coste de migración de la localización española en un proyecto ( o más bien en todos). Pero no será así ahora y tendremos posibiliades de hacerlo. Creo que aquí es mejor no adelantar acontecimientos y esperar a una confirmación escrita y volver sobre ello más adelante.

En cuanto a la migración de otros módulos también habrá que ver cómo plantearlos.

Así que en este punto es dónde está realmente lo interesante. ¿Debemos centrar nuestro esfuerzos en tener un alternativa de migración (Kafkadb o similar), o en unirnos a la estrategia de OpenERP sa , incluir OE en nuestra oferta de soporte y centrarnos en la migración de nuestro propios módulos ( desarrollados para un cliente o de otros miembros de la comunidad). El asunto es que si no he entendido mal podríamos publicar los scripts para migrar estos módulos a medida por lo que el esfuerzo solo se realizaría una vez en cada módulo. Es decir, sería escalable.

Esto no quita el trabajo a realizar en cada migración por parte del partner, desde luego, pero creo que también conviene pensar en la sostenibiliad del ecosistema y en que, mientras trabajemos con OpenERP, debemos buscar la mejor forma de cooperar y crecer conjuntamente, desde luego que tendremos diversos puntos de vista e incluso fuertes divergencias, pero quiza la revolución desde dentro sea una forma más inteligente de evolucionar que la división desfuerzos, la guerra de guerrillas o, como Pexego realmente a hecho hasta ahora en lo referente a esto, mantener una politica de no agresión mutua.

Es un apuesta más a larga plazo que de corto recorrido, apostar por tender a una centralización de procesos que ayuden a una mejora de todo el sistema.

Es algo abierto, un reflexión, un esfuerzo por tratar de ponerno sen l apiel de OpenERP sa, nada más

Final

Me he alargado mucho más de lo que había pensado. También me he dado cuenta de que me ha quedado como un poco promocional de OpenERP sa, no era mi intención, pero sí quería posicionarme un poco de su lado, por una vez.

Al igual que Ana quiero aprovechar para agredecer a varias - muchas personas por distintas cosas de estos días en Bélgica.

A Ana (AvanzosC) Está claro que nada sería igual sin ella. Le pueden el corazón y la boca :) , pero su lucha desde luego es incansable

A Nhomar (Vauxoo). Han sido totalmente inspiradoras tanto su charla como las conversaciones posteriores, en este post hay mucho suyo.

A Omar ( mi compañero en Pexego). Gran compañero de viaje, con aventura incluída y con enormes conversaciones de todo tipo (él también está en este post y podria estar en cien más)

A Nacho (Alfa90). Desearé siempre tener clientes así, dispuestos a colaborar y con ganas de hacer cosas y aportar en todos los sentidos.

A todas las personas que han compartido sus puntos de vista y su forma de ver las cosas conmigo y aquí, especialmente a Albert, Jordi y Raimon aunque no estuviesen en Bélgica porque siempre están presentes.

Y muchas, muchas, muchas gracias a Rubén y Christophe de OpenERP. Ellos saben por qué, esas carreras por Bruselas quedarán para el recuerdo.

Han sido tres grandes días en Buselas que espero resulten fructíferos y poder repetirlos. A ver si no vemos en Donosti.

Setting views for an action window

alberto — Mon, 18 Apr 2011 16:10:00 +0200

Working with OpenERP, is very often designing a wizard (either a wizard.interface or a osv.osv_memory) that returns a new window, perhaps being the most common case of creating a series of objects and listing them in a new tab. In most cases, these window actions that are responsible for managing this work smoothly and their corresponding views are loaded correctly; however, when working on an implementation with a large number of modules installed, it is normal to inherit views, which in turn are inherited by another module, and these in turn by others, etc; also, if views' priorities are reassigned, things can get pretty tedious ...

To solve this problem (or rather as a good programming practice), we can do the following, both from a Python file and from an XML file:

Launching specific views from a Python file:

Let's imagine that the action of our wizard creates a series of objects and we want to show the freshly created ids. To do this and after having developed the logic of our function, we can return a dictionary containing an action window as follows:

view_list_id = self.pool.get('ir.ui.view').search(cr, 1, [('name', '=', '<tree view name to use>')])[0]
form_view_id = self.pool.get('ir.ui.view').search(cr, 1, [('name', '=', '<form view name to use>')])[0]
#Now, we define our window action...
return {
'name': _('Created ids from this wizard'),
'type': 'ir.actions.act_window',
'res_model': 'model.name',
'view_type': 'form',
'view_mode': 'tree,form',
'domain': "[('id', 'in', %s)]" % [<created_ids>],
'view_id': False,
'views': [(view_list_id, 'tree'),(form_view_id, 'form'), (False,'calendar'), (False, 'graph')]
}

Here the key is the attribute 'views' of the window action, which allows us to specify the ids of the views that we cast for each of the types available.

Launching specific views from a XML file:

In this case we use the model 'ir.actions.act_window_view' to specify what views we want to launch of the total available (actually list, form, calendar or chart):

<record id="action_view_my_custom_model" model="ir.actions.act_window">
<field name="name">All Created Objects</field>
<field name="type">ir.actions.act_window</field>
<field name="res_model">my.model.name</field>
<field name="view_type">form</field>
</record>
<record id="view_action_view_my_custom_model_tree" model="ir.actions.act_window.view">
<field eval="1" name="sequence"/>
<field name="view_mode">tree</field>
<field name="view_id" ref="id_tree_view_to_use"/>
<field name="act_window_id" ref="action_view_my_custom_model"/>
</record>
<record id="action_project_invoices_form_view" model="ir.actions.act_window.view">
<field eval="2" name="sequence"/>
<field name="view_mode">form</field>
<field name="view_id" ref="id_form_view_to_use"/>
<field name="act_window_id" ref="action_view_my_custom_model"/>
</record>

Tableros y Notas de Tablero

alberto — Tue, 29 Mar 2011 10:45:56 +0200

    Uno de los objetos menos conocidos que está ganando protagonismo con la versión 6 de OpenERP son las notas de tablero (o board notes). Estas notas vienen a sustituir o complementar a las solicitudes presentes desde la versión 5, pero resultan un recurso mucho más visual y directo. Esto quizás se deba al gran empujón que se le está dando al cliente web y que éste ya cargue dinámicamente los tableros correspondientes a cada área (ventas, compras, etc) nada más entrar en ellas. Sin embargo, en muchos entornos se sigue utilizando el cliente de escritorio GTK por su rapidez y por herencia de versiones anteriores, en las que el cliente web no siempre era la mejor opción.
    Resulta muy útil que a un usuario se le muestre un tablón personalizado cuando se loguee en el sistema, para que pueda ver de un plumazo su agenda, horas de trabajo o tareas que actualmente tiene abiertas. Es una manera gráfica de controlar los puntos más frecuentes de su día a día.
    Por ello, vamos a ver cómo definir, configurar y asociar a un usuario un tablero personalizado, incluyendo las mencionadas notas.

DEFINIENDO Y CONFIGURANDO UN TABLERO

Lo primero que debemos hacer es instalar el módulo 'board' que es lo que nos permitirá realizar los siguientes pasos. A continuación, como usuario Administrador (u otro usuario perteneciente al grupo Administration/Configuration) nos dirigimos al menú Administración->Personalización->Informes->Definición tablero para crear un nuevo tablero que llamaremos 'Tablero Facturación'.

Ya dentro de la vista formulario, vamos a confeccionar un tablero dividido en 4 partes, en el que tendremos en la parte izquierda del mismo las notas públicas y los extractos bancarios, y en la parte derecha nuestras facturas de cliente y proveedor. Para ello, dentro del campo Vista tablero definiremos los cuatro elementos de la siguiente forma:

Hecho esto, tenemos la opción de crear un menú (mediante el botón 'Crear menú') que cuelgue por ejemplo del sub-menú 'Informe->Tablero' dentro de 'Contabilidad'. Para ello, le indicamos lo siguiente:

y comprobamos el resultado:

Ahora, podemos asociar dicho tablero a un usuario para que sea su acción inicial, nada más arrancar OpenERP. Para esto, desde el menú 'Administración->Usuarios' elegimos a uno o varios usuarios que pertenezcan a nuestro departamento de contabilidad y rellenamos el campo Acción Inicial con el tablero que acabamos de crear:

Así, cuando dicho usuario inicie sesión, le aparecerá lo siguiente:

Sobra decir que se puede trabajar directamente con todos los elementos que aparecen en el tablero, así como cambiar los elementos que lo componen por los que se desee.

CREANDO Y VISUALIZANDO NOTAS

Vamos ahora a profundizar un poco en los objetos 'notas de tablero' (o board notes). Lo primero que tendremos que hacer será dirigirnos al submenú 'Administración->Personalización->Informes->Publicar una nota' para crear una nota de tablero nueva.

Lo único a destacar en la creación de este objeto es el campo 'Tipo de nota', que es el que permite filtrar la visibilidad de las mismas en función del grupo al que pertenezca el usuario.

Ya por último, los usuarios que tengan accesible el tablero que creamos en el punto anterior, verán la susodicha nota:

Configuración de decimales y separador de miles en OpenERP 6

alberto — Thu, 24 Mar 2011 13:13:39 +0100

Uno de los problemas de formato más molestos de OpenERP es su tratamiento de decimales y miles en las cantidades numéricas, ya que, por defecto, separa los decimales con una coma, pero no separa los miles con un punto (como es habitual en nuestro país).

En la anterior versión 5 existía ciertos problemas para configurar correctamente esto (aquí y aquí se puede leer varios topics relacionados con el tema), sin embargo en la actual versión estable (6.0 a la hora de escribir estas lineas) se puede configurar de forma sencilla sin que se presente ningún problema.

Lo primero que tenemos que hacer es (como usuario con suficientes permisos) dirigirnos al menú 'Administración->Traducciones->Idiomas' y escoger el idioma que queremos modificar (en nuestro caso, el Español). Una vez en la vista formulario, debemos modificar los siguientes campos con estos valores:

Formato separador: [3] (en vez de [])
Separador de miles: . (en vez de un valor vacío)

Ya que estamos en esta vista, podemos asegurarnos de que no se nos presenta uno de los bugs más molestos que se dieron en las primeras revisiones de la versión 6.0, que consistía en que las horas estaban con un formato '%t' en vez de con un formato -por ejemplo- '%H:%M:%S', que provocaba que los campos datetime

fallasen al no poder cargar correctamente sus valores por defecto.

Aplicados los cambios, deberíamos tener una configuración similar a esta:

A continuación, cerraremos sesión y reiniciaremos el servidor de OpenERP (no hace falta hacer un --update=all) para que se apliquen los cambios. ¡OJO!

Si ni aún así conseguimos el efecto buscado, matad todas las conexiones abiertas de PostgreSQL que haya contra la Base de Datos que estamos modificando antes de reiniciar el servidor.

Si ya lo tenemos configurado todo correctamente, nuestras facturas, pedidos de venta, etc deberían mostrarse de la siguiente forma:

Venta y devolución de mercancías con OpenERP 6

alberto — Mon, 31 Jan 2011 11:58:27 +0100

Nota: Este tutorial se ha elaborado utilizando la versión 6.0.1 estable de OpenERP, concretamente con las siguientes revisiones:

-Addons: 4347 (20-01-2011 20:22:28)

-Servidor: 3317 (21-01-2011 05:58:28)

-Cliente GTK: 1793 (22-01-2011 06:03:35)

Los procesos aquí explicados pueden aplicarse también a la versión 5.0.x (aunque no se garantiza la funcionalidad de los mismos).

Hace poco nos surgió a través de un cliente una consulta acerca de cómo sería un proceso correcto de devolución de mercancías utilizando los módulos “mrp” y “point_of_sale” / ”sale” (claro ejemplo de uso de OpenERP como herramienta de gestión de ventas de productos almacenables en un entorno de mostrador). Revisando las distintas partes del flujo, lo cierto es que hay algunos puntos que pueden llevar a confusión o dejar al usuario en un punto en el que no sepa avanzar. Mediante este tutorial intentaremos reflejar un proceso de venta y devolución completo, en el que se refleje tanto el movimiento de mercancías a nivel de almacén como la contabilización de los distintos asientos contables generados.

Esta entrada está dividida en dos partes:

PARTE 1: VENTA Y DEVOLUCIÓN DE MERCANCÍAS CON EL MÓDULO TERMINAL PUNTO DE VENTA
PARTE 2: VENTA Y DEVOLUCIÓN DE MERCANCÍAS CON EL MÓDULO BASE DE VENTAS

Módulos necesarios

Tras haber instalado la versión 6.0.1 estable de OpenERP con las revisiones anteriormente mencionadas (o alguna posterior) y arrancado el cliente GTK, procederemos a instalar en una BD limpia (u otra con datos) los siguientes módulos:

-”point_of_sale”: Módulo para gestionar las ventas de forma más rápida y sencilla, emulando los procesos de un Terminal Punto de Venta. El módulo ha sido desarrollado por ZikZakMedia, cuenta con una extensión llamada “point_of_sale_extension” y se encuentra disponible en los addons.

-”mrp”: Módulo base de gestión de almacén. Nos permitirá configurar las políticas de envío de productos, sus distintas ubicaciones, etc. Se complementa con el módulo “stock” con el que conseguimos, entre otras cosas, trazabilidad de productos, soporte a códigos de barras o implementar métodos de gestión de inventario (FIFO, LIFO, etc). Ambos módulos se encuentran también en los addons.

-”sale”: Módulo base de gestión de ventas: clientes, facturación, albaranes, etc. También se encuentra en los addons.

-”account”: Módulo base de gestión contable. Lo utilizaremos para manejar diarios, comprobar asientos, trabajar con facturas, etc. Disponible también en los addons.

Habiendo instalado estos módulos, deberíamos tener (por lo menos) las siguientes entradas de menú:

Configuración de clientes

Trabajando de forma habitual tendremos confeccionada ya en el ERP una lista de clientes/proveedores con sus datos de contacto. Sin embargo, es importante destacar la pestaña “Contabilidad” dentro de la ficha de cada uno, ya que, por defecto, OpenERP le asigna a cada nuevo Partner una cuenta 43000000 genérica de cobro y una 41000000 genérica de pago, lo que puede llevar a quebraderos de cabeza revisando después la contabilidad:

Configuración de diarios (opcional)

A la hora de contabilizar las ventas que realicemos por caja, es necesario configurar un diario bancario de tipo “Banco/Caja”. Para ello, la instalación básica de OpenERP trae varios por defecto (con nombres Cash, Cash Journal -(test) o Visa Journal). Podemos elegir uno de estos y modificarlo a nuestro gusto o crear uno nuevo desde Contabilidad-->Configuración-->Contabilidad Financiera-->Diarios. A mayores, podemos observar que en la pestaña “Terminal Punto de Venta” podremos especificar opciones como “Apertura automática de caja” o la lista de usuarios que tienen permisos para imputar ventas contra ese diario. En el caso que estamos desarrollando:

Configuración de productos (opcional)

Una de las limitaciones que tendremos a la hora de elaborar un pedido de venta con el módulo point_of_sale es que no podremos introducir un texto libre como concepto de línea de venta (al contrario que en los propios pedidos de venta del módulo sale). Por tanto, es recomendable configurar los productos (si es que no lo hemos hecho ya o hemos instalado una BD sin datos demo). Para este ejemplo, vamos a utilizar los que vienen por defecto con la instalación básica de OpenERP. Si no, podríamos definir los que nos interesasen desde el menú Terminal Punto de Venta-->Productos.

Configuración de hojas de caja

Para realizar el flujo de ventas desde el módulo “Terminal Punto de Venta” deberemos contar con un registro de caja abierto sobre el que se van a contabilizar los distintos movimientos de efectivo. Así, desde Terminal Punto de Venta-->Registro de caja podremos definir un nuevo registro de caja en el que figurará el saldo inicial repartido en las distintas cantidades y las transacciones que ha realizado dicha caja. Una vez introducidos los saldos, pulsaremos el botón “Abrir caja” para que nos actualice el saldo de apertura y el calculado. Un ejemplo de Hoja de Caja en estado abierto podría ser:

Configuración de tiendas

Para llevar a cabo estadísticas y análisis de ventas es importante que tengamos correctamente configuradas las tiendas desde las que vamos a vender. Para ello, nos dirigiremos a Ventas-->Configuración-->Ventas-->Tienda para editar o crear una tienda nueva. En este caso, hemos creado una tienda llamada “Tienda Principal” con las siguientes características:

PARTE 1: VENTA Y DEVOLUCIÓN DE MERCANCÍAS CON EL MÓDULO TERMINAL PUNTO DE VENTA

PASO 1: IMPUTAR UNA VENTA EN OPENERP CON EL MÓDULO TERMINAL PUNTO DE VENTA

Realizados los pasos previos de configuración, nos dirigimos ahora al menú Terminal Punto de Venta-->Operaciones Diarias-->Pedido de Venta

En la parte superior de este formulario rellenaremos el cliente (si es que ya lo tenemos registrado), un número de contrato (si es que aplica) y la tienda desde la que estamos vendiendo (nuestra “Tienda Principal” definida en el paso anterior). De momento, indicaremos en el campo “Ref. Venta” un texto libre (por ejemplo, una fecha y hora, el nombre del cliente, etc...).

Hecho esto, confeccionaremos nuestras líneas de pedido de venta introduciendo los distintos productos con sus cantidades, precios y descuentos (OpenERP establecerá los valores correspondientes de estas cantidades siempre basándose en la tarifa que hemos elegido aplicar para nuestro cliente):

Una vez revisada nuestra orden de venta (prestando también especial atención a la pestaña “Información extra” en la que indicaremos parámetros como “Cajero”, “Vendedor” o “Método de precio”), pulsaremos el botón “Realizar pago” para hacerla efectiva. En este caso, además, le hemos indicado que nos genere una factura de cliente:

Hecho esto, nos debería haber generado (al cabo de unos segundos) la factura en forma de documento PDF (que podremos reimprimir en cualquier momento con el botón “Reimprimir” que acaba de habilitarse en la vista principal de la venta):

y una entrada en la pestaña “Pago” de la orden de venta con el importe total:

Asimismo, en el registro de caja asociado (Terminal Punto de Venta -->Registros de caja) podremos observar cómo se ha imputado la transacción anterior (de 355,50 €):

Por último, si nos dirigimos al listado de Facturas de Cliente (Contabilidad-->Clientes-->Facturas de cliente) podremos ver qué nuestra factura está confirmada y contabilizada:

Y que se han realizado correctamente los movimientos de stock de los productos (desde Almacén-->Trazabilidad-->Movimientos de stock):

De esta forma, ya tendríamos finalizada nuestra venta.

PASO 2: DEVOLUCIÓN DE MERCANCÍAS

Supongamos que al día siguiente de imputar la venta del Paso 1, vuelve nuestro cliente para devolver la carcasa de la torre que había adquirido (código de producto: [TOW1] Torre de tamaño medio ATX) porque tiene una tara en un lateral. Para reflejar el movimiento de stock correspondiente y contabilizar la factura rectificativa, deberemos lanzar el asistente "Devolver albarán" (dentro de la orden de venta). En este asistente, elegiremos las cantidades de productos que queremos devolver a stock y si queremos reemplazar el producto que estamos devolviendo por otro:

En nuestro caso (devolviendo sólo la torre) y eligiendo la opción "Refund without exchange", obtendríamos un pedido de venta rectificativo ("Refunded order") del siguiente estilo (tras haber agregado el campo 'cliente'):

Nuestra venta habrá quedado de la siguiente forma:

La hoja de caja habrá registrado correctamente la transacción:

Y finalmente, el movimiento de stock también se habrá producido:

Nota: En caso de que hubiésemos escogido la opción "Return with Exchange" en el asistente de devolución, nos aparecería la siguiente pantalla preguntándonos qué producto queremos utilizar como sustituto:

Para a continuación crear un nuevo pedido de venta de la forma habitual (en este caso, he realizado el cambio por un módulo de memoria RAM de 22,50 € -simplemente por ilustrar el proceso-).

Quedándonos finalmente la venta original modificada de la siguiente forma:

PARTE 2: VENTA Y DEVOLUCIÓN DE MERCANCÍAS CON EL MÓDULO BASE DE VENTAS

PRERREQUISITOS

Antes de abordar este proceso es importante haber configurado el plan contable de la compañía del usuario activo (desde Contabilidad-->Configuración-->Contabilidad Financiera-->Configuración financiera para una nueva compañía), ya que si no, tendremos problemas a la hora de validar las facturas que generemos. Asimismo, es importante tener definidas ubicaciones, almacenes y tiendas para reflejar correctamente los movimientos de stock en el proceso de venta.

PASO 1: REALIZACIÓN DE UNA VENTA CON EL MÓDULO BASE DE VENTAS

Para esta parte, vamos a presuponer que existe un diario de ventas asociado a la compañía del usuario actual correctamente configurado y asociado a un diario analítico, como por ejemplo:

y que realizamos una venta de forma habitual (desde el menú Ventas-->Pedidos de Ventas):

En el momento en que confirmemos dicha venta (mediante el botón correspondiente), se nos habrán generado dos albaranes de salida (uno con el movimiento de stock desde “Stock” a “Salida” y otro con el movimiento desde “Salida” a “Clientes”) que podremos comprobar desde la pestaña “Historial” de la orden de venta:

Vamos ahora a crear la factura correspondiente a esta orden de ventas mediante el botón “Crear factura final”. Esto hará que se nos abra una nueva pestaña con los datos de la factura rellenados en gran medida:

Si ahora validamos la factura, ya tendríamos nuestra venta contabilizada en forma de un asiento contable similar a este:

Si ahora volvemos a los pedidos de venta, podremos comprobar que el pedido que hemos modificado aparece facturado al 100%. Lo que nos resta ahora es hacer efectivo el movimiento de mercancías. Para ello, nos dirigimos a la pestaña “Historial” y hacemos doble click encima de uno de los albaranes creados (uno con el movimiento virtual y otro con el movimiento real: de nuestra Ubicación a la ubicación “Clientes”).

Ahora le indicaremos bien comprobar disponibilidad o bien forzar disponibilidad (según nos interese) y finalmente pulsaremos encima de “Process” para hacer efectivo el albarán. Hecho esto, nuestra orden de venta tendrá el siguiente aspecto:

En este punto ya podríamos dar por finalizado el proceso de venta.

PASO 2: DEVOLUCIÓN DE MERCANCÍAS CON EL MÓDULO BASE DE VENTAS

Dada la situación descrita en el Paso 1 y el siguiente albarán de salida asociado:

supongamos que al día siguiente nos vuelve el cliente y quiere devolver la mercancía;entonces volveríamos a nuestro albarán de salida (podemos poner los "Albaranes de Salida" como atajo en el menú principal para acelerar el proceso) y lanzar el asistente "Devolver productos". En este asistente lo interesante es saber diferenciar qué hacen los dos estados de facturación disponibles:

a) 'Para ser abonado/facturado': Nos permitirá facturar desde el albarán

b) 'No facturación': Tendremos que crear una factura rectificativa de abono a mano

Por tanto, vamos a elegir el estado 'Para ser abonado/facturado', ya que nos aligerará el proceso.

Confirmando el asistente nos habrá creado nuestro 'Albarán de Entrada' correspondiente en estado "Disponible" (y con la coletilla “-return” en la referencia). En este momento, todavía no se ha hecho "efectivo" el movimiento stock, pero sí que se ha registrado un movimiento "virtual". Para hacer efectivo ese movimiento de stock (que vuelva ese producto a stock), tendremos que pulsar en "Procesar" y validar el movimiento de productos asociado. Tras la ejecución de este asistente, ya habremos finalizado el flujo relativo a la mercancía. Lo podemos comprobar porque ha cambiado el estado del albarán a "Realizado".

Lo que nos falta ahora es contabilizar ese movimiento de entrada de stock mediante una factura rectificativa de abono. Para ello, desde el propio albarán, lanzamos el asistente de "Crear factura" en el que elegiremos una fecha de facturación y un diario donde reflejar los apuntes procedentes de facturas rectificativas:

Obtendremos una factura rectificativa de abono de cliente como la siguiente, habiendo cambiado además el campo “Control de factura” del albarán por “Facturado”.

Ahora lo que nos restaría sería confirmar esta factura de forma habitual para que se refleje en el movimiento contable correspondiente (pestaña "Otra información" de la factura).

Mejorando los extractos bancarios de OpenERP

borjals — Mon, 21 Jun 2010 19:25:00 +0200

Contabilidad analítica en extractos bancarios

La primera mejora a presentar, es la posibilidad de imputar gastos/ingresos en la contabilidad analítica ¡directamente desde los extractos bancarios!

Gracias al módulo pxgo_bank_statement_analytic

podremos contabilizar analíticamente aquellos pequeños gastos para los que no registramos factura (como comisiones bancarias).

Una vez instalado el módulo (disponible en los extra-addons de OpenERP), nos aparecerá una nueva columna ("Cuenta Analítica") en los extractos bancarios que nos permitirá seleccionar la cuenta a la que queremos imputar la el gasto/ingreso:

Cuando se confirme el extracto bancario, los asientos creados automáticamente incluirán, asociada a la línea de ingreso/gasto, la imputación en la cuenta analítica:

Hojas de caja en OpenERP

La segunda funcionalidad a comentar, es la nueva herramienta de "hojas de caja", que no es más que una versión simplificada y optimizada de los extractos bancarios, que nos permitirá hacer gestiones de caja con mayor facilidad.

El módulo pxgo_cash_statement nos añade una nueva entrada en los menús de codificación de asientos, justo a continuación de la opción de extractos bancarios, que nos permitirá acceder a la nueva vista de hoja de caja:

El formulario de "Asientos por hojas de caja", es una especie de extracto bancario minimalista, que elimina todos los campos superfluos y a cambio añade "tipos de línea" predefinibles. Estos tipos de línea permiten esconder la complejidad de las operaciones a los usuarios, que no tendrán que preocuparse por "qué número de cuenta usar" sino que en su lugar verán una lista personalizada de conceptos:

Totalmente configurable

La funcionalidad de las hojas de caja es totalmente configurable. Por un lado podremos establecer qué diarios financieros queremos ver en las hojas de caja:

Por otro lado, podremos definir los conceptos a usar en las líneas de caja en la configuración de la contabilidad financiera:

Los conceptos nos permiten preestablecer la cuenta contable, la cuenta analítica (si está instalado el módulo pxgo_cash_statement_analytic), el tipo de movimiento (deposito/retirada) la empresa asociada e incluso la descripción, que se usarán en la línea de caja:

Aun más, dado que cada tipo de línea, define si es una retirada o depósito en caja, OpenERP es capaz de corregirnos si introducimos una cantidad incorrecta (una salida de caja siempre debería ser negativa, y una entrada en caja positiva).

Ejemplo: Cobro de una factura por caja

Veamos un ejemplo práctico: El cobro de una factura en efectivo.

Supongamos que tenemos una factura pendiente de cobro como la siguiente, y el cliente ha venido a pagárnosla en efectivo:

Entrada en caja

Cuando el cliente nos entregue el dinero, daremos de alta la entrada en caja.

Para ello nos habremos creado un concepto "cobro factura" de tipo depósito. Da igual la cuenta contable asociada al concepto (por ejemplo una 555 Partidas pendientes de aplicación), puesto que al seleccionar el cliente se tomará su "cuenta contable a cobrar".

Creamos una hoja de caja (si no hay ninguna en borrador), añadimos una nueva línea y:

Seleccionamos el concepto "Cobro factura":
Escribimos la cantidad:
Seleccionamos el cliente:

Y listo, ¡no necesitamos cubrir ningún otro dato ni preocuparnos por los detalles!
La hoja de caja, una vez confirmada (tras hacer recuento al final del día), queda así de limpia y clara:

Conciliación de la factura

Por supuesto con dar entrada en caja no basta para que las facturas queden marcadas como pagadas (no hemos indicado en ningún momento a que factura se correspondía el abono, y la cantidad recibida ni siquiera tienen que corresponderse con una factura concreta), pero el trabajo adicional es mínimo (y ni siquiera tiene que ser realizado por la misma persona que registra las entradas/salidas de caja).
Sencillamente, tras cerrar las cajas, abriremos el asistente de conciliación automática:

Si es la primera vez (recordemos podemos guardar los valores del asistente para veces futuras), seleccionamos las cuentas de los clientes y proveedores, y los parámetros para los posibles redondeos (en la imagen se admite un redondeo máximo de 1 céntimo que irá para la cuenta "669 Otros gastos financieros").

Y ejecutamos el asistente, que tras unos segundos nos avisará del número de elementos conciliados, y pendientes de conciliación:

¡Ya está!, si volvemos a la factura original, podemos comprobar como aparece conciliada:

Y en la pestaña de pagos, podremos ver el ingreso antes realizado en caja:

Contabilidad analítica en hojas de caja

Por último, queda el módulo pxgo_cash_statement_analytic, que permite añadir a las hojas de caja la posibilidad de establecer una cuenta analítica, tal y como mostrábamos en el primer punto del post para los extractos bancarios.
Esto nos permitirá, como decíamos, contabilizar analíticamente (si queremos) aquellos pequeños gastos para los que no registramos facturas.
Con el módulo instalado, podremos preestablecer la cuenta analítica en los conceptos (tipos de línea) de hoja de caja:

De esta forma la cuenta analítica será utilizada automáticamente al escoger el concepto. Aunque siempre podremos establecerla a mano si lo deseamos desde la vista formulario de las líneas de hoja de caja (vista desde la que, por cierto, también podemos otros datos que normalmente están ocultos en las hojas de caja):

Actualización: Saldos acumulados en extractos bancarios

Continuamos mejorando poco a poco OpenERP :) Esta vez añadiendo un módulo (pxgo_bank_statement_running_balance) que nos permitirá ver los saldos acumulados en los extractos bancarios. Algo de tremenda utilidad a la hora de detectar incoherencias entre nuestros datos y el banco.

Subida del IVA en OpenERP con Account Chart Update

borjals — Fri, 11 Jun 2010 20:12:29 +0200

En breve (el 1 de julio de 2010) los usuarios españoles de OpenERP tendrán que comenzar a usar las nuevas tasas de IVA del 18% (tipo normal) y 8% (tipo reducido).

Recordemos que dicho cambio se aprobó en la Ley 26/2009, de 23 de diciembre, de Presupuestos Generales del Estado para el año 2010:

"Artículo 79. Impuesto sobre el Valor Añadido.
Con efectos desde el 1 de julio de 2010 y vigencia indefinida, se introducen las siguientes modificaciones en la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido.
Uno. Se modifica el apartado uno del artículo 90, que queda redactado de la siguiente forma:
«Uno. El Impuesto se exigirá al tipo del 18 por ciento, salvo lo dispuesto en el artículo siguiente.»
El resto del artículo queda con el mismo contenido.
Dos. Se modifica el encabezado del apartado uno del artículo 91, que queda redactado de la siguiente forma:
«Uno. Se aplicará el tipo del 8 por ciento a las operaciones siguientes:»
El resto del apartado y artículo quedan con el mismo contenido."

Por tanto, para poder continuar trabajando en OpenERP a partir del 1 de julio, tendremos que hacer estos cambios:

Crear los nuevos impuestos del 18% y 8%
Cambiar los impuestos asociados a nuestros productos y otros elementos.

Nuevos impuestos en OpenERP

Actualmente en OpenERP, gracias a Carlos Liebana de Ting!, ya están disponibles las plantillas de los nuevos códigos de impuestos, impuestos, cuentas contables y posiciones fiscales para los planes contables españoles. Por ello,si creamos una nueva empresa en un OpenERP actualizado, automáticamente se crearán los impuestos del 18% y 8%.

Sin embargo, actualizar las plantillas (actualizar el módulo l10n_chart_ES*), no afectará a los planes contables preexistentes en nuestras instalaciónes de OpenERP.

Es decir, para poder trabajar con los nuevos impuestos necesitaremos reflejar esos cambios, introducidos en las plantillas, en nuestro plan de cuentas concreto.

Por suerte, contamos con una herramienta específica para ello...

* Actualización (en respuesta al comentario "Paso 2 en blanco"): Tras actualizar el código del módulo l10n_chart_ES (bajando la última versión de LaunchPad y copiando el código en los addons) deberemos asegurarnos de recargar el módulo en OpenERP:

Actualizar el Plan Contable de manera asistida.

Disponemos, desde hace poco, de una herramienta que nos permite actualizar o combinar un plan contable con una plantilla de plan contable (que recordemos define no sólo cuentas, sino también impuestos).

Dicha herramienta, creada por Zikzakmedia y Pexego, está disponible en el módulo account_chart_update, de los extra-addons de OpenERP.

Con el asistente de actualización de plantes contables, es muy fácil aplicar los nuevos impuestos a cualquier plan contable creado en OpenERP, como veremos a continuación:

Tras instalar el módulo account_chart_update, en el menú de Contabilidad y finanzas -> Configuración -> Contabilidad financiera -> Plantillas tendremos disponible una nueva opción "Actualizar plan contable a partir de una plantilla de plan contable":

Si abrimos el asistente veremos una pantalla similar a la siguiente, donde podremos configurar la operación:

En general, para la actualización de los nuevos impuestos en una empresa española, el único campo que tendremos que establecer manualmente será el de Plantilla plan contable, que por defecto nos ofrecerá la plantilla PGCE completo cuando probablemente en nuestra empresa usemos el PGCE PYMES.

Una vez seleccionada la plantilla correspondiente (Plan General Contable PYMES 2008 para la mayoría de empresas españolas), pulsaremos Siguiente, para que tras unos segundos de espera, el asistente nos muestre las diferencias detectadas y los registros que van a ser creados o actualizados.

Concretamente, podremos ver como se van a crear códigos de impuestos para los nuevos impuestos del 18% y 8%:

Cómo se van a crear los impuestos en si (con las diferentes variantes según se traten de ventas o compras normales, de bienes de inversión...):

Las cuentas que se crearán para contabilizar dichos impuestos:

Y las posiciones fiscales con cambios, que en este caso van a ser actualizadas (por eso aparecen en rojo):

En cualquiera de las pestañas, haciendo doble clic (en los clientes de escritorio) podremos los detalles de las diferencias detectadas. Por ejemplo para una de las posiciones fiscales anteriores, podemos comprobar como faltaban los mapeos de los nuevos impuestos:

Finalmente, si estamos conformes con los cambios que va a aplicar el asistente, pulsaremos el botón "Crear/Actualizar para que comience el proceso. Tras unos segundos se nos mostrará, o bien un mensaje de error (en el raro caso de que algún cambio no se pueda aplicar), o bien una pantalla resumen como la siguiente:

Tras este último paso, ya tendremos disponibles los nuevos impuestos en OpenERP.

Sin embargo, nuestros productos por ahora seguirán usando los antiguos impuestos. El 1 de julio, antes de comenzar nuestra operación diaria, habremos de cambiar los impuestos por defecto que se usan en las compras y ventas.

Actualizar los impuestos por defecto

Aunque creemos nuevos impuestos, seguramente en las ventas (y compras) nos seguirán apareciendo por defecto los impuestos antiguos.

Deberemos configurar:

Los impuestos por defecto (si usamos esta opción) de las pantallas de ventas y compras.
Los impuestos por defecto de los artículos.

Actualizar el impuesto por defecto en documentos

Es posible que tengamos preconfigurado algún formulario, como el de ventas para que, al añadir líneas sin un producto asociado, se utilice automáticamente un impuesto predeterminado como en la imagen siguiente:

En ese caso, deberemos eliminar el impuesto que aparece actualmente por defecto (IVA 16% en la imagen), añadir el nuevo impuesto que lo sustituye (IVA 18%) y abrir el menú contextual del campo de impuestos (con el botón secundario del ratón) tal y como se muestra en la imagen, y pulsar en la opción "Definir como predeterminado":

De manera similar podremos preestablecer los impuestos a utilizar en otros documentos (compras, facturas).

Actualizar los impuestos por defecto de productos.

El punto anterior, sirve para establecer el IVA a usar cuando no se selecciona un producto concreto. En caso de que seleccionemos un producto, OpenERP automáticamente tomará el IVA especificado en la ficha de producto.

Por tanto, el 1 de julio habremos de actualizar los impuestos asociados a cada uno de nuestros productos.

Para ello iremos a la pestaña Contabilidad dentro de la ficha del producto que nos interese:

Y sustituiremos los impuestos antiguos por los nuevos:

Esto habremos de hacerlo en cada uno de los productos que tuviesen preconfigurados los antiguos impuestos.

Si tenemos un número muy elevado de productos, siempre es posible actualizarlos en lote, todos a la vez. Aunque no existe ningún asistente específico a tal efecto, podremos hacerlo de dos maneras: Usando la actualización masiva del cliente Koo (recomendado para usuarios), o usando sentencias SQL (recomendado para administradores de sistemas).

Lo más cómodo para el usuario común, es utilizar la herramienta genérica de actualización masiva del cliente Koo de OpenERP.

Actualización en lote con Koo

Si estamos usando o tenemos disponible el cliente de escritorio Koo, realizar la actualización de múltiples artículos es muy sencillo.

En el listado de productos, seleccionaremos aquellos registros que nos interesa actualizar (todos los que tengan un mismo tipo de IVA).

Luego en el menú principal de Koo, haremos clic en Formulario -> Modificar todos los registros seleccionados:

Se nos abrirá una pantalla similar a la del producto, pero con todos los campos vacíos:

Iremos a la pestaña de Contabilidad, y estableceremos los impuestos que deseamos usar para todos los productos que habíamos seleccionado:

Pulsaremos en Aceptar, y se nos mostrará un diálogo de confirmación, donde podremos comprobar que campos van a ser actualizados:

Si confirmamos el proceso Koo actualizará conjuntamente todos los productos seleccionados.

Actualización en lote SQL

La otra opción, para administradores de sistemas con conocimiento de SQL, es utilizar unas pocas sentencias SQL en PostgreSQL para actualizar los impuestos, concretamente podremos actualizar los impuestos de venta al 16% y de compra al 16% al 18% con este par de sentencias:

UPDATE product_taxes_rel
SET tax_id = (SELECT id FROM account_tax WHERE name = 'IVA 18%')
WHERE tax_id = (SELECT id FROM account_tax WHERE name = 'IVA 16%');

UPDATE product_supplier_taxes_rel
SET tax_id = (SELECT id FROM account_tax WHERE name = '18% IVA Soportado (operaciones corrientes)')
WHERE tax_id = (SELECT id FROM account_tax WHERE name = '16% IVA Soportado (operaciones corrientes)');

Evidentemente, habremos de cambiar los nombres ('IVA 16%') según los impuestos que deseemos actualizar.

Nota: Si tenéis asociados impuestos por defecto a cuentas contables, podéis actualizarlos de forma similar a los productos. Así por ejemplo en SQL:

UPDATE account_account_tax_default_rel


SET tax_id = (SELECT id FROM 
account_tax WHERE name = 'IVA 18%')
WHERE tax_id = (SELECT id FROM 
account_tax WHERE name = 'IVA 16%');

UPDATE account_account_tax_default_rel
SET tax_id = (SELECT id FROM 
account_tax WHERE name = '18% IVA Soportado (operaciones corrientes)')
WHERE
 tax_id = (SELECT id FROM account_tax WHERE name = '16% IVA Soportado 
(operaciones corrientes)');

Comentarios adicionales sobre el asistente de actualización de planes contables

Hay que destacar, antes de cerrar este tutorial, que el asistente de actualización de planes contables no sólo permite actualizar un plan contable según los cambios de su plantilla original, sino que también nos permitirá fusionar nuestro plan contable con una nueva plantilla.

¿Para qué puede servir esto?

Pues por ejemplo para una empresa que empezó siendo una PYME, y por tanto usaba el PGCE PYMES, y que 'de pronto' se da cuenta de que ha credido y está obligada a usar el PGCE completo.

En ese caso, seleccionando la plantilla del PGCE, el asistente de actualización nos permitirá crear aquellas cuentas que aparecen en el PGCE y no en el PYMES (como las cuentas de los grupos 8 y 9), y actualizar aquellas cuentas que aparecían en el plan PYMES con nombre ligeramente diferente:

Presentaciones Jornadas de OpenERP 2010

borjals — Tue, 18 May 2010 12:00:26 +0200

Ya están subidas las presentaciones y material auxiliar usado por Pexego, de las conferencias de las III Jornadas de OpenERP 2010 realizadas los días 13 y 14 de Mayo de 2010 en la Universidad Deusto de Bilbao.

Introducción al Workshop de Localización Española: funcionalidad e instalación de los módulos de localización

Ponentes: Borja de Pexego

Presentación online: http://www.slideshare.net/pexego/localizacion-4135894
Imágenes adicionales utilizadas durante la presentación: http://pexego.es/imagenes/openerp/localizacion-espanola-2010/

Mini-Curso: Diferentes motores de impresión con OpenERP

Ponentes: Raimon Esteve y Borja López

Ejemplo "Tarjeta de Felicitación Navideña con OpenOffice" de creación de reportes con pxgo_openoffice_reports para OpenERP: http://www.pexego.es/pub/openerp-jornadas-2010/demo-reportes-openoffice.zip

Para más información recomendamos visitar la web oficial de las jornadas: http://www.jornadasopenerp.com/

Creación de modelos 3D propios para Poser con Software Libre.

ivan — Fri, 07 May 2010 12:47:53 +0200

Una de las limitaciones de Poser es la incapacidad de crear nuestros propios modelos 3D. Una alternativa sería el empleo de los Props, especialmente de los primitives, y la deformación de los mismos para tratar de elaborar objetos sencillos, pero con esto estamos realmente limitados.

Para suplir esta carencia sin necesidad de realizar un gasto suplementario en la adquisición de un software compatible o la compra de modelos a través de la red, tenemos la opción de realizar los modelos necesarios con Blender y posteriormente exportarlos en un formato que Poser admita. Vamos a ver cuales serían los pasos a seguir (en nuestro ejemplo emplearemos la versión 8 de Poser y la 2.49a de Blender.):

En primer lugar deberemos crear nuestro modelo en Blender, en este caso emplearemos un modelo sencillo, el de la mascota de Blender: “Suzanne”, para generarlo simplemente pulsaremos la barra espaciadora y seleccionaremos Add + Mesh + Monkey.

De este modo obtendremos el siguiente modelo:

En Blender podríamos suavizar sus caras y no tener tan marcadas sus aristas accediendo al menú Editing y con el modelo seleccionado, pulsaríamos sobre Set Smoot.

Como vemos, el resultado sería mucho más suave, sin embargo, los cambios que podamos efectuar sobre el modelo desde este panel, (igual que si empleamos los modificadores, como SubSurf para suavizarlo todavía más), no tendrán efecto sobre la malla interna del objeto, por lo que al importarlos posteriormente a Poser nos encontraremos con el modelo original.

Lo que sí va a interesarnos es dividir el objeto en varios materiales, para poder editarlos posteriormente en Poser. Para ello, en primer lugar, vamos a asignar un material a nuestra Suzanne: seleccionaremos el panel Shading + Material Buttons y a continuación pulsaremos sobre Add New.

Ahora tendremos asignado el material por defecto, que podremos modificar a nuestro gusto, aunque posiblemente sea una mejor opción hacer esto en Poser, pues el motor de render de cada programa es distinto y el resultado variará considerablemente.

En nuestro caso vamos a aplicar dos materiales diferentes, uno para la cabeza de Suzanne y otro para la cara. Para ello debemos entrar en el modo Edición de nuestra malla (seleccionando el objeto 3D y pulsando el tabulador).

En esta imagen vemos que tenemos todas las caras de nuestra figura seleccionadas, por lo que primero debemos deseleccionarlas pulsando la tecla A, y a continuación debemos seleccionar las caras que nos interese cambiar de color, para ello puede ser más cómodo ver la imagen por caras y que sólo nos seleccione las que están en primer plano, por lo que activaremos las siguientes opciones:

A partir de aquí sólo tendremos que seleccionar las caras que nos interese cambiar de material. Podremos hacerlo pulsando el botón derecho del ratón sobre las caras y manteniendo pulsada la tecla de mayúsculas o utilizando el selector, que activaremos pulsando la tecla B una o dos veces según nos interese un selector lineal uno estilo pincel.

Ahora lo que deberemos hacer es aplicar un nuevo material a la selección actual: volvemos al menú Editing y pulsamos sobre New + Assign.

Para que nos sea más fácil identificar en Poser los distintos materiales que componen nuestro modelo podemos asignarles colores diferentes desde el panel Shading. Finalmente, volvemos de nuevo al modo Objeto con el tabulador.

Ya estamos listos para exportar nuestro modelo. Con él seleccionado debemos seleccionar el menú File + Export + Wavefront (.obj)...

El siguiente paso será indicar la carpeta en donde queremos generar los nuevos archivos, así como el nombre del mismo. Luego pulsaremos sobre Export Wavefont OBJ.

Aparecerá en pantalla un menú en el que activaremos el botón Material Groups para que nos mantenga independientes en Poser los materiales creados. A continuación pulsaremos Export, y Blender nos creará dos archivos: suzanne.mtl y suzanne.obj.

Ya podemos abrir Poser y proceder al importado del objeto. Seleccionamos la opción File + Import + Wavefront OBJ...

En el menú de importación seleccionaríamos las opciones que nos interesasen y a continuación pulsaríamos sobre OK.

Seguidamente nos pide que seleccionemos el archivo .obj a importar, lo hacemos y pulsamos sobre Abrir.

Podemos observar como el modelo ha sido importado correctamente, y aparece con el nombre que le hemos dado al archivo .obj.

Ahora podríamos modificar los materiales y las propiedades del objeto para conseguir el renderizado que más nos interese.

Tendencias TIC en el sector agroalimentario

santiago — Sun, 25 Apr 2010 23:52:46 +0200

Aprovechando la preparación de la charla a la que me han invitado el día 26 de Abril dentro del salón del vino Vintech, me ha parecido interesante dejar por escrito unas breves reflexiones sobre las tendencias en las que nos movemos en las TIC y qué grado de aplicación pueden tener en el sector.

Creo que es algo claro que en los últimos años se ha percibido una gran explosión de las redes sociales y en general de lo que se puede llamar software social, no limitándonos en exclusiva a redes como facebook, linkedin, tuenti y demás acompañantes, unas más nacionales, otras más internacionales, con públicos dispares y con mayor o menor verticalización por sectores, un punto este en el que todavía est á por ver un modelo que se imponga. Ahora mismo las aplicaciones no basadas fundamentalmente en web, como twitter y otra gran variedad nacidas o amplificadas varias de ellas por los markets de Android, iPhone o similares. Y es aquí donde se engancha con la otra gran tendencia, las aplicaciones para móviles, la movilidad en general y muy vinculada a ella el geoposicionamiento y la oferta de servicios geolocalizados. Tal vez como pegamento de todo esto podamos nombrar el Cloud Computing, de tal forma que utilizamos mapas de Google o capas de Layar, por ejemplo para mostrar la más diversa información, desde localización de restaurantes, o bodegas, o bares hasta posicionamiento de mensajes de Twitter.

Todo ello basado en la participación de los usuarios de internet, de la comunidad que aporta y enriquece los contenidos, valora y comenta todo lo que se mueve, desde cualquier lugar y hace visible lo que considera interesante de forma autónoma a los canales tradicionales. Una comunidad que opera, generando en el fondo conocimiento, de forma similar a la que e mueve en torno al software libre, la otra gran tendencia que se mueve y da potencia desde las bambalinas a todos estos movimientos, creando cada vez más y mejores aplicaciones y fortaleciendo la colaboración y la puesta en común de lo aprendido y lo desarrollado, permitiendo un crecimiento exponencial.

Ya desde hace tiempo en Pexego estamos involucrados en proyectos de todas estas áreas, nuestra vocación por el software libre es una constante desde nuestro nacimiento y sigue fluyendo cada vez más fuerte. Quizá lo más visible sea las implementaciones, desarrollos y localización de OpenERP http://www.openerp.com, la herramienta elegida para gestión empresarial. Dentro de esta área y relacionado con el sector agroalimentario, ya hemos finalizado un proyecto de I+D+i con el objetivo de crear una aplicación para la gestión de la trazabilidad en la industria agroalimentaria de la que ya hemos hablado en un post anterior (Trazabilidad para la industria agroalimentaria con OpenERP).

En cuanto a redes sociales hemos participado y contribuido al nacimiento de una red vertical, desarrollando software sobre django para cubrir las necesidades que una aplicación de este tipo necesita, y seguimos teniendo proyectos sobre la mesa, unos en marcha y otros en estudio con los que esperamos seguir evolucionando en este ámbito.

xacoveo http://www.xacoveo.com/, puesto en marcha para este año santo y poder seguir las evoluciones de peregrinos a lo largo del camino ha sido nuestra ilusionante incursión en las aplicaciones para móviles y el geoposicionamiento.

Actualmente estamos inmersos en otro nuevo proyecto de I+D+i plenamente relacionado con el sector agroalimentario y las aplicaciones para móviles. Se trata del desarrollo de una aplicación para la lectura e interpretación de códigos QR http://es.wikipedia.org/wiki/C%C3%B3digo_QR . Estos códigos QR estarán incorporados a las etiquetas de los productos y a través de ellos y mediante un teléfono móvil se podrá acceder a características del producto referentes a posibles alergias, información nutricional, trazabilidad, comentarios de usuarios, valoraciones, recomendaciones e incluso recetas o cualquier información comercial que el fabricante estime oportuno. Como se puede ver este proyecto es un compendio de las diversas tendencias de las que hemos hablado con anterioridad. También trata de ser el enlace entre estas tendencias TIC y la cada vez mayor exigencia del consumidor de alimentos y bebidas en cuanto a seguridad, orígenes del producto, valoraciones y la necesidad de expresar el conocimiento. Pensando en la charla para Vinitech se me antoja especialmente adecuado para el mundo del vino, donde todos sabemos del gusto por recomendar un vino, una bodega, o una zona, un mundo, el del vino, en el que cada uno tiene sus zonas favoritas y gusta de hablar del vino que probó en cierto sitio o el que bebió la última noche en su casa o en la de un amigo. Una actividad tan eminentemente social como beber un vino no estará de espaldas a todo este movimiento y la puesta en común de todo este conocimiento favorecerá a los que, como el que escribe, apreciamos un buen vino, pero no disponemos del conocimiento para poder escogerlo o valorarlo como se debe.

De cualquier forma el uso de herramientas de geoposicionamiento y la puesta en valor de la información de trazabilidad de cara al consumidor es una forma de potenciar la imagen de producto y facilitar al usuario de internet la interrelación con la empresa y con ello su fidelización. Con estas herramientas se facilita también otra de las grandes tendencias del mundo del vino, como es el enoturismo. Tener geolocalizada la bodega, el viñedo, poder conocer de dónde ha nacido la botella que tenemos entre manos, invita a conocerla, mostrar junto a esto una oferta gastronómica, cultural o de ocio, como la de nuestro país, es algo de gran valor que no se puede perder la oportunidad de mostrar y dar la oportunidad a la gente para que opine de ello.

Un brindis con todos y ¡Viva el vino!

Trazabilidad para la industria agroalimentaria con OpenERP

santiago — Sat, 24 Apr 2010 19:25:00 +0200

OpenERP (www.openerp.com) ya disponía de unos potentes módulos tanto para la gestión de almacenes y control de stock como para el control de la producción. Esta funcionalidad básica, a pesar de contar con herramientas para el seguimiento de la trazabilidad, no eran lo suficientemente completas ni fáciles de usar como para cubrir todas las necesidades de la industria.

Pexego, que se encuentra totalmente involucrada en el desarrollo de OpenERP en España, decidió iniciar la creación de módulos específicos que cubriesen plenamente estas carencias.

Las premisas fundamentales del proyecto eran:

Facilidad de uso. Simplificar al máximo la operativa del usuario. Se puede gestionar todo el sistema de trazabillidad registrando simplemente las entradas y salidas de producto y las órdenes de producción/fabricación con sus respectivos lotes. Las consultas de trazabilidad también se simplificaron permitiendo ver la trayectoria de un lote determinado a través de toda su ciclo, observando movimiento a movimiento, u obtener simplemente de donde proviene y dónde se encuentra o a quién se ha enviado o vendido. Se simplificó también la gestión por defecto de OpenERP para obtener mezclas de productos (por ejemplo en tanques y depósitos) y crear lotes internos para estos productos de forma que sea más completo y sencillo su seguimiento
Flexibilidad. Dado que se ha sido desarrollada como módulos para OpenERP, es posible utilizarla solo como herramienta de trazabilidad o instalar los módulos que se consideren necesarios para la emprea (OpenERP dispone de más de 500), para cubrir todas las áreas de negocio: Compras, ventas, facturación, contabilidad, CRM, recursos humanos, gestión de costes, etc...)

Personalizable. OpenERP es software libre bajo licencia GPL, esto otorga la libertad para su completa modificación además, su completa modularidad simplifica sobremanera esta tarea. Es importante recordar también que OpenERP no tiene ningún coste de licencia.

Se añadieron también facilidades para el bloqueo y gestión de lotes en alerta, con posibilidades de bloqueos en cascada, que permiten conocer ante cualquier incidencia los lotes afectados e impedir su uso. Es posible gestionar también los costes de cada lote y calcular los costes de materias primas en producción. Con la instalación de módulos adicionales se pueden calcular también costes de mano de obra y otros indirectos.

En fechas próximas estos módulos podrán encontrarse publicados en el repositorio extra-addons del proyecto OpenERP en launchpad (https://launchpad.net/openobject-addons) . A mayores se publicará en este blog un pequeño tutorial sobre el manejo de la trazabilidad en OpenERP

Actualmente Pexego ha finalizado una verticalización para la industria láctea y tiene prácticamente finalizadas nuevas verticalizaciones para bodegas y fábricas de licores que recogen necesidades específicas de estos sectores

Cierre del ejercicio en OpenERP

borjals — Fri, 26 Mar 2010 10:44:10 +0100

Introducción

En este tutorial es una guía práctica para quienes, usando un plan de cuentas español, desean realizar el cierre del ejercicio contable en OpenERP.

Desde hace poco (marzo de 2010) existe un asistente específico para las empresas españolas, que facilitará la creación de los asientos de regularización y cierre, junto con la apertura del nuevo ejercicio. A continuación se comentan los pasos previos al cierre del ejercicio, y posteriormente se detalla el uso del asistente de cierre de ejercicio para España.

Preparación

Antes de proceder con el asistente de cierre de ejercicio es necesario realizar ciertas operaciones:

Realizar una revisión general

Comprobaremos que no falte nada por contabilizar (quizá alguna factura que nos hemos olvidado de confirmar, y por tanto OpenERP no ha creado asiento); que los pagos realizados se correspondan con las facturas (quizá hemos conciliado el pago equivocado); que no se hayan hecho apuntes en cuentas incorrectas (podemos haber configurado mal la cuenta 'a pagar' o 'a cobrar' de un cliente o proveedor, o quizá nos hemos olvidado de crear una subcuenta para la empresa y hemos estado contabilizando en una cuenta genérica 4300000/4100000); que las cuentas de IVA soportado (472) y repercutido (477) tengan saldo 0 (para asegurarnos de no haber introducido ninguna factura tras el cierre del IVA del cuarto trimestre); etc.

Cabe destacar que el asistente de cierre de ejercicio de OpenERP para planes contables españoles, realizará algunas comprobaciones adicionales antes de proceder a crear los asientos de cierre: Se asegurará de que no existan asientos descuadrados, sin confirmar o con fechas incorrectas (*) en el ejercicio a cerrar.

* Recordemos que en otros países está permitido que el periodo fiscal y la fecha del asiento no se correspondan, por lo que OpenERP permite este extremo incorrecto en la fiscalidad española.

Nota: Para más información sobre los aspectos contables ver “Guía práctica para el cierre contable - Revisar las fichas del libro mayor una a una” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoRevisarFichas.htm

Inventario de existencias

El último día del ejercicio realizaremos el inventario físico de existencias (ver el punto siguiente para más detalles sobre como realizar el recuento), y posteriormente reflejaremos las variaciones de existencias (con respecto al año anterior) en el asiento correspondiente.

Por ejemplo si, a principios del ejercicio, lo guardado en nuestro almacén estaba valorado en 10.000€, y a finales del ejercicio está valorado en 12.000€ crearemos (actualmente es necesario hacerlo a mano) un asiento de la forma:

10000 (610) Variación de existencias de mercaderías a (300) Existencias de mercaderías 10000
12000 (300) Existencias de mercaderías a (610) Variación de existencias de mercaderías 12000

Nota: La valorización de existencias de OpenERP está basada en el “precio coste” del producto, que podemos configurar desde la pestaña “Precios & Proveedores” del formulario de “Productos”. Desde esta pestaña podremos establecer además el método de coste a utilizar pudiendo elegir entre dos: “Precio medio” y “Precio estandar”.
Actualmente en España, el PGCE, establece que, para bienes intercambiables entre si, el método de valoración a adoptar con carácter general es el de método del precio medio o coste medio ponderado; por tanto deberemos asegurarnos de elegir, en OpenERP, el método de coste “Precio medio” para este tipo de productos. Para bienes no intercambiables entre si o producidos para un proyecto específico, el PGCE, especifica que el valor se asignará identificando el precio o costes especificamente imputables a cada bien; es para este tipo de productos para los que habremos de usar el método de OpenERP “Precio estandar”.

Nota: Es posible configurar OpenERP para que se realicen movimientos contables cada vez que se mueve producto entre dos ubicaciones (incluyendo salidas a clientes o entradas de proveedores), aunque no es lo habitual.

Nota: Para más información sobre los aspectos contables ver “Guía práctica para el cierre contable – Ajustes - Existencias” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoAjustes.htm#existencias

Recuento

Hay que recordar que podemos ayudarnos de las herramientas del módulo stock de OpenERP para realizar las operaciones de recuento y seguimiento del stock.

Para realizar el inventario, a finales de año, podremos crear un nuevo Inventario Periódico ( Gestión de Inventario → Inventario Periódico → Nuevo inventario periódico ):

Rellenaremos la información del stock real de cada producto en la fecha de introducción del inventario (podemos usar el asistente Rellenar inventario o bien introducir los artículos que nos interesan a mano):

Y confirmaremos el inventario, con lo cual OpenERP automáticamente generará los movimientos de stock, correspondientes a las diferencias de inventario, contra la ubicación Pérdidas de Inventario:

Una vez realizados los ajustes de inventario, abriremos el informe “ Valores ubicaciones” ( Informe → Valores ubicaciones) y lo imprimiremos o exportaremos (actualmente el informe del módulo de stock muestra sólo la valorización actual, así que nos interesará conservarla).

Otra opción para el análisis, es utilizar el asistente de análisis de stock por ubicaciones para ver todos los movimientos realizados entre dos fechas (la variación de existencias) en esa ubicación. Para ello iremos a la ubicación en cuestión (podemos acceder desde Gestión de inventario → Configuración → Ubicaciones ) y ejecutaremos el asistente “ Productos por ubicación ”.

Amortización de los activos

Registraremos las pérdidas de valor que han experimentado los bienes de la empresa, bien por su uso, o bien por el simple paso del tiempo; y el gasto asociado a dicha pérdida.

Nota: Existe un módulo de gestión de activos en OpenERP ( account_asset) pero actualmente (25/03/2010) no está adaptado a la fiscalidad española.

Nota: Para más información sobre los aspectos contables ver “Guía práctica para el cierre contable – Ajustes - Amortizaciones” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoAjustes.htm#amortizaciones

Reclasificar saldos de las cuentas en función del vencimiento

Deberemos mover de las cuentas de largo plazo a las cuentas de corto plazo aquellos importes que vayan a vencer en el ejercicio siguiente.

Por ejemplo, si un crédito bancario expira en el año entrante, deberemos mover su importe de la cuenta Deudas a largo plazo con entidades de crédito (170) a la Deudas a corto plazo con entidades de crédito (520).

Ajustar otras cuentas que influyen sobre el resultado del ejercicio

Inmovilizado: Podremos activar (registrar como activo) el resultado de las inversiones en I+D o trabajos para la propia empresa realizados durante el ejercicio (de lo contrario serán considerados gastos).

Provisiones: Siguiendo el principio de prudencia, las posibles pérdidas deben contabilizarse lo antes posible. Así que, a final de año deberemos buscar pérdidas posibles (las pérdidas confirmadas van contra la cuenta de gastos) de valor o nuevos riesgos que no existían a principio de año y dotar las provisiones correspondientes.

Ajustes por periodificación: Registraremos aquellos gastos e ingresos que se han realizado por anticipado (por ejemplo cuando contratamos un servicio que no termina hasta entrado el ejercicio siguiente, pero que ya hemos pagado).

Ingresos y gastos a distribuir en varios ejercicios: Pasaremos a los resultados del ejercicio aquellos ingresos distribuidos en varios años (por ejemplo, si recibimos una subvención para un proyecto a tres años, en cada uno de los tres ejercicios sólo traspasaremos al resultado una parte del ingreso).

Nota: Para más información sobre los aspectos contables ver “Guía práctica para el cierre contable – Ajustes” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoAjustes.htm

Calcular el impuesto de sociedades

En este punto deberemos calcular y registrar los gastos por impuesto de beneficios. Dado que es una operación compleja y dependiente de la comunidad autónoma donde la empresa esté inscrita, no detallaremos aquí el procedimiento, recomendando en su lugar visitar los enlaces listados a continuación.

“Guía práctica para el cierre contable – Calcular Impuesto Sociedades” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoCalcularIS.htm

“Guía práctica para el cierre contable – Calcular Impuesto Sociedades” de Gábilos: http://www.gabilos.com/comosehace/CierreContable/textoEjemplos.htm

Renumerar los asientos contables

Es de exigencia legal que todos los asientos del Diario estén numerados de forma secuencial por orden de fecha.

OpenERP automáticamente asigna a los asientos números usando la secuencia configurada en su diario (permitiendo incluso usar una secuencia por cada diario, sin embargo en España lo habitual es tener un único Diario) según se van confirmando dichos asientos. Sin embargo, hay situaciones en las que el orden en que introducimos los asientos no se corresponde con la fecha real del asiento, y otras en las que borramos asientos (por ejemplo si cancelamos una factura para hacer una corrección, se borra su asiento, y al confirmarla de nuevo se crea un nuevo asiento con un número diferente).

Así que, finalmente, una vez hemos hecho las correcciones oportunas y creado los últimos asientos del ejercicio, procederemos a renumerar los asientos del diario usando el módulo account_renumber (disponible en los extra-addons ).

Para ello en Contabilidad y finanzas → Tratamientos de fin de año → Renumerar asientos contables disponemos de un pequeño asistente, que nos permitirá regenerar los números de los asientos contables, según su fecha de asiento y la configuración de la secuencia de su diario.

En el asistente, y para el caso del cierre del año, seleccionaremos todos los periodos del ejercicio a cerrar y todos los diarios disponibles, y pulsaremos el botón Renumerar.

Al cabo de algunos pocos segundos (si tenemos decenas de miles de asientos puede tardar más de un minuto) se nos mostrará una pantalla de confirmación desde la que se nos posibilitará (y es recomendable) revisar el resultado.

Cierre del ejercicio

Para el cierre del ejercicio de una empresa española, OpenERP nos ofrece (si instalamos el módulo l10n_ES_cierre_ejercicio de la localización española ) un asistente para crear de forma automatizada los asientos de regularización, cierre y apertura.

El asistente realiza diversas comprobaciones (para asegurar que no existan asientos descuadrados, asientos sin confirmar o asientos con fechas incorrectas), crea los citados asientos, y finalmente bloquea el ejercicio fiscal para impedir futuras modificaciones.

A continuación veremos los pasos para realizar el cierre de un ejercicio.

Nuevo cierre de ejercicio

Para iniciar un nuevo cierre de ejercicio, iremos a Contabilidad y finanzas → Procesamiento periódico → Tratamientos de fin de año → Cerrar ejercicio fiscal . Si por el contrario, deseamos continuar un proceso de cierre ya comenzado, o cancelar uno ya realizado, podremos usar el menú Contabilidad y finanzas → Procesamiento periódico → Tratamientos de fin de año → Cierres de ejercicios fiscales .

Al iniciar un nuevo cierre de ejercicio se nos mostrará una pantalla similar a la siguiente, donde podremos configurar el ejercicio a cerrar, el ejercicio a abrir y asignar un nombre o referencia para este proceso de cierre. En el caso general de que queramos cerrar el último ejercicio, sólo tendremos que hacer clic en el botón Continuar.

Selección de operaciones a realizar

A continuación el asistente nos mostrará un par de pestañas:

General, desde donde podemos seleccionar las operaciones a realizar y comenzar el proceso.
Configuración, desde donde podremos cambiar algunos parámetros de los asientos a crear.

Por defecto, en cuanto pulsemos el botón Ejecutar las operaciones se crearán los asientos de regularizaciones, cierre y apertura, realizándose previamente las comprobaciones marcadas. También es posible seleccionar desmarcar las operaciones que no queremos realizar todavía, permitiéndonos ejecutar el proceso paso a paso.

Configuración de las operaciones

En Configuración podemos establecer algunos parámetros de las operaciones a realizar. Normalmente, si tenemos OpenERP correctamente configurado, no será necesario cambiar nada, ya que todos los parámetros tomarán valores por defecto.

Podemos configurar el diario, periodo y descripción a utilizar para cada uno de los asientos que se crearán. Por defecto, si existen, se usarán el diario General y los periodos PG*, C* y A* correspondientes a los ejercicios a cerrar y abrir (por ejemplo PG09, C09 y A10).

Así mismo, podemos revisar y establecer el mapeo de cuentas a utilizar en las regularizaciones, y las cuentas a incluir en el cierre. Nuevamente el asistente ya viene preconfigurado según el PGCE.

: Parámetros para la operación de regularización de PyG, observese como desde aquí es posible cambiar la cuenta de Pérdidas y Ganancias donde se totalizarán los ingresos y gastos.

Ejecución

Como comentábamos en el punto 2, una vez marcadas las operaciones que queremos que el asistente realice, pulsaremos el botón Ejecutar las operaciones .

Se nos mostrará un diálogo de confirmación, donde sencillamente pulsaremos en Ejecutar.

En cuanto confirmemos que deseamos ejecutar las operaciones, OpenERP se pondrá manos a la obra. Dado que las revisiones y creación de asientos es una operación larga, se mostrará una pantalla de progreso.

En caso de que el proceso se alargue más de 20 segundos (lo cual sucederá con probabilidad si optamos por ejecutar todos los procesos en un sólo paso), aparecerá un segundo tipo de pantalla de progreso, que nos permitirá realizar el proceso en segundo plano (así podremos seguir usando OpenERP) o continuar esperando.

Finalmente se nos mostrará una pantalla, bien con el resumen de errores encontrados (por ejemplo asientos por confirmar) o bien informando del éxito. Al cerrar esta pantalla podremos ver como ahora, en la parte derecha del formulario, aparecen enlaces a los asientos recién creados.

Validación

A continuación deberemos revisar los asientos que ha creado el asistente y validarlos. OpenERP no nos permitirá confirmar el cierre del año sin antes validar cada uno de los tres (plan PYMES) o cuatro (PGCE) asientos recién creados.

Para ello abriremos, directamente desde el formulario, cada uno de los asientos marcados con “*”

Revisaremos las líneas del asiento (si lo deseamos podemos hacer cambios a mano) y finalmente pulsaremos el botón Validar y a continuación Aceptar. Repetiremos esto para cada uno de los asientos.

Una vez todos los asientos estén validados, será hora de pulsar en el botón Confirmar para terminar con el proceso de cierre: El ejercicio fiscal se bloqueará impidiendo futuros cambios.

Cancelar el cierre del ejercicio

En caso de que detectemos cualquier problema durante el cierre del ejercicio, o posteriormente al mismo, el asistente nos permite de forma cómoda cancelar todas las operaciones realizadas.

Para cancelar un cierre de ejercicio, iremos a Contabilidad y finanzas → Procesamiento periódico → Tratamientos de fin de año → Cierres de ejercicios fiscales :

Seleccionaremos el cierre que queremos cancelar:

Pulsaremos en el botón Cancelar y en el diálogo, confirmaremos que deseamos cancelar el cierre y esperaremos mientras el asistente deshace todas las operaciones realizadas (se reabrirá el ejercicio y se borrarán los asientos).