Barras horizontales, ordenadas de mayor a menor

La pregunta es de magnitud comparada entre categorías (venta por segmento). Horizontales porque las etiquetas son nombres largos, y ordenadas porque el orden alfabético no dice nada.

La forma la decide el trabajo que hace el dato —magnitud, identidad, polaridad, cambio en el tiempo, distribución—, no el gusto. Regla del curso: un solo eje.

Lo que quedó planteado la clase anterior (se proyecta la pregunta, NO la respuesta):

«Si el segmento está escrito de 23 formas, ¿de cuántas formas estará escrito el nombre del cliente? ¿Y el RUT?»

Tres preguntas, en silencio, 90 segundos (espaciado 1–3–7–21). Nadie habla todavía:

1. (clase 02) Filtramos WHERE segmento = 'Minería' y salieron CLP 980.768.001. Con las cinco escrituras salieron 1.360.516.886. ¿Por qué la primera consulta no dio error?
2. (clase 01) La pregunta del gerente de Administración y Finanzas tenía dos partes. ¿Cuáles eran?
3. (clase 01, contrato de IA) Le pides a la IA que te escriba un GROUP BY, funciona y lo entregas. ¿En qué nivel del contrato estás y qué tienes que hacer antes de entregarlo?

Par (2 min) → plenaria (3 min).

La pregunta colgada NO se responde acá con el número: se responde a las 21:00, corriendo la consulta. Hoy la apertura sólo deja el pronóstico anotado: pedir en voz alta «¿cuántas formas creen que hay del nombre del cliente? escríbanlo en el cuaderno».

La analogía, dicha una sola vez: tomas las 6.000 filas, las repartes en cajones —un cajón por segmento— y pegas un resumen en la tapa de cada cajón. Eso es GROUP BY. Lo que va en la tapa lo eliges tú: SUM, COUNT, AVG, MIN, MAX.

CREATE OR REPLACE TABLE ventas AS
SELECT * FROM read_csv_auto(
  'datos/finanzas/ventas_extracto.csv');

SELECT segmento,
       COUNT(*) AS lineas,
       ROUND(SUM(cantidad * precio_unitario)) AS venta_clp
FROM ventas
WHERE moneda = 'CLP'
GROUP BY segmento
ORDER BY venta_clp DESC;

Pregunta a la sala: «¿Cuántos segmentos comerciales tiene esta empresa?»

«El GROUP BY no se rompió. Hizo exactamente lo que le pediste: juntar lo que está escrito igual. INDUSTRIAL no está escrito igual que Industrial. Para SQL son dos cajones. Para el negocio son el mismo cliente pagando la misma factura.»

Primer auxilio, y su límite:

SELECT upper(strip_accents(trim(segmento))) AS seg,
       COUNT(*) AS lineas,
       ROUND(SUM(cantidad * precio_unitario)) AS venta_clp
FROM ventas
WHERE moneda = 'CLP'
GROUP BY 1
ORDER BY venta_clp DESC;

Cinco filas. Y ahí está otra vez el 1.360.516.886 de la clase pasada — el número correcto de Minería, ahora sin escribir las cinco variantes a mano.

«Tres funciones de texto —mayúsculas, sin tilde, sin espacios sobrantes— y los 23 cajones se volvieron 5. Guarden esa idea: **normalizar es agrupar por lo que el dato significa, no por cómo se escribió.**»

Y ahora se mira. Las dos consultas ya dieron el número: el gráfico no lo reemplaza, lo hace evidente. Es el primer gráfico del semestre y trae escrita la regla que se usa hasta el examen — la forma la decide el trabajo que hace el dato. Acá el trabajo es comparar magnitudes entre categorías con nombres largos, así que son barras horizontales ordenadas por valor, nunca alfabéticas: el orden alfabético no dice nada.

import matplotlib.pyplot as plt

# La paleta del curso, y no cambia en todo el semestre: gris para todo,
# UN color para lo único que se quiere mirar.
GRIS, TINTA, ALERTA = "#b8b8b8", "#102a38", "#8c2b20"

sucio = bd.sql("""
  SELECT segmento AS etiqueta,
         upper(strip_accents(trim(segmento))) AS clave,
         SUM(cantidad * precio_unitario) / 1e6 AS venta_mm
  FROM ventas WHERE moneda = 'CLP'
  GROUP BY 1, 2 ORDER BY venta_mm""")

limpio = bd.sql("""
  SELECT upper(strip_accents(trim(segmento))) AS etiqueta,
         upper(strip_accents(trim(segmento))) AS clave,
         SUM(cantidad * precio_unitario) / 1e6 AS venta_mm
  FROM ventas WHERE moneda = 'CLP'
  GROUP BY 1, 2 ORDER BY venta_mm""")

fig, ejes = plt.subplots(1, 2, figsize=(12, 6.4), sharex=True)
for eje, d, rotulo, grosor in ((ejes[0], sucio,  "Como lo escribió el ERP", 0.72),
                               (ejes[1], limpio, "Como se llama el negocio", 0.45)):
    eje.barh(range(len(d)), d.venta_mm, height=grosor,
             color=[ALERTA if c == "MINERIA" else GRIS for c in d.clave])
    eje.set_yticks(range(len(d)))
    eje.set_yticklabels([f"«{e}»" for e in d.etiqueta], fontsize=8.5)
    eje.set_title(f"{rotulo}: {len(d)} barras", fontsize=12, color=TINTA, loc="left")
    eje.set_xlabel("venta en millones de CLP", fontsize=9)
    for lado in ("top", "right", "left"):
        eje.spines[lado].set_visible(False)
    eje.tick_params(length=0)

for y, v in enumerate(limpio.venta_mm):
    ejes[1].text(v + 30, y, f"{v:,.0f}".replace(",", "."), va="center",
                 fontsize=9, color=TINTA)

fig.suptitle("Los 23 cajones de la izquierda son 5 segmentos:\n"
             "en color, las cinco escrituras de Minería que a la derecha son una sola barra",
             fontsize=13, color=TINTA, x=0.02, ha="left")
fig.tight_layout()
plt.show()

Qué se mira en el resultado, en este orden y sin apurarse:

1. Cuántas barras hay a cada lado. Veintitrés contra cinco. Es el mismo archivo, la misma plata y la misma consulta: lo único que cambia son tres funciones de texto.
2. Las barras de color. A la izquierda son cinco —Minería, MINERIA, MINERÍA, minería y una que además trae un espacio al final—; a la derecha son una sola, y mide exactamente lo que miden las cinco juntas.
3. Las comillas de las etiquetas. Están puestas a propósito: son la única manera de ver el espacio en blanco de «Construcción ». Un carácter invisible partió un segmento en dos.
4. El eje horizontal es el mismo en los dos lados. Si no lo fuera, la comparación no valdría nada. Ésa es la primera regla de lectura de un gráfico y hoy se dice por primera vez: antes de leer las barras, se lee el eje.

Ticket promedio por canal — y la primera lección de grano del semestre:

SELECT COUNT(*)                       AS lineas,
       COUNT(DISTINCT numero_factura) AS facturas,
       ROUND(COUNT(*)::DOUBLE
             / COUNT(DISTINCT numero_factura), 3)
         AS lineas_por_factura
FROM ventas;
-- 6000 | 2951 | 2.033

Detenerse aquí. «6.000 líneas, 2.951 facturas. 2,03 líneas por factura. Anoten ese número: explica un crimen que vamos a resolver en la clase 09 y que cuesta 9,7 puntos de margen.»

WITH factura AS (
  SELECT numero_factura,
         ANY_VALUE(canal) AS canal,
         SUM(cantidad * precio_unitario) AS bruto
  FROM ventas
  WHERE moneda = 'CLP'
  GROUP BY numero_factura
)
SELECT canal,
       COUNT(*)          AS facturas,
       ROUND(AVG(bruto)) AS ticket_promedio_clp
FROM factura
GROUP BY canal
ORDER BY ticket_promedio_clp DESC;

«Fíjense en lo que hicimos: primero agrupamos por factura, y después promediamos. Si promedian directo sobre las líneas, están promediando pedazos de factura y el "ticket" no es el ticket. Se llama grano, es la palabra más importante del semestre y vuelve en la clase 09.»

HAVING: filtrar después de agregar. WHERE filtra filas antes de repartirlas en cajones; HAVING filtra cajones ya armados.

SELECT upper(strip_accents(trim(region_cliente))) AS region,
       COUNT(*) AS lineas,
       ROUND(SUM(cantidad * precio_unitario)) AS venta_clp
FROM ventas
WHERE moneda = 'CLP'
GROUP BY 1
HAVING COUNT(*) > 500
ORDER BY venta_clp DESC;
-- METROPOLITANA 1446 | 2.290.179.576
-- VALPARAISO     742 | 1.306.465.271
-- ANTOFAGASTA    658 |   985.557.458

Error clásico, provocado a propósito: escribir WHERE COUNT(*) > 500. Leer el mensaje de DuckDB en pantalla y traducirlo al español con ellos. El error es material didáctico, no un accidente.

Y la primera pasada al margen —la mitad de la pregunta del gerente:

SELECT linea_negocio,
       ROUND(100.0 * (SUM(cantidad * precio_unitario)
                    - SUM(cantidad * costo_unitario)
                    - SUM(descuento_factura)
                    - SUM(flete_despacho))
             / SUM(cantidad * precio_unitario), 2)
         AS margen_aparente_pct
FROM ventas
GROUP BY linea_negocio
ORDER BY margen_aparente_pct DESC;

«Según esto, cada peso que vendemos en Fijaciones nos hace perder trece centavos. ¿Qué haría un gerente con esta lámina?»

«Esta consulta corrió sin error. Sumó cuatro columnas que existen. Y es la lámina con la que se cierran negocios rentables. Lo llamo el margen aparente y lo vamos a desarmar en la clase 09. Hoy sólo quiero que sepan que existe.»

Hilo 3 — salir de Excel: «Esto en Excel era una tabla dinámica. Y la tabla dinámica te habría dado las mismas 23 filas, con la misma cara de seguridad. El problema no es la lentitud de Excel: es que ninguna de las dos herramientas sabe que INDUSTRIAL e Industrial son lo mismo.»

Aquí se responde la pregunta colgada, corriéndola con ellos. Antes de correr, cobrar el pronóstico que anotaron a las 20:30.

SELECT COUNT(*)                       AS lineas,
       COUNT(DISTINCT cliente)        AS formas_cliente,
       COUNT(DISTINCT rut_cliente)    AS formas_rut,
       COUNT(DISTINCT segmento)       AS formas_segmento,
       COUNT(DISTINCT region_cliente) AS formas_region
FROM ventas;
-- 6000 | 100 | 74 | 23 | 62

«Cien. Y hay dieciocho clientes. El RUT, que es el número que el Estado usa para identificar a una empresa, viene escrito de 74 formas para 18 RUT. Eso es lo que hay adentro del archivo con que se arma el reporte de ventas.»

Ahora el mismo problema donde duele, cliente por cliente:

SELECT cliente, COUNT(*) AS lineas
FROM ventas
WHERE upper(strip_accents(cliente)) LIKE '%LOS ANDES%'
GROUP BY cliente
ORDER BY lineas DESC;

Un cliente. Cinco filas en el reporte. Ninguna con el total.

Y el intento de arreglarlo sólo con texto, corrido en vivo:

SELECT COUNT(DISTINCT cliente) AS crudo,
       COUNT(DISTINCT upper(trim(cliente)))
         AS mas_caja_y_bordes,
       COUNT(DISTINCT upper(regexp_replace(
         trim(cliente), ' +', ' ', 'g')))
         AS mas_espacios_internos,
       COUNT(DISTINCT upper(replace(replace(replace(
         rut_cliente,'.',''),'-',''),' ','')))
         AS por_rut_normalizado
FROM ventas;
-- 100 | 64 | 46 | 18

La cascada, escrita en la pizarra: 100 → 64 → 46 → … y ahí se atasca.

«Mayúsculas y espacios te llevan de 100 a 46. De 46 a 18 no llegas limpiando texto: llegas adivinando si SA es lo mismo que S.A., si el punto de más es un error de dedo, si "Ferretería" con y sin tilde es la misma empresa. Cada adivinanza es una apuesta. Y hay una columna en el archivo que no requiere adivinar ninguna: el RUT. Normalizado, cierra en 18 de una sola pasada.»

SELECT COUNT(DISTINCT rut_cliente) AS formas_crudas,
       COUNT(DISTINCT upper(replace(replace(replace(
         rut_cliente,'.',''),'-',''),' ','')))
         AS ruts_reales
FROM ventas;
-- 74 | 18

Regla que se copia: para agrupar personas o empresas, agrupa por la llave, muestra el nombre. El nombre es para leer; el RUT es para contar.

Los cinco clientes más grandes, ya bien contados:

SELECT upper(replace(replace(replace(
         rut_cliente,'.',''),'-',''),' ',''))
         AS rut_norm,
       ANY_VALUE(cliente)      AS un_nombre_cualquiera,
       COUNT(DISTINCT cliente) AS formas_de_escritura,
       ROUND(SUM(cantidad * precio_unitario) / 1e6, 1)
         AS venta_MM_clp
FROM ventas
WHERE moneda = 'CLP'
GROUP BY 1
ORDER BY venta_MM_clp DESC
LIMIT 5;

«Ninguno de estos cinco clientes aparecía completo en el reporte anterior. El más grande de la cartera estaba partido en seis pedazos.»

Pararse, estirar, subir la luz un segundo. Clase nocturna: el cuerpo también aprende.

Éste es el bloque que convierte dos sesiones en una clase. Se dicta de pie, sin proyectar SQL.

«Entonces el archivo no se puede arreglar solo. Mayúsculas y espacios te dejan en 46 y ahí se atasca: para llegar a 18 tienes que salir del archivo. ¿Y si le pegamos el maestro de clientes?»

Recoger tres respuestas de la sala en 90 segundos, sin corregir ninguna. Después:

«Es exactamente lo que haría cualquiera, y es lo que vamos a hacer en los próximos cuarenta minutos. Les adelanto una sola cosa, y quiero que la anoten antes de que la veamos: entran 6.000 líneas y salen 6.195. El resto de la clase es averiguar de dónde salieron las 195 que nadie vendió.»

Proyectar el JSON en un editor de texto, no en el navegador. Que vean la forma.

{ "rut": "76.412.885-9", "razon_social": "Constructora Vilches S.A.",
  "segmento": "Construcción", "region": "Metropolitana",
  "limite_credito_clp": 236000000 }

• Un maestro es la verdad oficial de la empresa sobre una entidad: quién es el cliente, cómo se llama de verdad, a qué segmento pertenece y cuánto crédito tiene autorizado. Vive en el ERP y lo mantiene una persona con nombre y apellido.
• Toda empresa vive de sus maestros: clientes, proveedores, artículos, centros de costo, plan de cuentas. El maestro es lo que permite que dos sistemas hablen del mismo cliente.
• Y ninguno está limpio, por una razón estructural que conviene decir en voz alta: el maestro se llena mientras se vende. Nadie detiene la facturación para ordenar el maestro.

Leerlo con SQL, sin abrir nada más:

CREATE OR REPLACE VIEW maestro AS
SELECT * FROM (
  SELECT unnest(clientes, recursive := true)
  FROM read_json_auto(
    'datos/finanzas/catalogo_clientes.json'));

SELECT COUNT(*) AS entradas,
       COUNT(DISTINCT rut) AS ruts FROM maestro;
-- 18 | 17

Detenerse. «Dieciocho entradas. Diecisiete RUT. Antes de unir nada: ahí ya hay un problema, y está del lado del maestro, no del nuestro.»

El JOIN en una frase: pegar a cada línea de venta la información del cliente que la generó, usando el RUT como puente.

Primero, la versión ingenua —la que casi todo el mundo escribe:

SELECT COUNT(*) AS lineas_pegadas
FROM ventas v
JOIN maestro m ON v.rut_cliente = m.rut;
-- 3641

«3.641 de 6.000. El 60,7 %. Y la consulta corrió sin error, sin advertencia y en medio segundo. Si mandas ese reporte, le acabas de decir a Finanzas que la empresa vendió el 39 % menos de lo que vendió.»

Preguntar: «¿por qué no pegó?» Van a llegar solos: el RUT viene escrito de 74 formas y el maestro lo escribe de una.

La cura, con la misma normalización de recién aplicada a los dos lados:

CREATE OR REPLACE VIEW ventas_n AS
SELECT *, upper(replace(replace(replace(
         rut_cliente,'.',''),'-',''),' ','')) AS rut_norm
FROM ventas;

CREATE OR REPLACE VIEW maestro_n AS
SELECT *, upper(replace(replace(
         rut,'.',''),'-','')) AS rut_norm
FROM maestro;

SELECT COUNT(*)
FROM ventas_n JOIN maestro_n USING (rut_norm);
-- 6195

Escribir el número en la pizarra, grande:

Entraron 6.000 líneas. Salieron 6.195.

«El JOIN inventó 195 líneas de venta. No están en el archivo de ventas, no las facturó nadie, y aparecerían en el reporte con su venta, su costo y su margen. Un JOIN que cambia el conteo de filas sin que nadie lo note es la forma más común de mentir con datos sin querer.»

La consulta de control que hay que correr SIEMPRE después de un JOIN —se copia, se pega en el cuaderno, se usa el resto del semestre:

SELECT
  (SELECT COUNT(*) FROM ventas_n) AS lineas_origen,
  (SELECT COUNT(*) FROM ventas v JOIN maestro m
     ON v.rut_cliente = m.rut)    AS join_sin_normalizar,
  (SELECT COUNT(*) FROM ventas_n JOIN maestro_n
     USING (rut_norm))            AS join_normalizado,
  (SELECT COUNT(*) FROM ventas_n LEFT JOIN maestro_n
     USING (rut_norm)
     WHERE maestro_n.rut IS NULL) AS lineas_sin_maestro,
  (SELECT COUNT(*) FROM ventas_n JOIN maestro_n
     USING (rut_norm)
     WHERE maestro_n.region IS NULL) AS lineas_sin_region;
-- 6000 | 3641 | 6195 | 99 | 774

LEFT vs INNER, en lámina y en una sola idea:

«Regla del curso: para diagnosticar, LEFT. Siempre. El INNER es una decisión que se toma después de mirar, no antes.»

Hilo 3 — salir de Excel: «Esto en Excel era un BUSCARV. Y hay una diferencia que hoy importa: BUSCARV devuelve la primera coincidencia y sigue. Con el cliente duplicado del maestro habrían obtenido 6.000 filas —el conteo cuadra, se ve perfecto— y a la mitad de las líneas de Punta Verde les habría pegado el segmento equivocado, sin duplicar nada y sin avisar nunca. El JOIN al menos te muestra el problema cambiando el conteo. Un error visible es infinitamente mejor que uno invisible.»

SELECT
  (SELECT COUNT(*) FROM ventas_n
     WHERE rut_norm = '967014435')
     AS lineas_reales,
  (SELECT COUNT(*) FROM ventas_n
     JOIN maestro_n USING (rut_norm)
     WHERE rut_norm = '967014435')
     AS lineas_tras_join;
-- 294 | 588

«Minera Punta Verde tiene 294 líneas de venta. Después del JOIN tiene 588. El cliente factura el doble sin haber vendido una unidad más, porque alguien la cargó dos veces en el maestro: una como Minería y otra como Industrial. Ésas son las 195 líneas inventadas (294 duplicadas menos 99 que se pierden, y las 99 vienen ahora).»

Nombre: fan-out. Se ve porque el conteo sube.

SELECT ANY_VALUE(cliente) AS cliente,
       COUNT(*) AS lineas,
       COUNT(DISTINCT numero_factura) AS facturas,
       ROUND(SUM(cantidad * precio_unitario))
         AS venta_nominal_clp
FROM ventas_n LEFT JOIN maestro_n USING (rut_norm)
WHERE maestro_n.rut IS NULL
GROUP BY rut_norm;
-- Salmonera Chiloé SpA | 99 | 49 | 85.343.323

«Salmonera Chiloé SpA. 99 líneas, 49 facturas, 85,3 millones. No está en el maestro de clientes. El INNER JOIN la borra y nadie se entera. El LEFT JOIN la deja con segmento nulo y aparece en el reporte como "(en blanco)". Ninguna de las dos cosas es aceptable.»

«774 líneas. Cuando Finanzas abra la cartera por región, esas 774 líneas se caen del gráfico sin avisar. El total del gráfico no va a cuadrar con el total del estado de resultados, y nadie va a saber por qué.»

Hilo 2: «Este maestro es exactamente lo que exporta un ERP chileno. La entrada duplicada de Punta Verde no es un invento mío: es lo que pasa cuando un cliente cambia de clasificación y alguien crea una ficha nueva en vez de editar la vieja. Van a ver esto en su primera semana de trabajo.»

Este catálogo es más chico y es más grave: define cuánto crédito puede dar la empresa.

CREATE OR REPLACE VIEW condiciones AS
SELECT * FROM (
  SELECT unnest(condiciones, recursive := true)
  FROM read_json_auto(
    'datos/finanzas/catalogo_condiciones_pago.json'));

SELECT * FROM condiciones ORDER BY dias;

Ahora, contra lo que el ERP realmente emitió:

SELECT v.condicion_pago_dias        AS dias,
       COUNT(*)                     AS lineas,
       ANY_VALUE(c.nombre)          AS nombre_en_catalogo,
       ANY_VALUE(c.vigente)         AS vigente
FROM ventas v
LEFT JOIN condiciones c ON v.condicion_pago_dias = c.dias
GROUP BY v.condicion_pago_dias
ORDER BY dias;

368 líneas fuera del catálogo vigente. Y son dos fallas distintas —esto es lo que hay que dejar clavado:

• 45 días · 233 líneas · el catálogo la tiene, pero con vigente: false. El JOIN pega perfecto y no dice nada. Sólo la ves si miras la columna vigente. Es un problema de gobierno del catálogo: existió, se retiró, y el ERP la sigue emitiendo.
• 120 días · 135 líneas · no está en el catálogo en absoluto. El INNER JOIN la borra; el LEFT JOIN la deja con nombre nulo. Es un problema de cobertura del catálogo.

«La primera es peor, porque no se cae. Un INNER JOIN te avisa cuando algo falta. Nada te avisa cuando algo calza pero ya no vale.»

Y la pregunta de negocio, que es de Finanzas y no de sintaxis:

SELECT condicion_pago_dias AS dias,
       COUNT(*) AS lineas,
       ROUND(SUM(cantidad * precio_unitario)) AS venta_clp
FROM ventas
WHERE condicion_pago_dias IN (45, 120) AND moneda = 'CLP'
GROUP BY 1 ORDER BY 1;
-- 45  | 218 | 277.352.802
-- 120 | 128 | 260.974.516

«538 millones de pesos de crédito que Finanzas nunca autorizó, dados a 45 y 120 días. Y el catálogo trae el costo_financiero_anual_pct justamente para poder preguntar: ¿cuánto nos cuesta el crédito que nadie aprobó? → eso se le pregunta a Tesorería y al Gerente de Administración y Finanzas.»

• Individual, sin material, 10 minutos. Formativo: 0 %. Decirlo antes de repartir: su función es diagnosticar antes del Parcial 1, no calificar.
• Al terminar, la pauta se proyecta y se autocorrigen con lápiz de otro color antes de entregar. La brecha entre "creía que sabía" y "sé" es el aprendizaje más barato del semestre.
• Recoger. Los C1 se leen antes de la clase 04: la apertura se arma con lo que fallaron.

Los dos roles en la misma lámina. Las dudas concretas que salen del dato de hoy:

KAM: «77.203.914-1 factura como Ferretería Los Andes Ltda. y también como Ferretería Los Andes LTDA. Mismo RUT, dos escrituras. ¿Es el mismo cliente? Y el RUT 96.701.443-5 está cargado dos veces: ¿es Minería o es Industrial?»

Administración de Ventas: «¿Por qué Salmonera Chiloé no está en el maestro, si nos compra hace dos años y le facturamos 85 millones?»

«Cuatro preguntas. Ninguna se responde con SQL. Y las cuatro tienen que estar contestadas antes de que ese reporte salga de tu computador. Ninguna toma más de un correo.»

Y la regla del curso, que ya está en la pizarra desde la clase 02, se repite en voz alta:

Una consulta SQL sin una conversación previa es una opinión con formato de tabla.

Síntesis, construida con ellos, escrita en la pizarra con sus palabras:

1. «¿Qué hace GROUP BY en una frase que entienda tu jefa?» → parte la tabla en cajones y resume cada cajón.
2. «¿Con qué columna se cuentan clientes y por qué no con el nombre?» → con el RUT normalizado: 74 formas cierran en 18; el nombre se atasca en 46.
3. «¿Qué se revisa siempre después de un JOIN?» → el conteo de filas: antes y después.
4. «¿Cuáles son las dos fallas distintas del catálogo de condiciones?» → una existe pero no está vigente (45 días), la otra no existe (120 días).

Ticket TC03 (3 min, se proyecta): a) ¿Por qué pegar el maestro NO arregla las 100 formas de escribir 18 clientes? Una frase. b) Uniste por rut_cliente = rut sin normalizar y pegaron 3.641 de 6.000 líneas; el GROUP BY por cliente sigue dando 100 grupos. Escribe el arreglo que va en la fuente y el que va en el maestro, en ese orden. c) 1–5 y qué te falta.

Anki: se importa hoy el mazo S1–S2 (mostrar el import en 1 minuto, no más).

Pregunta que queda planteada (se escribe en la pizarra y no se responde hoy):

→ El RUT sin normalizar pega 3.641 de 6.000 líneas. ¿De dónde saco lo que falta, y con qué fuente lo valido?

Puente a la clase 04, corto:

«La próxima salimos del edificio: CMF, Banco Central, SII, INE, Bolsa de Santiago. Y van a aprender a validar un RUT antes de ir a buscarlo afuera, con una regla aritmética que se explica en dos frases.»