--- title: "¿Cómo gestiona descuentos por volumen que varían por región y por producto?" blueprint: 015 slug: volume-discounts-by-region-and-product category: Precios published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/es/blueprints/volume-discounts-by-region-and-product/ language: es translation_of: https://blueprints.coevera.com/blueprints/volume-discounts-by-region-and-product/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # ¿Cómo gestiona descuentos por volumen que varían por región y por producto? **Respuesta corta.** **Una fila de lista de precios contiene exactamente un precio.** Todo su objeto de ajustes es un nivel de acceso y una lista de roles: no hay cantidad mínima, ni tramo, ni escalón en ninguna parte. Así que **los descuentos por cantidad no son nativos** y usted los modela. **En cambio, qué listas se ofrecen es muy configurable.** Puede haber cualquier número de listas de precios válidas a la vez, y cada una lleva una regla (con la etiqueta **price-list availability**) que decide si aparece en el desplegable de listas de precios del panel Products & Services. La regla evalúa cualquier campo del **presupuesto, la oportunidad o la cuenta**. **Rige la disponibilidad, no la aplicación.** El desplegable tiene por defecto **"Without price list"**, y una persona sigue eligiendo. Hasta que alguien lo hace, **cada línea se añade con un precio de cero**, lo que convierte el fallo de precios más común en un valor por defecto y no en un caso límite. Y de todas las dimensiones por las que una regla puede acotar la lista, **la cantidad no es una de ellas**: la cantidad es una propiedad de la línea, no de ningún registro que vea el filtro. Así que la forma que funciona es **un calendario de descuentos en el producto, almacenado como porcentajes**, más **productos solo bajo presupuesto marcados con un indicador en lugar de con precio cero**. Los porcentajes importan más de lo que parece: son lo que permite actualizar precios sin reconstruir todos los tramos. ## 01 · El 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. ## 02 · Por 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: > **Nada podría dirigir hacia ella.** La regla de disponibilidad de una lista de precios filtra > por campos del *presupuesto, la oportunidad y la cuenta*. La cantidad vive en la **línea**, que > ninguna regla evalúa, así que el tramo nunca podría ni siquiera acotar el desplegable. Y una > lista de precios se aplica a todo el registro, así que una persona tampoco podría elegir por > línea. Un esquema de una lista por tramo no tiene ningún mecanismo en su centro. 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. ## 03 · Modelo de datos Cuatro cuestiones, cuatro ubicaciones distintas. La base se trata en el [Blueprint 007](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) (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](https://help.coevera.com/en/articles/2710211-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. | Cuestión | Dónde vive | ¿Nativo? | |---|---|---| | Qué lista de precios se aplica | Un filtro `rules` en la lista de precios, que evalúa cualquier campo dentro del alcance | **Sí** | | El precio de lista | Una fila de lista de precios por producto y por lista | **Sí** | | El calendario de tramos por volumen | Campos de porcentaje de descuento en el **producto**, uno por tramo y por región | **No**: modelado | | Excepción solo bajo presupuesto | Una casilla de verificación en el producto, una por región | **No**: modelado | ### 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: | Pregunta | Modelado como | Qué significa si falta | |---|---|---| | ¿Se vende en esta región? | Un campo de disponibilidad de selección múltiple en el producto | No se ofrece allí | | ¿Tiene precio de lista aquí? | La existencia de una fila de lista de precios | **Ambiguo**: solo bajo presupuesto, o nadie la cargó | | ¿Es deliberadamente solo bajo presupuesto aquí? | Una casilla de precio bajo consulta por región | Debería haber tenido precio | 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 | Medida | Recuento | |---|---| | Productos en el catálogo | **1637** | | Filas de precio, región A | 788 | | Filas de precio, región B | 1193 | | Listados solo bajo presupuesto con un indicador en lugar de un precio | **709** (370 + 339) | 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. ## 04 · Configuración a nivel de campo ### Propiedades de la lista de precios que conviene conocer | Propiedad | Valores | Por qué importa | |---|---|---| | `rules` | Un filtro de campos | **El mecanismo de selección.** Véase más abajo | | `type` | `Standard` \| `Scheduled` | Una lista programada es el mecanismo para un cambio de precio con fecha | | `status` | `Active` \| `Inactive` \| `Scheduled` \| `Expired` | Estado derivado: una lista puede caducar por sí sola | | `startDate`, `endDate` | Fechas | Acotan una lista a un año de precios | | `isDefault`, `isActive` | Booleanos | La lista por defecto que viene de fábrica llega **inactiva** | ### 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ó. > **La regla rige la disponibilidad, no la aplicación.** Su etiqueta en la interfaz es *price-list > availability*, y eso es exactamente lo que hace: decide qué listas aparecen en el desplegable. > **El desplegable tiene por defecto "Without price list" y una persona elige.** Ninguna regla > aplica una lista por sí sola, y ningún campo que usted pueda fijar pondrá precio a un > presupuesto por usted. 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. > **Por qué el cuadro principal está vacío.** La condición que importa está en el presupuesto, así > que el cuadro a nivel de oportunidad no lleva nada. Un cuadro principal vacío no es un error de > configuración aquí: es el aspecto de «ninguna condición en este nivel». ### El calendario de descuentos en el producto Seis campos enteros (tres tramos, dos regiones): | Campo | Tipo | Contiene | |---|---|---| | `cf_{region}_disc_10_49` | entero | % de descuento sobre la lista con 10–49 unidades | | `cf_{region}_disc_50_99` | entero | % de descuento sobre la lista con 50–99 unidades | | `cf_{region}_disc_100_plus` | entero | % de descuento sobre la lista con 100 o más | | `cf_{region}_price_on_request` | casilla de verificación | Solo bajo presupuesto en esta región | 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ó. ## 05 · Automatizació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. > **Dicho claramente: este cálculo no estaba construido en el espacio examinado.** El catálogo, > las listas de precios con sus reglas de región, los seis campos del calendario, los indicadores > de precio bajo consulta y el campo de precio unitario neto están todos en su sitio y con datos; > ningún proceso calcula el tramo. El diseño que sigue es lo que admiten las primitivas, y no está > verificado en su comportamiento. ### 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](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/). 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](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) 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. ## 06 · Límites y compromisos > **No existe un tramo de cantidad nativo.** El objeto de ajustes de una fila de lista de precios > contiene un nivel de acceso y una lista de roles, y nada más. Ni cantidad mínima, ni colección > de tramos, ni tabla de escalones. Por tanto, todo diseño de precios por volumen en esta > plataforma es un desarrollo, y la única pregunta es cuál. - **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](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/). 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](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) y no de este. ## 07 · Verificació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?](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) — 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?](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/) — 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?](https://blueprints.coevera.com/es/blueprints/contact-migration-without-data-loss/) — 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?](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — el marco para decidir que un calendario de tramos pertenece al producto y no a una entidad nueva. ## Preguntas frecuentes ### ¿Cómo gestiona descuentos por volumen que varían por región y por producto? La región y la cantidad se gestionan en lugares distintos. Puede haber cualquier número de listas de precios válidas a la vez, y cada una lleva una regla de disponibilidad que evalúa cualquier campo del presupuesto, de la oportunidad o de la cuenta, de modo que una lista regional puede configurarse para que aparezca solo en los presupuestos a los que se aplica. Pero la regla solo controla qué listas ofrece el desplegable; el desplegable tiene por defecto "Without price list" y una persona elige. La cantidad no se puede gestionar ahí en absoluto, porque una fila de lista de precios contiene exactamente un precio y ninguna regla puede evaluar la cantidad de una línea. Así que modele el calendario de tramos como campos de porcentaje de descuento en el producto y haga que una automatización elija el tramo a partir de la cantidad de la línea. ### ¿Por qué no crear una lista de precios distinta para cada tramo de cantidad? Porque nada podría elegirla automáticamente y nadie podría elegirla a mano de forma fiable. La regla de disponibilidad de una lista de precios filtra por campos del presupuesto, la oportunidad y la cuenta; la cantidad vive en la línea, que ninguna regla puede ver, así que el tramo nunca podría acotar el desplegable, y una persona tendría que elegir la lista del tramo correcto línea por línea, lo cual ni siquiera es posible, porque una lista se aplica a todo el registro. Además, las listas se multiplicarían por cada una de las demás dimensiones por tramo, y cada una necesitaría un juego completo de filas de precios: en un catálogo de 1637 productos, dos regiones por cuatro tramos ya suponen más de diez mil filas mantenidas a mano en sincronía. ### ¿Un tramo de cantidad debe guardar un precio o un porcentaje de descuento? Un porcentaje. Guardar precios absolutos por tramo significa que cada cambio del precio de lista obliga a volver a introducir todos los tramos de ese producto, y los tramos quedan desactualizados sin que nadie lo note cuando eso no se hace. Un porcentaje sobre el precio de lista vigente sobrevive intacto a una actualización de precios, así que una revisión de precios es una sola importación en la lista de precios y no una reconstrucción del calendario de descuentos. ### ¿Cómo gestiona los productos que no tienen precio de lista? Con un indicador explícito por región, y sin ninguna fila de precio. Nunca con un precio de cero: un precio de cero produce un presupuesto de valor cero que parece un número real. Y nunca solo con la ausencia de la fila, porque una fila de precio ausente no se distingue de una que nadie ha configurado todavía. En un catálogo real, 709 de 2690 listados regionales eran solo bajo presupuesto y llevaban una casilla de precio bajo consulta en lugar de un precio. ### ¿Pueden los tramos de cantidad ser distintos entre regiones? No cuando los tramos son campos. Como cada tramo es su propio campo, los límites de los tramos viven en el esquema, así que todas las regiones tienen que compartir la misma estructura de tramos. Un catálogo real llegó con cinco tramos en una región y tres en la otra, y se normalizó a los tres tramos comunes; cambiarlo más adelante es un cambio de esquema más una migración de datos, no un cambio de configuración. --- Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos de clientes, sin datos personales.