¿Cómo gestiona descuentos por volumen que varían por región y por producto?

01El problema de negocio

Un fabricante vende un catálogo amplio a través de distribuidores regionales. Tres cosas varían a la vez, e interactúan:

• Región. El mismo artículo tiene precios distintos en dos territorios, y las dos regiones no tienen un catálogo idéntico.
• Cantidad. Si compra diez, paga un precio; si compra cien, paga otro. El calendario de tramos no es uniforme: varía según el producto.
• Excepciones. Algunos artículos no tienen ningún precio de lista. Son solo bajo presupuesto, y cuáles lo son varía según la región.

Un distribuidor que prepara un presupuesto debería obtener la cifra correcta sin saber nada de esto. Y cuando llega la actualización anual de precios, tiene que ser una carga de datos, no un proyecto.

Esa última frase es el requisito que decide en silencio todo el diseño, y suele ser el que nadie formula.

02Por qué falla el enfoque obvio

Una lista de precios por región y por tramo de cantidad

Lo natural, una vez que sabe que una lista de precios le da precios regionales, es crear más listas: Europa 10–49, Europa 50–99, Europa 100+, y lo mismo otra vez para cada una de las demás regiones. Falla por una razón estructural, no estética:

La aritmética del mantenimiento es el segundo problema, y se acumula. Como una lista puede hacerse disponible con casi cualquier condición, un catálogo real tiende a acumular listas: territorio, canal, un par de acuerdos negociados. Multiplique ese número, sea cual sea, por los tramos: en un catálogo de 1637 productos, dos regiones por cuatro tramos ya son ocho listas y más de diez mil filas de precios que mantener coherentes entre sí en cada revisión de precios. Además, convierte el desplegable en una lista de nombres casi idénticos entre los que un distribuidor tiene que elegir correctamente cada vez.

Guardar precios absolutos por tramo

Dondequiera que acaben viviendo los tramos, el instinto es guardar el precio del tramo, porque eso es lo que contiene la hoja de cálculo de origen. Así, cada cambio de precio futuro se convierte en una reconstrucción: el precio de lista se mueve, y cada tramo de ese producto debe recalcularse y volver a introducirse. En la práctica eso no ocurre, y los tramos derivan en silencio hasta describir los precios del año pasado.

Guarde en su lugar el porcentaje. El precio de lista se mueve, el tramo lo sigue automáticamente, y la actualización anual es una importación en una lista de precios.

Poner precio cero a lo que no tiene precio

Los artículos solo bajo presupuesto no tienen precio, y el atajo tentador es una fila de precio de 0. Un cero es un número: pasa al total de la línea, al valor del presupuesto, a la previsión, y parece completamente legítimo en todo el recorrido. Omitir la fila es mejor, pero sigue sin bastar, porque una fila de precio ausente no se distingue de una que nadie ha configurado todavía, y en un catálogo de este tamaño muchas simplemente faltan.

Un descuento sobre todo el presupuesto

Existe un descuento nativo a nivel de presupuesto, tanto en porcentaje como en importe. Es la herramienta adecuada para una concesión negociada en una operación, y la equivocada aquí, porque no puede decir esta línea tiene derecho a un tramo por volumen y aquella no. El precio por volumen es un hecho por línea.

03Modelo de datos

Cuatro cuestiones, cuatro ubicaciones distintas. La base se trata en el Blueprint 007 (un producto no lleva precio; el precio vive en una fila de unión entre el producto y una lista de precios) y todo lo que hay aquí se apoya en eso. Este ejemplo fija precios por región, pero nada del mecanismo es regional: lea «región» a continuación como «la dimensión que separe sus listas de precios». El artículo Price lists del centro de ayuda de Coevera solo ofrece una visión general de las listas y no es la fuente de sus reglas de disponibilidad; la capa de descuentos de más abajo no está documentada allí, y por eso se modela.

La fila de lista de precios es toda la restricción

Una fila de lista de precios es un producto, una lista de precios, una moneda, un precio, y un objeto de ajustes cuyo contenido completo es un nivel de acceso y una lista opcional de roles. No hay cantidad mínima, ni máxima, ni colección de tramos, ni tabla de escalones. Una fila, un precio. Todas las decisiones de diseño que siguen se derivan de ese único hecho.

Tres hechos por región que no son el mismo hecho

La gestión de excepciones solo funciona una vez que se advierte que son distintos, porque confundir dos cualesquiera de ellos produce cifras erróneas sin ningún aviso:

La tercera existe precisamente para desambiguar la segunda. Con ella, una fila ausente más una casilla sin marcar es una alerta de calidad de datos; sin ella, el mismo estado es invisible.

La forma que esto produjo en un catálogo real

Aproximadamente una cuarta parte de todos los listados regionales no tiene precio por diseño. Esa proporción es la razón por la que el mecanismo de excepciones no es un caso límite aquí: es una parte de primer orden del modelo.

04Configuración a nivel de campo

Propiedades de la lista de precios que conviene conocer

Cómo una lista de precios pasa a estar disponible

El filtro rules tiene la misma anatomía que los filtros de otras partes de la plataforma: un indicador de activación, un operador de grupo, un cuadro de filtro principal que designa una entidad, y cuadros hermanos para las entidades relacionadas. En una configuración de dos regiones que funciona, cada lista lleva:

• isEnabled: true, operador And;
• un cuadro principal en Opportunity sin condiciones;
• un cuadro hermano en Quote con exactamente una condición: un desplegable Region, operador Is, que coincide con la opción de región de esa lista.

Ambas listas filtran el mismo campo y reclaman una opción distinta de él, así que fijar la región en el presupuesto acota el desplegable a una única opción sensata. La lista que el usuario elige entonces queda registrada en el presupuesto en una relación nativa de lista de precios, de modo que el presupuesto guarda constancia permanente de con qué precios se construyó.

Tampoco hay nada regional en ella: un desplegable de región es simplemente por lo que filtraba este catálogo. El selector de campos de condición ofrece el presupuesto, la oportunidad y la cuenta, así que la disponibilidad puede depender de un nivel de cuenta, un tipo de contrato, un indicador de partner, un atributo de la oportunidad. Esas tres entidades son todo el alcance: la regla no llega más allá de ellas.

Y de todo lo que puede evaluar, falta la cantidad: la cantidad pertenece a la línea, y ningún registro que evalúe el filtro la lleva. Esa es toda la razón por la que el precio por volumen no puede vivir en una lista de precios, y es el eje sobre el que gira el resto de este blueprint.

Qué ocurre cuando se elige una lista

• Antes de la selección: el panel muestra "Without price list" y cada producto añadido entra con un precio de cero.
• Después de la selección: los productos añadidos toman su precio de esa lista.
• Al seleccionar: la interfaz pregunta si las líneas que ya están en el registro deben volver a tarificarse con la lista recién elegida, así que cambiar de lista a mitad de un presupuesto es una acción con confirmación, no un recálculo silencioso.

El panel también tiene su propio selector de moneda y un interruptor de sincronización de productos, y solo existe en Opportunity y Quote. Cualquier flujo de trabajo que necesite líneas con precio en otra entidad tiene que pasar por una de esas dos.

El calendario de descuentos en el producto

Seis campos enteros (tres tramos, dos regiones):

Dos propiedades de esta disposición son deliberadas y una es un coste que usted acepta:

• Por producto, no global. El calendario es un atributo del producto, así que un producto sin tramo por volumen simplemente tiene los campos vacíos: no hace falta ninguna lista de excepciones.
• Porcentajes, no precios. Una revisión de precios es una importación en la lista de precios y nada más. El calendario nunca necesita tocarse.
• Los límites de los tramos están en los nombres de los campos, lo que significa que son esquema, no datos. Cambiar 50–99 por 50–149 es un cambio de nombre de campo más una migración, y cada informe, formulario y proceso que haga referencia a él. El §6 vuelve sobre esto.

En la línea

La línea lleva de forma nativa quantity, price, amount, discount_percentage y discount_value. Una configuración que funciona añade un campo personalizado, un precio unitario neto, para que la cifra con descuento se almacene explícitamente en lugar de deducirse más tarde de las demás.

Una observación práctica sobre ese campo: su etiqueta y su api_name se habían separado, y el api name seguía llevando un sufijo de región de un diseño anterior que la etiqueta ya no menciona. Las etiquetas se pueden editar, y los api names son a lo que se vinculan las integraciones, las importaciones y las plantillas de procesos, así que el api name con el que crea un campo es con el que tendrá que vivir. Póngale nombre por lo que es, no por el primer lugar en que se usó.

05Automatización y lógica

Lo que hay que calcular

Todo lo anterior es modelo de datos. La única pieza de lógica es: dada la cantidad de una línea y la región del presupuesto, encontrar el tramo correcto y aplicarlo. En secuencia: leer la cantidad de la línea; seleccionar el campo de tramo que corresponde a la región del presupuesto; si contiene un porcentaje, escribirlo en el porcentaje de descuento de la línea, o calcular y escribir el precio unitario neto.

Por qué este es un único proceso

La mayoría de las automatizaciones de esta plataforma se fragmentan en varios procesos, porque un proceso lleva un filtro cuyas ramas se rigen por la primera coincidencia, y por tanto las condiciones independientes no pueden compartirlo: la restricción detrás del Blueprint 011.

Los tramos de cantidad son el caso contrario. Son mutuamente excluyentes: una línea de 60 unidades está exactamente en un tramo. Así que la primera coincidencia no es un obstáculo, es la semántica deseada, y un filtro con sus ramas ordenadas del tramo mayor hacia abajo es la forma correcta y completa. Ordénelas de forma descendente y la primera coincidencia siempre será la correcta.

La rama de excepción que es fácil olvidar

Un producto con precio bajo consulta no debe recibir un tramo sin que nadie lo note: no tiene precio de lista sobre el que descontar. El filtro de tramos necesita una rama previa sobre el indicador de precio bajo consulta que dirija la línea a una persona. Sin ella, un artículo solo bajo presupuesto en una línea grande recibe en silencio un porcentaje de descuento sobre un precio que no existe.

La precedencia, que hay que decidir en lugar de descubrir

El presupuesto también tiene un descuento nativo sobre el total. Una vez que una línea lleva un tramo por volumen, hay dos descuentos en juego, y nada en la plataforma decide si se acumulan, si gana el mayor o si un descuento negociado en el presupuesto sustituye al calendario. Decídalo, escríbalo en el proceso y póngalo en la plantilla del presupuesto; de lo contrario, cada distribuidor lo resuelve de una manera y los informes de margen no significan nada.

Lo que la lista de precios hará y no hará por usted

La regla de disponibilidad decide qué listas se ofrecen; no pone precio a nada. Lo que pone precio a las líneas nuevas en la interfaz es que una persona seleccione una lista, y el Blueprint 007 documenta el equivalente en la vía de la API: una línea creada sin un precio explícito entra a cero sin importar lo que cueste el producto en cualquier lista. Ambas vías convergen en el mismo fallo, así que cualquier importación, integración o automatización que construya líneas debe fijar el precio por sí misma.

06Límites y compromisos

• Los límites de los tramos son esquema. Como cada tramo es un campo, los límites quedan integrados en los nombres de los campos y en los formularios. Añadir un tramo o mover un límite es un cambio de campo, una migración de datos y una edición de todo lo que hace referencia a él, no un cambio de configuración. Elija los tramos contando con que sobrevivirán a varias listas de precios.
• Todas las listas de precios deben compartir una misma estructura de tramos. Un catálogo que llega con cinco tramos en una lista y tres en otra no se puede representar fielmente: o bien normaliza a los tramos comunes y pierde la granularidad más fina, o bien multiplica los campos por lista y el formulario del producto se vuelve inutilizable. El modelo real optó por lo primero y eliminó dos tramos de cantidad baja que solo existían en una región. Observe la asimetría: la selección escala libremente con nuevas listas, el calendario de descuentos no.
• La cantidad nunca puede llegar a una lista de precios. La regla de disponibilidad evalúa campos del presupuesto, la oportunidad y la cuenta; la cantidad es una propiedad de la línea. Casi todas las demás dimensiones están a su alcance; esta no, y esa es la razón estructural por la que todo el enfoque vive en el producto y no en la lista de precios.
• El cero es el valor por defecto, no la excepción. El panel se abre en "Without price list", así que un registro cuyo autor nunca tocó el desplegable pone cada línea a cero y parece terminado. Ninguna regla lo impide, porque las reglas solo deciden lo que ofrece el desplegable. Donde los presupuestos importen, trate las «líneas guardadas sin lista de precios» como un fallo de validación y detéctelas deliberadamente.
• Las reglas de disponibilidad solapadas producen una elección, no una resolución. Varias listas pueden ser válidas a la vez, así que dos reglas que coinciden dejan al usuario ante dos opciones plausibles sin ninguna orientación, y volver a elegir pide volver a tarificar todo lo que ya está en el registro. Escriba reglas mutuamente excluyentes.
• Una fila de precio ausente es ambigua a menos que usted lo evite. La ausencia significa solo bajo presupuesto o sin configurar, y la plataforma no puede decirle cuál. El indicador es lo que los separa, y tiene que mantenerlo lo que cargue el catálogo, o se degrada en la misma ambigüedad.
• Dos descuentos pueden aplicarse a una línea y nada arbitra. El tramo a nivel de línea y el descuento a nivel de presupuesto coexisten sin una precedencia definida.
• Las listas de precios programadas no se pusieron a prueba. El tipo, el estado y los límites de fecha están verificados en el esquema pero no en su comportamiento: no se observó cómo una lista Scheduled pasa a Active, ni qué ocurre con los presupuestos que hacen referencia a una que ha pasado a Expired.
• La línea no registra la procedencia del precio, según el Blueprint 007. El presupuesto registra qué lista usó; la línea individual no registra de qué fila de precio procede, así que un cambio de precio posterior no se puede rastrear hasta los presupuestos que habría alterado.
• Un api name es permanente en la práctica; una etiqueta no. Se separan, y el api name es aquel al que se vincula cada integración.

El compromiso que conviene decir claramente

Poner el calendario en el producto como porcentajes le da lo que más importa a lo largo de una vida de varios años: la revisión anual de precios sigue siendo una carga de datos. Los nuevos precios se importan en la lista de precios, y el calendario de descuentos, los indicadores de excepción y la automatización quedan intactos. Lo que cuesta es que los límites de los tramos se convierten en esquema, una sola estructura tiene que servir a todas las regiones, y el cálculo es un desarrollo y no un ajuste. Para un catálogo de miles de productos que se revisa cada año, es un buen intercambio. Para un puñado de productos con tramos a medida por cliente, es la forma equivocada por completo: eso son precios contractuales, y pertenecen a una lista de precios por cliente, que es terreno del Blueprint 007 y no de este.

07Verificación

Leído el 2026-09-16 en un espacio real que contiene un catálogo de distribuidor de dos regiones importado por completo.

• La restricción se confirmó a nivel de esquema: el objeto de ajustes de una fila de lista de precios expone exactamente dos propiedades, un enum de acceso y una lista de roles. No existe ninguna propiedad de cantidad, tramo o escalón en ningún lugar de la lista de precios ni de sus filas.
• El catálogo y las filas de precio cuadran exactamente. 1637 productos; 788 filas de precio en una región, 1193 en la otra. Frente a los archivos de origen (1158 y 1532 listados regionales, de los cuales 370 y 339 estaban marcados como solo bajo presupuesto), ambas cifras se reproducen con precisión: 1158 − 370 = 788 y 1532 − 339 = 1193. Los listados solo bajo presupuesto llevan un indicador de precio bajo consulta y ninguna fila de precio, que es lo que confirman esas dos restas.
• Las reglas de disponibilidad se leyeron completas en las dos listas activas, que eran válidas al mismo tiempo: activadas, operador And, un cuadro principal vacío en Opportunity y un cuadro hermano en Quote con una sola condición Is sobre un desplegable: el mismo campo en ambas listas, cada una reclamando una opción distinta. La regla es un filtro de campos corriente, así que el hecho de que el desplegable sea una región es una propiedad de este catálogo y no del mecanismo.
• Las propiedades de las listas de precios (el tipo Standard/Scheduled, el estado con cuatro valores, las fechas de inicio y de fin que acotan un periodo de precios, y una lista por defecto de fábrica inactiva que aún contiene filas de la creación de productos) se leyeron de los registros reales.
• El calendario de descuentos se leyó del esquema del producto: seis campos enteros de porcentaje, tres tramos en dos regiones, más dos casillas de precio bajo consulta por región y un campo de disponibilidad de selección múltiple.
• Se leyeron los campos de la línea, incluidos los nativos de cantidad, precio, importe, porcentaje de descuento y valor de descuento, y un campo personalizado de precio unitario neto cuya etiqueta y api name han divergido.

No observado, y se indica como tal:

• El cálculo del tramo. Ningún proceso del espacio calcula un descuento por volumen. El modelo tiene datos; la lógica no está construida. El diseño del §5 es lo que admiten las primitivas, no algo que se haya visto funcionar.
• El comportamiento de las listas de precios programadas: activación, caducidad y el efecto sobre los registros que ya hacen referencia a una lista.
• Si un descuento a nivel de línea y un descuento a nivel de presupuesto se acumulan, y en qué orden.
• Si el desplegable de listas de precios y la pregunta de volver a tarificar tienen algún equivalente en la vía de la API, donde una línea creada sin precio simplemente entra a cero.

Qué indicaría una regresión

• Líneas que entran con un precio de cero. El fallo más probable, y parece un número real todo el camino hasta la previsión. Revise cualquier importación o automatización que cree líneas sin fijar un precio explícitamente.
• Más filas de precio que listados regionales tras una revisión de precios. Significa que la importación creó filas para productos solo bajo presupuesto, y esos productos recibirán ahora en silencio tramos por volumen sobre un precio que no debería existir.
• Registros con líneas pero sin lista de precios registrada. Nadie movió el desplegable de "Without price list", así que cada línea está a cero. Es el estado por defecto, no un fallo raro, y por eso pertenece a la validación y no a una revisión mensual.
• Un campo de tramo con datos en un producto cuyo indicador de precio bajo consulta está marcado. Una contradicción en los datos que la rama de excepción del §5 existe para detectar.

Blueprints relacionados

• Blueprint 007 — ¿Cómo fija precios distintos para un mismo producto por región, segmento o contrato? — el modelo de listas de precios sobre el que se construye todo lo de aquí, y la negativa de la API a resolver un precio.
• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — filtros de primera coincidencia, y por qué los tramos por volumen son el caso en que eso es exactamente lo que se quiere.
• Blueprint 005 — ¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta? — por qué una importación de catálogo necesita una comprobación de la tasa de relleno, y con qué facilidad un valor puede no llegar sin que nadie lo note.
• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? — el marco para decidir que un calendario de tramos pertenece al producto y no a una entidad nueva.