General

Concepto general

El módulo Pricing implementa una técnica de condiciones. No existe un único campo “precio” — el precio final se calcula aplicando, en orden, una cadena de condiciones (precios base, descuentos, recargos, impuestos) que pueden variar según el material, el cliente, la fecha y el contexto de la transacción.

Entidades y relaciones

PricingProcedure
  └── ConditionType (ordenados por step)
        ├── ConditionClass  (A=Descuento, B=Precio, C=Gasto, D=Impuesto)
        ├── AccessSequence
        │     └── AccessSequenceStep (ordenados)
        │           └── ConditionTable
        │                 └── ConditionRecord (vigente, más específico)
        └── PriceList (solo si class = B)
              └── PriceListVersion (activa)
                    └── PriceListVersionMaterial (precio por artículo)

SchemaDetermination
  (TipoComprobante + CanalDeVentas? + CentroDeResponsabilidad? + Empresa)
    → PricingProcedure

Flujo de cálculo — end to end

Input: Artículo + contexto (TipoComprobante, CanalDeVentas, etc.) + fecha

1. SchemaDetermination
   → identifica el PricingProcedure correspondiente al contexto

2. PricingProcedure — para cada ConditionType (ordenado por step):

   Si class = B (Precio):
     → PriceList → versión activa → precio del artículo

   Si class = A / C / D (Descuento / Recargo / Impuesto):
     → AccessSequence → steps en orden:
         → ConditionTable → ConditionRecord que coincida con:
             - fecha dentro del rango de vigencia
             - artículo (o su categoría, familia, o global)
             - condición de pago (si aplica)
             → porcentaje (ej. -0.05 = -5%)

3. Aplicar en orden de step:
   precio_neto = precio_base × (1 + Σ porcentajes)

Output: precio con detalle de cada condición aplicada

Jerarquía de aplicación de ConditionRecords

El sistema usa el primer registro que coincide, buscando de más específico a más general:

1. Artículo específico
2. RubroCx (categoría)
3. Family (familia de neumático)
4. Global (aplica a todos)

Reglas de negocio

• No hay un único campo precio — el precio siempre es el resultado de aplicar un procedimiento de condiciones.
• Los ConditionRecord tienen fechas de vigencia: solo aplican si valid_from ≤ hoy ≤ valid_to.
• El sistema usa el registro más específico que encuentre en la jerarquía.
• La SchemaDetermination debe existir para el contexto de la transacción; si no hay ninguna que coincida, el sistema no puede calcular el precio.
• Las versiones de PriceList en producción tienen IDs fijos — no se reemplazan, se crean nuevas versiones y se copian a producción.