Tabla CSKS — Tabla de Datos Maestros de Centro de Costo
CSKS contiene el registro maestro dependiente del tiempo para un centro de costo dentro de un área de controlling: su período de validez, sociedad, moneda, asignación de jerarquía, persona responsable e indicadores de bloqueo. No almacena saldos ni contabilizaciones reales. Un centro de costo puede existir aquí con varias filas, una por segmento de tiempo, y confundir eso con un único registro actual es la lectura errónea más común.
CSKS es la tabla de datos maestros detrás de las transacciones KS01 a KS03 y de cada campo de selección de centro de costo en FI y CO. Esta página cubre la estructura de segmentos de tiempo de la tabla, las uniones que los consultores realmente escriben contra CSKT, CSKB y T001, y los errores recurrentes que se cometen al leer saldos, jerarquías o indicadores de bloqueo directamente de esta tabla.
Publicado el 15 sept 2026· 1108 palabras
Qué almacena
Una fila en CSKS representa un único segmento de tiempo de los datos maestros de un centro de costo dentro de un área de controlling. Debido a que atributos como la sociedad, el centro de beneficio, la moneda, la persona responsable o la asignación de jerarquía pueden cambiar a lo largo de la vida de un centro de costo, SAP no sobrescribe el registro al cambiarlo: cierra el segmento actual estableciendo su fecha de fin de validez e inserta una nueva fila para el nuevo período. Así, un centro de costo que ha sido reorganizado cinco veces en diez años tiene cinco filas en CSKS, no una. La tabla solo contiene atributos organizativos y de control. No tiene campos de importe ni campos de ejercicio o período de contabilización, porque no es una tabla de saldos; es la definición del objeto al que las contabilizaciones posteriores hacen referencia por número.
Campos clave
- MANDT - mandante
- KOKRS - área de controlling, el objeto es único solo dentro de esta área
- KOSTL - número de centro de costo
- DATBI - fecha de fin de validez de este segmento de tiempo, 99991231 para el segmento abierto actualmente
- DATAB - fecha de inicio de validez de este segmento de tiempo
- BUKRS - sociedad asignada al centro de costo para este período
- WAERS - moneda del centro de costo
- PRCTR - centro de beneficio asignado para este período
- KHINR - área de jerarquía estándar a la que reporta el centro de costo
- VERAK - número de personal o ID de usuario de la persona responsable
- ABTEI - texto/código de departamento, a menudo usado libremente en configuraciones antiguas
- FUNC_AREA - área funcional asignada al centro de costo
Cómo se une al modelo de datos
- CSKS-KOKRS = CSKT-KOKRS y CSKS-KOSTL = CSKT-KOSTL, emparejados en la misma fecha para obtener el texto de descripción para ese segmento de tiempo
- CSKS-KOKRS = CSKB-KOKRS y CSKS-KOSTL = CSKB-KOSTL, para encontrar qué clases de costo están permitidas contabilizar en este centro de costo en un período dado
- CSKS-BUKRS = T001-BUKRS, para confirmar la sociedad a la que pertenece el centro de costo y sus atributos de entidad legal
- ACDOCA-KOSTL = CSKS-KOSTL restringido también por ACDOCA-RCLNT y ACDOCA-KOKRS, al rastrear qué contabilizaciones reales se realizaron en un registro maestro de centro de costo dado
Cómo leerla de forma segura
Siempre restrinja primero por MANDT, luego por KOKRS, ya que KOSTL no es globalmente único y una consulta sin área de controlling puede unir silenciosamente el centro de costo equivocado entre áreas que por casualidad reutilizan el mismo número. Para cualquier búsqueda vinculada a una fecha específica, filtre DATAB menor o igual a esa fecha y DATBI mayor o igual a esa fecha en lugar de asumir que DATBI es igual a 99991231, lo que solo captura el segmento abierto y omite registros históricos o con fecha futura. La tabla en sí no es grande en la mayoría de los entornos, por lo que el rendimiento rara vez es el problema; la corrección del filtro de fecha sí lo es.
Cómo probarlo en los datos
Síntoma: una contabilización a un centro de costo es rechazada como no válida para la fecha de contabilización. Selección: lea CSKS para el KOKRS y KOSTL en cuestión sin filtro de fecha, liste todas las filas ordenadas por DATAB y compare la fecha de contabilización con el rango DATAB y DATBI de cada segmento. Si la fecha de contabilización cae en un espacio entre dos segmentos, o después del último DATBI, el centro de costo no tiene un registro maestro válido que cubra esa fecha, lo que explica el rechazo independientemente de cualquier problema de autorización o bloqueo.
ECC frente a S/4HANA
CSKS sigue siendo una tabla transparente en S/4HANA con la misma estructura de segmentos de tiempo que tenía en ECC; los datos maestros del centro de costo no fueron absorbidos por el diario universal ni reestructurados de la misma manera que las tablas de totales de FI. Todavía se mantiene a través de las mismas transacciones de creación, modificación y visualización de centros de costo y todavía alimenta ACDOCA como una característica en las partidas individuales contabilizadas. Las herramientas de reporting leen cada vez más los datos del centro de costo a través de vistas de compatibilidad en lugar de directamente de la tabla, pero la tabla subyacente y su diseño de campos no han cambiado.
Errores comunes
- Leer solo la fila con DATBI = 99991231 y tratarla como el registro actual. Si se contabilizó un cambio con una fecha de inicio futura, la fila que es realmente válida hoy puede tener un DATBI diferente, y la fila abierta puede no ser la que rige las contabilizaciones actuales.
- Unir solo por KOSTL a través de áreas de controlling. El mismo número de centro de costo puede existir en más de un KOKRS con atributos completamente diferentes; omitir KOKRS de la unión produce una falta de coincidencia cartesiana que parece plausible pero es incorrecta.
- Asumir que CSKS muestra el impacto financiero. No tiene saldo, ni importe, ni período fiscal. Quien quiera saber qué se contabilizó realmente en un centro de costo necesita ACDOCA o las tablas de partidas individuales de CO, no esta tabla.
- Confiar en VERAK como una respuesta precisa a 'quién es el propietario de este centro de costo'. En muchos entornos, este campo se establece una vez en la creación y nunca se mantiene después, por lo que refleja la historia en lugar de la realidad organizativa actual.
- Ignorar los indicadores de bloqueo al investigar una contabilización fallida. Un centro de costo puede ser estructuralmente válido para la fecha en cuestión pero bloqueado para contabilizaciones reales o planificadas en un período dado; los indicadores de bloqueo viven en el mismo registro y se pasan por alto en favor de solo verificar el rango de fechas.
- Leer el campo de jerarquía KHINR de forma aislada. El nodo al que reporta un centro de costo puede moverse dentro de la jerarquía estándar con el tiempo, por lo que un informe histórico construido sobre la asignación de jerarquía actual indicará erróneamente dónde se acumularon los costos antiguos.
De quién es este problema
La creación de centros de costo, el bloqueo y la asignación de jerarquía son responsabilidad del equipo de datos maestros de Controlling o FP&A, generalmente regidos por un proceso de solicitud de cambio vinculado a la estructura organizativa. Las finanzas de la unidad de negocio son responsables de la exactitud de la persona responsable y la categoría del centro de costo. Una disputa sobre si un centro de costo era válido, estaba bloqueado o estaba correctamente asignado jerárquicamente en una fecha determinada se resuelve consultando el historial de CSKS, no pidiendo al solicitante que recuerde lo que pretendía.
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/csksERPClimb 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.