Pretendo cumplir 3 objetivos:

• Que queden claras todas las opciones de instalación de OpenERP (que creo causa bastante confusión, sobre todo a gente no técnica ) y en qué consiste cada una.
• Que se entienda en qué consiste cada una de las fases de implantación, permitiendo a cada empresa identificar que tipo de arranque es el  más apropiado para ellos. Nadie mejor que uno mismo conoce su propia empresa (creo… )
• Que la empresa que está pensando en contratar una implantación conozca qué servicios se ofrecen habitualmente y que tenga claro al contratar, lo que está contratando, identificando además si le serán necesarios todos y cada uno de dichos servicios o sólo necesita algunos.

Sin más… aquí va. Espero que os guste:

Simulador de costes de proyecto, que permite elaborar presupuestos a clientes desde la definición de costes y posteriormente,permite generar automáticamente, tareas, pedidos de compra, subcontrataciones.. etc al confirmar el pedido proveniente de la simulación.

Creemos que puede ser muy útil a empresas de ingeniería, consultoría, construcción que emiten presupuestos al cliente en función del cálculo de costes del proyecto, pero que no desean mostrarle en el presupuesto el desglose o detalle de todas las tareas a realizar.

Esperando os sea de interés!!

Tenemos un par de clientes que arrancarán en Enero con multicompañía y por las pruebas que llevamos hechas, en principio, funciona y es usable. Ahora bien… hay que tener en cuenta algunas cosas y seguir una guía estricta para su configuración. También nos preguntan exactamente en qué consiste y cuándo es mejor opción poner una base de datos en multicompañía o una base de datos independiente para cada compañía. En cuanto a esto último, os pongo la claves para tomar la decisión.

1. Se hace todo en una única base de datos por lo que posteriormente es más fácil sacar informes globales tomando de datos de todas las compañías.
2. Se puede “compartir” la tabla de clientes/proveedores y la de productos por todas las compañías.
3. Se puede especificar que un cliente/proveedor o un producto concreto sólo sea visible y utilizabe por una única compañía
4. No se permite que un cliente/proveedor o producto sea asignado a más de una compañía. Es decir, será visible por todas o sólo por una por defecto. Si jugamos con la configuración de compañías padres e hijas, se puede hacer que un cliente / producto sea visible en el padre y todas sus hijas por ejemplo.
5. Cada compañía tiene sus usuarios.
6. Los datos de operativa de una compañía no los ve la otra, si no se permite. Es decir, un usuario que tiene acceso a pedidos, albaranes, facturas de una compañía, no verá por defecto los de otra compañía.
7. Se puede definir un superusuario de una compañía “padre” que vea todo de todas las compañías. Esta compañía padre, solo vale para visualizar datos conjuntos de todas pero no vale para operar, es decir, para crear pedidos, facturas y demás… Esta compañía “padre” no existe legalmente, solo es una compañía ficticia, que se usa para configurar los maestros de todo el resto de compañías y para ver informes globales de todas.
8. Cada compañía puede tener sus propios precios por los productos “compartidos”, sus impuestos, su propia tabla de cuentas contables. Cada cliente “compartido” también tendrá una cuenta contable propia en cada compañía.
   Es decir, un usuario que entre a ver un producto en la compañía A verá un precio y un usuario que entre a ver el mismo producto en la compañía B verá otro precio (si lo tienen distinto). Igual pasa cuando ves un cliente.
9. Cada compañía también tiene sus propios almacenes.
10. Seguro que me dejo muchas otras cosas pero básicamente esto os puede hacer tener una idea de si poner una multicompañía o hacer cada compañía en una base de datos independiente.

A continuación os pongo una lista de las tareas que hay que llevar a cabo para configurar una multicompañía en OpenERP 6.0

• Crear la nueva compañía en administración / compañías. Esto crea el cliente asociado a la compañía. Completar los datos básicos de cada una, incluido logo y datos básicos para informes, moneda… etc.
• Completar direcciones, sedes y contactos del cliente asociado a cada compañía.
• En contabilidad / configuración / configuración financiera / ejecutar asistente configuración financiera para nueva compañía. Siguiendo los datos del asistente crear la nueva configuración financiera, teniendo en cuenta haber instalado previamente los módulos de localización de cada país.
• Hasta aquí, lo más básico… Curiosamente cuando instalamos una monocompañía, el sistema de base nos carga una serie de datos de configuración que no se incluyen cuando creamos una nueva compañía. Entre ellos:
  • Ventas: Crear la/s tienda/s de ventas para cada compañía
  • Almacén: Crear la/s ubicación/es y almacén/es de cada compañía.
  • Usuarios: Crear los usuarios de cada compañía
  • Secuencias: Hay que duplicar manualmente todas las secuencias de la compañía “muestra” creando y asociando al menos las mismas para cada compañía. Cuidado con los nombres ya que posteriormente utilizaremos dichas secuencias para que sean asociadas a los diarios contables. Si no marcamos con un tag o un nombre distinto cada país/compañía, luego nos será complicado asociar la secuencia correcta.
  • Diarios: Igual que con las secuencias, hay que crear manualmente muchos de los diarios. Algunos ya se crean durante la ejecución del asistente de configuración financiera pero otros no. Cuidado al asignar las secuencias. Coged en cada diario asociado a cada pais/compañía, las que correspondan. Si no, dará errores al operar. En España, tanto para multicompañía como para monocompañía, es requerido instalar nan_account_invoice_sequence. En los diarios de compra, venta y devolución de facturas, asignar la secuencia de factura correcta a cada tipo de diario.
• Configuración de divisas:
  • Si requerimos además de multicompañía, que sea multidivisa, será necesario establecer una base de moneda para cada compañía. Es decir, en España la base monetaria será el Euro pero en USA será el dolar. Por lo tanto, debemos configurar cada moneda con su propia base para cada compañía. El resto de monedas serán calculadas como divisa con respecto a esta base.
  • Recomendable instalar el módulo currency_rate_update. Permite que openERP se conecte a un Webservice para la actualización automática de los cambios de divisa. Puede ser ejecutado manualmente o puede establecerse una periodicidad para su ejecución, de forma desatendida.
• Configuración de tarifas:
  • Cuidado aquí. Las tarifas de venta y compra deben ser creadas para cada compañía. Cada tarifa Base, debe llevar asignada la moneda base de dicha compañía.
  • Se pueden establecer tarifas en otra moneda distinta a la de la compañía, basadas en la tarifa base, de tal forma que se mostrará la moneda en la que se compra o vende, durante todo el ciclo hasta la factura. Sin embargo, al realizar el asiento contable de la factura de compra o venta realizará la conversión a la moneda base en el asiento contable y marcará el importe en divisa. Cuidado también aquí con la moneda base establecida en el diario en que se hace el apunte. Debe ser igual que el de la compañía, si queremos contabilizar todo en moneda única.
• Precios de productos:
  • Si se requiere establecer un precio base para cada producto en cada país/moneda, recomendamos instalar product_multi_company. Esto convierte el campo precio en un campo property, lo cual nos permite tener un precio base del producto para cada compañía.

Y creo que es todo. Con esto, hemos conseguido configurar una base de datos multicompañía, con los elementos básicos para funcionar en las áreas de gestión (ventas, compras, almacén, facturación y contabilidad)

Esperando sea de vuestro interés, cordiales saludos:

Ana

Aquí va la primera parte, donde se muestra cómo realizar la configuración de los maestros (operaciones, fábrica, máquinas, hoja de ruta o proceso, listas de materiales …)

http://www.openerpsite.com/wp-content/uploads/advanced_manufacturing_tutorial.htm

A continuación la segunda parte de operativa de fabricación en OpenERP donde se muestra cómo crear la orden de fabricación basada en una lista de materiales y un proceso predefinidos además de cómo operar y gestionar dicha orden, sus operaciones, la asignación de operarios y las imputaciones de tiempo de operarios y máquinas.

http://www.openerpsite.com/wp-content/uploads/advanced_manufacturing_tutorial_Second part.htm

Recordaros que los módulos están publicados en nuestra rama en launchpad:

https://launchpad.net/avanzosc

Estamos testeando los módulos y os solicitamos colaboración en esta tarea. Estaremos encantados de que nos registreis bugs en nuestra rama y puesto que aún tenemos funcionalidad pendiente de desarrollar en la Fase 2, también nos gustaría que nos remitais mejoras tanto en funcionalidad como en usabilidad.

Para preguntas funcionales o de uso, por favor utilizad los foros oficiales de openerp, los propios de openerpsite o consultad próximamente el curso que publicaré al respecto en AulaERP.

Muchas gracias por vuestra colaboración:

Ana

Es decir, el pedido quedaba en estado “enviado”, los movimientos de stock se habían realizado, en algunos paises también existe implicación contable con estos movimientos… en fin, que las implicaciones eran varias, por tanto era un poco complicado encontrar una solución intermedia, que sin impactar con la funcionalidad standar de OpenERP, permitiera realizar la vuelta atrás del albarán, volver a poner el pedido en estado borrador, y volver a confirmar dicho pedido para recrear de nuevo el albarán.

Después de largas discusiones entre los expertos de las listas y un montón de comentarios sobre cual sería la mejor solución, esta es la que se ha decidido y YA está disponible en la última versión de launchpad.

Aquí los pasos que son necesarios seguir para volver atrás un albarán:

1. Para cada albarán relacionado con el pedido que se desea volver atrás, en la segunda solapa del albarán, se ha añadido un link al pedido desde el que proviene. Es necesario BORRAR este enlace y grabar el albarán. Es decir, hay que desligar todos los albaranes del pedido.
2. Para cada albarán REALIZADO: “Devolver” las mercancías al almacén. Es decir, deshacer lo que se hizo mal, con una devolución de materiales. Para ello, utilizar el botón de la derecha del albarán “Devolver mercancía”.
3. Para cada albarán SIN REALIZAR: “Cancelar” directamente el albarán. Puesto que el movimiento nunca se hizo, no es necesario devolver nada.
4. Una vez terminado el proceso con todos los albaranes del pedido: Abrir el pedido, cancelarlo, volverlo a borrador y volver a confirmar. Esto genera un nuevo albarán completo, relacionado con el pedido, como si el anterior no se hubiese hecho nunca.

Esperando os sea de utilidad, cordiales saludos!!

Ana

A petición de Nhomar, publico el video donde se muestra.

Saludos!!!

Ana

El módulo recientemente publicado, os permitira ubicar a todos los Clientes registrados en OpenERP en un google map, sin necesidad de registrar los datos uno a uno… Además, os permitirá ver la facturación por paises, u os mostrará las rutas y el número de envíos realizados a cada Cliente…

IMPRESIONANTEEEEE!!!!!!

Hola Ana, te paso esta información por si la crees interesante para publicarla en opernerpsite.com
En la versión 5.0.1 para windows, no funciona el sistema de hacer backups y restores desde el cliente GTK.
Me lo he estado mirando y haciendo un par de truquitos… se puede hacer funcionar, te lo detallo al final del email.

Un saludo cordial
Javier Peirats.
Inercia.com

Por supuesto que interesa recibir y publicar este tipo de información. De hecho, este es el objetivo de OpenERPsite. Muchísimas gracias Javier por tu aportación. Aquí van los truquitos que nos envías, tal cual me lo pasas:

Descargar las fuentes de linux, buscar y editar el fichero /src/bin/service/web_services.py

He de decir, que hasta el momento no hemos tenido mucha cosa que comentar ya que todo va sobre el plan previsto y en principio no hemos encontrado escollos irresolubles. He aquí un pequeño problemilla que me ha traido de cabeza todo el día, hasta que (para variar) Jordi Esteve, me ha enviado la solución por e-mail. Es obvia, pero si no se te ocurre al momento o no te acuerdas, puede hacerte pensar que realmente hay un error importante cuando no es así. Por lo que aquí va.

Probad lo siguiente.

• Definid un producto almacenable, de compra, contra stock
• En su ficha, indicad plazo de servir al Cliente 5 días.
• Creáis un pedido de venta y confirmáis.
• Vais al albarán y comprobáis la fecha prevista de entrega para dicho albarán. ¿Coincide con lo que teníais previsto que pusiera? Posiblemente no.

La fecha prevista de entrega del albarán de Venta en Openerp se calcula en función del número de días que establezcáis en la solapa abastecimientos y ubicaciones de la ficha del producto. Según esta fecha, y lo que habéis puesto en el punto 2, la fecha prevista tendría que ser la de hoy más 5 días. El tema es que no hay que olvidarse que en la ficha de configuración de la compañía en administración /usuarios/arbol de la compañía/compañía se establecen unos plazos de seguridad para el cumplimiento de fechas.

Por lo tanto, en ese punto del sistema se establece un plazo de seguridad de otros 5 días para el envío al Cliente. El albarán debe estar preparado 5 días antes. O sea que a los 5 días de la ficha del producto le RESTA los 5 días establecidos en la ficha de configuración de la compañía… aquí está el tema. Ajustando correctamente estos valores, el sistema funciona perfectamente.

Aquí va.

- Corre el Servidor OpenERP si instalarlo directo desde el Script (esto no es imperativo yo lo hago para sentirme con mayor control)
- Ejecutalo utilizando el parámetro “-c /ruta/fichero/config”
- Crea Varios Ficheros de configuración con distintos “puertos” de conexión.
-8069
-8071
-8073 por ejemplo.
De esta forma tendrás Varios Servers corriendo, si estas manipulando tu servidor vía ssh te recomiendo uses “Screen” programa para enviar la consola a segundo plano, bien útil.
- Para el Servidor Web harás lo mismo, con el parámetro “-c” lo mandas a buscar ficheros con distintos puertos 8080, 8081, 8082… respectivamente.
- Luego configura tu servidor DNS para que reconozca cada dominio de cada empresa.
de esta forma podras tener varias empresas…. y las llamarás de la siguiente forma.
http://www.empresa1.com:8080
http://www.empresa2.com:8081
http://www.empresa3.com:8082
Recuerda que el servidor web “escucha” un único puerto en este caso el 8080, por ende “todo” lo que pida …:8080 verá la empresa asociada a ese puerto, por esto deberás usar claves super-administradores diferentes, y nombres de usuarios y paswds distintos entre empresas, por seguridad.
Para evitar que algunos vean las empresas de otros, puedes dedicarte a configurar IPtables, filtrando las Ip’s de Origen y esas cosas, pero eso es cuento de otro manual…
Para levantarlos automáticamente te recomiendo le eches un ojo al curso gratuito de instalación de openERP en “aulaerp.com” donde incluso hay unos scripts de arranque de varias empresas-servidores ya hechos…
Espero te sirva, si alguien conoce una mejor metodología sería genial saberla.

Esperando sea de vuestro interés…

Ana