SAP SD: qué hace y dónde fallan las implementaciones

SAP SD (Ventas y distribución) gestiona el ciclo del pedido al cobro en SAP: oferta, pedido de venta, entrega, facturación y traspaso a finanzas. En S/4HANA cambia de formas que afectan al alcance del proyecto. Los clientes pasan a ser interlocutores comerciales, la gestión de crédito se traslada a SAP Credit Management, las bonificaciones retroactivas pasan a contratos de condiciones y la facturación contabiliza directamente en el Universal Journal. Esta guía es para responsables de operaciones de ventas, controllers financieros y directores de proyecto que necesitan saber qué hace SD y dónde falla. La respuesta corta a lo segundo: los datos maestros de clientes, las condiciones de precios, la verificación de disponibilidad y la determinación de cuentas. Pruebe esos cuatro con datos reales antes del go-live.

En un despliegue posterior a una implementación completa de SAP, los pasos del ciclo del pedido al cobro se construyeron exactamente como se habían diseñado. En el mapa de procesos se veían bien. Nadie había comprobado cómo llegaban las actualizaciones de stock desde producción.

Ventas decía a los clientes cinco días. Fabricación sabía que eran casi diez.

Esa brecha costó más que las entregas tardías. Costó confianza, y la confianza es más difícil de reconstruir que un parámetro de configuración.

SD está al inicio de la cadena logística. Convierte el interés de un cliente en una factura mediante una cadena de documentos:

1. Consulta: el cliente pide precio o disponibilidad
2. Oferta: una propuesta formal de precio y entrega con un periodo de validez
3. Pedido de venta: el cliente se compromete, se ejecuta la verificación de disponibilidad y se confirma una fecha de entrega
4. Entrega: el almacén hace el picking y el embalaje; la salida de mercancías reduce el stock
5. Facturación: se crea la factura junto con su documento contable
6. Cobro: finanzas compensa el cobro recibido contra la partida abierta

Cada documento hace referencia al anterior. Ese flujo de documentos es lo que hace trazable el ciclo del pedido al cobro. Si la cadena está limpia, puede rastrear cada factura hasta la solicitud original. Si los documentos se crean fuera de secuencia o se omiten, los informes se rompen y llegan las disputas.

1. 01ConsultaSe pide precio o disponibilidad
2. 02OfertaPropuesta formal con fecha de validez
3. 03Pedido de ventaLa verificación de disponibilidad confirma la fecha
4. 04EntregaPicking, embalaje, salida de mercancías
5. 05FacturaciónFactura y documento contable
6. 06CobroFinanzas compensa la partida abierta

Cada factura se puede rastrear hasta la solicitud original

Bien hecha, esa cadena elimina traspasos manuales. Un cliente del sector manufacturero redujo su ciclo del pedido al cobro un 40 % después de poner SD en producción, sobre todo al eliminar los traspasos entre ventas, almacén y finanzas.

Pedidos de venta y verificación de disponibilidad

El procesamiento de pedidos de venta es donde se concentra la mayor parte del esfuerzo de configuración de SD: clases de pedido, tipos de posición, repartos y la verificación de disponibilidad.

El Available-to-Promise (ATP) es la pieza más crítica para el negocio. Comprueba si la fecha solicitada se puede cumplir con el stock, las recepciones previstas y los compromisos existentes. Bien configurado, ventas dice a los clientes lo que el sistema realmente puede comprometer. Mal configurado, ventas dice a los clientes lo que espera entregar.

En el despliegue del principio, nadie había comprobado cómo llegaban las actualizaciones de stock desde producción. Ventas cotizaba fechas que la planta no podía cumplir.

Precios y condiciones

La determinación de precios es la configuración más subestimada de SD. Parece sencilla hasta la primera disputa de una factura.

La técnica de condiciones de SD gestiona precios base, descuentos de cliente, escalas por volumen, recargos, flete e impuestos. Cada elemento es una clase de condición con una secuencia de acceso, y el registro de condición contiene el valor.

El problema de precios más común que veo: condiciones de precios antiguas del go-live que nunca se actualizaron. El negocio renegocia un descuento, nadie actualiza el registro de condición en SD, la factura sale mal y la disputa acaba en cuentas por cobrar.

El gobierno de los precios es una decisión de proceso, no de configuración. Alguien tiene que ser responsable del mantenimiento de los registros de condición.

Expedición

El procesamiento de entregas abarca el picking, el embalaje y la salida de mercancías. La salida de mercancías es el evento crítico: contabiliza la reducción de stock, coloca la entrega en la lista de facturación pendiente y registra la fecha real de entrega. El puesto de expedición y la determinación de ruta controlan cómo se crean las entregas. Las empresas con redes de distribución complejas lo amplían con SAP Transportation Management (TM).

Facturación, determinación de cuentas e impuestos

La facturación convierte la entrega en una factura y crea el documento contable. La determinación de cuentas asigna cada posición de factura a cuentas de ingresos, de impuestos y otras cuentas del libro mayor, según la organización de ventas, los grupos de imputación de cuentas de cliente y de material y la clase de condición. Cuando es incorrecta, la factura se contabiliza en la cuenta equivocada y finanzas lo descubre en el cierre mensual.

La determinación de impuestos es igual de frágil. Depende de la clasificación fiscal del cliente, de la clasificación fiscal del material y del país o la jurisdicción de entrega. Un desajuste puede generar una factura sin impuestos en una venta gravada, o con impuestos en una venta exenta.

Gestión de crédito

Las verificaciones de crédito bloquean o señalan los pedidos que llevarían a un cliente más allá de su límite de crédito. Solo funcionan si los límites se mantienen. Los límites estáticos fijados en el go-live dejan de significar algo cuando cambian el comportamiento de pago y los volúmenes.

Cuando un límite cae por debajo del tamaño habitual de pedido de un cliente, todos los pedidos se bloquean automáticamente. Los equipos de ventas aprenden entonces a liberar los bloqueos en lugar de pedir una revisión del límite.

Eso no es gestión de crédito. Es un parche.

Estos son los elementos de la estructura de SD y con qué se vincula cada uno.

Elemento de estructura	Finalidad en SAP SD	Vínculo clave
Organización de ventas	Unidad de venta de nivel superior, responsable de las condiciones de venta y de la responsabilidad	Asignada a una sociedad en FI
Canal de distribución	Cómo llegan los productos al cliente (mayorista, minorista, directo)	Controla precios, datos maestros y determinación de interlocutores
Sector	Grupo de productos dentro de la organización de ventas	Agrupación de materiales para informes y salidas
Área de ventas	Organización de ventas, canal de distribución y sector juntos	Obligatoria para cada documento de ventas y registro de cliente
Oficina de ventas	Unidad de venta geográfica	Informes regionales y determinación de interlocutores
Grupo de vendedores	Equipo dentro de una oficina de ventas	Persona responsable en los pedidos
Puesto de expedición	Lugar desde el que se envían las mercancías	Vincula SD con la gestión de almacenes y el transporte
Centro	Unidad productora o suministradora	Origen del stock, vinculado al puesto de expedición

El área de ventas es la unidad operativa. Los datos de ventas del cliente se mantienen por área de ventas y cada documento de ventas se crea en una de ellas. Muchas migraciones tropiezan aquí: los registros de clientes heredados que no encajan limpiamente en áreas de ventas necesitan una preparación real antes de la carga.

Si pasa de ECC, estos son los cambios de SD que debe incorporar al alcance. SAP clasifica el área como «Ventas» en su documentación de S/4HANA, aunque la mayoría de los equipos sigue llamándola SD.

ECCS/4HANA

ClientesECCRegistro maestro de clientesS/4HANAInterlocutor comercial con rol de cliente

Gestión de créditoECCFI-AR-CRS/4HANASAP Credit Management (FIN-FSCM-CR), no es opcional

Bonificaciones retroactivasECCProcesamiento de bonificaciones de SD, reconstruido desde un índiceS/4HANAContratos de condiciones en Settlement Management

Verificación de disponibilidadECCVerificación básica de disponibilidad de productoS/4HANAATP avanzado: asignación, pedidos pendientes, centros alternativos

FacturaciónECCFI y CO conciliados por separadoS/4HANAUna sola posición en el Universal Journal (ACDOCA)

Reconocimiento de ingresosECCLógica de diferimiento a medida en muchos programasS/4HANASAP Revenue Accounting and Reporting, con licencia aparte

1. Los clientes son interlocutores comerciales. Los datos maestros de cliente se mantienen mediante el interlocutor comercial con rol de cliente. En una conversión, la integración cliente-proveedor debe configurarse antes de ejecutar la conversión.
2. La gestión de crédito pasa a SAP Credit Management. La gestión de crédito de ECC (FI-AR-CR) no está disponible en S/4HANA. SAP Credit Management (FIN-FSCM-CR) es su sustituto, así que una conversión tiene que migrar los datos y los parámetros de crédito. No es opcional.
3. Las bonificaciones retroactivas pasan a contratos de condiciones. El procesamiento clásico de bonificaciones retroactivas de SD se sustituye por Settlement Management (gestión de contratos de condiciones). Las condiciones de bonificación se aplican de inmediato en lugar de reconstruirse desde un índice.
4. ATP avanzado. El ATP avanzado de S/4HANA añade asignación de producto, procesamiento de pedidos pendientes, confirmación basada en alternativas entre centros, liberación para entrega y asignación de suministro. En S/4HANA Cloud estas funciones forman parte de la licencia estándar. On-premise requieren una licencia específica una vez activadas.
5. La facturación se contabiliza en el Universal Journal. FI, CO y el análisis de márgenes comparten una única posición en ACDOCA, lo que elimina el trabajo de conciliación FI-CO de ECC. La contrapartida: un error en la determinación de cuentas es una contabilización inmediata en la cuenta equivocada, visible a nivel de posición.
6. Reconocimiento de ingresos. Para contratos de múltiples elementos, suscripciones o servicios a largo plazo bajo la NIIF 15, SAP Revenue Accounting and Reporting sustituye la lógica de diferimiento a medida que muchos programas de ECC construyeron. Tiene licencia aparte y hay que diseñarlo antes del go-live, no descubrirlo en el cierre del ejercicio.

El Clean Core cambia la forma de tratar la personalización de SD. En la nube pública no es posible incluir código personalizado en el núcleo. En la nube privada y on-premise es posible, pero hace más difícil cada actualización. La mayoría de las antiguas rutinas Z de precios se pueden sustituir por clases de condición estándar, fórmulas y BAdIs. Lo que realmente queda pertenece a una extensión side-by-side en SAP BTP. Mi guía de Clean Core trata esa decisión.

SD con MM

La verificación de disponibilidad lee el stock de MM y la salida de mercancías contabiliza el movimiento de stock. Si los datos de inventario son incorrectos, los resultados del ATP no son fiables. Si la salida de mercancías falla porque el stock no está realmente en el puesto de expedición, la entrega no puede completarse y la facturación se detiene. Mantenga ambos alineados mediante los datos maestros y mediante disciplina: sin ajustes manuales de stock que eludan las contabilizaciones estándar.

SD con PP

En los escenarios de fabricación bajo pedido, un pedido de venta puede impulsar directamente la producción, de modo que la fecha confirmada se convierte en un compromiso respaldado por una orden de fabricación. El grupo de estrategias del maestro de materiales controla cómo interactúan los pedidos de venta y las previsiones. Si se configura mal, se suman en lugar de compensarse, la ejecución de la planificación sobrestima la demanda y llega la sobreproducción. Mi guía de SAP PP trata el lado de la planificación.

SD con FI

El documento de facturación es la interfaz. Cada factura crea un documento contable que contabiliza los ingresos, los impuestos y la partida abierta del cliente en el Universal Journal. Las condiciones de pago del maestro de clientes determinan la fecha de vencimiento. Cuando ventas negocia condiciones sin avisar a finanzas, el sistema aplica condiciones que finanzas nunca acordó.

Si el diseño de SD trata todos los ingresos como reconocidos en la facturación y los contratos dicen otra cosa, la corrección posterior sale cara. Acuerde el reconocimiento de ingresos con finanzas antes de aprobar el diseño. Para el lado financiero de la integración, consulte mi guía de SAP FICO.

Cuatro puntos de fallo causan la mayor parte del dolor posterior al go-live.

Datos maestros de clientes sin preparar. Cada campo importa aguas abajo. Sin clasificación fiscal, el impuesto es incorrecto. Sin condiciones de pago, FI no puede calcular las fechas de vencimiento. Sin condiciones de expedición, la programación de entregas se rompe. Los volúmenes son mayores y los datos de origen peores de lo que supone el plan, y la limpieza requiere decisiones de negocio. Empiece pronto y trátelo como un frente de trabajo de negocio, no como una carga técnica. Mi artículo sobre por qué fracasa la migración de datos en SAP explica el método.

Condiciones de precios sin mantener. Las condiciones del go-live que nadie revisa se convierten en disputas de facturas durante el primer año.

Verificación de disponibilidad desconectada de la realidad. Un ATP que lee datos obsoletos genera promesas que el negocio no puede cumplir. Valídelo con escenarios reales de producción y de stock, no con los datos de prueba limpios de las pruebas unitarias.

Huecos en la determinación de cuentas descubiertos tras el go-live. Pruebe con el plan de cuentas, los indicadores de impuestos y los grupos de materiales reales. Unos indicadores de impuestos que no coinciden pueden bloquear pedidos o provocar disputas de facturas antes de que nadie entienda qué falla.

La tabla es la lista de comprobación que repasaría antes de la aprobación de las pruebas de aceptación de usuario (UAT).

Riesgo	Impacto	Mitigación
Datos maestros de clientes incompletos	Errores en facturas, fallos de entrega, huecos en las contabilizaciones de FI	Empezar pronto el frente de datos; definir los campos obligatorios por área de ventas antes de la migración
Condiciones de precios obsoletas	Disputas de facturas, ingresos incorrectos	Nombrar a un responsable de los registros de condición y un ciclo de revisión en el go-live
ATP desconectado de PP o MM	Promesas de entrega poco fiables	Probar el ATP con escenarios de planificación reales antes de la aprobación de UAT
Huecos en la determinación de cuentas	Ingresos contabilizados en las cuentas equivocadas	Probar con el plan de cuentas real y el conjunto completo de indicadores de impuestos
Liberación de bloqueos de crédito como rutina	Exposición no controlada, disputas de cuentas por cobrar	Exigir revisiones de límites; hacer seguimiento de las liberaciones manuales en los primeros 90 días
Salidas sin probar	Facturas y notas de entrega que no se envían automáticamente	Probar cada tipo de salida con el enrutamiento real de impresión y correo electrónico antes del go-live
Condiciones de pago desalineadas	Fechas de vencimiento incorrectas, errores en la previsión de caja	Acordar las condiciones entre ventas y finanzas antes de cargar los datos de clientes

Si el equipo de ventas libera de forma rutinaria los bloqueos de crédito en lugar de pedir una revisión, corríjalo en los primeros noventa días, antes de que el hábito se consolide.

¿Qué es SAP SD y qué hace?

SAP SD (Ventas y distribución) gestiona el ciclo del pedido al cobro: consultas, ofertas, pedidos de venta, entregas, facturación y traspaso a la contabilidad financiera. Su flujo de documentos vincula cada paso con el anterior, de modo que cada factura puede rastrearse hasta el pedido original. Se integra con MM para el stock y la salida de mercancías, con PP para la fabricación bajo pedido y la disponibilidad, y con FI para ingresos, impuestos y cuentas por cobrar.

¿Cuál es la estructura organizativa en SAP SD?

La unidad operativa es el área de ventas: una organización de ventas, un canal de distribución y un sector juntos. Cada documento de ventas se crea en un área de ventas y los datos de ventas del cliente se mantienen por área de ventas. Las oficinas de ventas y los grupos de vendedores quedan por debajo, para informes y responsabilidades. En el lado logístico, los puestos de expedición y los centros determinan desde dónde se envían las mercancías. Defina bien la estructura antes de cargar los datos de clientes, porque cambiarla después significa volver a cargar los datos.

¿Cómo funciona la determinación de precios en SAP SD?

La determinación de precios usa la técnica de condiciones. Cada elemento de precio es una clase de condición, una secuencia de acceso decide qué registro de condición se aplica y un esquema de cálculo combina las clases de condición en orden. La mayoría de las disputas de precios se remontan a registros de condición que no se actualizaron cuando cambiaron las condiciones comerciales, no a errores de configuración.

¿Qué es el ATP avanzado en SAP S/4HANA?

El Available-to-Promise avanzado (aATP) es la verificación de disponibilidad de S/4HANA. Además de la verificación básica de disponibilidad de producto, añade asignación de producto, procesamiento de pedidos pendientes, confirmación basada en alternativas entre centros, liberación para entrega y asignación de suministro. Estas funciones están incluidas en S/4HANA Cloud y requieren una licencia específica on-premise una vez activadas. Úselas donde el suministro esté limitado o importen las reglas de asignación. Para cadenas de suministro estables, una verificación básica bien configurada suele bastar.

¿Cómo se integra SAP SD con la contabilidad financiera?

A través del documento de facturación. Liberar un documento de facturación a contabilidad crea un asiento para los ingresos, los impuestos y la partida abierta del cliente. La determinación de cuentas decide las cuentas del libro mayor a partir de la organización de ventas, los grupos de imputación de cuentas y la clase de condición. Los impuestos dependen de las clasificaciones fiscales del cliente y del material. Las condiciones de pago del maestro de clientes fijan la fecha de vencimiento. Para los casos de NIIF 15, SAP Revenue Accounting and Reporting difiere y reconoce los ingresos a lo largo del tiempo.

¿Qué cambia en SAP SD al pasar de ECC a S/4HANA?

Los clientes pasan a ser interlocutores comerciales. La gestión de crédito pasa de FI-AR-CR a SAP Credit Management, que es obligatorio. El procesamiento de bonificaciones retroactivas se sustituye por contratos de condiciones en Settlement Management. El ATP avanzado pasa a estar disponible y la facturación se contabiliza en el Universal Journal. Incorpore todo esto al alcance desde el principio, porque cada punto requiere configuración, migración de datos y pruebas.

¿Cuáles son los errores más comunes en las implementaciones de SAP SD?

Cinco aparecen una y otra vez. Subestimar los datos maestros de clientes. Dejar las condiciones de precios sin responsable después del go-live. Probar el ATP solo con datos limpios. Probar la determinación de cuentas con datos simplificados. No probar las salidas de principio a fin. Esta última es fácil de pasar por alto. Cuando las facturas no salen automáticamente, alguien empieza a imprimirlas a mano y el parche se vuelve permanente.