Normalizar precios de configuradores de coches: PVP, neto y descuento

El problema: una pregunta, veintiocho respuestas

Si extraes precios de varios configuradores y los pones en una misma columna, lo más probable es que estés comparando cosas distintas. Un fabricante publica el precio con IVA, otro sin él; uno ya descuenta la promoción y otro muestra el precio de tarifa; algunos incluyen el impuesto de matriculación y otros lo dejan fuera. Si no distingues la base de cada importe, cualquier comparación entre marcas, países o fechas queda contaminada.

Normalizar no consiste en «limpiar» el dato, sino en declarar, para cada importe, qué es: si es de tarifa o con descuento, bruto o neto, con o sin impuestos especiales. Esa declaración es lo que permite usar el dato después en un panel, un modelo de precios o un contrato. Detrás de cada página de marca del hub de configuradores OEM hay un diccionario de campos precisamente para esto.

Los tres ejes que no se pueden mezclar

Antes de mirar campos conviene fijar el vocabulario. Hay tres ejes independientes y cada importe de un configurador ocupa una posición en cada uno:

• Tarifa frente a final: el precio de lista (PVP o MSRP) antes de cualquier promoción, frente al precio tras descuento del fabricante o del concesionario.
• Bruto frente a neto: el importe con IVA (lo que paga un particular) frente al importe sin IVA (lo que interesa a una empresa que lo deduce).
• Con o sin impuestos especiales: en España existe un impuesto de matriculación que depende de las emisiones; algunos configuradores lo incorporan al precio mostrado, otros no, y en otros países hay impuestos equivalentes con nombres y lógicas propios.

Campos reales: BMW, Kia y Toyota

La mejor forma de ver la diferencia es mirar filas verdaderas. La tabla recoge una fila de cada marca, procedente de las muestras de nuestros actores para el mercado español, en euros. No son cifras agregadas ni comparativas: son los campos tal como los entrega cada configurador.

Qué enseñan esas filas

En BMW el neto y el bruto son campos hermanos y la diferencia entre ambos se publica en total_taxes. En esa fila, 8757.678 dividido entre el neto 34010.4 da 0.2575, es decir, el 21 % de IVA más el 4,75 % de emission_tax_pct. Conclusión práctica: total_taxes no es solo IVA; agrupa IVA e impuesto por emisiones, y si lo restas pensando que es IVA, obtendrás un neto equivocado.

En Kia, la estructura es otra: hay un precio de lista, un descuento y un precio final, más un indicador booleano, is_net_price, que avisa de si el importe mostrado es neto. Aquí la comprobación es aritmética: 48995.01 menos 13465 da 35530.01, y 35530.01 dividido entre 1,21 da 29363.64. El campo net_price es, por tanto, el neto del precio tras descuento, no el de lista.

Toyota es la trampa más fina. price_net vale 22975.21, que es el neto del precio de lista (27800 entre 1,21), no del precio con descuento. El neto tras descuento aparece en otro campo, price_ex_vat, con 20247.93. Dos marcas con un campo llamado «neto» y dos bases distintas: de ahí que nunca se deba mapear por el nombre del campo, sino por lo que cada campo representa verificado contra una fila.

Un esquema común para homogeneizar

El objetivo es un esquema en el que cada importe lleve su base explícita. Una propuesta mínima, que usamos como punto de partida en los proyectos de normalización de datos, es la siguiente:

Normalizar sin perder el dato original

Una regla que ahorra problemas: conserva siempre el campo original junto al normalizado y añade una bandera de calidad en lugar de descartar filas. Si el neto se ha derivado dividiendo entre el IVA, márcalo como derivado; si la fuente no deja separar el impuesto de matriculación, deja el campo nulo y márcalo. Quien consume el dato decide si acepta las filas derivadas. Algunos de nuestros actores ya hacen esto de forma nativa: Toyota entrega tax_calculation_status y price_quality, y Volkswagen entrega price_net_status y registration_tax_status.

Esta filosofía, marcar y dejar pasar, evita el error opuesto, que es filtrar en silencio y que el analista nunca sepa que faltaban datos. Con la bandera, un panel puede mostrar la cobertura de neto verificado frente a derivado, y un modelo puede decidir si excluye las derivadas.

Una lección de clasificación: el falso positivo «EV» en «Clio evolution»

La normalización no es solo de precios. Para comparar coches eléctricos con híbridos y de combustión hace falta clasificar la propulsión, y la tentación es detectarla por el nombre del modelo o de la versión. Es un error clásico. Si buscas la subcadena «ev» en el texto, una versión llamada «Clio evolution» se clasifica como eléctrica, igual que cualquier nombre que contenga «ev» en cualquier posición, desde «Level» hasta «Revolution».

La solución tiene tres capas. Primera: usa los campos de combustible o propulsión que entrega el configurador, como fuel_type en BMW, fuel_code e is_hybrid en Toyota o engine_category_name, antes que el nombre comercial. Segunda: si hay que recurrir al texto, tokeniza y compara palabras completas, con límites de palabra, nunca subcadenas. Tercera: guarda la señal que usaste, por ejemplo propulsion_source = fuel_field | token | unknown, para poder auditar después las clasificaciones inciertas. Y una prueba unitaria con el caso «Clio evolution» evita que el error vuelva con un cambio de código.

Pasos para montar el pipeline

Resumido en un orden de trabajo que puedes seguir:

• Descarga una muestra por marca y lista los campos de precio y de impuestos con sus valores en una fila real.
• Para cada campo, comprueba aritméticamente la base: resta, divide por el IVA y verifica que cuadra con otro campo de la misma fila.
• Define el esquema común y la tabla de mapeo por marca, y documenta los casos ambiguos como el de price_net en Toyota.
• Deriva lo que falte, siempre con bandera derived, y deja nulo lo que no se pueda calcular.
• Clasifica la propulsión por campos de combustible y tokens, nunca por subcadenas.
• Añade pruebas con filas reales, incluidos los casos conflictivos, y revisa de forma periódica los campos nuevos que aparezcan.

Dónde ver los campos de cada marca

Cada marca tiene su página con cobertura, filas reales y diccionario de campos. Para los ejemplos de esta guía: BMW, Kia, Toyota y Dacia y Renault, esta última con price_retail, price_type y price_without_tax. El hub comercial es datos de precios de coches nuevos, y si quieres recibir los datos ya homogeneizados, puedes pedir un dataset normalizado.