Tabla KNA1 — Datos generales de cliente
KNA1 contiene los datos generales a nivel de mandante de un registro maestro de cliente: nombre, puntero de dirección, país, idioma, números de identificación fiscal y bloqueos centrales. Existe una fila por número de cliente, independientemente de la sociedad o del área de ventas. Los datos específicos de la sociedad se encuentran en KNB1, los datos específicos del área de ventas en KNVV; KNA1 por sí solo rara vez proporciona la información completa sobre si un cliente puede realmente realizar transacciones.
Esta página cubre lo que representa una fila de KNA1, qué campos consulta realmente un consultor y cómo la tabla se une a los documentos de ventas y a los datos de dirección. La sección de trampas se centra en el error recurrente de interpretar un bloqueo central o un indicador de borrado en KNA1 como la palabra final, cuando el bloqueo real a menudo se encuentra un nivel más abajo en KNB1 o KNVV.
Revisado por un consultor SAP de ERPClimb el 15 sept 2026· 1153 palabras
Qué almacena
Una fila en KNA1 representa un único número de cliente a nivel general, independiente del mandante: los datos que son verdaderos independientemente de qué sociedad o área de ventas esté realizando transacciones con ese cliente. Esto incluye el nombre y el término de búsqueda del cliente, el puntero al registro de dirección, país y región, idioma para la correspondencia, campos de registro fiscal y un pequeño conjunto de indicadores de control centrales, como el indicador de borrado general y el bloqueo central de pedidos o contabilizaciones. KNA1 no contiene datos de precios, crédito o envío, y no contiene campos específicos de grupo de cuentas para una sociedad o área de ventas determinada. Es la fila ancla de la que dependen las extensiones de KNB1 y KNVV; sin una fila de KNA1, el número de cliente no existe en el sistema en absoluto.
Campos clave
- MANDT - mandante, parte de cada clave, fácil de olvidar al escribir SQL nativo directamente contra la base de datos
- KUNNR - número de cliente, la clave primaria y el campo de unión a casi todas las tablas posteriores
- NAME1 - nombre del cliente línea 1, utilizado en listas pero poco confiable para búsquedas debido a duplicados
- LAND1 - clave de país, impulsa la lógica fiscal y el formato de dirección posteriormente
- ORT01 / PSTLZ / STRAS - ciudad, código postal, calle, los campos básicos de dirección postal
- REGIO - región/estado, relevante para la determinación de jurisdicción fiscal en algunos países
- SPRAS - clave de idioma utilizada para correspondencia y determinación de salida
- KTOKD - grupo de cuentas, controla el estado de campo y el rango de números en la creación, no se puede cambiar posteriormente sin una conversión especial
- ADRNR - número de dirección, la clave de unión a ADRC para la dirección estructurada completa
- STCEG - número de identificación fiscal, a menudo en blanco para clientes puramente nacionales
- LOEVM - indicador de borrado central, un marcador no un mecanismo de aplicación
- SPERR - bloqueo de contabilización central, bloquea al cliente en todas las sociedades
- AUFSD - bloqueo de pedidos de ventas central, bloquea la creación de pedidos en todas las áreas de ventas
Cómo se une al modelo de datos
- KNA1-KUNNR = KNB1-KUNNR (datos específicos de la sociedad, una fila por sociedad)
- KNA1-KUNNR = KNVV-KUNNR (datos específicos del área de ventas, una fila por organización de ventas/canal de distribución/división)
- KNA1-KUNNR = KNVP-KUNNR (asignaciones de función de interlocutor a nivel de datos maestros de cliente)
- KNA1-ADRNR = ADRC-ADDRNUMBER (detalle de dirección estructurada, incluye versiones de validez)
- KNA1-KUNNR = VBAK-KUNNR (interlocutor de ventas almacenado redundantemente en la cabecera del documento de ventas para informes)
- KNA1-KUNNR = VBPA-KUNNR (interlocutor determinado en un documento de ventas, entrega o facturación individual)
Cómo leerlo de forma segura
Restrinja siempre en MANDT implícitamente a través del inicio de sesión correcto del sistema en lugar de seleccionar entre mandantes. KUNNR es el único campo con selectividad real; seleccionar en NAME1 con un comodín contra la tabla completa es una fuente común de consultas descontroladas porque el campo no es la ruta de acceso principal y los nombres duplicados son comunes. Al investigar un cliente específico, siempre consulte KNA1 junto con KNB1 para la sociedad relevante y KNVV para el área de ventas relevante en la misma sesión, porque ninguna de las tres por sí sola responde una pregunta transaccional. No intente una descarga completa de la tabla para el análisis; filtre por KTOKD o un rango de KUNNR primero si realmente se necesita una extracción más amplia.
Cómo verificarlo en los datos
Síntoma: no se puede crear un pedido para un cliente, el sistema indica que el cliente está bloqueado. Seleccione KNA1 donde KUNNR sea igual al número de cliente y verifique AUFSD (bloqueo de pedido central) y SPERR (bloqueo de contabilización central). Si ambos están en blanco, el bloqueo no es central; vaya a KNVV para esa organización de ventas/canal de distribución/división y verifique los campos de bloqueo de pedidos y entregas específicos del área de ventas allí. Un bloqueo visible en KNVV pero no en KNA1 es el caso normal, no una anomalía.
ECC frente a S/4HANA
KNA1 aún existe en S/4HANA con la misma clave y en gran parte el mismo conjunto de campos. Bajo el modelo de interlocutor comercial, el maestro de cliente se mantiene a través de la transacción de interlocutor comercial y se sincroniza en KNA1, KNB1 y KNVV a través del mecanismo de integración cliente/proveedor que se ejecuta en segundo plano. El contenido directo de la tabla sigue siendo técnicamente legible y se puede unir exactamente como antes, pero la fuente de verdad para el mantenimiento se ha trasladado al objeto de interlocutor comercial, y los cambios manuales que omiten esa sincronización no son compatibles.
Errores comunes
- Leer LOEVM en blanco y concluir que el cliente está completamente activo: el indicador puede establecerse a nivel de sociedad o área de ventas en KNB1 o KNVV de forma independiente, y un indicador en blanco en KNA1 no dice nada sobre esos niveles
- Tratar LOEVM como un mecanismo de aplicación: es un marcador verificado por el archivo y por algunos controles manuales, por sí mismo no impide la contabilización o la creación de pedidos
- Suponer que un cliente existe para un área de ventas determinada porque existe una fila de KNA1: la ausencia de una fila de KNVV coincidente significa que el cliente nunca se ha extendido a esa organización de ventas, y la creación del documento de ventas fallará solo por esa razón
- Buscar por NAME1 y tratar el primer resultado como el cliente correcto: los campos de nombre son de texto libre, los duplicados entre empresas del grupo y sucursales son rutinarios, KUNNR es la única clave segura
- Confundir los campos de bloqueo central SPERR y AUFSD con los bloqueos de pedidos y entregas específicos del área de ventas que residen en KNVV: estos son campos diferentes con un alcance diferente y se verifican en distintos puntos del procesamiento de documentos
- Suponer que la dirección en el documento coincide con KNA1/ADRC en el momento de la lectura: los documentos de ventas pueden llevar una dirección modificada manualmente o con una validez temporal capturada en el momento de la creación, independientemente de los cambios posteriores en los datos maestros
- Tratar STCEG como obligatorio: es legítimamente en blanco para muchos clientes solo nacionales y su ausencia no es en sí misma un error de datos
- Olvidar que los grupos de cuentas de cliente esporádico hacen referencia a un registro dummy compartido de KNA1, con el nombre y la dirección reales ingresados por documento en VBPA/datos de interlocutor en lugar de en KNA1 mismo
De quién es este problema
La calidad de los datos maestros de cliente normalmente es responsabilidad de un equipo de gobierno de datos maestros o de datos maestros de SD, no de Basis o del equipo técnico de configuración de SD. Los bloqueos centrales y la configuración del grupo de cuentas son una decisión de gobierno de datos; la extensión del área de ventas y los bloqueos específicos del área suelen ser una decisión conjunta entre el propietario del proceso de SD y la función de crédito/cobranzas.
Objetos SAP relacionados
Páginas revisadas con las que este objeto se conecta en el grafo de conocimiento de ERPClimb.
Fuente: ERPClimb — https://erpclimb.com/sap-tables/kna1ERPClimb es una plataforma independiente y no está afiliada a SAP SE. Las páginas de referencia las escriben y revisan consultores SAP para el aprendizaje y la resolución de problemas.