Lea esto primero
El monitoreo de riesgo no es una capacidad de SLP, y las respuestas de los cuestionarios modulares nunca llegan a su ERP. Esas dos frases definen la mayor parte de la arquitectura.
SLP, SIPM, Supplier Risk y SPM son cuatro soluciones con una superficie compartida — cuestionarios modulares, certificados, findings y enriquecimiento D&B — y bordes marcadamente distintos. El monitoreo de riesgo y la evaluación de riesgo basada en controles requieren SAP Ariba Supplier Risk, licenciado por separado. Las SPM Reviews, por el contrario, no son una capacidad de Supplier Risk. Y el atajo del sector según el cual “SIPM es clásico, SLP es nuevo” no es confiable: el propio material de SAP trata new-versus-classic como un atributo de ambos. Confirme el entitlement, no el posicionamiento.
Esto importa de inmediato, porque los cuestionarios modulares no existen en la arquitectura clásica de SIPM. Prometerlos antes de confirmar la arquitectura equivale a prometer una capacidad que el sitio no puede entregar. Las aplicaciones de Supplier Management corren sobre SAP BTP y se acceden desde el sitio de Ariba — lo que implica al menos cuatro superficies de administración, dos de ellas con nombres casi idénticos, antes de configurar nada.
El ciclo de vida, y dónde falla cada etapa
Seis fases del ciclo de vida, cada una con su propio tipo de proyecto. Qualification se identifica por punto de matriz, no por proveedor — diseñe la matriz de commodity/región/departamento antes de crear registros masivamente.
| Etapa | Qué se crea | Dónde falla |
|---|---|---|
| Supplier Request | Proyecto Supplier Request | El chequeo de duplicados detiene la solicitud; la aprobación nunca resuelve un aprobador; la solicitud se aprueba pero no se crea el proveedor |
| Perfil Supplier 360 | SM Vendor ID (VDR…) | El perfil se crea sin un ERP Vendor ID |
| Supplier Registration | Proyecto de Registration, cuestionarios externos e internos | La invitación nunca se envía; el proveedor no puede ver el cuestionario; la aprobación empieza demasiado pronto o nunca |
| Sincronización con el ERP | SAP Business Partner / registro maestro de vendor | El disparador de estado mínimo falla; el ERP rechaza por unicidad o longitud de campo; el estado queda atascado en In Progress |
| Qualification | Proyecto de Qualification por punto de matriz | “A qualification already exists for one or more of these matrix points” |
| Cuestionarios modulares | Proyectos MQ, certificados | Las respuestas no llegan al ERP; la invitación masiva se limita a casi 100 proveedores |
| Preferred Supplier Management | Designación de preferido por categoría | Bloqueado por una descalificación en un nivel inferior de la matriz |
| SPM | Scorecards, encuestas, KPIs | La plantilla no permite documentos de KPI; el puntaje de la encuesta nunca llega al scorecard |
El traspaso de request → registration es la costura más frágil del producto. Una docena de artículos de soporte independientes describen fallas ahí, entre 2022 y 2025: atascado en Submitted, aprobado sin crear proveedor, valores de campo que no se trasladan. La tercera variante suele resultar ser un desajuste de tipo de respuesta — Address en la solicitud contra Extended Address en registration.
El proveedor experimenta todo esto a través de Ariba Proposals and Questionnaires en SAP Business Network. Que la configuración del lado del comprador sea correcta no demuestra nada sobre la visibilidad del proveedor, lo cual coloca la administración de la cuenta de Business Network directamente en la ruta crítica del go-live — no en el backlog de integración.
Las decisiones que no puede revertir
- Migración a Unified Vendor Model
- Requerida para SLP. Una migración de datos única, no un cambio de configuración — falla ante registros duplicados, campos obligatorios vacíos e incompatibilidades de formato. Limpie los datos primero.
- Dónde residen los campos vinculados al ERP
- Las respuestas de cuestionarios modulares no están soportadas para sincronización con el ERP. Equivocarse aquí implica reconstruir cuestionarios y volver a recolectar datos de proveedores en vivo.
- Convención y capitalización del ERP vendor ID
- Escritura única en un proveedor integrado. Estandarice la capitalización y exija unicidad antes de cargar la base legacy.
- Proveedores legacy registrados internamente
- Los proveedores registrados internamente no pueden establecer una relación transaccional — eso limita la ruta transaccional para la porción de la base incorporada de esa forma.
- Process rollout (SM-16798)
- Una vez habilitado, se bloquean las nuevas qualifications de estilo legacy. La fuente no documenta si es reversible. Decida antes de producción.
- Idioma base de la plantilla
- SAP documenta cómo modificarlo. Nada indica que sea reversible.
Un sitio migrado aún puede admitir registros por la puerta antigua — se ha observado que el autoregistro de proveedores legacy sobrevive a una migración a UVM. Presupueste un ciclo de pruebas separado para la base migrada: se comporta distinto de los proveedores registrados nativamente en el chequeo de duplicados, la recuperación por API, el estado de llegada y el vencimiento de qualification.
Dónde va cada pregunta
Una implementación de SLP vive o muere por esta única decisión, y la documentación del producto no ofrece ninguna guía al respecto.
| Colóquelo en… | Cuándo | Restricción ineludible |
|---|---|---|
| Supplier Request | Necesario para la decisión de crear/verificar duplicados, o vinculado al ERP y conocido al momento de la solicitud | El chequeo de duplicados opera aquí, por pregunta |
| Cuestionario de Registration | Debe llegar al registro de SAP Business Partner / ERP | Es la única ruta documentada vinculada al ERP junto con la solicitud |
| Supplier Profile Questionnaire | Información de perfil duradera, no ligada a un evento del ciclo de vida | Mapear SPQ → cuestionario de registration es un paso administrativo manual |
| Cuestionario modular | Recurrente, periódico, impulsado por certificados o cumplimiento | Las respuestas no pueden sincronizarse con un ERP integrado |
La trampa. “Registration liviano más cuestionarios modulares robustos” es, en principio, una arquitectura sensata — los cuestionarios modulares se pueden reemitir por ciclo. Los equipos que la adoptan terminan con sus campos relevantes para el ERP varados, y la solución es reconstruir cuestionarios y volver a recolectar datos de proveedores en vivo.
Los tipos de respuesta son más ricos de lo documentado
La narrativa nombra cinco familias — texto libre, opción múltiple, carga de archivo, numérico, fecha. El corpus de soporte evidencia Bank Account, Address, Extended Address, Tax, Money, Certificate, List of Choices, Yes/No, Attachment y los selectores de matriz de Commodity / Region / Department, cada uno con su propio comportamiento. Las respuestas de tipo Attachment tienen un límite de 10 MB declarado — contrástelo con certificados, documentos de seguros y cartas bancarias.
Las preguntas bancarias y fiscales merecen un tiempo de diseño desproporcionado. Los campos IBAN se entregan sin validación de sintaxis por defecto ni marca de obligatoriedad; se aceptan datos bancarios duplicados durante el registration; los límites de caracteres afectan al nombre del banco, al nombre del titular de la cuenta y a la región. El comportamiento por país es real y está poco documentado — pruébelo contra la lista real de países de proveedores del cliente.
Condiciones, y el clúster de defectos
Existen cuatro tipos de condición: visibilidad, editabilidad, basada en usuario/grupo, y a nivel de proyecto. La restricción que reconfigura los diseños: no se puede condicionar un cuestionario completo dentro de una plantilla de registration — solo preguntas individuales. No existe forma de ramificar un registration hacia cuestionarios distintos.
- Condiciones dentro de secciones repetibles — un Known Error y el clúster de defectos más denso de SLP
- Condiciones + secciones repetibles + mapeos de GenericCustomField es una combinación conocida como problemática
- Los valores iniciales/por defecto interfieren con las condiciones de visibilidad
- Las condiciones de commodity no se propagan a las commodities hijas
- Condicionalmente oculto no es lo mismo que eliminado
El User Matrix
El User Matrix no aparece en ninguna parte de la documentación narrativa, y sin embargo impulsa la resolución de aprobadores en tres tipos de proyecto. Existe solo en títulos de artículos de soporte — pero aparece de forma repetida y tiene su propio código de componente SAP, BNS-ARI-SLP-REG-UMX. Esa combinación es una evidencia sólida de que se trata de un objeto de administración central y de primera clase.
Se importa a través de SM Administration, contiene asignaciones de commodity, región y categoría de compra por usuario, y determina la asignación automática de aprobadores, propietarios de proyecto y membresía de la pestaña Team en proyectos de Supplier Request, Supplier Registration y Engagement Request. Su formato de archivo, nombres de columna y algoritmo de coincidencia no están documentados.
Las aprobaciones en SLP fallan con mucha más frecuencia por no resolver un aprobador que por ser rechazadas. Construya y valide la matriz antes de probar cualquier flujo de aprobación, o estará depurando la capa equivocada durante días.
Una advertencia relacionada que vale la pena decir con claridad: el control Team Access en proyectos de Supplier Management no restringe la visibilidad ni la edición para otros usuarios. No confíe en la membresía del equipo del proyecto para la confidencialidad a nivel de campo.
| Síntoma | KBA |
|---|---|
| “No task approvers were found based on the provided information” | 3181051 |
| Se asignaron grupos de aprobación, el sistema sigue pidiendo agregar aprobadores faltantes | 3187869 |
| Los aprobadores no se asignan automáticamente por categoría pese a las asignaciones de categoría del comprador | 3643900 |
| La matriz no completa aprobadores en la pestaña Team de las Supplier Requests | 3613932 |
| La matriz no agrega el grupo como propietario del proyecto en proyectos de registration | 3748470 |
| Error de importación del User Matrix registrado como “Verify Group” | 3188861 |
El modelo de vendor keys
Ninguna documentación lo describe; solo puede inferirse del contenido de soporte. Existen cuatro identificadores, y la relación entre los dos primeros es un mapeo, no una identidad.
| Identificador | Qué es |
|---|---|
| SM Vendor ID (smVendorId) | La clave interna de vendor de SLP, representada como un número VDR… |
| ERP Vendor ID (erpVendorId) | El número de vendor / Business Partner en el ERP backend. Trátelo como de escritura única |
| ANID | La identidad de SAP Business Network, almacenada en el registro de vendor de SM |
| ACM ID | Un ID de organización de la plataforma core de Ariba. Nunca se expande ni se define en la fuente — no imprima una expansión que no pueda citar |
El diagnóstico de una línea: si Supplier 360 muestra un valor VDR… donde se espera el número de vendor del ERP, el proveedor tiene un SM Vendor ID y no tiene ERP Vendor ID. Nunca se integró con éxito, o el mapeo de claves nunca volvió. Eso es un hallazgo de reconciliación, no un error de visualización — construya el reporte “SLP suppliers with no ERP Vendor ID” desde el primer día.
Dos proveedores de Ariba pueden terminar con el mismo ERPVendorID y requerir resolución manual de conflictos. El desvínculo de ANID se bloquea mientras el registro exista en SM. ANID y ACM ID no forman parte del payload saliente por defecto. Y un proveedor sin un vendor ID válido bloquea un award de Sourcing — no solo la administración de proveedores. El estado de sync no es sync exitoso: concilie contra el ERP en lugar de confiar en el campo.
Síntoma → capa
| Síntoma | Revise |
|---|---|
| El proveedor no puede ver el cuestionario de registration | La visibilidad del lado del proveedor en Ariba Proposals and Questionnaires, y luego la cadena de invitación |
| La solicitud de proveedor queda atascada en Submitted | Contacto faltante, NullPointerException, o configuración de auto-aprobación |
| La solicitud se aprueba pero no hay proveedor / no hay perfil 360 | El traspaso de solicitud → registration — la costura más frágil de SLP |
| “Add missing approvers” / pestaña Team vacía | El User Matrix, antes que cualquier otra cosa |
| Las condiciones de visibilidad o editabilidad no se disparan | Secciones repetibles, mapeos de GenericCustomField, valores iniciales, traducciones |
| Se pierden datos tras un cambio de plantilla | La elegibilidad de Template Upgrade y los tipos de cambio destructivos (KBA 3232993) |
| El proveedor no sincroniza / el estado queda en In Progress | El disparador de estado mínimo, luego la generación del payload; el estado de sync no es éxito de sync |
| El ERP Vendor ID muestra un número VDR… | Nunca se integró, o el mapeo de claves nunca volvió — un hallazgo de reconciliación |
| Errores de maxLength / MinOccurs / “not defined for country” | El catálogo de mapeo de campos y los límites de caracteres — un tema de diseño, no de UAT |
| La operación masiva reportó éxito pero no hizo nada | Concilie los conteos y descargue el resumen de importación desde SM Administration |
Dos hábitos se pagan solos. El éxito silencioso es el modo de falla dominante en las operaciones masivas — invitaciones masivas que no envían nada, importaciones que reportan éxito y no crean registros — por eso concilie los conteos de registros cada vez. Y amplíe el alcance de las pruebas de regresión fuera de SLP cada vez que cambie el estado del proveedor o el modelo de datos de proveedores: desactivar un proveedor en SLP también lo desactiva en Buyer, y el estado de registration puede condicionar el acceso a eventos de sourcing.
Orden de construcción, y qué sucede si se invierte
| # | Haga esto primero | Qué sucede si lo invierte |
|---|---|---|
| 1 | Confirme el derecho de uso (entitlement) y eleve toda solicitud de habilitación SM-/ARI- | Que Supplier Management simplemente no esté en el sitio; algunas funciones requieren un caso de soporte, lo cual consume tiempo de calendario |
| 2 | Establezca la estrategia de cuenta de SAP Business Network | Configuración del comprador completa y correcta mientras ningún proveedor puede ver nada |
| 3 | Cargue organizaciones y grupos antes que los usuarios | FatalAssertionException: User with UniqueName … and PasswordAdapter … not found |
| 4 | Cargue códigos de commodity, regiones y departamentos antes que las plantillas | Una plantilla de qualification basada en matriz referencia datos maestros que no existen |
| 5 | Decida el reparto Request / Registration / SPQ / modular antes de mapear un solo campo | Campos vinculados al ERP quedan varados en cuestionarios modulares. No es reversible por parámetro |
| 6 | Construya y valide el User Matrix antes de probar cualquier flujo de aprobación | Días depurando la capa de aprobación por una falla en la matriz |
| 7 | Publique la plantilla antes de esperar que los usuarios la vean | Nada — y es una falla de tres capas: estado de publicación × acceso a la plantilla × membresía de grupo |
| 8 | Habilite el framework de cuestionarios modulares antes de planificar el vencimiento de certificados | Los certificados se entregan con cuestionarios modulares; no existe una ruta exclusiva para certificados |
| 9 | Biblioteca de KPI → la plantilla de SPM permite documentos de KPI → proyectos de SPM | “Can't add selected items because of template rules” |
Y un orden que es un punto de no retorno, no una secuencia. Habilitar process rollout (SM-16798) bloquea directamente las nuevas qualifications de estilo legacy. La fuente no documenta si puede revertirse. Decídalo antes de producción, no durante la hipercuidado (hypercare).
Checklist de configuración
Fundamentos y datos
- Entitlement de Supplier Management confirmado antes de cualquier diagnóstico de configuración.
- Migración a Unified Vendor Model dimensionada, con los datos de proveedores limpiados antes de ejecutarla.
- Arquitectura del sitio (new / classic) confirmada — determina la disponibilidad de cuestionarios modulares.
- Solicitudes de habilitación presentadas con anticipación para cada función SM-/ARI- dentro del alcance.
- Estrategia de cuenta de SAP Business Network acordada e incluida en el plan de go-live.
- Códigos de commodity, regiones y departamentos cargados antes del diseño de plantillas.
- Organizaciones y grupos cargados antes de los usuarios que los referencian.
- Exportación antes de cada importación; verifique los conteos de registros y nunca confíe en un mensaje de importación exitosa.
Diseño, aprobaciones e integración
- Reparto Request / Registration / SPQ / modular decidido antes de mapear un solo campo.
- Tipos de respuesta mantenidos consistentes entre request → registration (Address ≠ Extended Address).
- Condiciones dentro de secciones repetibles minimizadas.
- Campos bancarios, fiscales y de dirección diseñados contra la lista real de países de proveedores.
- User Matrix construido y validado antes de probar cualquier flujo de aprobación.
- Licenciamiento de grupos verificado antes de asignar SM Ops / SM ERP Administrator.
- Dos niveles de integración planificados, no tres — el managed gateway solo soporta Test y Production.
- Unicidad y capitalización de ERPVendorID exigidas en la capa de integración.
- Reporte de reconciliación construido: SLP suppliers with no ERP Vendor ID.
- Ninguna plantilla de cuestionario en vivo editada sin ensayar el upgrade en un entorno de prueba.
Glosario
- SLP
- SAP Ariba Supplier Lifecycle and Performance — desde la solicitud hasta el registration, qualification, estatus preferido, descalificación y descontinuación
- UVM
- Unified Vendor Model — el modelo de datos de proveedores centralizado requerido para SLP; adoptarlo desde las organizaciones de proveedores es una migración única
- ANID
- Ariba Network ID — la identidad de SAP Business Network que se conserva en el registro de vendor de SM
- SPQ
- Supplier Profile Questionnaire — datos duraderos de perfil, capacidad y certificación
- Cuestionario modular
- Cuestionario reemitible, impulsado por ciclos. No disponible en la arquitectura clásica de SIPM; las respuestas nunca llegan a un ERP integrado
- User Matrix
- Objeto de primera clase de SLP, no documentado, que determina la resolución de aprobador, propietario y pestaña Team a partir de commodity, región y categoría del comprador
- Template Upgrade
- El mecanismo que traslada los cambios de plantilla a los proyectos existentes. La elegibilidad depende del estado y algunos cambios destruyen datos de respuestas
- Punto de matriz
- La combinación de commodity / región / departamento contra la que se aplica la unicidad de qualification
- Managed gateway
- SAP Integration Suite, managed gateway for spend management (antes CIG). Solo Test y Production — no existe un nivel de integración DEV
- Process rollout (SM-16798)
- El framework de proceso modular. Una vez habilitado, se bloquean las nuevas qualifications de estilo legacy; la reversibilidad no está documentada
Basada en la documentación de SAP Help Portal para la versión 2605 y en 1066 artículos indexados de supplier management y supplier risk dentro de un corpus de 13 050 SAP KBAs y Notes (2013–2026). Cuando la fuente guarda silencio, esta guía lo indica en lugar de rellenar el vacío.