Entradas

Novedades del módulo de gestión de almacén en OpenERP v8

  • Gestión de almacenes y coste mediante los métodos FIFO/LIFO/medio/FEFO.

Y por supuesto con la escalabilidad y posibilidad de adaptaciones que siempre ha caracterizado a OpenERP.

Esto es sólo una pequeña parte de todo lo que parece que nos aguarda en la versión 8 de OpenERP respecto al módulo de gestión de almacén.

En el siguiente slideshare, podemos encontrar información mas detallada:

Fuente: slideshare.net extraído de OpenERP.tv

Modo desarrollador del cliente web 6.1 de OpenERP

acerca de

En la ventana emergente que aparece se muestra el enlace “Activar modo desarrollador” en la parte superior derecha, y haciendo clic sobre él se activará este modo y estarán disponible todas las nuevas funcionalidades.

modo desarrollador

Una vez activado el modo desarrollador al acceder desde el cliente a una vista aparecerá una lista junto al titulo con varias opciones.

openerp depurar vista

Por defecto este listado indicará “Depurar Vista#…” y junto a la almohadilla aparecerá el número de la vista.

La primera opción del desplegable anterior es “Ver Campos”, haciendo clic sobre él se obtendrá un listado de los campos de la vista actual con los parámetros correspondientes.

campos del modelo openerp

Haciendo clic sobre “Obtener Campos de Vista” se obtendrá el XML generado para mostrar esta vista, ojo, porque si la vista se ha generado usando varias vistas XML extendiendo unas a otras aquí se mostrará el resultado final.

campos de la vista openerp

Al hacer clic en “Gestionar Vistas” se mostrará un listado de las vistas relacionadas con la vista actual. Aquí se podrán crear nuevas vistas, eliminarlas o editarlas, aunque lo recomendable es usarlo solo a modo de consulta y siempre realizar esas modificaciones creando nuevos módulos.

gestionar vistas openerp

El resto de opciones sirven para acceder a editar directamente las vistas relacionadas con la vista actual.

editar vista openerp

Accediendo en un formulario aparecerá una nueva opción, “Ver Registro(perm_read)”, que muestra información relativa al registro actual.

ver registro openerp

Por último, al igual que en la versión 6.0 del cliente web, en modo formulario al situar el puntero sobre un campo mostrará información relativa al campo.

información campo openerp

Esta información será diferente en cada tipo de campo, por ejemplo en botones el método al que llama.

información botón openerp

Al situarlo sobre un widget de estado mostrará los posibles estados.

información estado openerp

Prestashop (y OpenERP)

A pesar de su temprana edad, actualmente es la segunda plataforma más popular comparándolo con sus rivales libres más cercanos, de acuerdo con Google Trends,. Sin atrevernos a realizar pronósticos, parece que la tendencia es creciente, mientras que Magento, líder actual indiscutible de plataformas de comercio electrónico, ya parece haber tocado techo. Por debajo de ambas quedan prácticamente empatadas la solución ecommerce más popular para Joomla, VirtueMart y un creciente OpenCart, al que no hay que perder la pista. Y en último lugar, un obsoleto OsCommerce, que tal y como se obseva fue pionero y líder indiscutible en años anteriores, hasta que aparecieron sus nuevos rivales, tecnológicamente superiores y lo destronaron sin compasión.


capturas_openerp

Fecha de la captura: Julio 2012. Enlace actualizado en Google Trends.

¿Por qué Prestashop? ¿Y por qué ahora? En Domatix tenemos mucha experiencia con ecommerce, aunque en los últimos años nos hemos concentrado en soluciones que conectaran con OpenERP. Lamentablemente, descartando osCommerce por ser un producto ya obsoleto, y Zoook, solución que también se las prometía, únicamente nos queda Magento. Magento es un excelente producto, muy completo y complejo, pero por ello quizás costoso levantar, y mantener un ecommerce con esta plataforma. La curva de aprendizaje del usuario final también es elevada y por ello otras soluciones más sencillas pero no por ello menos completas ahora mismo están en auge.

Y ahí es donde entra Prestashop, que además ya cuenta con una base de clientes enorme, pero todavía no ofrece la posibilidad de conectar con OpenERP. Para solucionar esta carencia, Akretion y Camptocamp, dos grandes de OpenERP, han unido sus fuerzas, tal y como pulicaron en su nota de prensa y pretenden proporcionar un conector que permita a Prestashop gestionar la tienda y ventas utilizando como BackOffice a OpenERP, para gestionar los stocks, finanzas, incidencias, pedidos, etc…

Aunque ya existe un conector anterior, desarrollado por TechReceptives, llamado openerp_prestashop_sync, actualmente alojado en un repositorio de Bitbuckett, éste aún no ha conseguido llegar a una versión estable y proporcionar una buena conexión e interoperabilidad con OpenERP. Tampoco parece que la aproximación técnica para realizar las tareas de conexión sea la más adecuada.

Para cubrir este nicho actual, la alianza de Akretion y Camptocamp con la presentación de prestashoperpconnect puede ser determinante, y esperamos contar en breve con una versión 100% funcional y estable de su nuevo conector.

Actualmente en Domatix estamos probando todo el trabajo realizado y aunque todavía no parece preparado para entrar en producción en una tienda ya funcional, algunas de las tareas básicas del conector se realizan  sin problemas.

En breve estaremos informando con novedades al respecto.

Mejorar control de envíos desde pedidos (módulo OpenERP)

Para cubrir esa necesidad, hemos creado el módulo dx_sale_line_delivered, que mejora el módulo base y añade los siguientes campos a la linea del pedido:

  • Enviado, cantidad enviada, obtenida de los albaranes asociados y validados, hasta que no se valida un albarán no lo tiene en cuenta.
  • Stock real, el stock que hay en los almacenes.
  • Stock disponible, es el stock de los almacenes restando el reservado y añadiendo el pendiente de recibir.

Con esto no sólo conoceremos el estado de envío de cada linea de pedido, sino que tendremos accesible también la información del stock real y disponible para poder estimar cuando podremos servir los productos restantes.

El módulo esta liberado bajo AGPL y está disponible en launchpad https://code.launchpad.net/~domatix/dx/6.1 y en http://apps.openerp.com/addon/7655

Reflexiones tras las Jornadas OpenERP 2012

En primer lugar, enhorabuena al equipo de Avanzosc por la organización. No es una tarea fácil, y una vez más, el equipo de organizadores realizaron un trabajo excelente para facilitarnos a todos los presentes y conferenciantes nuestra asistencia. Recomiendo también la lectura del artículo-resumen “oficial” colgado en la página de las Jornadas.

Sobre el programa, un año más las presentaciones han sido expuestas por distribuidores/partners de OpenERP y por tanto mayoritariamente las preocupaciones y exposiciones son de carácter técnico y funcional, orientadas hacia la comunidad de desarrolladores. Aunque se habló de la posibilidad “censar” a los usuarios finales que se han “auto-implantado” OpenERP (algo imposible de realizar en la práctica, el censo, no la auto-implantación) y de que necesitan un lugar para exponer sus necesidades, carencias y problemática. Si bien lo cierto es que no hay una comunidad ni representación activa de los mismos, y orientar parte del tiempo o esfuerzos hacia éstos creo que no sería tan productivo como dedicar energías a tratar de atraer nuevos implantadores para potenciar la comunidad y que a su vez promuevan OpenERP para seducir a nuevos clientes potenciales y aumentar el número de implantaciones. En definitiva, la “comunidad” de OpenERP está formada por empresas que distribuimos OpenERP, y escuchamos las necesidades nuestros clientes, trabajando de una manera u otra para resolver dichas necesidades. Para soporte adicional, siempre se puede contar con OpenERP s.a.

Sobre las charlas, de varios tipos (nota: no es mi intención describirlas todas, esa tarea ya está realizada en la web oficial de las Jornadas):

Soluciones verticales, como siempre un trabajo excelente de las empresas desarrolladoras, con charlas más completas en gestión de granjas (de dos tipos, cría de animales y huevos), gestión de proyectos según Project Management Institute (excelente trabajo de Eficent), módulo para LOPD (que bien pudiera servir para la localización, ya que es aplicable a todas las empresas),  gestión de recursos para actividades lúdicas de Abartia, y nuestra vertical de transportes, éstas dos últimas no se pudieron ver en directo debido a una caída de la conexión a internet.

Charlas ténicas: a destacar KafkaDB, propuesta para migración de módulos y datos entre versiones de OpenERP, que simplifica el trabajo, pero todavía queda muy lejos ser algo fácil, MongoDB, una excelente alternativa para almacén de datos alternativo y complementario y BABI, un “embrión” de Business Intelligence para OpenERP, aunque lamentablente no va a ser liberado.

Módulos para la comunidad: entre otros, el l10n_es_gestion_comercial, para la gestión de efectos comerciales (cobros y pagos), para el que estamos prestando nuestro apoyo y ayudaremos a dar un empujón y mejorarlo/terminarlo en breve. También a destacar la presentación de Omar Castiñeira, de Pexego para la gestión de la documentación de expedientes.

También vimos la presentación del nuevo proyecto de Carlos Liébana, Factor Libre, al que deseamos mucha suerte desde aquí, aunque no la necesite, excelente comienzo y previsiones aún mejores.

Para dar una nota de color, se presentó el “competidor comunitario” de OpenERP, Tryton. Nosotros mismos sugerimos la charla en la lista de correo, aunque finalmente fue realizada por el equipo de Nan-tic, elección acertada, pues ellos están involucrados muy activamente en la localización española y difusión del proyecto.

Mención especial a la charla sobre los aspectos legales de las licencias GPL y derivadas (como AGPL). Agradeciendo a Helena Fuentes su asistencia y la presentación, como buen conocedor de los aspectos legales sobre las mismas, debo aclarar algunos puntos de la presentación, que lejos de cumplir el objetivo de aclarar conceptos y dilucidar los límites de los derechos de propiedad y licencia, acabaron confundieron bastante más, por tratar algunos temas de manera incorrecta. Quisiera aclarar algunas equivocaciones expuestas en dicha ponencia:

Nota: después de leer todas las aclaraciones, y viendo el tamaño de las mismas, he preferido enmarcar el contenido, y separarlo en otro artículo, de interés para aquellos que deseen conocer más acerca de los fundamentos jurídicos de las licencias libres.

Leer el artículo completo.

Alejándonos un poco de los temas técnicos nos sorprendió agradablemente saber que ya existen empresas cuyo modelo de negocio principal es OpenERP pero no implantan ni desarrollan, sino que vienen del mundo del asesoramiento legal y contable. Complementa los servicios que ofrecemos los partners y enriquece al cliente final, dado que realizan todos los trabajos contables y fiscales sobre la implantación del cliente de OpenERP. Recomendable, como mínimo, conocer a Gafic, porque creo que han abierto una nueva línea y van a ser una referencia a seguir para otros que vengan.

Nuevamente agradecer la presencia oficial de OpenERP s.a, representados por Rubén Real y Frédéric van der Essen, que acudieron para presentarnos las futuras novedades de OpenERP en el cliente web y POS y escucharon pacientemente nuestras sugerencias y aportes para trasladarlos a las personas correspondientes. Enhorabuena por el trabajo realizado y gracias por seguir al pie del cañón, a pesar de que parte de la comunidad española a veces puede parecer un poco hostil con las políticas de OpenERP.

Y por último, y relativo al debate sobre la localización española. Antes que nada pedir perdón por tener que marcharnos apenas unos minutos antes del final, pero nuestros compromisos personales no nos permitieron apurar más tiempo. Pido disculpas a amigos, colaboradores y sobretodo a la organización, por no haber encontrado un momento para despedirnos “oficialmente”. Obviamente no podíamos interrumpir el debate, y tampoco pudimos demorar más nuestra marcha.
capturas_openerp
Imagen que no tiene nada que ver con el artículo, pero con suerte puede hacer su lectura más amena 🙂

En el debate, como siempre, varias opiniones, todas ellas correctas desde un punto de vista individual, entendiendo que cada empresa cuenta con unas circunstancias, clientes, experiencia y equipo diferentes, pero muy difícil de unificar, especialmente todo lo relativo a crear formas fiscales o grupos de trabajo “oficiales” o asignación de tareas, distribución de las mismas de manera remunerada (canalizadas, previsiblemente por dicha forma fiscal). Lo cierto es que la localización española siempre ha destacado por su buena trayectoria y rumbo, y si bien es cierto que la mayor parte de trabajo ha sido realizado por muy pocas empresas no es menos cierto que hasta ahora ha funcionado y muy bien. Y las aportaciones y número de contribuidores, aunque discretamente, sigue creciendo. Mi opinión personal es que algo que funciona, y lo hace bien, no debería ser expuesto a demasiados cambios, en especial si algunas de las partes no están conformes con dichos cambios… aunque, una pequeña reflexión al respecto:

Actualmente cuando OpenERP no cubre una funcionalidad, el primer cliente en necesitarla la financia y cuando la empresa desarrolladora la libera, ya está disponible para todos los demás clientes. Es una fórmula muy buena, porque realmente funciona, aunque tiene algunos “peros” de base. Por ejemplo puede ser un requerimiento realmente costoso, y por tanto no asumible por dicho cliente, lo que puede derivar en tres posibles caminos:

  1. El cliente elige otra solución No-OpenERP. Obviamente el peor de los casos. Se pierde el proyecto y la implantación.
  2. El cliente “asume” las carencias. No es una buena solución, pero es mejor que la anterior. Y cabe la posibilidad de que dichos requisitos se desarrollen por otros más adelante.
  3. El distribuidor encuentra que otros de sus clientes actuales pueden estar interesados en dicha solución y los agrupa, dividiendo presupuesto entre todos, para desarrollar dicha funcionalidad.

Al final, en caso de ser desarrollada, todos ganamos, pues ya forma parte de OpenERP o de la localización española. Sin embargo, el “problema” de estos casos es que sin duda perjudican a la comunidad en general por falta de posibilidades y perjudican a las empresas más pequeñas. Ahí si que cabría preguntarse si puede haber una solución que beneficie a todos.

Y quizás la haya…¿sería viable colaborar para el desarrollo de un portal para crowdfunding OpenERP? Algo tipo www.goteo.org pero exclusivo para OpenERP, donde un distribuidor, a petición de un cliente publicara unos requerimientos, y exisitiera la posiblidad de que las demás empresas colaboraran económicamente a dicho proyecto (a través de sus clientes interesados, claro). Creo que estableciendo unas normas claras (1 proyecto = 1 desarrollador, para no crear conflictos), un precio mínimo individual establecido y generado por la división automática del total proyecto entre todos los “pujantes” y sobretodo, liberación automática de todo lo realizado e inclusión en la localización española, podría ser muy bueno para todos. Atraer y generar negocio del que se beneficien todos. Evidentemente habría muchos cabos que atar, el primero de ellos la financiación, crowdfunding o patrocinio del mismo portal, dado que debería ser comunitario y sin ánimo de lucro, pero creo que puede ser viable, aunque sólo participemos una parte de los distribuidores. Para facilitar la salida de desarrollos sencillos e incluso a largo plazo tratar de abarcar cosas más complejas (¿generación de nóminas y laboral? ¿Por qué no, si 100 asesorías “participan” con 50 euros mensuales?).

Otra ventaja es que permanecería el histórico de todo lo realizado, con los análisis y la documentación, para facilitar el conocimiento de todo lo desarrollado (clientes potenciales y otros distribuidores).


capturas_openerp

Un goteo.org para OpenERP ¿buena iniciativa o pésima idea? Dependerá de la comunidad…

En fin, que quizás después de todo lo dicho ya esté pensando de más, pero la necesidad está ahí… Sólo hay que saber canalizarla. En Domatix nos ofrecemos a poner en marcha la iniciativa o colaborar si encontramos el apoyo suficiente. Y si llegamos tarde para la iniciativa, siempre es algo que podemos volver a plantear en las próximas jornadas. Tenemos todo un año para ordenar ideas, y salvo que haya algún impedimento, los ojos están puestos en Valencia para ser el próximo candidato 🙂

Conforme se vayan definiendo un poco mejor las ideas y si vamos recibiendo feedback, iremos actualizando nuestras sensaciones en este blog, a través de twitter, o mediante correos electrónicos, bien a la localización o entre los interesados.

Nuevamente, gracias a todos los que han patrocinado, acudido y charlado en las Jornadas, y espero que nos volvamos a ver el próximo año. Perdón por el tocho y gracias por la lectura.

Avance de OpenERP 6.2

Una de las novedades presentadas en la versión 6.1 fue la vista tipo Kanban. Kanban, cuyo significado viene de las palabras del japonés “kan” significa visual y “ban”, que significa tarjeta, es una forma visual de mostrar información utilizada en sistemas de gestión ágiles. La intención de OpenERP s.a para sus próximas versiones, desde OpenERP 6.2 y para la 7, es utilizar este tipo de vista para visualizar todos los documentos de OpenERP.

Por ejemplo para las ventas se pueden ver en un tablero en que cada venta es una tarjeta, y dependiendo de la columna en la que esté la venta se encontrará en un estado del proceso o en otro.

gestion de calidad

Para la versión 6.2 se ha realizado una revisión del diseño, se ha limpiado la interfaz, haciéndola mas simple pero manteniendo la funcionalidad. En la siguiente captura de la vista del listado se puede ver en la parte superior que se han sustituido los campos del buscador por un único campo en el que añadir todos los parámetros de búsqueda.

gestion de calidad

Respecto a la usabilidad, se está trabajando en mejorar y simplificar la interfaz para el usuario final, para que en todo momento sepa lo que tiene que hacer de manera clara y sencilla. Por ejemplo, al visualizar un listado vacío, aparecerá un mensaje que mostrará las indicaciones para crear nuevos documentos.

gestion de calidad

Para hacer OpenERP más social se está trabajando en crear un “muro” tipo Facebook, en el que se mostrarán las acciones realizadas y peticiones de los usuarios, además de permitir la comunicación entre ellos de manera muy fácil y sencilla. En la siguiente captura se puede ver entre otros mensajes, una petición de vacaciones que será posible validar o rechazar desde el mismo “muro”, un mensaje indicando que se ha creado un nuevo usuario, y un mensaje de una venta realizada.

gestion de calidad

Estos mensajes podrán crearse en la página de cualquier documento. En la siguiente captura se puede ver una venta, que tiene dos seguidores, y en los mensajes se pueden ver las acciones realizadas en esa venta y la comunicación realizada sobre el mismo.

gestion de calidad

Dichos desarrollos actualmente se encuentran en fase de beta, y no serán estables hasta el lanzamiento de la versión 6.2 de OpenERP.

¿Que es Tryton?

OpenERP es lo que se denomina un Commercial Open Source Project (Proyecto de Código Abierto Comercial), esto es, un desarrollo de código es abierto y libre (GPL). Cualquiera puede usarlo, redistribuirlo y colaborar en su desarrollo sin restricciones, pero la empresa OpenERP S.A. es la encargada de decidir que mejoras se incluyen en el proyecto y cuales no. Esta restricción hace que empresas que colaboran con el proyecto hayan desarrollado mejoras que finalmente por criterios de OpenERP S.A. no queden incluidas en OpenERP. Así, Tryton aparece como una alternativa 100% comunitaria, donde las elecciones se toman según las aportaciones que se realizan al proyecto, como una meritocracia, y en la que el proyecto es gestionado por la comunidad de desarrolladores. De hecho se esta creando una fundación para gestionar el software y con el principal objetivo de mantener el proyecto abierto y que no dependa de una sola empresa.


capturas_openerp

OpenObject es un framework excelente, es decir el núcleo de la aplicación es muy bueno, entonces ¿Por qué hacer un fork de un proyecto que ya es bueno? Además de la necesidad de mantener el proyecto 100% libre y una toma de decisiones comunitaria, como se hace en otros desarrollos libres, gran parte del cambio viene por la decisión de los programadores de Tryton de reescribir los módulos base haciendo uso de nuevas funcionalidades. OpenERP ha crecido mucho en estos últimos años en cuanto funcionalidad, pero ha mantenido muchos de los módulos básicos casi inalterables.

Tryton es un proyecto muy activo, con una comunidad muy fuerte detrás, y una excelente base para el desarrollo de un ERP, o desarrollos a medida, pero todavía tiene mucho camino por delante, y no es una solución final tan madura como OpenERP ni cuenta con la misma cantidad de módulos disponibles. Igualmente, de momento al menos, es un producto más orientado a desarrolladores que a consultores, por lo que la mayor parte de la documentación disponible es técnica, no funcional.

Actualmente Tryton se encuentra en su versión 2.2 y cuenta con los siguientes módulos base:  Contabilidad, Facturación, Administración de Ventas, Administración de Compras, Contabilidad Analítica y Administración de Inventario.

Web oficial: http://www.tryton.org/es/

Multidivisa en OpenERP

Configuración de monedas

La configuración de monedas se encuentra en Contabilidad/Configuración/Varios/Monedas


capturas_openerp

En el listado de monedas aparecen las monedas disponibles en cada compañía, en este ejemplo se han borrado las monedas que no se van a utilizar y se ha quitado la información de la compañía para que las tasas de cambio estén para todas las compañías.


capturas_openerp

En el formulario de cada moneda esta disponible un listado con las diferentes tasas de cambio en cada fecha.
capturas_openerp

Por comodidad lo ideal es desactivar las monedas que no se utilicen. Al crear la base de datos de OpenERP creará todas las monedas disponibles y las asociará a la primera compañía creada.

Trabajando en multicompañía habrá que crear las monedas para cada compañía y comprobar las reglas de acceso para que desde cada compañía solo se tenga acceso a las monedas asociadas a si misma. O no asociar la moneda a ninguna compañía para que estén disponibles para todas las compañías.

Para cada compañía en el formulario de compañías en el menú Administración/Compañías/Compañías se indicará la moneda principal de la compañía.


capturas_openerp

Actualización de tasas de cambio

Para actualizar las tasas de cambio se puede hacer manual o automáticamente obteniendo los datos de internet. Para hacerlo automáticamente se tendrá que instalar el módulo currency_rate_update y configurar el actualizador de divisas para cada compañía.

En el formulario de compañías después de instalar el módulo  currency_rate_update habrá una nueva solapa en la que se podrá configurar la actualización de cambios de divisas.
capturas_openerp

En cada linea de “Currency updates services” se podrá indicar el servicio del que obtener el cambio de divisas y para que monedas.


capturas_openerp

Con esto el sistema estará configurado para actualizar los cambios de divisas. Clickando el botón “Refresh Currencies” se actualizarán las tasas de cambio en este momento.

Configuración de tarifas multidivisas

Para trabajar con multidivisa desde el pedido habrá que crear una tarifa para cada moneda.


capturas_openerp
La forma mas sencilla es crear primero la tarifa para la moneda principal con las reglas necesarias y para cada moneda crear una tarifa con una única regla que indique que el precio lo tomamos de la tarifa principal, esto hará que las tarifas del resto de monedas serán dinámicas cogiendo el cambio disponible en cada fecha, pudiendo indicar un incremento como tanto por ciento o fijo.

En este ejemplo se muestra la regla por defecto para la tarifa en $ usando como base la tarifa en €
capturas_openerp
También, si en una regla de tarifa de una una tarifa con una moneda distinta de la principal de la compañía indicamos que el precio de tarifa depende del precio de compra o de venta del producto el precio de tarifa también será dinámico y dependerá del cambio de la moneda.

Un desarrollo interesante sería hacer multidivisa los precios de compra y venta de la ficha del producto así en las reglas de tarifas se podría escoger por ejemplo entre el precio de venta en la moneda principal de la compañía y el precio de venta de la moneda de la tarifa. Con esto se conseguiría hacer tarifas independientes para cada moneda, esto por el momento se puede solventar sin desarrollo haciendo una tarifa indicando un precio fijo para cada producto.

Pedidos y Facturas

En el momento de crear un pedido si se indica que use una tarifa con una moneda distinta de la moneda principal de la compañía se trabajará con es moneda exactamente igual que con la principal, todo el trabajo de cambio de divisas lo está haciendo por debajo el sistema de tarifas para recuperar el precio que corresponda.
capturas_openerp

En la captura del ejemplo el producto tenía un precio de venta de 1 euro, al usar la tarifa en dolares usará la tarifa de cambio para recuperar el precio de venta en dolares.

Al crear una factura a partir de un pedido, la factura se creará en la moneda de la tarifa del pedido. También se puede crear la factura directamente en la moneda que nos interese y si es necesario realizar luego el cambio de moneda.
capturas_openerp

Con el botón de cambio de divisa permitirá cambiar la divisa de la factura usando el cambio asociado en la fecha actual.


capturas_openerp
Después de indicar la nueva moneda y clickar el botón de cambio de moneda actualizará los importes.
capturas_openerp

Pago de facturas

Al realizar el pago de la factura y seleccionar el modo de pago aparecerán los vencimientos en la moneda principal de la compañía con la tasa de cambio del momento en el que se validó la factura. Si al realizar el pago el importe pagado es distinto del importe del vencimiento por diferencias en las tasas de cambio, habrá que conciliar el pago con un desajuste, indicando que el desajuste irá contra la cuenta contable correspondiente (Diferencias positivas de cambio).
capturas_openerp

Nuevo proceso de instalación de localización española de OpenERP

  • La instalación se hace como la instalación estandar de otro módulo, ya no habrá que cancelar la instalación de la contabilidad a medio.
  • Instalación del plan contable y creación de periodos y diarios en multicompañía.
  • La configuración del ejercicio antes era estática comenzando el día 1 de enero y terminando el 31 de diciembre, ahora se puede configurar el inicio y fin para casos especificos como en educación que comienzan ejercicio en septiembre.
  • La configuración de los periodos antes era estatico por trimestres, ahora se puede utilizar periodos mensuales.
  • Posibilidad de crear o no periodos de apertura y cierre.

La instalación de la localización española ahora es tan sencillo como instalar el módulo l10n_es_account_pyme y ejecutar el asistente de configuración.

Al configurar la contabilidad y seleccionar el plan de cuentas español se podrá seleccionar para que compañía realizar la instalación, las fechas de inicio y fin del periodo, la duración de los periodos (mensuales o trimestrales) y si se desea crear los periodos de apertura, cierre y para Perdidas y Ganancias.


capturas_openerp

En el siguiente paso igual que antes se podrá seleccionar el número de dígitos para las cuentas y los diarios a crear.

Una vez terminado el asistente se podrá abrir el ejercicio creado y comprobar que se han creado los periodos de Apertura, Cierre y PG


capturas_openerp

Si por cualquier motivo no se marca en la instalación también se podrán crear estos periodos en un ejercicio que no los tenga con el botón que se muestra a continuación


capturas_openerp

TRCRM – Aplicación de Android como Cliente CRM OpenERP

Dado que el producto todavía está en desarrollo, y lamentablemente aún no está en castellano, Tech Receptive hace un llamamiento a la comunidad para solicitar feedback en su correo android@techreceptives.com.

El objetivo a largo plazo es completar el ciclo de ventas desde la aplicación, almacenando todas las actividades de “leads” y oportunidades, guardar y sincronizar datos con la agenda de contacto, reuniones, tareas pendientes, llamadas, emails y creando presupuestos al vuelo.

Confiamos poder ver en breve los avances de este programa, y agradecemos al equipo de Tech Receptive sus esfuerzos por unir lo mejor de ambas plataformas, potenciando más el uso y la facilidad de OpenERP como CRM.

Más info y enlace a la aplicación en AndroidPIT.