Ya están disponibles para OpenERP y Tryton los módulos para realizar órdenes de pago y órdenes de cobro (remesas de recibos) con el nuevo formato SEPA (Single Euro Payment Area). Este formato sustituye los antiguos formatos Norma 19, 58, 32, 34 que dejan de estar en vigor des del 1 de febrero de 2014, si bien las normas 58 y 32 se pueden usar hasta el 1 de febrero de 2016 (Adeudos Directos SEPA) y para las otras la Comunidad Europea hace unos días dictaminó una moratoria de 6 meses, hasta 1 de agosto, pero de aplicación voluntaria según el banco Single Euro Payments Area (SEPA)

Si desea usar los nuevos formatos SEPA en OpenERP o Tryton se recomienda contactar con el servicio de soporte para realizar los ajustes, debido que cambia bastante la forma de generar los ficheros. Entre otras cosas hay que:

• Cambiar todas las cuentas bancarias de 20 dígitos a IBAN de 24 caracteres. Lo mejor es añadir los nuevos IBAN junto a las antiguas de 20 dígitos y convertirlos en cuentas bancarias por defecto. Si fueran muchos podemos hacer un script para automatizar el proceso.
• En caso de remesas de recibos (antigua Norma19) es necesario configurar el "Identificador de acreedor SEPA" en el tercero de la empresa.
• En caso de remesas de recibos (antigua Norma19) hay que crear mandatos diferentes para cada cliente, indicando si son recibidos únicos o periódicos. Convendría enviar estos mandatos a los clientes para que los devuelvan firmados y sellados.

Los módulos de Sepa también están incluidos en la modalidad SaaS de OpenERP y Tryton.

Las empresas que disponen de canales de venta on-line o tiendas virtuales suelen recurrir a aplicaciones ya existentes y dedicadas sólo a este uso. El objetivo de estas tiendas virtuales (generalmente canales B2C) es sólo la venta (clientes, productos y pedidos). No son herramientas de gestión globales y no contemplan muchos de los procesos internos: logística (albaranes, stock, transporte, ...), tarifas, generación de pedidos de proveedor, incidencias o relación con el cliente (CRM), ...

Para integrar nuestra tienda de comercio electrónico con nuestra herramienta de gestión (ERP) generalmente en el ERP se incorpora un módulo que realiza esta comunicación o sincronización. Uno de los errores de diseño de estos módulos es hacerlos independientes para cada software de comercio electrónico, cuando hay una base común en muchos softwares de comercio electrónico: el uso por parte del usuario y el código de ciertos procesos (buscar direcciones o clientes existentes, generación de pedidos, cálculo de impuestos, ...).

Para evitar esta duplicidad, en Tryton se ha diseñado un módulo que controla toda la base común de cualquier comercio electrónico, conocido como eSale. El módulo eSale contempla la gestión base de cualquier tienda de comercio electrónico, ya sea Magento, Prestashop, Amazón, Virtuermart, Drupal e-commerce, ... y para cada uno de ellos deberemos disponer de un módulo concreto que haga de capa de comunicación intermedia entre la tienda electrónica y el ERP (conexión vía webservices que es propio para cada tienda virtual).

También se ha dividio la gestión entre el ERP y la tienda virtual en varios módulos eSale. Aunque se recomienda que toda la gestión sea controlada por el propio ERP y no disponer de otras herramientas, algunos de los proyectos nos encontramos que ciertos procesos se realizan por terceras aplicaciones y integradas con la tienda electrònica. Un ejemplo típico es la carga de productos a partir de terceras aplicaciones.

Al tener cada proceso separado en módulos conseguimos no incluir ciertas gestiones en el propio ERP si no son requeridas. Esto conlleva que la gestión diaria sea más simple para el usuario con menos tareas a realizar (por ejemplo si no se gestionan productos para la tienda virtual, no hace falta instalar el módulo que incluye toda la gestión de importación y exportación de productos).

La práctica totalidad de las empresas de comercio electrónico que disponen de una o más tiendas virtuales tienen contratado los servicios de un transportista para el envío y entrega de las ventas al cliente. En algunos casos, estas mismas empresas transportistas gestionan el propio almacén de la empresa de comercio electrónico, de forma que se envía directamente. O el propio proveedor del producto lo envía directamente al cliente (proceso llamado Drop Shipment).

Aunque la propia tienda virtual disponga de módulos de conexión con los webservices de estas empresas de transportistas, se recomienda que no sea la propia tienda virtual quien realice el envío de los pedidos a los proveedores de transportistas. Veamos dos ejemplos de incidencias reales en el momento de procesar el pedido en el almacén:

• Que no haya stock de uno de los productos en el momento de empaquetar el pedido. Deberemos hacer envíos parciales o esperar que haya stock para envío completo.
• Que no todos los productos estén en condiciones de envío. En ciertos productos delicados puede pasar que en el proceso de empaquetar se rompan o debido a la fecha de caducidad no se puedan entregar.

Esto ocasionaría que la recogida por parte del proveedor se retrase unas horas (mañana o tarde) o incluso al día siguiente. Por esto es importante el envío del paquete sea en el momento de empaquetar el pedido, nunca antes. Cuando dispongamos el paquete listo para enviar es el momento que nuestro ERP puede dar la notificación de entrega al transportista.

Ya que existen muchos proveedores de transporte (Envialia, MRW, Seur, UPS, DHL, ...), se ha diseñado un módulo genérico que contiene la lógica para la gestión de envíos al transportista y sólo debe añadirse el módulo que hace la conexión con la empresa de mensajería o transporte mediante sus propios webservices. De este modo disponemos de la funcionalidad básica para cualquier envío y así la integración con un transportista en concreto es mucho más sencillo y menos costoso que desarrollar un módulo para cada proveedor de mensajería tal como se había realizado en el caso de OpenERP.

En el comercio electrónico son muchos los pedidos de venta que se quedan en estado borrador o pendiente por el motivo que no se ha realizado el pago. Muchas de estas veces es debido a que el usuario no finaliza el pago. Aquí van algunas razones:

• Ha tenido que realizar otra tarea y ya no se acordado de volver a realizar el pago.
• No se acuerda del usuario de Paypal.
• No dispone la tarjeta de crédito con la que desea realizar el pago.
• No dispone de la tarjeta de números para confirmar el pago.
• No dispone de batería en el móvil para recibir el SMS de la tarjeta de crédito.
• Final de mes. No hay saldo en la tarjeta de crédito.

El Apps OpenERP o Tryton Sale Payment ofrece un simple formulario web con el que introducir el número del pedido de venta, seleccionar el pago, y realizar el pago.

Esta plataforma, que se adapta perfectamente a tiendas electrónicas existentes, también es de utilidad para las empresas que realizan ventas de telemarketing. Estas empresas pueden generar pedidos de venta en tiempo real y ofrecer al cliente la posibilidad de pagar en ese momento sin la necesidad de usar un TPV físico, por ejemplo.

También, después de crear pedidos de venta, se puede enviar un correo electrónico con la información del pedido donde se incluya un vínculo con el que acceder a la área de pago rápidamente.

En qualsevol projecte web amb connexió amb l'ERP fem ús del que anomenem webservices que es connecten mitjançant una API. Això ens permet connectar terceres aplicacions en temps real al nostre ERP.

En el cas d'OpenERP disposem de:

• OOOP
• ERPPeek

En el cas de Tryton disposem de:

• Proteus

Per cadascun d'ells hem dissenyat petits scripts per realitzar una tasca i obtenir el temps necessari per executar-la.

Estem veient que el nou paquet ERPPeek ha superat el consolidat OOOP en molts tests, però en la cerca de molts registres li veiem un coll d'ampolla bastant gran.

real: 0m1.142s
user: 0m0.344s
sys: 0m0.024s

real: 0m0.118s
user: 0m0.072s
sys: 0m0.016s

real: 0m0.843s
user: 0m0.092s
sys: 0m0.200s

real: 0m1.088s
user: 0m0.344s
sys: 0m0.036s

real: 0m0.555s
user: 0m0.208s
sys: 0m0.032s

real: 0m0.785s
user: 0m0.208s
sys: 0m0.100s

real: 1m54.359s
user: 0m3.548s
sys: 0m0.268s

real: 7m54.161s
user: 0m6.272s
sys: 0m0.720s

real: 2m45.493s
user: 0m27.838s
sys: 0m0.288s

real: 0m58.620s
user: 0m1.444s
sys: 0m0.156s

real: 0m1.728s
user: 0m0.364s
sys: 0m0.036s

real: 0m0.600s
user: 0m0.068s
sys: 0m0.044s

real: 0m0.578s
user: 0m0.164s
sys: 0m0.132s

real: 0m1.660s
user: 0m0.348s
sys:0m0.036s

real: 0m0.471s
user: 0m0.072s
sys: 0m0.036s

real: 0m0.838s
user: 0m0.264s
sys: 0m0.120s

real: 0m1.172s
user: 0m0.344s
sys: 0m0.028s

real: 0m0.247s
user: 0m0.056s
sys: 0m0.028s

real: 0m0.593s
user: 0m0.184s
sys: 0m0.100s

Magento es una plataforma de comercio electrónico popular. Muchos de estas plataformas están pensadas para ser canales de comercio electrónico B2C (para clientes finales), pero no para entornos B2B (para distribuidores).

De todos modos, en Magento está disponible una funcionalidad que sería similar a un cana de venta B2B: Grupo de precios.

La opción de grupo de precios permite marcar un precio concreto según el grupo de cliente. A parte del precio por defecto o el precio especial, a cada grupo de Magento le podemos marcar un precio distinto.

Por ejemplo, si un usuario pertenece al grupo 'Retailer', el producto tenga un precio distinto que un usuario que pertenece al grupo 'NOT LOGGED IN'.

Podemos diseñar diferentes tarifas en nuestro ERP y asociar que tarifa se usará para calcular los precios de cada grupo de cliente de Magento. OpenERP puede calcular los precios de las tarifas a partir de precio de coste, precio de venta, a partir de otra tarifa, etc.

Está disponible la documentación OpenERP y Magento y Tryton y Magento sobre como se configuran y se utilizan los precios por grupo.

Ya hace más de año, el 16 de noviembre de 2011 iniciamos el proyecto OpenERP e-Sale (al principio se llamaba Zoook). Este proyecto apareció después de trabajar con conectores con tiendas virtuales como Magento o Prestashop (antes OSCommerce). El motivo es que la configuración de cualquier conector es complicada, sobretodo, si se desea personalizar. Por este motivo se ha desarrollado un nuevo proyecto de comercio electrónico en el que OpenERP es la base del proyecto.

Al cabo de unos meses ya teníamos OpenERP e-Sale implementado en varios proyectos, aunque cabe de decir que son tiendas más del estilo B2B que B2C. El sistema proporciona un sistema de recálculo de precios de producto, generación de líneas de pedido según stock y proceso de los pedidos de venta sin conectores.

Ahora hemos vuelto a revisar el mundo de las tiendas electrónicas sobre el lenguaje Python. Del proyecto Satchmo hemos pasado por LFS hasta encontrar Oscar Commerce.

Podríamos decir que a simple vista Oscar Commerce es buen sustituto de OpenERP e-Sale y de los conectores de Magento y Prestashop si son proyectos de nueva creación. Dos de los puntos claves de usar esta plataforma en nuestros servicios son:

• Plantillas Bootstrap. Fin de los sites únicamente para móviles. Con bootstrap podemos conseguir que nuestra tienda electrónica también esté optimizada para nuestros smartphones.
• Añadir funcionalidades extras en el código origen. Muy similar a la herencia que proporcionan OpenERP y Tryton, también podemos cambiar el comportamiento inicial. Por ejemplo, que los costes de envío provengan del ERP y no del propio Oscar Commerce.

Partiendo de la filosofía del código de Tryton que consigue que cada vez seamos más Pythonistas, nos ha inspirado para crear un nuevo paquete Python para la generación de una copia de base de datos para Tryton y OpenERP que es muy útil como entorno de pruebas o formación.

Hasta ahora la generación de una base de datos de copia se realizaba cuando se realizaba una copia de seguridad, normalmente cada día por la madrugada. Esto ocasionaba que cada día tuviéramos una nueva base de datos para hacer pruebas reemplazando la anterior, pero si el cliente necesita hacer pruebas durante varios días no le era útil. Además la generación de una copia de base de datos conlleva un tiempo y el tiempo de las copias de seguridad era mayor. Otro inconveniente era que el usuario no podía hacer un clon de su base de datos cuando quería y debía esperar al día siguiente.

Finalmente, después de estos inconvenientes, el equipo de Zikzakmedia hemos desarrollado el módulo Database Copy (dbcopy) que permite la generación de esta base de datos cuando se quiera. En un par de clicks y un café instantáneo ya se dispone de una nueva base de datos para pruebas. Este módulo usa el paquete erpdbcopy para la generación de bases de datos copia.

Antes de iniciar el 2013 deberemos realizar en nuestro OpenERP estas dos configuraciones extras:

Este mes hemos estado trabajando con una librería de Python para la comunicación con los servicios de Envialia (webservices). Envialia es una empresa de mensajería como Seur, MRW, Nacex, Tipsa, ... cuyos servicios son la recogida de paquetes en nuestro almacén y su entrega al cliente o bien ellos disponen de nuestro almacén y hacen entregas directamente a nuestro cliente. Este tipo de servicios es muy usado para empresas que se dedican al comercio electrónico, ya sea con la gestión de Magento, OpenERP e-sale o Tryton e-sale.

Todas estas empresas de mensajería disponen de su propio software para la gestión de paquetes en su plataforma. El inconveniente es que estas empresas usan tecnologías un poco obsoletas y tienen estos clientes disponibles sólo para escritorios Microsoft Windows.

La librería que hemos diseñado nos permite comunicar con el servicio de envío de Envialia para las siguientes acciones:

• Creación de entregas. Envío de nuestros albaranes a Envialia
• Listado de albaranes. Listado de albaranes entregados a Envialia por fecha
• Información del albarán. Detalles del albarán de Envialia
• Estado del albarán. Estado del albarán de Envialia
• Etiqueta del albarán. Etiqueta del albarán de Envialia (obtención de fichero)

Esta librería está disponible tanto para los ERPs Tryton como OpenERP, así como aplicaciones web Django o Flask.