OpenERP cambia su nombre a Odoo

OpenERP se convierte Odoo.

Aunque se venía gestando desde hacía algún tiempo, ayer saltó noticia oficialmente, OpenERP cambia de nombre a Odoo.

En primera instancia para los partners oficiales de OpenERP / Odoo, y seguidamente se propagó rápidamente por las redes sociales.A fecha de hoy el cambio ya es real,  y apenas queda rastro de OpenERP en su web oficial. El motivo del cambio […]

Para mantenerte informado sobre los nuevos cambios puedes visitar nuestra web haciendo click en el siguiente enlace.

Leer más

Jornadas OpenERP 26 Y 27 de Junio de 2014

1. Cambio de nombre odoo
2. Odoo más comunitario
3. Proyectos ocb y oca
4. Posibilidades del cliente web odoo y sus apps
5. Sepa en odoo

Leer más

Instalación y configuración SEPA OpenERP

En el siguiente documento vamos a mostrar los pasos a seguir para la instalación y configuración de SEPA OpenERP de manera sencilla y rápida.

Instalación SEPA

El primer paso para iniciar la instalación de SEPA es la elección del módulo de SEPA de OpenERP que queremos utilizar. Actualmente existen las versiones 6.0, 6.1 o 7.0, que las podemos encontrar en la página de SEPA Tools for OpenERP. En esta ocasión, nosotros vamos a tomar como referencia la versión 6.1. Para empezar, al ejecutar el comando “bzr branch lp:sepa-tools/6.1 sepa-tools” nos creará una carpeta de nombre “sepa-tools” en el directorio de ejecución. En esta carpeta aparecerán todos los módulo de SEPA detallados.

Una vez tenemos el repositorio descargado, añadiremos al parámetro “addons_path” del servidor una ruta para que cuando tengamos listo el OpenERP nos la reconozca. A continuación, lo ponemos en marcha y nos vamos al menú “/Configuración/Módulos/Actualizar lista de módulos”. Este asistente se encargará de refrescar nuestro listado de módulo para que cuando termine se abra automáticamente. Si no se hiciera de esta manera, habría que ir a “/Configuración/Módulos/Módulos” para verlos.

Si filtramos el campo nombre con valor SEPA, nos aparecerán 2 módulos: “account_payment_sepra_credit_transfer” y “account_payment_sepa_direct_debit”, para remesas de pago y remesas de cobro respectivamente. Ambos pueden ser instalados o sólo el que nos interese, en nuestro caso vamos a instalar ambos, para poder explicarlos más tarde.

Configuración General SEPA

Lo primero a configurar es el identificador SEPA de nuestra empresa, que con ayuda del siguiente post: Mandatos SEPA  calcularemos este número. Usando el CIF de Pexego, B-27323906 y operando según el enlace, obtenemos que nuestro identificador es: ES50000B27323906.

Este nº de identificador lo escribimos en la ficha de la compañía, en /Configuración/Compañías/Compañías y en el formulario de nuestra compañías, en la pestaña Configuración, en los campos “Identificador SEPA del acreedor” e “Initiating Party Issuer”.

Las cuentas bancarias de nuestros clientes y proveedores también deben configurarse como IBAN, con el número de cuenta en formato IBAN. También deberemos asegurarnos de que el …read more

También puedes ver otras funcionalidades de OpenERP en nuestra web.

Leer más

VIII Aniversario de las jornadas OpenERP Madrid

ha llegado el mometno de celebrar la VIII Jornada OpenERP y este año se celebraran en Madrid. A continuación el correo de Carlos Liébana de Factor Libre en el que se cierran ya las fechas del evento del año de OpenERP – Odoo.

este año se desarrollara durante los días 15 y 16 de Junio y coorganizado por Pedro M. Baeza.

A continuación, el correo completo:

Horario

Objetivo

Localización

Aportaciones de los participantes

Leer más

Modo desarrollador del cliente web 6.1 de OpenERP

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.

 

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

 

Leer el artículo completo: http://www.domatix.com/modo-desarrollador-del-cliente-web-61-de-openerp

Para más información sobre OpenERP haz click aquí.

Leer más

Novedades OpenERP para la versión 6.2: Community & Partner Days.

A continuación, hablaremos sobre las novedades OpenERP 6.2

Leer más

OpenERP Transportes

La operativa básica de OpenERP Transportes se lleva a cabo, mediante el ingreso de los datos correspondientes a las partidas que contiene toda la información de un transporte solicitado por un Cliente y la asignación de las mismas a los expedientes.

Estos expedientes son el lugar donde se registra la información de cada transporte realizado por la Empresa.

Para la aplicación de las tarifas correspondientes existe un módulo que permite definir tarifas para ventas, costes y conductores según zonas (también definibles) de origen y destino y propiedades de la mercancía transportada.

Una vez confirmada la realización del servicio, el sistema permite la facturación automática de los mismos.

Funcionalidades:

Para comprender el alcance de las diferentes funcionalidades instrumentadas describimos algunos de principales elementos desarrollados:

• Zonas: son un grupo de localidades a las cuales interesa referirse en forma conjunta fundamentalmente para definir condiciones de Tarifas.
• Definición de Tarifas: El sub-módulo para la definición de tarifas es muy amplio y completo; y está dividido tres partes: Ventas, Costes y Conductores.
• Ventas: definición de tarifas a aplicar a un grupo de clientes, para las mismas es posible especificar:

• Fechas de vigencia (general o por Cliente que integra el grupo)
• Condiciones de aplicación según: factores de conversión de metros cúbicos y metros lineales, tipo de servicio, tipo de tráfico, incoterm y zonas de origen y destino del transporte.
• Escalado de valores de la tarifa según peso, volumen o metros lineales de la mercancía transportada o distancia que implica el transporte

• Costes: iguales características que Ventas pero aplicado a proveedores, útil para empresas de transporte que suelan subcontratar a otras empresas y posean un conjunto de tarifas ya definidos por las mismas.
• Conductores: similares características que Ventas pero destinado a definir las tarifas correspondientes a los conductores que  participen del Transporte  (Dieta, Complementos de productividad, etc.)

Las tarifas definidas generan “conceptos facturables” que en esencia son productos del tipo servicio y determinan la perfecta integración con los demás módulos de OpenERP relacionados a esta operativa como por ejemplo gestión de ventas, gestión de compras y gestión financiera.

Transporte:

La información relativa al transporte se registra por una parte; en Partidas (transporte para un cliente de un conjunto de mercancías desde un origen a un destino en un determinado momento).

Y por otra parte, en expedientes (documento que  registra la información relativa al viaje entre dos localidades realizado por un vehículo de la empresa o una subcontratada para atender los transportes que determinan una o varias partidas)

Partidas:

Éste elemento permite visualizar un importante conjunto de información que se presenta en dos formatos:

Grupaje y contenedor (según el transporte se realice en un camión con lona o en contenedor, respectivamente).

Como información básica podemos señalar: cliente, tipo de servicio, tipo de tráfico, incoterm, origen, destino, fechas programadas y reales de recogida y entrega, distancia y detalle de la mercancía a transportar así como sus propiedades (peso, volumen, metros lineales, etc.)

En base a la información precedente es posible aplicar en forma automática o manual las tarifas que correspondan, visualizándose en las solapas respectivas la información de facturación al cliente y gastos producidas.

Expedientes:

Éste elemento además de vincular las partidas relacionadas a un viaje permite visualizar en forma conjunta todos sus componentes: Datos específicos del viaje  de acuerdo a las partidas que lo componen e información relativa a gastos, conductores y vehículos.  Es un resumen donde se agrupan una o varias partidas.

Además,  indicando la suma de los ingresos y gastos relativos a las distintas partidas, además de los propios del expediente.

Gestión de calidad:

Mediante la extensión del módulo CRM de OpenERP se ha instrumentado la Gestión de Calidad para el seguimiento de incidencias.

Provee una forma ágil de vincular diferentes documentos de la aplicación, registrar información de sucesos, agenda de gestiones, valoraciones de peritación, centralizar información de contactos, responsables, etc. para un seguimiento de casos eficiente.

La funcionalidad implementa algunas mejoras a la gestión de documentos externos para cada caso particular.

En definitiva, permite la gestión de incidencias, tanto internas como en los casos en que haya que dar parte al seguro, para el seguimiento del mismo y los documentos asociados a él.

Acceso Web:

Para permitir el seguimiento por parte del Cliente se ha previsto lo siguiente:

La información necesaria de los clientes que permita el su acceso mediante una interfaz WEB, así como la presentación de la información pertinente.

OpenERP transportes es una solución vertical desarrollada por Domatix que actualmente se encuentra en proceso de migración a la versión 6.1.

Más información y contacto.

También puede encontrar más información sobre el tema del artículo en: https://openerpspain.com/

Leer más

Como realizar el análisis inicial para implantar un ERP

A lo largo de este artículo, vamos a ver los principales puntos que deberíamos de tener en cuenta a la hora de implantar un ERP.

Cada punto mencionado debería ser ilustrado en detalle para ofrecer una visión global pero a la vez clara y resumida de los principales procesos de negocio de la empresa.

En primer lugar, se recomienda que toda empresa que vaya a implantar un ERP, realice un análisis inicial, previamente a la selección de la empresa consultora o propietaria del software que realizará la implantación.

Si se le entregan los requerimientos de la empresa detallados, el presupuesto estará mejor detallado, se podrá realizar un plan de proyecto mucho más ajustado a la realidad y posiblemente se evitarán a posteriori sorpresas desagradables.

Con todo esto, vamos a pensar en un análisis inicial que cubra únicamente las áreas básicas de la empresa (compras, ventas – Marketing y CRM -, logística, tesorería, Recursos humanos )

Como mínimo, un análisis inicial debe contener los siguientes aspectos:

Análisis de datos maestros necesarios para implantar un ERP:

Los datos maestros de un ERP, son aquellos datos críticos y necesarios para poder empezar a operar con la herramienta. En función de cómo se configuren estos datos maestros, la herramienta permitirá realizar ciertas acciones o no, o su comportamiento será distinto en algunos aspectos.

Ejemplos:

• Si en ficha maestra de un cliente le asignamos una forma de pago transferencia bancaria, evidentemente el sistema no generará ningún recibo, por tanto, en la ficha maestra definimos la forma de cobrar a este Cliente.
• En el supuesto de que en la ficha, definimos que un proveedor nos exige un pago los días 10 de cada mes, cuando nosotros habitualmente pagamos los días 5 y 20, deberá quedar reflejado en la ficha del proveedor, y parametrizar la herramienta para que contemple esta situación.
• En el caso que, se requiera realizar un pedido a un proveedor, en las fichas maestras o maestros, debe estar registrado el proveedor, el artículo que le queremos comprar, el precio de dicho artículo con las condiciones de tarifa del proveedor….

Datos maestros:

Existen una serie de datos que si previamente, o en el momento de necesitarlos no se registran, no se puede trabajar con el sistema. Estos datos serían los maestros.

Es por ello, por lo que, la acción de configurar estos maestros, sería la más complicada de la fase de implantación. Si no se hace correctamente, será imposible que el comportamiento del programa sea el esperado.

A continuación, se detalla una lista qué datos maestros son imprescindibles analizar en una empresa estándar de tamaño medio. Son necesarios todos, pero puede haber más. Es necesario destacar que cada sector de negocio tendrá sus propios datos maestros y de aquí surge a veces la necesidad de crear módulos adicionales para el ERP que configuran una solución Vertical para dicho sector.

La tabla adjunta pretende al menos nombrar aquellos maestros existentes en todas las empresas de los sectores de industria y servicios.

Para cada uno de ellos, en el análisis inicial se reflejará cómo es actualmente y qué se espera que se pueda registrar y centralizar en el ERP a futuro. Se incluirá cualquier dato que se considere relevante.

Datos relevantes:

1. Mi empresa
2. Catálogo de productos
3. Almacenes
4. Clientes
5. Proveedores
6. Tarifas de Venta
7. Tarifas de compra
8. Formas de pago

Mi empresa (todos los módulos)

En este apartado se incluyen datos relevantes de mi empresa.

• Estructura departamental.
• Sedes y ubicaciones
• Volumetría de empleados
• Días de pago a proveedores
• Días de pago de nóminas…
• Otros

Empleados (todas las áreas)

Un empleado puede ser un agente de ventas, un administrativo, un operario de máquina en fabricación, jefes de proyecto…

El concepto empleado es utilizado por casi todos los módulos del ERP donde sea necesario especificar quien hace qué. Operarios de fabricación, agentes de venta, técnicos de soporte en CRM, administrativos…

• Datos de empleados
• Calendarios
• Horarios
• Turnos
• Grupos
• Categorización
• Nivel
• Vacaciones
• Skills
• Edad media de los empleados
• Ubicación física en la empresa.
• Política salarial de la empresa: Configuración de Rangos salariales, primas, extras (solo requerido en el módulo de nóminas)

Esta parte del análisis es primordial ya que permitirá entre otras cosas:

• Dimensionar el número de puestos que será necesario habilitar para trabajar con la nueva herramienta
• Orientar sobre la formación previa en informática de los futuros usuarios y su edad lo que permitirá dimensionar y planificar las jornadas de formación.
• Obtener una visión general de la estructura de permisos y usuarios de la aplicación.

Catálogo de productos (logística, materiales, compras, ventas…)

En este apartado, especificaremos cómo es nuestro catálogo. Algo aparentemente trivial, puede ser el escollo más importante a salvar en una implantación. Existen infinidad de formas de registrar y categorizar los productos de una empresa. Es necesario definir al menos los siguientes aspectos:

Aspectos a tener en cuenta:

• Tipología de artículos
  • Qué es lo que se compra
  • Qué se vende
  • Fabricación de mi empresa
• Categorías de artículos
• Volumen de artículos codificados.
• El código del artículo. Referencias:
  • Como identifico mi artículo como único. Hay categorizar el que se vende, el que se compra y el que se transforma.
  • El código será secuencial, da información de forma inteligente, utilizando bloques de cifras para indicar algo dentro de dicho código…
• Datos adicionales del artículo. Como varían en función de la tipología y de las categorías.
• Unidades de medida en las que se compra, vende y almacena el artículo.
• Serialización y números de lote de los artículos. Qué tipologías y categorías de artículos es necesario que lleven números de lote o serial. Quién genera dicho número de lote y cómo se genera.
• Atributos o variantes del artículo (Color, talla, medidas…etc, etc). Categorización y tipología de los artículos en los que varía el precio de venta o compra en función de los atributos.
• Indicar si requieren imágenes o no. Cuantas. La imagen se registra a nivel de producto o a nivel de variante.
• Señalar si requieren registro de documentos adjuntos. Cuantos. Cuales. Qué formatos.

En el análisis del catálogo se incluirá cualquier aspecto que se considere de interés o inherente al sector que pudiese causar conflicto en su configuración en el ERP.

Almacenes (logística)

Cuantos hay y donde están. Información y características relevantes de cada almacén

Clientes (ventas, CRM)

Aquí se incluyen datos relevantes que desee registrar de Clientes.

• Volumetría
• Codificación de Clientes
• Datos generales
• Categorización de Clientes
• Contactos de Clientes
• Estructura de empresa de mis Clientes
• Datos asociados a esta estructura
• Sedes de Clientes.
• Direcciones y tipología de dirección (sede, almacén, oficina administración… etc)
• Formas de pago
• Bancos
• Etc…

Canales de venta

• Agentes comerciales
• Tiendas físicas
• Comercio On-Line

Proveedores (compras)

Aquí se incluyen datos relevantes que desee registrar de mis Proveedores

• Volumetría
• Codificación de Proveedores
• Datos generales
• Categorización de Clientes
• Contactos de Proveedor
• Estructura de empresa de mis Proveedores
• Datos asociados a esta estructura
• Sedes de Proveedor.
• Direcciones y tipología de dirección (sede, almacén, oficina administración… etc)
• Formas de pago
• Bancos
• Etc…

Tarifas de venta (ventas)

Las tarifas de venta son un aspecto fundamental en la configuración del ERP. Pueden ser dinámicamente calculadas en función de otros campos (la más sencilla: tarifa de compra + %margen), o asignadas para cada uno de los artículos.

En el análisis es necesario reflejar como se realiza en la actualidad esta asignación de tarifas venta a los productos a fin de evaluar la complejidad de su configuración.

Teniendo en cuenta la categorización y tipificación de los productos de venta:

• Mostrar cómo se calcula la tarifa
• Indicar si se existen o no descuentos por volumen
• Señalar cómo se configuran las ofertas
• Indicar si existen packs de productos en oferta
• Denotar cualquier aspecto relevante referente a las tarifas de venta.

Tarifas de compra (compras)

• Mostrar cómo se reciben las tarifas de proveedor
• Indicar cómo se registran las tarifas de proveedor
• Señalar si se existen o no descuentos por volumen
• Indicar cómo se configuran las ofertas
• Denotar si se recepcionan packs de productos en oferta
• Indicar cualquier aspecto relevante referente a las tarifas de compra.

Formas de pago (tesorería)

• Indicar formas de pago que se utilizan habitualmente en cualquier área de gestión de la empresa (transferencia, cheque, giro, pagaré, tarjeta de crédito, facturing, confirming, etc.)

Formas de envío y transporte (logística). Tarifas.

• Indicar formas de envío que se utilizan habitualmente (Camión propio, Camión de Cliente, Camión de Proveedor, Agencia de transporte, Agencia de mensajería…)

Señalar qué forma de envío es utilizada en función de qué condiciones. Y sobre todo, marcar las excepciones.

Ejemplos:

• Un proveedor envía la mercancía en su camión y cobra los portes. Habitualmente el resto de proveedores, envían una agencia de mensajería, también a portes pagados.
• En cuanto a envíos de mercancía a Clientes, la empresa utiliza una furgoneta de reparto para servir los pedidos locales, para la península se utiliza una agencia de transporte.
• A clientes con pedidos superiores a una cantidad, se les envía la mercancía con un 20% de descuento en la tarifa habitual.

Embalajes, volumen y peso (logística).

Es necesario que quede bien definida la información requerida para los embalajes:

• Tipificación de embalajes
• Códigos de embalaje
• Asociación de embalajes a artículos, a volúmenes, a pesos…

Es decir, cualquier información relevante a embalajes.

Ejemplo:  Se envía mercancía en contenedores. La agencia de transporte cobra por contenedor con un límite de peso, independientemente del número de bultos que incluyen. Se requiere registrar tamaños y volúmenes de embalajes, materiales que la componen, relación de artículos con embalajes.

Contabilidad

A la hora de implantarlo, es imprescindible en el área de contabilidad, si el plan contable no está definido correctamente no será posible llevar las finanzas con el ERP.

• Definición de la estructura del plan contable.
• Ejercicios, períodos (mensuales, trimestrales)
• Definiciones de impuestos (IVA, recargo de equivalencia, retenciones IRPF
• Plazos de pago
• Remesas de recibos (CSB19, CSB58), órdenes de pago o transferencia (CSB34)
• Importación de extractos bancarios (CSB43)
• Liquidaciones

Es por ello, que una vez definidos estos aspectos se podría hablar de que ya hemos creado una visión general de los datos maestros de la empresa en las áreas mencionadas y se podrían comenzar a definir los procesos operativos.

Procesos de negocio de la empresa (workflow de procesos):

También, en este apartado se incluyen en la medida de lo posible los procesos actuales de la empresa. Es necesario al menos indicar 2 niveles de procesos:

Nivel 1: Procesos interdepartamentales:

A continuación veremos los procesos interdepartamentales.

• Cuales son las áreas/dptos en los que se divide la empresa
• Cómo interactúan entre ellas:
  • Flujos de documentos
  • Procesos de aceptación, validación, asignación de tareas…
  • Herramientas utilizadas

Ejemplo muy simplificado de un proceso interdepartamental

• Cliente realiza pedido de venta (Att Cliente)
• Se verifica si existe stock del producto en almacén (Logística)
  • Si existe, se sirve al Cliente. (Logística)
  • Si no existe y el producto es de distribución
    • Se realiza pedido de compra a proveedor. (Compras)
    • Recepción del material (Logística)
    • Verificación su calidad (Calidad)
      • Si pasa el control, se incluye en almacén (Logística)
      • Si no pasa el control
        • Se devuelve al proveedor (Logística).
        • Compras gestiona la devolución (Compras)
        • Att Cliente indica el retraso en la entrega al Cliente y facilita nueva fecha de entrega (Att Cliente)
  • Si no existe y el producto es de fabricación, se fabrica (fabricación)
    • Se verifica su calidad (Calidad)
      • Si pasa el control, se incluye en almacén (Logística)
      • Si no pasa el control ….
    • Se almacena y se sirve al Cliente. (logística)

En este ejemplo, se puede comprobar que intervienen distintos departamentos desde que se recibe el pedido del Cliente hasta que es posible entregarlo.

Entonces, actualmente ¿Cómo se gestiona esta comunicación interdepartamental?

• Modo de registro de los pedidos
• Como se comunica att cliente con compras para indicarle que tiene que hacer un pedido
• Conocimiento por parte de  fabricación sobre que tiene que fabricar un producto y cómo lo tiene que fabricar. Como sabe fábrica a qué fecha debe tener fabricado el producto.
• Como conoce ventas las incidencias que ha habido desde que el Cliente hizo el pedido y como sabe que tiene que avisarle de un retraso en la entrega…

En fin, cuanto más se detalle este proceso interdepartamental más sencillo resultará configurar los flujos de información correctos en el ERP.

Nivel 2: Procesos intradepartamentales (Dentro de un mismo área/dpto)

Así mismo, es necesario realizar el mismo ejercicio, pero dentro de un mismo área/dpto.

Por cada área/dpto se indicará:

• Cómo se trabaja
• Quien hace qué
• Cómo lo hace
• Qué herramientas usa actualmente

En el mismo ejemplo utilizado anteriormente, se pueden dar infinitas combinaciones de formas de trabajar.

Pongamos un ejemplo irreal pero posible de una empresa ficticia:

• Att Cliente recibe un pedido de venta:
  • Existen 3 canales de entrada de pedidos de venta:
    • Teléfono, Fax
    • E-mail
    • Tienda On-Line
  • Hay un agente de ventas asignado a cada canal.
  • Cada agente recepciona únicamente los pedidos que entran desde dicho canal.
  • Al recepcionar un pedido, se registra en una hoja de cálculo o en una base de datos.
  • Posteriormente se envían por correo electrónico al almacén para que verifiquen in situ si hay stock o no. Los agentes del canal de fax, teléfono y tienda on-line registran el pedido en el la base de datos y además lo copian en cliente de correo para enviar un correo a almacén.
  • A veces, los clientes que realizan el pedido por teléfono también envían un correo electrónico, por si acaso.
  • El agente que atiende el canal de correo electrónico, no sabe que el del teléfono ya ha registrado el pedido en el access por lo que se registra el mismo pedido 2 veces por 2 personas distintas, con distinto número.
  • Almacén recibe 2 correos solicitando la misma cantidad de producto para el mismo Cliente pero por el volumen diario de pedidos, no identifica que se trata del mismo pedido duplicado.

Concluisones del ejemplo:

Como se puede comprobar, ya en el primer punto de nuestro proceso interdepartamental, ya se han detectado que existen puntos de mejora que ahorrarían tiempo, errores y en definitiva costes.

• En Att Cliente, registran el pedido 2 veces. Una en la base de datos local y otra para enviarlo por correo a almacén.
• No existe comunicación entre los distintos agentes del dpto. No conocen si otro agente ya ha tratado el pedido.

A partir de este punto, donde el error ya se ha producido, y continuando con el ejemplo, este Cliente podría acabar recibiendo 2 pedidos iguales, pero con una diferencia importante de tiempo.

Podría ocurrir que en almacén recepcionan el primer pedido, tienen stock y lo sirven, pero cuando llega el segundo, ya no hay stock y pasan aviso a compras para que emita el pedido a proveedor.

O incluso peor, tienen que pasar a fábrica el aviso para que se fabrique…

Se fabricará algo innecesario que ya fue entregado. El Cliente recibirá un pedido que no solicitó. Se producirá una devolución… y todo se complicará todo lo que pueda complicarse causando pérdidas de tiempo y económicas a la empresa.

Ahora el mismo ejemplo con el ERP:

• Att Cliente recibe un pedido de venta:
  • Existen 3 canales de entrada de pedidos de venta:
    • Teléfono, Fax
    • E-mail
    • Tienda On-Line
  • Hay un agente de ventas asignado a cada canal.
  • Cada agente recepciona únicamente los pedidos que entran desde dicho canal.
  • Al recepcionar un pedido, se registra en el ERP.
  • En el análisis inicial, se verificó que se producían errores de duplicación de pedidos de clientes por lo que se incluyó un control, donde al registrar un segundo pedido del mismo cliente y el mismo artículo en las mismas cantidades, el mismo día, advirtiera al agente que dicho pedido ya existe en el sistema.
  • El agente verificará si es el mismo pedido o realmente el Cliente solicita 2 pedidos y podrá optar por registrar o borrar el segundo pedido.
  • Se ha decidido eliminar el envío del correo a almacén. En su lugar, se ha establecido que almacén tendrá acceso a consultar los pedidos de venta pendientes registrados en el ERP.

Han sido eliminados varios pasos del proceso anterior. Se ha mejorado la productividad, se han eliminado tareas repetitivas y sin valor añadido.

Se ha agilizado la labor de nuestros empleados y optimizado los recursos de la empresa, lo cual finalmente se traduce en un ahorro de costes para la empresa.

Conclusiones:

En resumen, el objetivo de este apartado es detectar aquellos procesos repetitivos, poco productivos y sin valor añadido que se podrían eliminar del proceso de negocio.

A su vez, permite examinar los procesos actuales y verificar si los procesos definidos de base en el estándar del ERP podrían encajar o adaptarse a los requeridos por la empresa.

En caso de no ser así, permite identificar aquellos elementos que por ser inherentes y específicos de la empresa, no estarán en definidos de base en el estándar del ERP.

En nuestro ejemplo anterior, tras implantar un ERP, se detectó que dicho ERP cubría el proceso de base, ya que permitía registrar pedidos y enviarlos por e-mail, pero en esta empresa concreta, se requería un control adicional en el ERP para evitar registrar pedidos de venta por duplicado.

Los procesos mínimos que habrá que detallar son:

• Presupuestación de productos
• Sistema de Cálculo de costes
• Procesos de Compras
• Trascursos de Ventas
• Procesos de devolución de materiales a proveedor
• Trascurso de Calidad ( en fabricación, en recepción de materiales, en subcontratación, en atención al Cliente …)
• Procesos de recepción y expedición de materiales
• Desarrollo de fabricación
• Procesos de gestión de devoluciones de Cliente

Es por ello, por lo que este apartado puede ser sumamente sencillo o tremendamente complicado según la empresa que se esté analizando.

Informes, documentos, estadísticas

A continuación, en este apartado se indicarán los documentos requeridos en cada área de trabajo o departamento que deberán estar configurados en el ERP antes de la fecha del arranque, para que puedan ser impresos desde la herramienta. La empresa deberá definir el formato y la información que requiere mostrar en estos documentos.

Además, es habitual que todos los ERP incluyan en el estándar documentos preformateados, que pueden ser perfectamente válidos en cuanto a la información que muestran, por lo tanto bastaría con adaptar su diseño a la imagen corporativa de la empresa.

Incluso, si la exigencia en este sentido no es muy alta, ni siquiera esto será necesario. No obstante es necesario analizar los requerimientos de la empresa.

Algunos de los documentos mencionados podrían ser:

• Pedido de compra a proveedor
• Albarán de Venta
• Factura de Venta
• Certificado de calidad
• Recibos
• Orden de fabricación
• Albarán de devolución de mercancía
• Lista de embarque
• Informes contables (mensuales, trimestrales, anuales)
• Reclamación a proveedor por retraso en entrega de mercancía
• Reclamaciones de pagos a Clientes
• Informes de gestión en tesorería
• Informes estadísticos de cada área
• …

Migración de datos de sistemas actuales

Para llevar a cabo una migración de forma correcta, es imprescindible especificar con qué sistemas de gestión se cuenta actualmente y sobre todo las fuentes de datos que se utilizan.

El objetivo es analizar la calidad de estos datos y comprobar si es posible su inserción automática en el ERP bien sea parcial o totalmente.

Además, en un ERP, todos los datos deben ser consistentes. La estructura de datos está centralizada y normalizada. Por este mismo, si los datos de la empresa están distribuidos en varios soportes y sistemas, cada uno de ellos realizará sus propias codificaciones en los objetos, sus validaciones…

Organizar, unificar y normalizar todos estos datos puede ser sumamente complejo y a veces imposible.

En ocasiones, en función del volumen y calidad de los datos, es muchísimo mejor configurar y registrar estos datos manualmente en el ERP pero otras, por los mismos motivos, es imprescindible realizar una migración de datos automática desde dichas fuentes de datos al ERP.

Procesos de migración

En consecuencia, habrá que desarrollar los procesos de migración correspondientes. Estos desarrollos, son de por sí un proyecto y hay que tratar su desarrollo, como tal. En ningún caso es necesario definirlos en este documento de análisis. El objetivo de este apartado es:

• Estudiar las estructuras de datos en los que se encuentran actualmente los maestros de la empresa.
  • Ejemplo: las ventas se gestionan desde una base de datos en Acces, el listado de proveedores en una hoja de cálculo. Hay un programa a medida que gestiona el almacén.
• Examinar la calidad de los datos
• Analizar la codificación de los datos y su posibilidad de normalización.
• Examinar volumetría de los datos susceptibles de ser migrados.

Recomendaciones a la hora de migrar:

Así mismo, se recomienda NO MIGRAR datos de operativas antiguas.

Habitualmente no hay problema en migrar los datos de Maestros pero por complejidad que hay en mantener la integridad de datos y evitar incoherencias en el nuevo sistema no es recomendable migrar:

• Temas pendientes:

abiertos o en proceso (Pedidos, albaranes, facturas, casos, tiques, ordenes de fabricación….etc). Se recomienda finalizar la gestión de estos casos en el sistema antiguo. Una vez finalizados pueden quedar en dicho sistema como histórico.

• Temas cerrados:

Aunque se recomienda siempre que queden en el sistema antiguo como histórico, siempre son mucho más sencillos de llevar al nuevo sistema porque no hay que unificar los procesos del sistema antiguo con los del nuevo. A veces es imprescindible migrar (ej: casos antiguos cerrados como historial del Cliente en el CRM)

Plan de Arranque

Por otra parte, es necesario pensar en Como quiero arrancar. Como y cuando hay que dejar de trabajar con el sistema antiguo y se empezará con el nuevo. En este punto hay que indicar la fecha límite “deseada” para el arranque.

Es por ello, por lo que hay muchas formas de realizar un arranque. Un factor muy importante es si hay migración de datos, pero pueden influir muchos más.

Con migración:

• En primer lugar, se define un día donde se cierra el sistema antiguo y se empieza con el nuevo.
• En segundo lugar, es necesario extraer los datos del sistema antiguo y cargarlos en el nuevo. Este es un punto tan crucial como delicado, y en gran medida depende del volumen de datos.
• Por último, una vez realizada la migración se debería cerrar el sistema antiguo, o dejarlo sólo como histórico.

Sin migración:

• En primer lugar, poco a poco se van introduciendo los datos manualmente en el sistema.
• En segundo lugar, se van teniendo configurados los datos de maestros de cada área dicha área ya puede operar. Se puede comenzar en paralelo, realizando pruebas en un sistema y en otro y verificando la consistencia de los datos.
• Y por último, se define una fecha real de arranque donde todas las áreas de la empresa estarán trabajando con la herramienta. Los datos introducidos por los distintos departamentos, previos a esta fecha serán considerados como no consistentes o de pruebas en entorno real.

Responsables del proyecto

Así mismo, es necesario por parte de la empresa definir un jefe de proyecto.

Por último, es muy recomendable que un responsable de cada área esté implicado en todas las fases a la hora de implantar un ERP e imprescindible que lo esté en las fases de análisis inicial y en el arranque.

En resumen:

A continuación, realizaremos una valoración general. Antes de solicitar un presupuesto para un implantar un ERP, hay que intentar reflejar en un documento al menos los aspectos identificados en este artículo, pero sin dejar de incluir otros que se consideren relevantes o críticos para finalizar la implantación con éxito.

Artículo modificado. Original con licencia CC realizado por Ana Juaristi.

Para acabar, si tiene alguna duda sobre cómo implantar un ERP Puede encontrar más información relacionada con este tema en nuestra página web haciendo clic aquí.

Leer más

Multicompañía en OpenERP 6

Módulo Multicompañía – crear compañía

Lo primero que necesitamos para trabajar con OpenERP en multicompañía es añadir a nuestro usuario el grupo “Useability / Multi companies”. De esta forma podremos ver los campos referentes a la multicompañía.

Si nuestro usuario tiene asignado este grupo podremos ver el menú /Administración/Compañías, en la ventana de Compañías podremos dar de alta las compañías.

Las diferentes compañías se pueden crear en OpenERP en una estructura de jerárquica. Así, si queremos crear un grupo de empresas llamado A formado por las empresas B y C primero crearemos la compañía A y luego al crear las compañías B y C completaremos el campo compañía padre con la compañía A.

En el menú compañía árbol de compañías podemos ver esta estructura.

Módulo Multicompañía – accesos

Una vez creadas las compañías tenemos que configurar el acceso a los diferentes documentos, conociendo como funciona el control de acceso a cada compañía. Cada usuario tendrá una lista de compañías a las que se le permite el acceso, y entre esas compañías una será la compañía actual.

Si vamos al menú de usuarios podemos ver la compañía actual del usuario:

y la lista de compañías a las que tiene acceso:

De esta forma cuando un usuario se conecte a OpenERP lo hará con una compañía, y no tendrá acceso a los datos de otras compañías aunque esté en su lista de compañías autorizadas. Importante: Hay que tener cuidado de no trabajar con el usuario admin en multicompañía, ya que este usuario se salta los controles de acceso multicompañía. Así que lo mejor es cuando se cree una compañía crear un usuario administrador de esa compañía con el que hacer toda la configuración.

Ahora que tenemos claro como funciona el control de acceso podemos ver las “reglas de registro”.  Las reglas de registro se encuentran en el menú “Administración/Seguridad” y nos sirven para definir quien va a tener acceso a cada documento. Por ejemplo con reglas de registro podríamos hacer que los comerciales solo puedan ver los pedidos que han creado ellos mismos.

Esto nos va a servir en un entorno multicompañía para definir que documentos podemos ver, por ejemplo:

• Un pedido de venta lo podremos ver si no está asociado a compañías o si esta asociado a nuestra compañía o alguna compañía que esté por debajo.

{code hidden:false title:false}[‘|’,(‘company_id’,’=’,False),(‘company_id’,’child_of’,[user.company_id.id])]{/code}

• Una empresa la podremos ver si no está asociada a compañías o está asociada a nuestra compañía o alguna compañía por encima o por debajo.

{code hidden:false title:false}[‘|’,’|’,(‘company_id.child_ids’,’child_of’,[user.company_id.id]),(‘company_id’,’child_of’,[user.company_id.id]),(‘company_id’,’=’,False)]{/code}

Módulo multicompañía – otras cuestiones

Hasta aquí hemos visto como crear las compañías y dar acceso a usuarios y documentos. Todavía quedan problemas por resolver para hacer totalmente funcional el sistema multicompañía.

El primer problema que nos encontramos es que la instalación de muchos módulos no está pensada para la multicompañía. Por esta razón, los objetos creados automáticamente en la instalación de un módulo, como las secuencias de pedido del módulo de ventas, sólo se crean para la primera compañía creada. Lo ideal sería que la creación de esos objetos se crease mediante un wizard, y poder lanzarlo en cada compañía, pero de momento nos toca crear esos datos a mano para cada compañía.

Aunque podemos definir una estructura de árbol en las compañías, la consolidación de la contabilidad no está contemplada en este sistema, aunque tenemos cuentas contables virtuales, pero no una forma automática de crear todas las correspondencias.

Otro problema que se está planteando en el canal irc de openobjects es como podemos restringir diferentes accesos de un usuario para cada compañía, por ejemplo un usuario que tenga acceso a compras y ventas en una compañía pero solo a ventas en otra compañía. De momento tampoco podemos contemplar esto y la solución sería crear dos usuarios distintos.

Para más información sobre OpenERP visita nuestra web haciendo un clic aquí.

Leer más

Fabricación

Datos maestros

Listas de materiales maestros describe la lista de materias primas o subproductos que se utilizan para fabricar un producto terminado. La estructura jerárquica permite gestionar listas multinivel de materiales de varios niveles de los materiales.

Listas de componentes de los materiales componentes son componentes y sub-productos que se utilizan en las Listas de materiales maestros.

Rutas define la lista de operaciones que se realiza en un centro de trabajo de montaje o de fabricación de un determinado producto. Una lista de materiales puede ser vinculados a una ruta, que describe la forma de montaje o de fabricación del producto.

Los Centros de trabajo son unidades independientes dentro de la planta de fabricación, consistentes en una o varias personas y/o máquinas. Los Centros de trabajo se utilizan con el propósito de planificar la capacidad y hacer previsiones.

Planificación

Calculo de temporizadores. El temporizador es el corazón del sistema del ERP en términos de planificación. Organiza las órdenes de fabricación basadas en las prioridades (sub-productos de fabricación, fechas requeridas, etc), lanzamientos de órdenes de compra para los componentes que faltan y asigna productos en stock.

La herramienta del temporizador es normalmente planificada para ser lanzada de forma automática una vez al día. Esta frecuencia se puede ajustar según los sectores de su empresa y sus necesidades. También puede ejecutarse de forma manual en caso de ser necesario.

Fabricación

Órdenes de fabricación describe la lista de materias primas que se utilizarán para cada etapa de producción. La materia prima puede ser consumida de una sola vez o de forma progresiva durante el proceso de producción. Además OpenERP proporciona una gestión de desechos, la producción parcial también es posible.

Las Órdenes de compra programarán una propuesta para la adquisición automática del producto que necesita reposición. Esta contratación iniciará una tarea, ya sea una forma de orden de compra para el proveedor, o una orden de producción dependiendo de la configuración del producto.

Las Órdenes de trabajo son operaciones de fabricación requeridas para producir o ensamblar productos. Las diferentes Órdenes de trabajo tienen diferentes efectos sobre los costes de fabricación y planificación, en función de la carga de trabajo disponibles.

Control

Abastecimiento en excepción. En el proceso de planificación de los requerimientos de material (MRP), las órdenes de abastecimiento se crean para lanzar órdenes de producción, órdenes de compra, distribución del inventario, etc… Las Órdenes de abastecimiento se generan de forma automática por el sistema y a menos que haya un problema, el usuario no recibirá ningún tipo de notificación.

En caso de problemas, el sistema lanzará algunas excepciones de abastecimiento para informar al usuario sobre los problemas de bloqueo que deben resolverse de forma manual (como por ejemplo la falta de estructura de Lista de materiales (LdM) o falta de proveedor).

Informes

“Carga del centro de trabajo” es una proyección de cargas en un centro de trabajo para un determinado período. La carga se expresa en horas (para recursos humanos) o ciclos (para máquinas)

“Variación del valor semanal de las existencias” permite seguir la evolución del valor de las existencias, de acuerdo al nivel de las actividades de fabricación (consumo de materias primas, producción de productos terminados, estimación del valor añadido de las existencias) a medida que avanzan en el proceso de transformación.

también le adjuntamos a continuación el enlace a nuestra web, haceindo clic aquí.

Leer más