By PVG viagra

a short-term loan Payday loans huge rate of inflation.

Archivo categoría modulos openerp

Interesante discusión sobre la comunidad española y la localización

Por Ana Juaristi Olalde - Comunidad Española OpenERP, Instalación OpenERP, modulos openerp - 18 abril 2012

No puedo dejar de publicar esto… Acabo de encontrarme con un hilo en la lista de correo de la localización española donde se plantea un interesantísimo debate y a su vez se responden dudas generales sobre su instalación, su evolución, el SAAS y la comunidad.

Aquí os  dejo un resumen con extractos de los párrafos más interesantes y una genial conclusión de Santi de Pexego y ahí paro, ya que la siguiente reflexión de Jose Prieto, tiene fácilísima solución y a mi entender no aporta demasiado. Si te falta algo NO PIDAS a otros que lo hagan. Busca clientes que lo financien y subcontrata lo que necesites o hazlo tú mismo. Fundamento del software libre. Repetimos por enésima vez en estos días que ninguno somos ninguna ONG.

Espero que a los recién llegados también les aclare ciertas dudas sobre la parte financiera/contable de OpenERP en España. También invito a nuestros clientes y a los de todos a leer en detalle este hilo al completo directamente en nuestra lista de correo de localización: openerp-spain@googlegroups.com

Cordiales saludos!!

Ana

JM: Hola a todos, Estoy interesado en utilizar la opción que ofrece OpenERP en la modalidad SaaS pero me preocupa los relativo a la localización española ya que en la modalidad SaaS no tienes acceso a instalar módulos. Me imagino que en el SaaS utilizarán el módulo estándar l10n_es, y no se si con eso es suficiente ya que no conozco las diferencias con el l10n_es_pyme_account.

RE: El módulo l10n_es sólo añade el pla contable español. Relativo a todo lo otro, debes añadir la larga lista de 20 módulos que empiezan por l10n_es. En www.aulaerp.com encontraràs documentación cada uno de ellos (o los más comunes)

Más información sobre módulos l10n_es: http://www.zzsaas.com/es/modulos

AJ: Es que el SAAS “oficial” de OpenERP no incluye ni módulos de localización, ni módulos a medida de los clientes. Solo tiene los módulos oficiales y por tanto sólo incluye el módulo básico de la localización l10n_es “certificado”. Como te dice Raimon, la localización española tiene más de 20 módulos l10n_es que no están “certificados” por Bélgica, ni se incluyen en la versión “oficial”.
No obstante tienes alternativas varias, entre ellas zzsaas, como te comenta Mario.

JM:Una cosa más: ¿veis viable en la práctica trabajar solo con el módulo básico de la localización española?
¿Se podrían presentar los impuestos telemáticamente solo con el módulo básico?

IB:Sinceramente, si utilizar solo el módulo básico pierdes gran parte de la funcionalidad que tiene la localización españoa. Este módulo solo carga el plan contable, posiciones fiscales e impuestos. Faltan módulos que en mi opinión son bastante necesarios para la contabilidad española: recibos 19,32,34 y 58, extractos con la norma 43, modelos 340,347 y 349, aunque el 340 de momento no es obligatorio para todas las empresas,
informes financieros y aunque no imprescidible pero muy util la base de datos de bancos y municipios.

La presentación telemática de impuestos no esta en el módulo básico. Son módulos a parte que te he comentado antes. Yo te recomendaria utilizar una empresa española para el servicio Saas o montar tu propio servidor en la nube con los módulos que precises.

Los modelos 340, 347 y 349, exportan a fichero de texto que es compatible con la presentación telemática de Hacienda

JM: Entonces ¿la función de OpenERP que permite exportar a fichero de texto para la presentación telemática del modelo 340 y demas no está?Lo digo porque como la presentación telemática de impuestos (con esos ficheros de texto) es obligatoria, si el modulo básico no permitegenerar estos ficheros entonces no es que se pierda funcionalidad si no usas la localización española, es que es directamente inviable trabajar solo con el módulo básico. ¿estoy en lo cierto?

JP: No se si has instalado OpenERP, pero si vas a la descripción de los módulos, te especifica que instala en cada uno de los módulos.
Tampoco se muy bien a qué le llamas “módulo básico” de localización española.. Más que nada, por que vas a tener que instalar varios; el account_renumber, el de nan para las secuencias separadas de facturas y asientos, los informes contables de Zikzakmedia… Todas esas cosas te  hacen falta para poder trabajar a nivel contable en España.
Tengo una listilla por ahí de los módulos necesarios, si quieres, te la envío; también tienes los cursos de Aulaerp, que si eres muy novato, te recomiendo hacer, por que vienen con vídeos paso a paso y muy claritos.
Pero vamos, que los 340, 347 y 349 sí se generan, instalando el módulo correspondiente, que de memoria no se cuál es, y ahora mismo no puedo abrir la instancia de OpenERP.
IB:Son modulos a parte. Siempre que te refiera como módulo básico al l10n_es que viene por defecto en OpenERP.
> Lo digo porque como la presentación telemática de impuestos (con esos > ficheros de texto) es obligatoria, si el modulo básico no permite generar estos ficheros entonces no es que se pierda funcionalidad si no usas la localización española, es que es directamente inviable trabajar solo con el módulo básico. ¿estoy en lo cierto?

Me temo que si, porque lo puedes presentar via internet o en dvd. Pero en ambos casos necesitas los modulos.
En el caso del 340 que comentas no es obligatorio para todas las empresas, desarrollamos ese modulo hace un año porque en Navarra es obligatorio para las empresas que reciben subvencion en el sector de la agroalimenticio.

Mi postura normalmente es servidor en la nube personalizado, la razon es porque ninguna empresa es igual a otra y al final siempre necesita alguna personalización. Si optas por servicios Saas informate bien que sucede en el caso de necesitar modulos especiales o personalizados, no deberias tener problemas pero informate por si acaso.

SA: A ver, centrémonos un poco.

La modalidad SaaS de OpenERP sa es válida para una funcionalidad muy estándar y si quieres llevar un control “por encima” de la contabilidad sin más, de forma que, por ejemplo, la tengas completamente externalizada y la empresa solo lleve un registro muy generla. Podemos decir que básicamente solo llevas facturación.
OpenERP sa es totalmente consciente de esto pero mantienen que su oferta SaaS es así, y que buscan solo este tipo de clientes, que para los otros no creen en un SaaS si no en una solución hosted y yo, hasta un punto, lo comparto, aunque puede haber casos donde el SaaS sea suficiente.

A José Ramón. Entiendo que te gustaría que OpenERP tuviese un montón de cosas,y no solo en contabilidad, igual que a los demás, pero lo que hay a día de hoy es totalmente suficiente para prestar un buen servicio a muchas empresas, a lo mejor no a todas, pero sí a una mayoría de Pymes.
Cuando cerramos nuestro primer proyecto ni siquiera teníamos Balance y PyG y mucho menos otras cosas de contabilidad. Partimos de que esto es software libre, si realmente tienes un cliente del tamaño que te mire como un friki cuando le presentas la funcionalidad de contabilidad, que financie las mejoras necesarias, esto es así, otros han pagado lo que ya tiene hecho, no va a pagar licencias, que contribuya en la parte que le toca que es la económica, que se involucre, que sea parte de una comunidad.

Las herramientas evolucionan y, en general, lo que he visto en el último año en una comunidad que ha crecido muchísimo es mucha palabra y poco trabajo, o al menos poco trabajo que haya revertido en la comunidad, con un montón de nuevos partners y otros miembros de la comunidad cuyos aportes han sido más bien nulos (con excepciones, desde luego).
Con esto quiero decir que plantear grandes discusiones sobre desarrollos a realizar no conduce a nada. El año pasado en Lugo se trataron de planificar mejoras a implementar y no se consiguió nada.
Si alguien va a iniciar nuevos desarrollos que afecten a la localización, que lo diga en esta lista, que trate de buscar apoyos tanto de trabajo como de conocimiento o incluso económico (otros podemos tener clientes interesados pero sin capacidad para acometerlo entero), que cree una nueva rama en launchpad y adelante, así de simple y de difícil.

Con esto quiero decir, que, aunque no lo parezca tenemos una de las localizaciones sobre OpenERP más completas del mundo y la única de este nivel promovida y realizada por una COMUNIDAD y no por una única empresa que la dirija y esto debería ser un orgullo y  se ha hecho gracias a la colaboración de empresas y, sobre todo , PERSONAS (Pedro, Albert, Jordi, Borja,… etc) No es un modelo fácil pero, en general, sí nos ha permitido transmitir seguridad en el software. Busquemos apoyo y colaboración sobre algo en firme, sostenible y financiable más que grandes enfoques. Es mi opinión.

Y TAMBIEN LA MIA… al 100%

,

No hay Comentarios

Gestionar incidencias en proyectos

Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 12 diciembre 2011

Como ya todos sabeis existen 2 módulos en el CRM de OpenERP que nos permiten registrar incidencias: crm_claim(reclamaciones) y crm_helpdesk(incidencias). Una limitación de estos módulos es que para controlar el tiempo dedicado a la resolución del caso, es requerido crear una tarea asociada al mismo en el área de proyectos. En el caso se registra el historial de interacciones con el cliente y en la tarea se registra el tiempo dedicado a su resolución, por lo tanto, de alguna manera se duplica la información, aunque esta forma de trabajar es totalmente válida y permite tener centralizadas todas las tareas de un proyecto, sean del tipo que sean.

Si queremos simplificar la gestión de casos de incidencias, además de estos 2 módulos, también también contamos con los siguientes en el área de proyectos.

project_issue –> Permite registrar incidencias con la misma estructura, estados y campos que en los módulos mencionados anteriormente con el añadido de que podemos directamente asociar el caso a un proyecto y si fuese necesario, desde el propio caso crear la tarea en proyectos.

project_issue_sheet –> Añade la posibilidad de imputar contra una cuenta analítica, el tiempo dedicado a la resolución del caso, directamente en el propio caso, sin tener que acceder a la tarea asociada.

Utilizando estos 2 módulos evitamos por tanto la necesidad de generar específicamente una tarea para la resolución de una incidencia puesto que la imputación de tiempo se puede realizar directamente en el caso.

Muy útiles para empresas de servicios que deseen controlar costes por tiempo dedicado o facturar por dicho concepto.

, ,

No hay Comentarios

Facturación periódica en OpenERP

Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 7 diciembre 2011

Este es otro tema recurrente sobre el que recibimos también muchas consultas. En este post intentaré aclarar las posibles soluciones que existen al respecto.

OpenERP de base, trae el módulo Suscriptions que permite de forma sencilla emitir facturas periódicas. Se crea una suscripción y para cada una, el sistema creará una copia de la factura del mes anterior.

Como alternativa y con una funcionalidad más potente, el año pasado KnDati / Sraps de Alistek publicó el módulo periodical_invoicing para OpenERP5.0 que permitía:

  • Configurar cuotas periódicas mediante metodologías de facturación (alquieres, cuotas mensuales de mantenimiento, cuotas periódicas como suscripciones a revistas… etc)
  • Parametrizar periodicidad de cobro de las cuotas (trimestral, anual, mensual) en contratos ilimitados y/o con fecha fija de baja.
  • Incluía un nuevo concepto “contrato” donde se establecían las condiciones de facturación para un determinado cliente en función de los servicios contratados y su metodología de facturación.
  • Se controla también parciales de un mes. Es decir, si son 30 días del mes y se da de alta el día 15, facturará medio mes.
  • Mejora de la generación automática de facturas desde contabilidad analítica, ampliando el asistente incluido el standar de OpenERP.

Viendo la potencia del módulo y dada la necesidad de uno de nuestros clientes, decidimos migrarlo a 6.0 y extenderlo incluyendo además nueva funcionalidad requerida por dicho cliente.

La versión actual del módulo para 6.0, además de lo ya mencionado  permite:

  • Incluir en una única misma factura, conceptos periódicos y no periódicos realizados en una o varias ventas.
  • Permite definir en la ficha de producto cómo lo vamos a facturar, bien sean servicios o bien sean materiales. Hemos incluido los tipos de facturación “pago único”, “pago a plazos”, “facturación recurrente” y “no pago”
  • Para aquellos productos marcados como “facturación recurrente” se crea automáticamente el contrato al confirmar el pedido. En la línea de pedido podemos establecer las fechas en que se iniciará la facturación y su periodicidad.
  • Para aquellos productos marcados como facturación única, creará su correspondiente línea de facturación en analítica una vez se confirma el pedido.
  • Para los productos marcados como “a plazos”, se puede establecer la fecha de inicio de facturación y el número de plazos en la propia línea del pedido. El sistema generará en su fecha correspondiente tantas líneas en analítica como plazos de pago se establezcan.

Es decir, creamos un enlace desde ventas a analítica, de tal forma que se van “apuntando” todos los conceptos que son necesarios facturar, independientemente del momento en que se emita la factura.

Las líneas llevan una fecha. En el momento en que se ejecuta el proceso de  facturación, estableceremos qué periodo deseamos facturar indicando 2 fechas. Para cada cliente/cuenta analítica, todas las líneas  facturables de analítica cuya fecha esté entre dichas 2 fechas serán incluidas en la misma factura, tanto si son cuotas creadas automáticamente , como materiales, como horas dedicadas a una tarea, como otros conceptos, como si se incluyen las líneas manualmente en analítica sin provenir de ningún pedido…

Ejemplo:

  • Vendemos a un cliente en uno o varios pedidos los siguientes conceptos:
    • Un servicio que consta de un único pago por alta de servicio
    • Un equipo informático a pagar en 3 plazos.
    • Un contrato de mantenimiento con un importe mensual
  • En la primera factura, se incluirán:
    • El alta del servicio
    • El primer plazo del equipo
    • La primera cuota mensual por adelantado. Si el alta se da a mediados de mes, contará los días correspondientes y facturará dichos días.
  • La segunda factura y la tercera incluirán:
    • Segundo plazo del equipo
    • Cuota mensual completa
  • La cuarta factura incluirá únicamente la cuota mensual.

Aquí el link al proyecto, donde podeis descargaros los módulos, reportar bugs, hacer sugerencias o incluso subir mejoras si os animais:

https://launchpad.net/openerp-invoicing

Esperando os sea de utilidad.

Edito a 12/12/2011: A raiz de la publicación de este post, hace unos días Kaspars de Alistek inició un hilo en sus foros donde muestra su disconformidad por la forma en que la comunidad evoluciona o según él hace “un fork” de sus módulos. Os invito a participar ya que se ha convertido en un interesante debate. Por nuestra parte tenemos la conciencia totalmente tranquila al respecto. Como ya me venís conociendo hace bastante tiempo, el objetivo principal de esta Web es informar y siempre intentamos dar atribuciones a quien ha escrito el post, ha realizado los módulos o publica sus formaciones. También me causa cierto orgullo que la gente dé tanta importancia a la forma de informar en un simple post, de un simple blog y que éste sea mío. :)

Aprovecho la edición para incluir en el post los links que se me solicitan.

Saludos de nuevo:

Ana

,

9 Comentarios

Configuración multicompañía en OpenERP 6.0

Por Ana Juaristi Olalde - Funcionalidad OpenERP, Manuales técnicos OpenERP, modulos openerp, Tutorial OpenERP - 5 diciembre 2011

Ultimamente me están llegando algunos correos donde nos preguntan si la multicompañía en OpenERP 6.0 funciona y en caso de que sí, cómo se configura.

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

,

3 Comentarios

Liberado el primer módulo de OpenERP para la gestión de Ayuntamientos

Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp - 27 octubre 2011

Nos congratula anunciaros que el primer módulo de OpenERP para ayuntamientos ha sido liberado.

Rama de launchpad para su descarga:

https://code.launchpad.net/~ting/ting-addons/ting_fee_management

Entre otra funcionalidad incluye la siguiente:

  • Callejero, con la información legal exacta del municipio
  • Terceros, normalmente la información del padrón del municipio completada con los datos de no empadronados. Todos los terceros tienen asociados los conceptos y subconceptos que les son aplicables.
  • Conceptos y subconceptos de tasas municipales, incluyendo diferentes tipo de cálculos para la correcta definición de las mismas.
  • Creación de expedientes y liquidación de los mismos, siguiendo con la emisión de tasas correspondientes.
  • Modelo 060 de recibo bancario para el cobro de los importes de la tasa emitida.

Os paso link a la noticia completa publicada por Carlos de Ting en Twitter:

http://www.ting.es/2011/10/27/openerp-ayuntamientos/

No hay Comentarios

Minitutorial cómo configurar el plugin con Thunderbird para su conexión con OpenERP

Por Ana Juaristi Olalde - Funcionalidad OpenERP, Manuales de usuario / Tutoriales de OpenERP, modulos openerp - 22 septiembre 2011

Hoy va de videotutoriales internos.

Aquí uno muy resumido para configurar el conector de Thunderbird. Hay 2 partes, por lo tanto, os paso los links a 2 videos.

PARTE1: Configurar módulo en OpenERP y guardar Plugin para su instalación posterior en Thunderbird (3 frames)

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

PARTE2: Instalar plugin en Thunderbird + asociar correos a partners + crear iniciativas con correos de Thunderbird + crear contactos en OpenERP desde Thunderbird

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

Esperando os sirva de algo:

Ana

1 Comentario

Minitutorial como configurar servidor email OpenERP para generar casos de CRM automáticamente

Por Ana Juaristi Olalde - Funcionalidad OpenERP, Manuales de usuario / Tutoriales de OpenERP, modulos openerp, Trucos Openerp - 22 septiembre 2011

Hola:

He montado un pequeño tutorial para uso interno que he creido que podía ser de interés también para vosotros. Se trata de cómo configurar el módulo fetchmail de OpenERP 6.0 para la creación automática de distintos elementos en el CRM.

En el ejemplo del videotutorial, he creado una cuenta “info@cualquiera” de tal forma que cualquier correo enviado a dicha cuenta creará automáticamente un lead / iniciativa en OpenERP.

Igualmente, podeis realizar el mismo enlace o automatización utilizando distintas cuentas de correo para crear distintos elementos en el CRM. Por ejemplo, podría asociar un caso de helpdesk o incidencia a “helpdesk@cualquiera” o un caso de reclamación administrativa a “administración@cualquiera”.

Aquí os dejo enlace al minitutorial. 10 frames.

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

No hay Comentarios

OpenERP 6.0 – Oscommerce / Zencart conector

Por Ana Juaristi Olalde - integración OpenERP Tiendas Virtuales (Oscommerce, Magento, Spree), modulos openerp - 9 mayo 2011

Hace ya algunas semanas realizamos las pruebas de conexión del conector Oscommerce de OpenERP con una tienda Zencart. Vimos que a excepción de algún ajuste en la parte php, básicamente el conector standar (esale_osc) funciona bastante bien. Permite sincronizar el catálogo de productos tanto en subida como en bajada, sincronizar stocks, importar pedidos y crear clientes nuevos en OpenERP.

Por las pruebas que hemos realizado, hemos visto que incluso las últimas mejoras que incluimos en el conector de Oscommerce standar no han causado problemas relevantes en los mapeos. Entre ellos…

  • Detectar y controlar CIFs europeos
  • Localizar clientes por CIF, además de por Id de la web a fin de evitar duplicar registros de clientes dados de alta por distintos canales.
  • Descargar impuestos de los pedidos teniendo en cuenta la posición fiscal del cliente.
  • Además de la descarga global del catálogo a partir de una fecha, permitir descargar un único producto desde su ficha.
  • etc…

Por si alguien está interesado en descargarse esta última versión del conector para 5.0, aprovecho para comentaros que hemos pasado el mantenimiento del módulo de la rama extra-addons 5.0 a nuestra propia rama http://www.launchpad.net/avanzosc.

Además, en la misma rama, podeis encontrar varios módulos esale_  que amplían la funcionalidad del conector standar esale_osc. Serían lo que llamamos el conector avanzado para Oscommerce. Evidentemente estos módulos no serán compatibles con Zencart a no ser que las mismas contribuciones publicadas para Oscommerce hayan sido instaladas en el Zencart, cosa poco probable.

Por tanto, los módulos que componen el conector avanzado son:

  • esale_avanzosc : Mapea multiimágenes, SPPC y descuentos por volumen.
  • esale_extra_fields: Mapea campos extra de productos
  • esale_m2m_categories: Mapea múltiples categorías de producto. Depende del módulo extra m2m_categories de Openlabs.
  • esale_variants: Mapea multivariantes y depende del módulo extra products_variant_multi de Akretion

Además, los módulos tienen dependencias con otros módulos de la comunidad como nan_external_prices o la localización española.

Y por último …  ya tocaba hacer funcionar tanto el conector standar como el avanzado con la versión 6.0 de OpenERP. Iniciadas las primeras pruebas con esale_osc, el balance es positivo. Si todo va bien os anunciaré la publicación de todos los módulos migrados en unos días, aunque esta misma semana creo que estaremos en disposición de subir la primera versión funcional de esale_osc migrado a nuestra rama.

Esperando sea de vuestro interés, cordiales saludos!!

Ana

,

3 Comentarios

OpenERP – Openbravo POS / TPV

Por Ana Juaristi Olalde - Comunidad mundial OpenERP, Funcionalidad OpenERP, modulos openerp - 7 mayo 2011

Buenas… anunciaros que Rvalyi ha publicado que ya tienen finalizado y disponible para ser usado en producción la integración del TPV de OpenBravo con OpenERP. Como nadie mejor que él para explicar lo que han hecho, os traduzco un post suyo que hemos recibido en ingles:

Hola gente:

Quisiera anunciaros que Akretion ha realizado una integración entre OpenERP y el terminal de venta para pantalla tactil de Openbravo. Lo tenemos en producción desde hace un mes en uno de nuestros clientes de USA, importando alrededor de 300 pedidos al día y actualizando el catálogo de más de 3000 productos  cada 5 minutos al TPV. Utiliza los módulos base_external_referentials y base_sale_multichannels y se ejecuta en la misma instancia de OpenERP al que también se han conectado 2 tiendas Online Magento hace varios meses.

Utilizamos la tecnología TerminatOOOR (ETL pentaho + plugin OOOR; aquí la v2 no ha sido aún documentada desafortunadamente).  Estamos reutilizando en gran medida lo que Openbravo utiliza para conectar su TPV a su propio ERP. Son 2 softwares distintos, uno bueno (el TPV) y el otro no en mi opinión.

Todo es software abierto y publicado, menos la transformación de kettle por si misma.
Conectamos a OpenERP a través sólo de webservices. Como para el sofware estamos enlazando de forma estática, somos los propietarios de la librería OOOR y el ETL de Kettle es LGPL, no viola ninguna licencia; nosotros siempre prestamos atención extrema a respetar las licencias puesto que en Akretion creemos en el modelo de software abierto.
Nosotros podremos posiblemente liberar todo el código en el futuro, dependiendo del retorno que hemos evaluado y la inversión podremos querer o no en términos de imagen (estimamos que hemos invertido muchísimo en contribuciones y esto no siempre cubre la cuenta desafortunadamente), notad que somos ya los quintos en la lista de contribuciones en apps.openerp.com, hemos hecho y publicado la localización brasileña, el conector de Magento, la tecnología OOOR, la tecnología TerminatOOOR e incluso luchamos por contribuir con parte de nuestras ganancias a OpenERP, SA, por lo que no somos en ningún caso parásitos del software libre y considero que estamos jugando de forma justa por un amplio margen.
En cualquier caso, vendemos la integración muy barata. Hoy, nuestro producto aún no ha sido empaquetado totalmente “out of the box” por lo que es necesario todavía algún trabajo de integración pero esperamos que podremos cubrir las últimas millas para esto.
Las ventajas de esta solución son:
A largo plazo, estoy de acuerdo en que la nueva solución TPV propuesta por OpenERP SA es totalmente válida (la anterior no lo era, en mi modesta opinión). Veo que la solución Openbravo POS es una solución alternativa para los próximos uno o dos años mientras el TPV de OpenERP esté maduro para los disintos hardwares y negocios. En Akretion creemos en las aplicaciones HTML5 directamente sobre OpenERP, también hemos iniciado productos en esa línea también, de todos modos no dependemos de OpenERP 6.1 para ellos así como nuestros clientes que no financiarían algo lejano a sus necesidades diarias.
Os invito a que nos contacteis en caso de que esteis interesados en esta tecnología para su uso inmediato.

Saludos

Raphaël Valyi
Founder and consultant
+552130109965 begin_of_the_skype_highlighting +552130109965 end_of_the_skype_highlighting

1 Comentario

Presentación de nuevos módulos de fabricación OpenERP 6.0

Por Ana Juaristi Olalde - Funcionalidad OpenERP, modulos openerp, Tutorial OpenERP - 7 abril 2011

Por fin puedo presentaros un par de videos sobre la ampliación de funcionalidad que entre Ting y Avanzosc hemos realizado a los módulos de fabricación de OpenERP 6.0.

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

,

1 Comentario