Estos últimos días me han pedido sacar informes de un Magento. Ha sido muy interesante porque no me esperaba tener esta información en el CMS, pero sí, ahí estaba. Resulta que Magento viene con un atributo de coste de los productos, que es de sistema. Dicho atributo de producto tiene el código cost. Además, en la información que se guarda en cada pedido tenemos el precio original, este coste del sistema en el momento de la venta, y más información. Con esto podremos saber el margen de beneficio que hubo en el momento de la venta. Es importante notar que supongo que ya usas el atributo de coste del sistema, o que tienes un ERP enganchado a Magento que te lo está manteniendo actualizado con cada pedido de compra.
Magento
25 entradas
Magento es muy grande, aguanta carros y carretas, pudiéndole añadir gran cantidad de módulos. Uno de los proyectos en los que he participado alcanzó la friolera de 131 módulos, siendo algunos de estos módulos mega-módulos. Ha requerido mucho esfuerzo, todo hay que decirlo. Casi nunca suele ser “copiar y pegar los ficheros y ya está” como aquel que dice. Por el camino hay que resolver los conflictos, y tratamos día a día de evitar el añadir módulos si no es bien necesario. Hacemos limpieza de todos los que no se usen, y tratamos de actualizar todos los que se puedan, depende del tiempo que haya. Siempre surgen conflictos, y supone mucho tiempo hacer funcionar todas las opciones de ciertos módulos que entran en conflicto entre sí. Esto es el día a día del mantenimiento de los Magentos. Origen de los problemas Los desarrolladores hacen los módulos en un Magento limpio, recién instalado, sin que se requiera ningún otro módulo para su funcionamiento. Este es el entorno ideal, un Magento recién instalado. Pero la realidad nunca es así.
Es habitual que cuando haces cambios en Magento necesites flushear la caché. Esto es resetear, borrar los ficheros o datos temporales, que almacena Magento para agilizar sus tareas. Magento va guardando ficheros intermedios que se ejecutan más rápido que los originales. También guarda variables, combina ficheros de configuración de los módulos, traducciones, bloques, layouts de las plantillas, etc.. Todos estos ficheros agilizan mucho la ejecución, así que si no tienes la caché activada deberias de activarla ya mismo. Problema Puede ser que tengas que estar instalando y desinstalando módulos y de repente deja de funcionar Magento. Quizá has modificado en la base de datos algún dato y no se ven los cambios. O quizá incluso modificando algunos ficheros te deja de funcionar Magento. El problema viene cuando no puedes entrar al panel de control de Magento y darle al botón de ‘Flush Magento Cache’.
En el post anterior hablaba de cómo activar estas alertas, para que el cliente se pudiera registrar a las alertas por vuelta a stock de producto. Si tenemos activada esta opción deben de haberse apuntado los clientes interesados en ciertos productos que no tienes en stock ahora mismo. El siguiente paso es pedir productos a los proveedores..
Una opción muy interesante para tener activada en Magento es el dejar que los clientes se puedan suscribir a ciertas alertas por email. Estoy hablando de que si un producto se nos queda sin stock, que se muestre en el front y que el cliente pueda suscribirse para recibir una alerta cuando volvamos a tenerlo. Estas son las alertas por vuelta a stock de producto. Si tenemos los productos configurados para mostrarse en el front cuando están fuera de stock, podemos también dejar que el cliente pueda registrarse para recibir una alerta. Entonces, si el cliente se registra en esta alerta, cuando pongamos en stock el producto, recibirá un sencillo email explicándole que tiene el producto disponible para comprar. Mostrar productos fuera de stock o no en el front En Sistema > Configuración > Catálogo > Inventario > Opciones de existencias > Visualizar los productos agotados tenemos que ponerlo a Sí. De esta manera se verán en el front. Activar las alertas de vuelta a stock de productos En Sistema > Gestión > Catálogo > Catálogo > Alertas de producto > Avisar cuando el producto vuelva a estar en existencias lo tenemos que poner también a Sí. Terminando Con esto […]
Una información muy interesante para el equipo directivo de una empresa, puede ser simplemente el saber qué clientes son los más activos. Quizá queremos calcular un promedio de pedidos por cliente, cuántos intentos de pedido ha habido sin llegar a éxito, terminados en cancelación o no. Quizá sólo hacen un pedido y no vuelven más a la web. O quizá no suelen hacer ni un pedido, pero los que hacen pedidos suelen repetir… Esta información, y mucha más, es información necesaria para lo llamado como: Inteligencia de Negocio. Esta información, muchas veces no es suficiente con los reportes del panel del control, pero es bastante sencillo de sacar a partir de scripts en PHP. En el panel de control de Magento, podemos ir a la sección de Informes > Clientes > Clientes por total de pedidos, o a Informes > Clientes > Clientes por número de pedidos y veremos listados exportables como el siguiente: Los subreportes en Magento de casa están limitados a 5, por esto que sólo verás 5 resultados por día o por mes. Lo que no veo, por ejemplo, es que no salen los clientes con 0 pedidos, tampoco tengo emails ni teléfonos para arrancar acciones comerciales. […]
Hoy traigo otro code-kata, esta vez para Magento y hecho en PHP. Se trata de un simple script que se lanza en línea de comandos. Con este script obtendremos primero todos los métodos de pago que se han usado al hacer los pedidos. Después, haremos un listado, por método de pago, y entre ciertas fechas, del monto de pedidos completados por método de pago. Es decir, supongamos que queremos saber cómo han ido las ventas con el método de pago por tarjeta de crédito. O quizá queremos saber si la financiación es un método de pago que funciona bien. O quizá simplemente queremos tener el total de ventas entre fechas. Pues todo esto es bastante sencillo sabiendo donde está cada cosa. Métodos de pago usados en pedidos A saber, los pedidos en Magento 1 guardan parte de sus datos principales en la tabla sales_flat_order. La información del método de pago utilizado en cada pedido se guarda en la tabla sales_flat_order_payment. Entonces, sacando la columna method de la tabla sales_flat_order_payment tendremos todos los métodos de pago utilizados en los pedidos. Esto en lenguaje SQL queda así: SELECT distinct(sfop.method) FROM sales_flat_order_payment sfop ORDER BY sfop.method ASC; Ventas de los pedidos enviados El […]
Hoy traigo otro pequeño HOWTO para trabajar con las numeraciones internas de Magento 1.9. Los pedidos, envíos, facturas y abonos se pueden numerar. Se pueden poner prefijos por defecto, o a nivel de store, puedes seleccionar distintos prefijos y numeraciones. En un Magento original sólo te permite hasta una numeración por store para facturas, abonos, envíos y pedidos. Esto incluso se puede mejorar haciendo varias numeraciones por store, pero ya no es una configuración normal. Para hacer 2 numeraciones de facturas en una misma store habrá que controlar el evento de creación de facturas, para así ir reenumerando ‘al vuelo’, mediante programación. La tabla con las numeraciones Se trata de la tabla eav_entity_store, por ejemplo: Las numeraciones siguen todas la misma estrategia. En la columna increment_last_id tendremos el último elemento numerado. Por ejemplo, miremos el último pedido numerado es el P00127586, cuyo prefijo que lo tenemos en la columna increment_prefix es el P. Entonces nos queda que el número 00127586 es la numeración. Para calcular el siguiente le suma 1 y le vuelve a poner el prefijo. Por ejemplo, si hacemos lo mismo con la última fila, tenemos A18X010000 es el último incremento usado. Su prefijo es el A18X, con […]
Puede ser que necesitemos en Magento alguna forma de almacenar datos globales, es decir, que no son relacionados con ningún otro elemento individual. Todo o casi todo en Magento tiene atributos: los productos, clientes, pedidos, direcciones, facturas, abonos, etc.. Pero para almacenar estos atributos globales tenemos dos opciones, o los guardamos como variables de configuración o como variables del core de Magento. La diferencia es que las variables de configuración se cachean y las del core no. Muchas de las variables de configuración se pueden gestionar desde el panel de control en Sistema > Configuración. Si modificamos mediante código las variables de configuración no se refrescarán los datos, sin embargo si modificamos las variables mediante el panel de control casi todas se refrescan en el momento. Sin embargo con las variables del core esto no pasa.. conforme se guardan se tienen actualizadas al consultarlas de nuevo. Usar variables del core provoca más consultas a la base de datos, sin embargo, las variables de configuración se actualizan sólo cuando se refresca la caché de variables de configuración.
Es el gran dilema en el desarrollo de aplicaciones web. Te hablan sobre un proyecto; con unos requerimientos, unas especificaciones. Debes elegir con las premisas que te dan: presupuesto, tiempo de entrega, calidad, flexibilidad, mantenibilidad, practicidad.. ¿Existe ya una solución para el proyecto? ¿Se puede partir de un CMS y modificarlo? ¿Son demasiadas las modificaciones que se van a hacer al CMS? ¿Es viable partir de un framework de calidad? ¿Buscamos máxima calidad, o menor precio? ¿Hay muchos desarrolladores disponibles en el mercado para mantener el proyecto?
He recibido una consulta sobre cómo sacar el ciclo de ventas de Magento. Ya respondí, pero los cálculos no me salen exactos. Así que jugando, jugando.. he tratado de encontrar cómo Magento calcula el ciclo de ventas que vemos en el panel de control. Como no me daba exacto, he recorrido después las facturas, que tampoco me daba exacto. Y después añadí el recorrido de los abonos. Con y sin impuestos, tampoco me daba la misma cifra. Balanceando facturas con abonos, con y sin impuestos, que es lo correctamente contable tampoco me salía la misma cifra, aunque se iba acercando.. Conclusión, que en una tarde recorriendo los pedidos, facturas y abonos, no salen los mismos cálculos que te muestra Magento en el panel de control. Pero aquí dejo la información para el que le pueda servir 😉 de todas formas, contablemente, lo correcto son contabilizar las facturas y abonos.
Montar una web con lo imprescindible, ponerle el contenido y diseño, y olvidarnos de ella.. sería como comprarnos un coche y ya no preocuparnos nunca por pasarle una revisión. Sería como si nos diera igual si hay una bajada de potencia del motor, que las ruedas no estuvieran bien hinchadas. Quizá una bujía deja de dar los chispazos al 100%.. Y no sólo están los problemas de mal-funcionamiento, sino que quizá también hay algunas mejoras extras. No todo viene de casa, y puedes hacer que el coche vaya mejor. ¿Porqué no entonces dedicarle ese tiempo a nuestra web para revisar esas cosas? Es más, ¿porqué no poner a un mecánico que sepa lo que está haciendo? Está claro que nos podemos quedar tal cual, nuestro coche andará. Pero queremos que no le falte esa alegría, que responda sin pereza. Resumiendo, queremos que la maquinaria esté bien engrasada, sacando el 100% de su rendimiento. Entonces necesitaremos a un especialista que toque, pero no de oídas, sino que sepa lo que está tocando.