Hola Luis Alberto, buen caso. En ECC (SD) se puede resolver con un “doble carril”: una condición real que ajusta la base imponible (antes de IVA) y otra estadística que solo se muestra en la factura como “descuento final (incluye IVA)”. El IVA se recalcula automáticamente porque es una condición en el procedimiento de precios (p.ej. MWST) y su posición determina la base sobre la que aplica .

• Condiciones (V/06):
  • ZDCP_G (Cupón bruto, estadística):
    • Manual (cabecera o posición según aplique), estadística = X, sin clave contable.
    • Si el cupón es global, marcar como Group Condition para prorratear por valor.
    • Se introduce el importe “con IVA” (ej.: 5).
  • ZDCP_N (Cupón neto, real):
    • No manual (o manual no visible). Real, con clave contable (p.ej. ERS) para contabilizar como deducción comercial.
    • Cálculo alternativo (VOFM): leer el importe bruto de ZDCP_G y convertirlo a neto dividiendo por (1 + tipo IVA) de la posición. Es decir: valor(ZDCP_N) = valor(ZDCP_G) / (1 + %IVA).
    • Si es a nivel cabecera, mantener Group Condition y prorratear por base de valor.
• Procedimiento de precios (V/08), secuencia orientativa:
  • … Precio base (PR00) y descuentos previos.
  • Subtotal KZWI1 = base neta antes del cupón.
  • ZDCP_N (real): colocar antes del IVA. Añadir un Requirement (VOFM) que la active solo si existe ZDCP_G.
  • Subtotal KZWI2 = neto tras cupón (opcional, útil para impresión/analítica).
  • MWST (IVA): definir From/To para que la base incluya hasta el paso de ZDCP_N. Así el IVA se recalcula sobre el neto ajustado, reduciendo proporcionalmente el impuesto. Esto se alinea con el estándar: el IVA es una condición en el procedimiento y su posición controla la base .
  • ZDCP_G (estadística): ubicarla al final para “visualizar” el descuento final (incluye IVA) en la factura, sin impacto contable ni fiscal.
• Impresión (formulario de factura):
  • Mostrar ZDCP_G con el texto “Descuento final (incluye IVA)”.
  • Ocultar ZDCP_N si no se desea mostrar la línea de descuento neto técnica.
  • El IVA y totales ya aparecerán recalculados por la posición de MWST en el procedimiento .
• Contabilidad (FI):
  • ZDCP_N lleva la clave contable (p.ej. ERS) y sí impacta en FI (deducciones sobre ingresos).
  • ZDCP_G es estadística, sin clave contable, no se contabiliza.
  • MWST contabiliza el IVA sobre la base reducida.
• Ejemplo (tu caso 21%):

  Base neta:     100,00
  Cupón bruto:     5,00  (introducido en ZDCP_G)
  Cupón neto:      5 / 1,21 = 4,132231  (calculado en ZDCP_N)
  Nuevo neto:     95,867769
  IVA (21%):      20,132231
  Total:         116,00
  Visualización:  “Descuento final (incluye IVA)” = 5,00 (ZDCP_G)

Detalles técnicos y consideraciones:

• VOFM:
  • Altern. cálculo de valor para ZDCP_N (convierte bruto→neto por posición usando el %IVA de cada línea).
  • Requirement para aplicar ZDCP_N solo si existe ZDCP_G.
• Prorrateo: si el cupón es a cabecera, marcar ambas condiciones como Group Condition y repartir por valor (p.ej., base KZWI1).
• Redondeos: ajustar por posición y, si hace falta, cuadrar diferencias en la última línea para que la suma de descuento neto + bajada de IVA = cupón bruto exacto.
• Casos mixtos: si hay líneas con distintos IVA (o exentas), la rutina debe calcular por posición respetando su MWSKZ y excluir lo que no corresponda.
• Alternativa: si no quieres una condición estadística aparte, puedes permitir entrada manual “bruta” en la condición real y que la propia rutina interprete el importe como “con IVA”. Aun así, recomiendo mantener ZDCP_G para que la factura muestre el rótulo de negocio.

Si te encaja, te paso ejemplos de rutas VOFM y la parametrización típica de V/06/V/08 (nombres Z*, indicadores, y sugerencias de Subtotales KZWI) para que lo repliques en tu mandante.

Referencias del estándar: la lógica de procedimiento de precios (condiciones reales vs. estadísticas, subtotales, claves contables) y el IVA como condición (MWST) posicionada en el esquema son parte del comportamiento estándar de SD .

¡Buena pregunta, Luis! Para cuadrar los “céntimos” sin pelearte con el reparto bruto→neto por línea, la condición estándar que resuelve el redondeo en SD es DIFF (Rounding Difference).

• Qué hace: ajusta automáticamente la cifra final del documento hasta la unidad de redondeo definida por sociedad/moneda en T001R, y distribuye la diferencia entre ítems según valor (es condición de grupo). Esto evita descuadres de 0,01–0,02 al sumar descuentos e IVA.
• Dónde ponerla (V/08): ubícala al final del procedimiento, después de MWST y tras tu lógica de cupón (ZDCP_N real antes de IVA y ZDCP_G estadística para mostrar). Así se recalcula el IVA correctamente y, si queda residuo por redondeo, DIFF lo corrige al cierre.
• Cómo parametrizar (V/06):
  • Condición automática (sin acceso y sin entrada manual).
  • Grupo de condición = X (para que reparta por valor).
  • Sin clave contable (no genera línea propia en FI; ajusta el neto/IVA resultante).
• Notas útiles:
  • Revisa la unidad de redondeo en T001R (por ejemplo 0,01 o 0,05 según tu negocio); DIFF usa ese parámetro.
  • Si en algún caso necesitases “forzar” un valor de cabecera y que se redistribuya y se recalcule el IVA, existe la cabecera HM00 (manual), que reparte a ítems y provoca re-cálculo de impuestos; no es para redondeo per se, pero es buena referencia del comportamiento estándar de redistribución.

En resumen: añade DIFF al final del esquema y asegúrate de tener definida la unidad de redondeo en T001R. Encaja perfecto con el “doble carril” propuesto (condición real que ajusta base e IVA + condición estadística para mostrar el descuento con IVA) y elimina los descuadres residuales.

¡Gran pregunta, Luis! Comparo los dos enfoques para el “cupón de fabricante” (descuento mostrado “con IVA” pero que legalmente reduce la base imponible) y cuándo conviene cada uno.

• Enfoque sin VOFM (100% estándar de personalización)
  
  • Qué haces: defines un Z* real (p.ej., ZDCP_N) ubicado antes de MWST, de modo que el IVA se recalcule sobre la base ya reducida, que es el comportamiento estándar en SD porque el IVA se determina como condición en el esquema y su posición controla la base de cálculo . Añades un Z*G estadístico (p.ej., ZDCP_G) al final para “mostrar” el descuento bruto en la factura sin impactar el neto; las condiciones marcadas como estadísticas son informativas y no modifican el valor neto .
  • Visualización del bruto: se puede introducir manualmente en ZDCP_G o calcularlo en el formulario de factura (fuera del pricing). No hay “enganche” automático entre neto y bruto dentro del procedimiento de precios.
  • FI: el Z real (ZDCP_N) contabiliza contra deducciones de venta vía cuenta clave (p.ej., ERS) en VKOA; el IVA (MWST) se contabiliza por el procedimiento fiscal del país y las cuentas de impuestos se determinan en FI (p.ej., MWS en OB40) .
  • Pros: sin desarrollo en pricing, menos mantenimiento técnico, rápida implantación.
  • Contras: la coherencia “bruto mostrado = (rebaja neta + baja de IVA)” depende de la disciplina de usuario o de lógica en el formulario; se complica con múltiples tipos de IVA, exenciones o prorrateos a cabecera; menos trazabilidad del cálculo dentro de SD.
• Enfoque con VOFM (rutina de cálculo/requirement en pricing)
  
  • Qué haces: mantienes un Z*G estadístico para introducir el bruto de negocio y un Z*N real que, mediante cálculo alternativo, deriva el neto dividiendo por (1 + %IVA) por posición (según MWSKZ). Colocas MWST después de Z*N para que el IVA se recalcule sobre la base ya ajustada (comportamiento estándar del IVA en pricing) . Z*G queda al final, solo para mostrar.
  • Control: puedes añadir un requirement que active Z*N solo si existe Z*G, prorratear a cabecera como group condition y asegurar que “suma(rebaja neta) + reducción de IVA = cupón bruto” al céntimo.
  • FI: solo Z*N impacta contabilidad (asignación de cuentas de condiciones de precio vía VKOA), y MWST contabiliza sobre la base reducida por el esquema fiscal del país; Z*G al ser estadístico no afecta el neto ni FI .
  • Pros: determinismo y trazabilidad del cálculo dentro de SD, robusto con múltiples tipos de IVA/exenciones y cupones a cabecera (prorrateo por valor). Minimiza error humano y cierra auditoría (el importe mostrado “con IVA” coincide exactamente con el efecto neto + impuesto).
  • Contras: requiere una rutina VOFM (desarrollo/QA/transporte), gobierno de cambios.

¿Cuál elegir?

• Evitar VOFM si tu casuística es simple: un solo tipo de IVA por documento, tolerancia a resolver centésimos vía redondeo estándar y te basta con que el “descuento final (con IVA)” sea un dato de visualización (estadístico o calculado en el formulario) mientras que el efecto real lo produce la condición Z*N antes de MWST (estándar de SD) .
• Usar VOFM si necesitas garantías fuertes: cupones a cabecera a prorratear por posición, mix de tipos de IVA o exentos en el mismo documento, requisito de auditoría para que el “bruto mostrado” sea exactamente igual al efecto combinado neto+IVA, o si quieres bloquear incoherencias (requirement) y reducir entradas manuales.

Blueprint mínimo sugerido (sin VOFM):

• V/06: ZDCP_N (real, con clave contable p.ej. ERS, group cond si es a cabecera); ZDCP_G (estadística, sin clave contable) .
• V/08: ZDCP_N antes de MWST; definir From/To de MWST hasta el paso de ZDCP_N para que el impuesto se recalcule sobre la base reducida; ZDCP_G al final, solo visual .
• FI: ZDCP_N vía VKOA a deducciones de ventas; MWST a cuentas de impuestos según procedimiento fiscal/clave MWS en OB40 .

Si quieres, te propongo la parametrización concreta (V/06, V/08) para ambos escenarios y una pauta de pruebas con ejemplos de líneas con IVA 21% + exentas para ver las diferencias en prorrateo y auditoría. ¿Te encaja este plan?