|
|
|
Lo que entregamos · No. 07 · 7 al 11 de septiembre 2026
Una sola regla,
un solo lugar.
Varias entregas de la semana mueven una regla a un único dueño. Las fechas críticas de un contrato de mall se calculan en el servicio de contratos, así que Nexum y Beaver no pueden mostrar fechas distintas del mismo documento. Helix quedó como dueño de quién aprueba una compra, y Atelier consulta esa lista en vez de mantener la suya. Y en Atelier la regla de qué archivo viaja al proveedor pasó a vivir en un solo lugar, en vez de deducirse en cada consumidor.
En Nexum, las comisiones de agosto quedaron cerradas y reliquidadas con la regla de sobrecumplimiento que definió el negocio: el jefe de tienda cobra la venta de su local el mes completo, y del subjefe hacia abajo la venta individual, con la de la tienda solo los días en que el reemplazo está registrado y aprobado.
Y la reportería de tiendas quedó cuadrada contra sí misma, pantalla por pantalla: se midió la misma venta en cada reporte que la muestra. Es el cuadre que una comparación reporte contra reporte no ve, y es lo primero que mira el usuario.
|
🎯 Séptima edición · Newsletter interno Badamax Tech
|
|
|
|
$0
Neto de agosto en Nexum tras
reversar la centralización
|
|
|
72
Locales con sus fechas de contrato
en la matriz de Beaver
|
|
|
40 s
Búsqueda de cancelaciones en
Gate, antes 54 minutos
|
|
|
|
|
57
Cambios pasados a producción
en la semana
|
|
|
433
Documentos de artículo
clasificados por rol en Atelier
|
|
|
1.352
Líneas de código retiradas en el
rediseño de cotizaciones de Atelier
|
|
|
|
|
Palabras de apertura
La misma regla en dos lugares termina siendo dos reglas.
Mauricio Álvarez
Chief Digital Officer
Badamax
|
"Atelier mantenía su propia lista de aprobadores y Helix la suya. No fallaba nada: simplemente se le pedía la firma a gente que ya no estaba en el grupo. Ese es el costo real de duplicar una regla — no un error visible, sino una decisión tomada sobre información vieja. Por eso esta semana varias reglas se movieron a un único dueño: quién aprueba una compra vive en Helix, las fechas de un contrato se calculan en el servicio, y qué archivo viaja al proveedor se decide en un solo lugar. Todo lo demás consulta."
|
|
|
|
En este número
Diecisiete frentes de trabajo.
|
01 Atelier y Helix · Cotizaciones
02 Atelier · Documentos del artículo
03 Atelier · Confirmaciones de PI
04 Atelier · Composiciones
05 Beaver · Contratos de mall
06 Nexum · Comisiones de venta
07 Nexum · Centralización
08 Nexum · COMEX
09 Gate · Gestión de Personas
|
10 Gate · Despachos de marketplace
11 Gate · Retiro en tienda
12 Reportería · Cuadre entre pantallas
13 Reportería · Book y promociones
14 Qlik · Metas y calendario
15 Plataforma de datos
16 Explorador de Datos
17 Proyectos e iniciativas
|
|
|
|
🤝
|
No. 01 · Atelier y Helix · Compras
Un mismo artículo se cotiza a varios proveedores.
|
El cambio más grande de la semana está en el flujo de cotización de Atelier: la cotización pasó a ser una entidad propia. Antes los artículos colgaban de una canasta y cada cotización derivaba sus líneas de ahí, así que un artículo no podía estar en dos cotizaciones a la vez — el sistema lo escondía para impedirlo.
| Ahora cada cotización tiene sus propias líneas, y un mismo artículo se puede cotizar a varios proveedores en combinaciones distintas, repartiendo el volumen entre ellos. Aprobar también cambió de forma: en vez de elegir qué artículos entran, se quitan los que no van. |
| Se aplicó sin detener el servicio. El cambio tocó el modelo de datos y salió con dos migraciones, ensayadas dos veces sobre un respaldo de producción antes de aplicarse, con las copias escritas de manera que la versión anterior siguiera leyendo las mismas filas mientras ambas convivían. Junto con eso se retiraron 1.352 líneas de código que ya no se ejecutaban. |
| Quién aprueba una compra se movió a Helix. Atelier mantenía su propia lista de aprobadores, que había quedado desactualizada, mientras el mantenedor de Helix mostraba a los vigentes. El desfase no producía ningún error: simplemente se le pedía la firma a personas que ya no integraban el grupo. Helix quedó como dueño de los grupos y de las firmas, y Atelier consulta y cierra según esa respuesta. |
| En Helix, la pantalla de aprobación muestra la cotización artículo por artículo, con las diferencias de color respecto de lo planificado, las fechas del plan y el comentario del planificador. Antes mostraba solo un cruce por familia. |
| En el correo al proveedor, los archivos adjuntos ahora viajan con el mensaje y se muestra su peso. La cotización quedaba registrada como enviada y el correo salía sin la ficha técnica ni la planilla de medidas. El peso importa: una ficha técnica pesa entre 3,9 y 18 MB, así que con dos artículos el correo supera el límite. |
|
|
|
📎
|
No. 02 · Atelier · Diseño
Cada documento declara qué es, y el Size Spec llega al proveedor.
|
En Atelier, el sistema guardaba el formato del archivo y cada consumidor deducía por su cuenta cuál era la ficha técnica. El correo de cotización filtraba con la regla "todo PDF es una ficha", y funcionaba por coincidencia: medido en producción, los 433 documentos cargados son todos PDF y todos son la ficha técnica. Ahora el documento se clasifica al cargarlo —ficha técnica, Size Spec u otro— y la regla de qué viaja al proveedor vive en un solo lugar.
| El Size Spec viaja adjunto a la cotización — el caso que la regla anterior habría salteado sin avisar, porque al ser un Excel y no un PDF nunca se habría adjuntado. Para eso se habilitó la carga de archivos Excel en Atelier, que hasta ahora solo aceptaba imágenes y PDF, así que el Size Spec ni siquiera se podía subir. |
| El nombre del archivo sale del propio documento. El correo forzaba la extensión de PDF sobre todo lo que adjuntaba, de modo que un Size Spec habría llegado al proveedor con doble extensión. |
| Ante lo desconocido, el criterio es conservador: un documento sin clasificar no se envía. Es preferible que falte un adjunto a mandarle a un proveedor un archivo que no corresponde. Y los documentos duplicados quedaron visibles — un artículo tenía dos PDF cargados, uno de ellos de otro artículo por un error de carga. La clasificación no adivina cuál es el correcto: los deja a ambos como ficha técnica, y el valor está en que ahora se ven. |
| Se conservó el resguardo de la clasificación, que estaba marcado para eliminarse una vez desplegados ambos sistemas. Con los dos arriba se revisó antes de sacarlo y se confirmó que sacarlo era un error: el guardado del artículo es un reemplazo total, así que ante una vuelta atrás del servicio cada artículo guardado en esa ventana habría quedado con su ficha técnica reclasificada como "otro", de forma permanente y sin aviso, dejando de adjuntarse a sus cotizaciones. |
| El aviso de peso de los adjuntos ahora dice algo accionable. Cuando los adjuntos automáticos por sí solos superan el límite, el mensaje culpaba a archivos que nadie había elegido y se contradecía —decía que lo elegido sumaba 0 MB y aun así se pasaba—. El caso se vuelve frecuente con el Size Spec: un solo artículo con ficha y medidas supera el presupuesto del correo. El mensaje nuevo dice cuánto pesa el correo de por sí, por cuánto se pasa, y nombra las dos salidas reales: aligerar los documentos del artículo o cotizar menos artículos por correo. |
|
|
|
📄
|
No. 03 · Atelier · Confirmaciones de PI
Cada PI queda asociada a su proveedor.
|
| Al guardar en Atelier, la PI llega con el proveedor ya propuesto según el nombre del documento. Queda como columna y filtro en el listado, y la cronología registra cada cambio de asociación. |
| Una tercera marca que no existe dejó de aparecer en el listado: un error de tipeo en el nombre de una marca real creaba una entrada propia con 1 PI, 2.970 unidades y USD 77.457. Ahora colapsa a la marca correcta. |
| La cronología abre siempre: un tipo de evento nuevo tumbaba el panel completo. |
|
|
|
🧵
|
No. 04 · Atelier · Composiciones
Las composiciones con decimales se leen completas.
|
| Atelier leía de forma incompleta las composiciones que SAP escribe con decimales, y devolvía una mezcla distinta de la real. Se midió dos veces en modo solo lectura sobre el catálogo completo —953 artículos antes del cambio y 955 después—: los 10 artículos con composición decimal devuelven ahora sus tres componentes sumando 100%. |
| El arreglo corrige las lecturas nuevas pero no repara las que ya estaban guardadas, así que quedó documentada la vía de limpieza sin tocar la base de datos: abrir la composición del artículo en Diseño y guardar sin modificar nada —ahora resuelve correctamente— y recién entonces eliminar la composición pendiente desde la pantalla. |
|
|
|
🏢
|
No. 05 · Beaver · Contratos de mall
Toda la red de locales en una matriz.
|
Nueva vista en Beaver: una fila por cada uno de los 72 locales de la red y una columna por cada fecha crítica del contrato —inicio de vigencia, término, aviso de salida, salida anticipada, renovación y remodelación—. Permite comparar toda la red de un vistazo en vez de abrir contrato por contrato.
| Solo dos de esas seis fechas están guardadas; las otras cuatro se calculan a partir de las cláusulas —meses de vigencia, días de aviso, ventanas habilitadas—. Ese cálculo quedó en el servicio de contratos y no en la pantalla, así que Nexum y Beaver no pueden mostrar fechas distintas del mismo contrato. |
| El semáforo mide el plazo de aviso, no la vigencia. Un contrato puede estar perfectamente vigente y haber perdido igual la ventana para avisar la salida — ese es el caso que hace perder capacidad de negociación con el mall, y es el que la pantalla pone primero. Cinco estados: vencido, sin margen para avisar, avisar ya, preparar aviso y en plazo, con los mismos umbrales que el correo de alertas de Nexum, que se siguen administrando en un solo lugar. |
| Tres accesos directos por tipo de decisión: salida (ventana vigente), renegociación (vence dentro de 12 meses o ya sin margen) e inversión (remodelación comprometida). El filtro de período se aplica sobre la fecha que uno elija, porque "qué vence entre marzo y junio" y "a qué tengo que avisar entre marzo y junio" son preguntas distintas. |
| Concentración de vencimientos por año —cuántos contratos vencen y cuánta renta representan, clickeable para filtrar— y resumen por administradora de mall, con renta total, próximo vencimiento y cuántos locales están sin margen, para negociar por bloque en vez de contrato por contrato. Suma también los montos: renta mínima en UF, superficie, garantía y el recargo por no remodelar. Los contratos totalmente variables se muestran vacíos y no como cero. |
| La pantalla declara qué dato falta y por qué, distinguiendo tres casos que antes se veían iguales: el contrato no lo contempla, falta cargar el contrato, y hay contrato pero falta re-extraer las fechas. Sin eso, una fila vacía se leía como "no aplica" cuando en realidad era un hueco de carga. Se exporta a Excel lo que quede filtrado, en tres hojas —matriz, resumen por operador y parámetros aplicados—, pensado para llevar al comité. |
|
Lista de carga para Nexum
La pantalla marca uno por uno los locales por completar: 9 sin contrato cargado y 6 con contrato pero sin fechas extraídas. Además, 31 de 59 contratos no declaran el plazo de aviso y se usa el valor por defecto de 6 meses —esas fechas son estimación y la pantalla lo advierte—, y solo 9 de 40 locales con remodelación obligatoria tienen declarado el recargo por incumplir. Los tres casos se resuelven re-extrayendo en Nexum.
|
|
|
|
💳
|
No. 06 · Nexum · Comisiones de venta
Agosto quedó cerrado y reliquidado.
|
| En producción en Nexum, el sobrecumplimiento con la regla nueva por rol: el jefe de tienda cobra la venta de la tienda el mes completo y nunca su venta propia; del subjefe hacia abajo se cobra la venta individual, y la de la tienda solo los días en que el reemplazo de la jefatura está registrado y aprobado. |
| Quién se lleva el componente de tienda depende del rol que se cubre, no del tipo de solicitud: los traslados y los cambios de cargo también entregan la jefatura. Verificado contra el mes cerrado. |
| Incidente detectado y cerrado: un grupo de movimientos de personal perdió su estado de aprobación de un día para otro. Los motores de comisión solo pagan sobre movimientos aprobados, así que agosto quedó por debajo de lo que Remuneraciones había bajado. Se restauraron las aprobaciones y se reliquidó el mes completo; lo que queda por mover a mano está identificado persona por persona. |
| La alarma que vigila esos movimientos se movió antes del pago. Corría después de la cadena que paga, así que avisaba cuando el pago ya estaba publicado y servido; ahora frena en vez de dejar constancia. |
| La meta de la tienda dejó de depender de que exista un jefe cargado: hay tiendas sin nadie homologado a jefe de tienda, y esos días la meta desaparecía. Ahora se lee del dato de la tienda, que tiene cobertura completa. El reparto de la meta por hora se acotó al horario operativo en las dos ramas —tienda y persona—, y se corrigió toda la historia, no solo lo que viene de aquí en adelante. |
| Se recuperó la asistencia anterior a febrero de 2026, que había quedado en el sistema antiguo de marcaje. Con eso se puede reconstruir la meta por persona de los meses previos, que hasta ahora tenían un techo. Y en el reporte de comisiones, la columna de factor de sobrecumplimiento salía en cero para todo el mundo: corregida. |
|
|
|
📘
|
No. 07 · Nexum · Remuneraciones
La reversa se contabiliza en su propio período.
|
| En la centralización de Nexum, el asiento espejo se fechaba con el día del clic, así que cancelar agosto en septiembre dejaba el cargo en agosto y el abono en septiembre: agosto no quedaba en cero y septiembre arrastraba un abono que no correspondía. Ahora la reversa se contabiliza en el período original. Ya se usó en producción sobre agosto 2026 —1.697 líneas por $611.562.726— y el mes quedó en neto $0. |
| Historial por período: cada fila abre el detalle completo —quién sincronizó, quién creó los empleados, quién cargó a SAP, quién canceló y quién volvió a centralizar—, con fecha, hora, autor y el número de asiento de cada movimiento, incluido el del asiento inverso. |
| Una columna nueva muestra cuántas veces se centralizó cada período y en qué posición está cada fila. Y los errores también quedan registrados: si falla la traída desde el sistema de personas, la creación de empleados o la carga a SAP, queda en el historial con el motivo en vez de perderse. |
|
|
|
🚢
|
No. 08 · Nexum · COMEX
El atraso del embarque se recalcula solo.
|
| En Nexum, al cambiar la fecha de embarque el indicador de días de atraso quedaba con el valor anterior y había que reabrir y volver a guardar para que se actualizara. Se encontraron 48 filas en producción con el número equivocado, con desvíos de 9 a 60 días. Ahora se recalcula solo y el distintivo indica contra qué fecha comparó. |
| Se retiró un aviso que aparecía sobre datos correctos tres de cada cuatro veces: la advertencia de que el embarque de referencia ya no existía salía en 132 de 180 filas sin motivo. |
| Las PIs que en realidad son un estado se pueden ocultar: aquellas cuyo número es un texto como cancelado, eliminado o sin unidades ensuciaban la plantilla — son 79 PIs y 125 filas en producción. Quedan ocultas con un interruptor para volver a verlas. |
| Los documentos se descargan con su nombre real desde las dos vistas; antes bajaban con el nombre interno del servidor. Y se agregó un transportista nuevo al catálogo. |
|
|
|
🧑💼
|
No. 09 · Gate, Helix y Nexum · Gestión de Personas
La tienda crea y corrige sus propias solicitudes.
|
| Lo que puede hacer la tienda |
| Una solicitud en Gate era inmutable: si la tienda se equivocaba había que esperar el rechazo y rehacerla, y estas solicitudes mueven cargo y comisión. Mirado de cerca, la tienda tampoco podía crear — no había ninguna ruta de escritura habilitada. Ahora la tienda crea y edita, editar una aprobada la devuelve a pendiente, y el cambio queda con su detalle legible en el registro. |
| Pedir un reemplazo porque la persona está con licencia vuelve a ser posible — el caso de uso más común del módulo se rechazaba justamente por tener licencia en ese rango. Ahora se separa el conflicto que bloquea del que solo informa, según el tipo de solicitud y de quién se trate; el formulario los muestra en cajas distintas y el criterio lo pone el servidor. |
| El supervisor deja de estar acotado por jerarquía. El alcance salía del sistema de personas, y los supervisores que no se resolvían caían a la rama corporativa y veían todo, así que el único restringido era aquel cuya ficha estaba bien cargada. Es además la definición del cargo: si uno falta, otro tiene que poder cubrirlo. |
| La nómina entró al módulo como primer tab: era un ítem suelto del menú de Gate y consultarla obligaba a salir de Gestión de Personas, siendo la lista sobre la que se opera. En paralelo se construyó la conexión con la fuente nueva y su banco de pruebas de cuadratura, sin conectar nada todavía — medir antes de mover. |
| Que el verde signifique algo |
| La integración con el sistema de tienda ahora se comprueba: se marcaba sincronizada aunque nadie hubiera verificado que el movimiento llegó. Un proceso relee al empleado y compara tienda y cargo; como tarda minutos, la comprobación va en diferido y el estado intermedio se rotula "Validando sincronización" en vez de un verde anticipado. Lo mismo con el sistema de asistencia, donde una llamada sin error no prueba que el cambio quedó — hubo una sincronización marcada correcta cuya información horas después seguía apuntando a la tienda de origen. |
| Una solicitud ya no se puede aplicar dos veces a la vez. Aplicar tarda unos quince segundos y el estado recién cambia al final; en esa ventana la misma fila seguía siendo candidata para el proceso automático, para el botón y para otro servidor. Ahora se toma una marca de "en proceso" con vencimiento, para que un servidor caído no la deje trabada, y quien pierde recibe un mensaje claro. |
| Reintentar un traslado dejó de chocar contra sí mismo: se comprobaba el vínculo de la tienda de origen pero nunca si el de destino ya existía, así que el reintento enviaba un duplicado que el sistema de tienda rechazaba — y el motivo del rechazo se descartaba, dejando solo un código. Ahora hay guarda de duplicados y el mensaje incluye la respuesta recibida. |
| El envío por lote al sistema de tienda pasó de dos minutos a 30 segundos. Se trataba como fallo algo que no lo era —el archivo ya estaba en una carpeta que el proceso levanta solo— y se esperaba el tiempo completo sin ganar información; además dos operaciones simultáneas se pisaban el archivo porque la ruta es fija. Ahora se tolera esa espera, se serializan subida y ejecución en una cola, y el resultado es el mismo con cuatro veces menos espera. |
| Si la conexión se corta durante esos segundos, la pantalla explica lo que importa —sin respuesta no se puede concluir que no se aplicó— en vez de un error crudo del navegador, y ofrece un botón de reintento con el aviso de que nada lo hace solo. Y un movimiento de un día alcanza a cubrirse: se restauraba en la madrugada del mismo día, así que el colaborador volvía a su cargo original antes de que abriera la tienda. |
| Remuneraciones ve los movimientos desde Nexum, en solo lectura garantizada en dos capas: la interfaz no dibuja acciones y el intermediario acepta únicamente lecturas, así que la garantía no depende de la pantalla. Impactan la nómina, pero abrirles Gate no correspondía. |
| La copia del módulo que vive en Helix quedó documentada y sincronizada. Su documentación no la mencionaba ni una vez, así que quien tocaba Gate no tenía cómo enterarse — se desincronizó al menos dos veces, una con un error de fechas que mostraba las vigencias un día antes. Quedó escrita la receta de re-copiado, la única diferencia legítima y el comando que verifica la sincronía en un paso; se portaron los seis arreglos de la semana y se ocultó desde Helix el interruptor de escritura, que es un control de Gate. |
| Los procesos automáticos dejaron de tomar movimientos que ya habían ocurrido: no filtraban por origen y procesaron 52 registros migrados del sistema antiguo, que son la constancia de cosas hechas hace meses. Se agregó el filtro por origen y una recuperación que restaura el estado anterior leyendo el registro sin borrar la traza. Y ahora se puede re-migrar un movimiento puntual sin tocar los otros 3.700, para cuando el sistema antiguo edita algo ya migrado. |
|
|
|
🏷️
|
No. 10 · Gate · Despachos de marketplace
Cada pedido se confirma por separado.
|
| El reintento de etiquetas en Gate tenía tres defectos que se alimentaban entre sí: el filtro de candidatos no descartaba las órdenes ya entregadas o canceladas, cuando un lote no producía nada se marcaba a todos como fallidos sin registrar el motivo —y un fallido vuelve a ser candidato—, y el lote era solidario, así que un único pedido cancelado de meses atrás impedía que los otros ochenta y cinco recibieran etiqueta. Ahora se excluyen los estados finales, se lee el motivo que ya venía en la respuesta, se confirma pedido por pedido y se filtra de entrada lo que no va a resolverse en ese ciclo. |
| El descubrimiento de pedidos sin etiqueta se invirtió: para arreglar uno se dependía de un listado del marketplace que justamente no incluye a los pedidos sin etiqueta, y cuando ese listado dejó de indexar, algunos nunca recibieron etiqueta y por lo tanto nunca llegaron a la bodega. La consulta ahora arranca de nuestra propia base y la conexión del pedido se resuelve en cascada, sin llamadas extra. |
| Las cancelaciones del marketplace ahora cierran el pedido, incluso cuando llegan después de que avanzó. La búsqueda pasó de 54 minutos por corrida a 40 segundos, se lee por la vía que no se traga el dato en silencio, y el cierre no depende de un solo aviso externo que a veces no vuelve. |
| El transportista del despacho same-day quedó configurable: lo elige Gate y no el integrador, y estaba fijo en el código, así que cambiarlo exigía desplegar. |
|
|
|
🏬
|
No. 11 · Gate · Retiro en tienda
Cada retiro llega a su tienda.
|
| El sistema de tienda trata la nota de pedido como única, así que un pedido con dos retiros en locales distintos enviaba la misma nota dos veces y la segunda rebotaba — esa tienda nunca veía su retiro. Ahora la nota lleva la tienda cuando hay más de un retiro. Y cuando la nota ya existía, la integración quedaba sin registrar y se reintentaba indefinidamente: ahora se registra como integrada. |
| Una tienda con la bandeja vacía volvió a ver sus pedidos para preparar: el intermediario filtra por la identidad del local cuando quien consulta es una tienda, y esa identidad apuntaba a otro local. Corregido y verificado midiendo contra producción. |
|
|
|
📊
|
No. 12 · Reportería de tiendas
La misma venta pesa igual en cada pantalla.
|
Se midió la misma venta en cada reporte que la muestra y da el mismo peso en todas. Las dos diferencias que aparecieron quedaron explicadas: un filtro horario del propio reporte y una diferencia ya declarada del detalle de productos. Es el cuadre que una comparación reporte contra reporte no ve, y es lo primero que mira el usuario — si veo la venta en una pantalla, en la de al lado tiene que ser la misma.
| En el ranking de tiendas la meta se estaba midiendo con el grano de persona, y una persona sin marca de asistencia ese día queda sin meta mientras la tienda sí la tiene. A la tienda se le perdía esa meta y el orden del ranking salía alterado — la mayoría de las tiendas cambiaba de posición. Corregido y verificado en producción; lo detectó el usuario mirando una tienda puntual. En el detalle por vendedor, la fila con el total de la tienda tampoco estaba sumando. |
| Los días con el contador de tráfico caído muestran "no aplica" en la conversión, en vez de un porcentaje que induce a error: esos días el tráfico se completa con una estimación, así que la conversión no es lo que la tienda convirtió sino una constante que inyecta el propio proceso. Replicado en las tres aplicaciones que muestran el reporte. |
| Toda la sección de reportes pasó a un único calendario compartido; ya no quedan filtros de fecha sueltos con otro comportamiento. Se sumó el filtro por código de producto en Stock y Stock CD, y la fecha de preparación al filtro de Retiro en Tienda. |
|
|
|
🎁
|
No. 13 · Reportería · Book y promociones
Una promoción se mide con la boleta completa.
|
| El reporte de promociones medía solo la línea con descuento, así que el resto de la boleta no existía y las promociones de regalo figuraban sin venta y con margen negativo. Ahora se mide la venta de la boleta completa donde participó la promoción, y la marca funciona como eje y no como filtro. |
| El regalo de empaque dejó de contarse como unidad vendida en el reporte de productos. |
| El maestro del Book de productos pasa a alimentarse del archivo de Comercial dentro de la cadena de mercadería, y ya no desde Qlik. En el camino quedaron corregidos códigos de producto que no se podían buscar en pantalla y nombres de atributos que llegaban recortados. |
|
|
|
📉
|
No. 14 · Qlik
Cada aplicación de meta con su propio archivo.
|
| Incidente corregido en producción: las dos aplicaciones de meta escribían y leían el mismo archivo temporal y arrancaban con el mismo disparador, así que la que perdía la carrera repartía el mes de la otra. Eso dejó septiembre duplicado —vendedores con meta mayor que su tienda— y el reparto individual de agosto incompleto. Cada aplicación quedó con su propio archivo. |
| Hallazgo con fecha de vencimiento, resuelto antes de que llegue: el calendario que comparten una veintena de aplicaciones vivas termina el 31 de diciembre de 2026. El 1 de enero la comparación contra el año anterior se habría ido a cero en todas ellas, sin que nada fallara en rojo. Ya quedó publicada en el repositorio de datos una versión del calendario sin vencimiento. |
| Arrancó la capa puente para que Qlik lea del repositorio de datos: existe, tiene sus primeros conjuntos corriendo por su cuenta y un control que impide saltarse la capa. |
| Se midió algo que se daba por cierto: el cubo de venta no rehace la historia entre recargas, los años cerrados no se mueven. Eso permite exigirle al repositorio coincidencia exacta en períodos cerrados, en vez de negociar una tolerancia. |
| La herramienta con que cuadramos los archivos de Qlik ahora también compara los números: era ciega a la mitad numérica de los campos y daba verde aunque el número cambiara detrás de un texto idéntico. Corregida y probada contra un caso real que había pasado desapercibido. |
|
|
|
🗄️
|
No. 15 · Plataforma de datos
La foto diaria de inventario, con toda la historia.
|
| Quedó en producción qué quedaba en stock cada día, por producto y tienda, con los episodios de quiebre, y con toda la historia cargada. Las cuatro verificaciones previstas pasaron sin diferencias. |
| Las guías de despacho de tienda quedaron completas en el repositorio de datos: terminó el traspaso y se cerraron sus tres verificaciones de cuadratura. |
| La auditoría que compara los datos consolidados contra su origen tiene horario propio y ahora puede fallar. Antes dejaba su veredicto en un lugar donde nadie lo leía y siempre terminaba en verde. |
| Quedó cerrado el primer bloque del envío de datos a la nube. Se volvió a medir, sobre cuatro publicaciones seguidas de código, que los despliegues ya no interrumpen los procesos en ejecución: ninguna corrida se cayó. Y el archivo de movimientos de personal, que se publicaba después de que Qlik ya lo había leído, quedó anclado al peor caso del horario ajeno. |
|
|
|
🔎
|
No. 16 · Herramientas internas
Explorador de Datos, en producción.
|
| Quedó en producción el navegador del repositorio de datos, con acceso restringido, para revisar y descargar los archivos publicados sin tener que pedirlos. |
|
|
|
🛒
|
No. 17 · Proyectos e iniciativas
Dos bodegas más firmadas para el piloto.
|
| Multiorigen · dos bodegas adicionales aprobadas y firmadas el 8 de septiembre, con el piloto de despacho desde tienda activo en Costanera Center desde el 31 de agosto. Se cerró además el problema del inventario que declaraba disponibilidad de productos sin stock — el ticket con la plataforma de marketplaces quedó resuelto. El plazo que manda sigue siendo el congelamiento de Cyber, del 5 al 7 de octubre. |
| Migración de la tienda: la sincronización de productos con la plataforma de marketplaces se probó con éxito el 10 de septiembre, el mismo día del arranque de la incorporación, con sesión de continuación el 15. Llegó además el archivo de parametrización de catálogo e inventario. La fecha de salida sigue en el 16 de noviembre. |
| Despacho desde tienda · 46% de avance, con 34 de 73 locales activos y los tres primeros tramos completos. El cuarto tramo ya tiene identificadas sus 13 tiendas. |
|
⚠️ Fecha operativa
Una tienda cierra el 21 de septiembre por 35 días de remodelación. Ese mismo día hay que desactivarle el retiro en tienda y el despacho desde tienda.
|
|
|
|
🎯
|
Lo que hay detrás
Una copia no falla.
Se desactualiza.
|
Las duplicaciones que aparecieron esta semana tienen algo en común: ninguna estaba fallando. La lista de aprobadores de Atelier funcionaba perfecto, solo apuntaba a gente que ya no estaba en el grupo. La copia del módulo de personas en Helix funcionaba, solo mostraba las fechas un día antes. Las dos aplicaciones de meta corrían, solo se pisaban el archivo. Nada de eso se ve en un tablero de estado — se descubre cuando alguien compara las dos versiones. Por eso la respuesta no fue arreglar cada copia, sino dejar una sola dueña y que el resto consulte.
|
Cuatro titulares del periodo
→ En Nexum las comisiones de agosto quedaron cerradas y reliquidadas con la regla de sobrecumplimiento del negocio.
→ En Atelier la cotización pasó a ser una entidad propia: un artículo se cotiza a varios proveedores a la vez.
→ Beaver muestra los 72 locales con sus fechas críticas de contrato y el plazo de aviso primero.
→ La reportería de tiendas quedó cuadrada contra sí misma, pantalla por pantalla.
|
|
|
|
Gracias al equipo
Seguimos.
Gracias a todo el equipo por esta semana. Si algo de lo que leíste aquí te sirve —o te falta— escríbeme y lo conversamos.
✉️ malvarez@badamax.cl
|
|
|
Un abrazo,
Mauricio Álvarez · Chief Digital Officer
Una publicación de Badamax Tech
Serie · Lo que entregamos
|
|
|
|