Las distintas formas y maneras que tenemos los seres humanos de expresar las unidades de tiempo, medida, precio… son una maldición bíblica real. Una de las cosas más veraces que he leído en la Biblia es la historia de la torre de Babel.
Si tuviésemos un idioma común y una forma común de expresar las unidades de tiempo, medida, distancia, tamaño… ahorraríamos un tiempo y unos esfuerzos ingentes en todo el mundo.
Esto viene a cuento de que he estado un día entero peleándome con la Excel, mi programa de gestión y el Zencart, por culpa de un quítame aquí esas comas y cámbialas por un punto. Me explico: como os dije la semana pasada, estoy terminando la versión digital de nuestra tienda. Anteayer me puse a pasar los artículos desde nuestra aplicación de facturación y presupuestos al Zencart. Cuando me puse a comprobar si los precios estaban correctos, vi algunos errores en ellos. Los errores eran provocados porque el software de importación de la tienda redondeaba los precios, es decir no tenía en cuenta los decimales en los precios que yo le enviaba.
El sistema de importación de precios es algo complejo, desde mi aplicación paso los artículos a un fichero de Excel. Lo abro con la Excel, le cambio el nombre a las columnas y lo exporto a ficheros TXT, los TXT lo coge el Zencart y los introduce en su base de datos. Pues el problema era que mi aplicación y mi Excel daban los precios con la coma “,” como separador decimal y el Zencart esperaba un punto “.”. Tras perder un montón de horas en mi aplicación… que mejor no contar, la solución fue muy sencilla, cambie los parámetros de la Excel y los puse en modo americano, y automáticamente tenía el punto como separador decimal.
Y esto me ha pasado con una sencilla aplicación de carro de la compra, no quiero ni pensar las horas de programadores y de usuarios que perdemos por ahí por culpa de que alguien espera la fecha en formato mes-día-año, otros la esperan en formato año/mes/día…
Lo dicho para algunas cosas nada mejor que estandarizar la información.
9 Comentarios
Comentarios Cerrados
Dices que “Lo abro con la Excel, le cambio el nombre a las columnas y lo exporto a ficheros TXT”
Yo hubiese cambiado la coma por puntos en el txt directamente. Con un simple editor buscar y reemplazar y listo. 🙂
El problema corsaria serían entonces los nombres de los productos, familias, subfamilias, descripciones si las hay…
Corsaría: ratón ha contestado antes que yo. De todas maneras, en la entrada el proceso está muy simplificado, porque lo de los TXT es otra historia. Si los genero directamente desde mi aplicación, cuando los coge el Zencart la cosa no va fina del todo. Si los paso por el OpenOffice, lo mismo, al final me toca tener el Excel solo para esta tarea… es el único que genera el TXT como el Zencart tiene… lo cual también tiene delito.
Vaya, se me escapó ese detalle, claro, las comas las usa también para separar familias, productos, etc.
Esa “integración” excel+zencart si que tiene delito. 🙁
Bueno, supongo que tu aplicación trabaja con una bbdd, yo en esos casos siempre trabajo con texto, es más flexible. El procedimiento suele ser hacer la consulta directamente sobre la BBDD con SQL estándar, redirigir a un fichero, le pones a la consulta los parametros correctos para que no salgan por ejemplo delimitadores, lineas de division, cabeceras, resumen de filas, etc, que te salga una tabla tal cual, tabulada. Una vez tienes eso, el poder es tuyo, por ejemplo con ‘sed’ y ‘cat’ se puede hacer verdaderas virguerías y dejar el fichero tal cual lo quieras. Además si quieres luego usar Excel (yo no acostumbro, 🙂 el importador de txt es más que decente con lo que te reconoce las filas y columnas, puedes decirle cual es el delimitador, etc.
En fin, que soy un forofo del texto puro, sobre todo para extraer de un sitio y meter en otro. Si las dos BBDD son la misma ni que decir que te estas complicando la vida innecesariamente, pero vaya, no creo.
Kike: muy buena explicación. Mi origen no está en SQL, mi destino si que está en MySql, pero el componente de importación trabajo con ficheros TXT como entrada. Cuando he probado a generar lo TXT directamente yo, no consigo que el importador los reconozca, solo cuando los mando desde la Excel.
Reconozco que si dedicase unos días a estudiar la estructura del MySql del Zencart podría montar algo de forma directa, pero como siempre vamos con poco tiempo… pues vamos a soluciones ya hechas, pero que al final provocan algo de ruido.
dios, como me he reido al leer esto… me ha pasado exactamente lo mismo hace 4 horas… y tuve que cambiar mas de 40 puntos por 40 comas.
Lo mas grave es que el problema lo genero mi profesor de universidad, no una empresa yankee hni nada.
Si tu destino está en MySQL hacer los INSERTS no es muy complicado. Tienes que tener en cuenta que el script lo harás una vez y lo usarás con TODOS los registros. Zencart tendrá sus tablas y sus scripts de importación con lo que solo tendrías que ver que hacen sus scripts.
Lo complicado del asunto es dejar un txt que zencart entienda, para eso solo hay que fijarse en como deja Excel los txt y que separador de columnas usa.
Es un poco paradójico que el proceso sea tan dependiente de dos aplicaciones que no trabajan nativamente con texto sin formato. ¿Como está la información actualmente en el origen?¿Son tablas Excel?
Kike: la información en el origen son tablas DBF. La solución que apuntas es la mejor. El problema es que para dar de alta a un artículo en Zencart se hacen una serie de comprobaciones: familia, fabricante, tarifa… y luego tiene una buena colección de tablas solo para el artículo: descripción, código, descuentos… y pasa lo de siempre, probé un complemento que funcionaba bien y era rápido… pero de todas maneras lo estoy pasando mal para la primera carga, luego solo hay que mantener los precios y para eso si que voy directamente a la tabla de precios (pero repasaré antes el formato de dichos precios).