Su Template de datos para solicitudes del proceso de compra a pago
Su Template de datos para solicitudes del proceso de compra a pago
- Atributos recomendados para un análisis detallado
- Actividades clave para descubrir el proceso
- Instrucciones para extraer datos de SAP S/4HANA
Atributos del proceso de solicitud de compra a pago
| Nombre | Descripción | ||
|---|---|---|---|
| Fecha y hora del evento EventTime | Fecha y hora exactas en que se produjo una actividad específica. | ||
| Descripción La fecha y hora del evento indican cuándo tuvo lugar una actividad. Estos datos son esenciales para ordenar cronológicamente los eventos de un caso y sirven de base para calcular duraciones y rendimiento en Process Mining. Por ejemplo, la diferencia entre los eventos 'Solicitud enviada para aprobación' y 'Solicitud aprobada' determina el tiempo de ciclo de aprobación. Las fechas y horas exactas son esenciales para analizar el rendimiento del proceso, detectar demoras y supervisar el cumplimiento de los acuerdos de nivel de servicio. Este atributo permite crear Dashboards que muestran los tiempos de ciclo, identifican solicitudes estancadas y comparan el rendimiento en distintos periodos. Por qué es importante Esta fecha y hora son esenciales para ordenar los eventos, calcular los tiempos de ciclo y analizar el rendimiento del proceso y sus cuellos de botella. Dónde obtenerlo Por lo general, las fechas y horas se obtienen de las cabeceras de los documentos de modificación (CDHDR-UDATE, CDHDR-UTIME) o de los registros de eventos del flujo de trabajo. Ejemplos 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID de solicitud de compra PurchaseRequisitionId | Identificador único de un documento de solicitud de compra. | ||
| Descripción El ID de solicitud de compra es la clave principal que identifica de forma única cada solicitud de bienes o servicios en SAP S/4HANA. Es el identificador central del caso y vincula todas las actividades y modificaciones relacionadas con una solicitud específica, desde su creación hasta su estado final, como la aprobación, el rechazo o la conversión en una orden de compra. En Process Mining, este atributo es fundamental para reconstruir el ciclo de vida completo de cada solicitud. Al agrupar todos los eventos relacionados bajo un mismo ID de solicitud de compra, las personas analistas pueden medir con precisión los tiempos de ciclo, seguir los cambios de estado y analizar las distintas rutas que puede seguir una solicitud durante el proceso de aprobación. Por qué es importante Este es el identificador esencial del caso que conecta todos los pasos relacionados del proceso y permite obtener una visión completa y coherente del ciclo de vida de la solicitud. Dónde obtenerlo Este atributo corresponde al número de solicitud de compra, que se encuentra en la tabla EBAN, campo BANFN. Ejemplos 100178901001789110017892 | |||
| Nombre de la actividad ActivityName | Nombre de la actividad de negocio que tuvo lugar en un momento específico del proceso de solicitud. | ||
| Descripción El nombre de la actividad describe un evento o una tarea específicos que tuvieron lugar durante el ciclo de vida de una solicitud de compra. Estas actividades se obtienen de registros del sistema, como los documentos de modificación y el historial del flujo de trabajo, y representan hitos clave del proceso, como 'Solicitud creada', 'Paso de aprobación iniciado' u 'Orden de compra creada'. Analizar estas actividades permite visualizar el flujo del proceso, identificar cuellos de botella y medir el tiempo dedicado a las distintas etapas. Comprender la secuencia y la frecuencia de actividades como 'Solicitud modificada' o 'Solicitud rechazada' es fundamental para detectar ineficiencias y oportunidades de mejora. Por qué es importante Define los pasos del proceso, constituye la base del mapa de procesos y permite analizar el flujo, las variantes y los cuellos de botella. Dónde obtenerlo Este atributo se deriva, por lo general, de la interpretación de datos de las tablas de documentos de modificación (CDHDR, CDPOS) y de los registros del flujo de trabajo (por ejemplo, SWWLOGHIST). Ejemplos Solicitud creadaPaso de aprobación completadoSolicitud aprobadaOrden de compra creada | |||
| Departamento Department | Departamento o centro de coste al que se imputan los costes de la solicitud. | ||
| Descripción El atributo Departamento, que en SAP suele representarse mediante el centro de coste, identifica la unidad de negocio responsable de la compra solicitada. Es un dato financiero y organizativo clave que se asigna en el nivel de posición de la solicitud. En Process Mining, este atributo es esencial para analizar el rendimiento de cada departamento. Permite crear Dashboards que comparan métricas clave, como los tiempos de ciclo, la frecuencia de modificaciones y la tasa de rechazo entre departamentos. Así se pueden identificar los departamentos con mejores resultados, cuyas prácticas podrían adoptarse en otros, y aquellos que quizá necesiten más formación o apoyo para mejorar sus procesos. Por qué es importante Permite comparar el rendimiento entre unidades de negocio y detectar diferencias en los tiempos de ciclo o las tasas de rechazo para identificar buenas prácticas y oportunidades de mejora. Dónde obtenerlo Es el centro de coste, que suele encontrarse en la tabla de imputación contable EBKN, campo KOSTL. Ejemplos FIN-1001IT-2005MKT-3010 | |||
| Estado de la solicitud RequisitionStatus | Estado actual de procesamiento o aprobación de la solicitud de compra. | ||
| Descripción El estado de la solicitud indica en qué punto de su ciclo de vida se encuentra. En SAP, suele representarse mediante el indicador de liberación, que muestra si una solicitud está bloqueada, en aprobación, aprobada parcialmente o aprobada por completo. El estado cambia a medida que la solicitud avanza por el flujo de trabajo. Seguir los cambios de estado a lo largo del tiempo es fundamental para comprender el flujo del proceso. Ayuda a identificar dónde se atascan las solicitudes y durante cuánto tiempo. Analizar las transiciones entre estados permite conocer en detalle el proceso de aprobación y sus variantes. Por qué es importante Indica el estado actual de una solicitud, un dato clave para seguir su avance, identificar cuellos de botella y analizar el flujo del proceso. Dónde obtenerlo El estado de liberación suele determinarse mediante el indicador de liberación, que se encuentra en la tabla EBAN, campo FRGZU. Ejemplos B1S | |||
| ID de la persona aprobadora ApproverId | Identificador de la persona usuaria que realizó un paso de aprobación o rechazo. | ||
| Descripción El ID de la persona aprobadora identifica específicamente a quien completó una actividad de aprobación o rechazo. A diferencia del ID de usuario general, se centra exclusivamente en quienes toman decisiones dentro del flujo de trabajo de aprobación. Registrar esta información es fundamental para analizar el proceso de aprobación en detalle. Este atributo permite analizar el comportamiento en las aprobaciones, por ejemplo, identificar a responsables que tardan mucho en aprobar o que rechazan solicitudes con frecuencia. Es fundamental para los Dashboards que muestran los tiempos de ciclo de cada paso de aprobación y el análisis de cuellos de botella del flujo de trabajo, ya que ayuda a localizar a las personas o funciones que pueden estar causando demoras. Por qué es importante Identifica a quien toma la decisión en cada paso de aprobación y permite analizar en detalle los tiempos de ciclo y los cuellos de botella por persona o función. Dónde obtenerlo Por lo general, esta información se extrae de tablas de SAP Business Workflow, como SWW_WI2OBJ y SWWLOGHIST, que vinculan los elementos de trabajo con la persona usuaria que los completó. Ejemplos MJOHNSONCWILLIAMSLBLACK | |||
| ID de usuario UserId | Identificador de la persona usuaria que creó la solicitud o realizó una actividad específica. | ||
| Descripción El ID de usuario identifica a la persona empleada o usuaria del sistema responsable de un evento concreto del ciclo de vida de la solicitud. Puede ser quien creó la solicitud, la persona responsable que la aprobó o quien la modificó. En los pasos automatizados, puede corresponder a un ID de usuario del sistema o de procesamiento por lotes. El análisis por ID de usuario ayuda a comprender el comportamiento de cada persona usuaria, la distribución de la carga de trabajo y el rendimiento. Es clave para detectar necesidades de formación, reconocer a quienes obtienen buenos resultados y garantizar la rendición de cuentas en el proceso. También permite analizar el rendimiento de los departamentos al combinarlo con los datos maestros de usuarios. Por qué es importante Permite analizar el rendimiento de las personas usuarias, la distribución de la carga de trabajo y el cumplimiento del proceso. Es clave para detectar oportunidades de formación y cuellos de botella relacionados con los recursos. Dónde obtenerlo Para quien crea la solicitud, se encuentra en EBAN-ERNAM. Para las modificaciones posteriores, está en CDHDR-USERNAME. Para las aprobaciones, se encuentra en los registros del flujo de trabajo. Ejemplos JSMITHRROEWF-BATCH | |||
| Importe de la solicitud RequisitionAmount | Valor monetario total de la solicitud de compra. | ||
| Descripción El importe de la solicitud representa el coste total estimado de los bienes o servicios solicitados. Este valor suele ser un factor clave para determinar la complejidad y la duración del flujo de trabajo de aprobación, ya que las solicitudes de mayor importe suelen requerir más niveles de aprobación. Analizar este atributo permite segmentar el proceso por importe y responder preguntas como: '¿Las solicitudes de importe elevado tardan más en aprobarse?' o '¿Cuál es el importe de las solicitudes que se rechazan con frecuencia?'. Es una dimensión clave para comprender el impacto financiero de las ineficiencias del proceso. Por qué es importante Permite segmentar el proceso según su impacto financiero, que suele estar relacionado con la complejidad de la aprobación y el tiempo de ciclo. Es esencial para analizar los procesos según su valor. Dónde obtenerlo El valor total se encuentra en la tabla EBAN, campo GFWERT. El valor por posición está en EBAN-PREIS. Ejemplos 1500.0075000.50250.75 | |||
| Tipo de solicitud RequisitionType | Código que clasifica la solicitud de compra, por ejemplo, para artículos estándar, servicios o gastos de capital. | ||
| Descripción El tipo de solicitud, también conocido como tipo de documento en SAP, es un campo de configuración clave que clasifica las solicitudes de compra. Los distintos tipos pueden activar diferentes flujos de trabajo de aprobación, tener distintas opciones de campos y responder a diferentes necesidades del negocio, como artículos de inventario estándar, servicios externos o compras de activos. Analizar el proceso según el tipo de solicitud permite comprender cómo se gestionan las distintas solicitudes. También permite comparar el rendimiento, los tiempos de ciclo y las rutas de aprobación entre categorías, lo que puede revelar qué tipos de solicitud son más o menos eficientes y ayudar a adaptar las mejoras del proceso. Por qué es importante Clasifica las solicitudes para facilitar el análisis comparativo y comprender si los distintos tipos siguen flujos de proceso diferentes o presentan otros cuellos de botella y tiempos de ciclo. Dónde obtenerlo Es el campo Tipo de documento, que se encuentra en la tabla EBAN, campo BSART. Ejemplos NBFORV | |||
| Automatizada IsAutomated | Indicador que señala si una actividad la realizó una persona usuaria del sistema en lugar de una persona. | ||
| Descripción El atributo Is Automated es una marca booleana que indica si una actividad fue ejecutada por un usuario de sistema o de procesamiento por lotes, como «WF-BATCH» para las acciones del flujo de trabajo. Esto permite distinguir los pasos manuales de los automatizados. Este atributo es esencial para medir el nivel de automatización del proceso de solicitud de compra y calcular el KPI «Tasa de aprobaciones automatizadas». Al filtrar los pasos manuales o automatizados, quienes analizan el proceso pueden comparar su eficiencia e identificar oportunidades para automatizar más tareas, reducir los tiempos de procesamiento y disminuir el trabajo manual. Por qué es importante Distingue las actividades realizadas por personas de las ejecutadas por sistemas. Esto es clave para medir los niveles de automatización e identificar oportunidades para automatizar tareas manuales. Dónde obtenerlo Es un atributo derivado que suele basarse en una regla que comprueba si el User ID de un evento pertenece a una lista de usuarios de sistema o de procesamiento por lotes conocidos. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador que señala si una actividad constituye un retrabajo, como una modificación posterior al envío. | ||
| Descripción Es retrabajo es una marca booleana calculada que identifica actividades que representan trabajo repetitivo o que no aporta valor. Un ejemplo habitual en este proceso es la actividad «Solicitud de compra modificada» después de que la solicitud ya se haya enviado para su aprobación, lo que obliga a reiniciar el proceso de aprobación. Este atributo es fundamental para cuantificar el retrabajo en el proceso y su efecto en los tiempos de ciclo generales. El Dashboard de modificaciones de solicitudes y tasa de retrabajo utiliza esta marca para mostrar las ineficiencias del proceso. Reducir el retrabajo suele ser un objetivo prioritario de las iniciativas de mejora, ya que permite ahorrar tiempo y esfuerzo. Por qué es importante Marca las actividades que representan esfuerzo desperdiciado o repetido, lo que permite medir directamente el retrabajo y su efecto en la eficiencia del proceso. Dónde obtenerlo Es un atributo calculado. La lógica suele marcar como retrabajo cualquier actividad «Solicitud de compra modificada» que ocurra después de la primera actividad «Solicitud de compra enviada para aprobación». Ejemplos truefalse | |||
| Fecha requerida RequiredByDate | Fecha en que la persona solicitante necesita los bienes o servicios solicitados. | ||
| Descripción La fecha requerida, denominada fecha de entrega en SAP, indica cuándo se necesitan los bienes o servicios de una posición de solicitud. La establece la persona solicitante y sirve como objetivo para todo el proceso de compras. Este atributo es esencial para calcular el KPI de la tasa de solicitudes completadas a tiempo. Al comparar la fecha requerida con la fecha de aprobación final o de creación de la orden de compra, la organización puede medir su capacidad para cumplir los niveles de servicio internos y atender las necesidades del negocio. Analizar las solicitudes que no cumplen esta fecha puede revelar demoras sistemáticas en el proceso de compras. Por qué es importante Define la fecha objetivo para completar una solicitud y permite medir las entregas a tiempo y el cumplimiento de los niveles de servicio internos. Dónde obtenerlo Es la fecha de entrega, que se encuentra en el nivel de posición de la tabla EBAN, campo LFDAT. Ejemplos 2023-11-152023-12-012024-01-20 | |||
| Hora de finalización EndTime | Fecha y hora exactas en que se completó una actividad específica. | ||
| Descripción EndTime es la marca de tiempo que registra cuándo terminó una actividad. Muchos eventos generados por el sistema son instantáneos, por lo que StartTime y EndTime coinciden. En cambio, las tareas realizadas por personas, como las aprobaciones, pueden tener una hora de inicio y otra de finalización. Esta última marca el momento en que se completó el trabajo. Contar con un EndTime independiente permite medir con más precisión el tiempo de procesamiento activo y el tiempo de espera. Se utiliza junto con StartTime para calcular la métrica ProcessingTime. Este nivel de detalle mejora el análisis del uso de los recursos y de la eficiencia de las tareas manuales. Por qué es importante Indica cuándo se completa una actividad, permite calcular el tiempo de procesamiento activo y ofrece una visión más detallada de la duración de las tareas. Dónde obtenerlo Se obtiene de los registros del flujo de trabajo, que pueden incluir tanto el momento en que se creó un elemento de trabajo (StartTime) como el momento en que se completó (EndTime). Ejemplos 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Moneda Currency | Código de moneda del importe de la solicitud. | ||
| Descripción Este atributo especifica la moneda en que se expresa el importe de la solicitud, por ejemplo, USD, EUR o JPY. Aporta el contexto necesario para interpretar el importe de la solicitud, especialmente en organizaciones multinacionales que operan con varias monedas. Para realizar análisis e informes financieros precisos, es esencial tener en cuenta la moneda. Al agregar o comparar importes de solicitudes, se deben convertir todas las cantidades a una moneda común para obtener resultados significativos. Este atributo es necesario para realizar esas conversiones. Por qué es importante Aporta el contexto necesario para interpretar el importe de la solicitud y permite realizar análisis y comparaciones financieras precisos en entornos con varias monedas. Dónde obtenerlo Se encuentra en la tabla EBAN, campo WAERS. Ejemplos USDEURGBP | |||
| Motivo del rechazo RejectionReason | Motivo indicado cuando se rechaza una solicitud de compra. | ||
| Descripción El motivo del rechazo explica por qué una persona aprobadora decidió rechazar una solicitud de compra. Entre los motivos posibles están superar el presupuesto, incluir información incorrecta, incumplir una política o duplicar otra solicitud. Esta información aporta un contexto clave para comprender los fallos del proceso. Analizar los motivos de rechazo ayuda a identificar las causas de las ineficiencias y del retrabajo. Por ejemplo, si 'Centro de coste incorrecto' es un motivo frecuente, puede ser necesario ofrecer más formación a las personas usuarias o validar los datos en el sistema. Este atributo es clave para el Dashboard de análisis de rechazos de solicitudes y resulta esencial para mejorar el proceso de forma específica. Por qué es importante Aporta información sobre las causas de los fallos del proceso y permite aplicar mejoras específicas para reducir el retrabajo y aumentar la tasa de solicitudes correctas desde el primer intento. Dónde obtenerlo A menudo no existe un campo estándar para este dato. Puede registrarse en elementos del contenedor del flujo de trabajo, en textos largos asociados a la solicitud o en campos personalizados. Ejemplos Supera el presupuestoProveedor incorrectoSolicitud duplicada | |||
| Nivel de urgencia UrgencyLevel | Clasificación de la urgencia de una solicitud, que puede influir en su prioridad de procesamiento. | ||
| Descripción El nivel de urgencia indica la prioridad de la solicitud de compra. Aunque no existe un campo estándar específico para este dato, algunas organizaciones utilizan campos como Requirement Tracking Number para registrarlo. Así, quienes realizan las solicitudes pueden señalar necesidades críticas que quizá requieran un procesamiento acelerado. Analizar el efecto de la urgencia permite evaluar si el proceso da prioridad a las solicitudes críticas de manera eficaz. El Dashboard de análisis del impacto del nivel de urgencia utiliza este atributo para comparar los tiempos de ciclo y las tasas de aprobación de las solicitudes urgentes y las estándar. De este modo, ayuda a determinar si la gestión prioritaria está dando los resultados esperados. Por qué es importante Permite analizar cómo varía el rendimiento del proceso en las solicitudes de alta prioridad y comprobar si realmente se atienden con mayor rapidez. Dónde obtenerlo No hay un campo estándar para indicar la urgencia. Algunas empresas utilizan Requirement Tracking Number (EBAN-BEDAR) con este fin. También puede tratarse de un campo personalizado. Ejemplos AltaMediaBaja | |||
| Nombre del paso de aprobación ApprovalStepName | Nombre o descripción específicos de un paso de aprobación del flujo de trabajo. | ||
| Descripción El nombre del paso de aprobación ofrece una descripción clara de una etapa concreta del flujo de aprobación, como «Aprobación del gerente» o «Aprobación del vicepresidente de Finanzas». Es más descriptivo que una actividad genérica como «Paso de aprobación completado». Este atributo es fundamental para los Dashboards de Tiempo de ciclo del paso de aprobación y Análisis de Bottleneck del flujo de trabajo. Permite examinar el proceso de aprobación con más detalle, identificar con precisión qué etapas provocan las mayores demoras y detectar dónde se acumula el trabajo. Este nivel de detalle es necesario para aplicar medidas específicas y agilizar la cadena de aprobaciones. Por qué es importante Ofrece información detallada sobre las etapas de aprobación y permite identificar con precisión los cuellos de botella en el flujo de aprobación de varios niveles. Dónde obtenerlo Esta información se obtiene de la descripción de la tarea del flujo de trabajo, que puede consultarse vinculando el registro del flujo de trabajo con tablas de definición de tareas como T528T. Ejemplos Aprobación del gerenteAprobación del directorAprobación del vicepresidente de Finanzas | |||
| Número de orden de compra PurchaseOrderNumber | Número de la orden de compra creada a partir de la solicitud. | ||
| Descripción El número de orden de compra identifica el documento oficial de compras creado a partir de una solicitud aprobada. La creación de una orden de compra suele ser el resultado final satisfactorio de una solicitud: indica que esta se ha convertido en un pedido formal a un proveedor. Este atributo es clave para medir el KPI del tiempo de entrega desde la solicitud hasta la orden de compra y la tasa de conversión general. Vincula el proceso de solicitud con el proceso de compras posterior y permite obtener una visión más amplia, de principio a fin, del ciclo completo de compra a pago. Por qué es importante Vincula la solicitud con el documento de compras posterior y permite medir la tasa de conversión y el tiempo de entrega desde la solicitud hasta la orden de compra. Dónde obtenerlo Se encuentra en la tabla EBAN, campo EBELN, una vez creada una orden de compra a partir de la posición de la solicitud. Ejemplos 450001789045000178914500017892 | |||
| Sistema de origen SourceSystem | Identifica la instancia específica de SAP S/4HANA de la que se extrajeron los datos. | ||
| Descripción El atributo Sistema de origen indica el sistema en que se generaron los datos del proceso. En las organizaciones con varias instancias de SAP, como sistemas distintos para desarrollo, control de calidad y producción, o sistemas separados por región, este campo es clave para la gobernanza de datos y el contexto. Permite distinguir los datos de distintas fuentes, evita agregaciones incorrectas y facilita el análisis específico de cada sistema. Es un atributo obligatorio para mantener la trazabilidad del origen de los datos y garantizar que se pueda seguir su recorrido. Por qué es importante Aporta contexto esencial sobre el origen de los datos y su gobernanza, especialmente en entornos con varios sistemas, y garantiza su trazabilidad. Dónde obtenerlo Por lo general, se trata del ID del sistema SAP (SID), que puede obtenerse de las variables del sistema o de las tablas de configuración. Ejemplos S4PECCS4H_PROD_01 | |||
| Última actualización de los datos LastDataUpdate | Fecha y hora que indican cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen. | ||
| Descripción Este atributo registra la fecha y hora de la extracción o actualización más reciente de los datos desde el sistema de origen. Es un metadato clave para conocer la actualidad de los datos analizados. Las personas analistas y usuarias de negocio consultan esta fecha y hora para saber si los datos del proceso reflejan el estado más reciente de las operaciones. En cualquier análisis de procesos, conocer la actualidad de los datos es fundamental para tomar decisiones informadas. Este atributo ayuda a gestionar las expectativas de las personas usuarias y garantiza que las conclusiones se basen en datos tan actualizados como requiera cada análisis. Por qué es importante Indica la actualidad de los datos, un aspecto clave para confiar en el análisis y tomar decisiones de negocio a tiempo. Dónde obtenerlo Esta fecha y hora se generan y se añaden durante el proceso de extracción, transformación y carga de datos (ETL). Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Actividades del proceso de solicitud de compra a pago
| Actividad | Descripción | ||
|---|---|---|---|
| Orden de compra creada | Indica que se ha generado una orden de compra vinculada a la posición de la solicitud. Es un evento explícito del sistema que relaciona la solicitud con un documento de compras posterior. | ||
| Por qué es importante Este es un hito importante y un resultado satisfactorio del proceso de solicitud. El tiempo entre la aprobación de la solicitud y la creación de la orden de compra es un KPI clave para medir la eficiencia de compras. Dónde obtenerlo Se registra explícitamente cuando se crea una posición de orden de compra. El vínculo se almacena en la tabla EKPO (posición de orden de compra), que contiene el número de solicitud de origen (BANFN) y el número de posición (BNFPO). Capturar Relacione la tabla EKPO con EBAN mediante el número y la posición de la solicitud. La fecha de creación de la posición de la orden de compra marca el evento. Tipo de evento explicit | |||
| Paso de aprobación completado | Se produce cuando una persona aprobadora aprueba una solicitud y completa un paso del flujo de trabajo de aprobación multinivel. Se infiere a partir de un cambio en el estado de liberación de la solicitud. | ||
| Por qué es importante Esta actividad permite analizar en detalle el flujo de trabajo de aprobación y medir el tiempo que lleva cada paso. Ayuda a distinguir entre las personas aprobadoras eficientes y los cuellos de botella del proceso. Dónde obtenerlo Se infiere a partir de los documentos de modificación (CDHDR/CDPOS) de la tabla EBAN. Un cambio en el estado del código de liberación (por ejemplo, en el campo FRGZU), de no liberado a liberado para un código específico, indica este evento. Capturar Realice un seguimiento de los cambios en los campos de estado de liberación de EBAN para cada código de liberación definido en la estrategia. Tipo de evento inferred | |||
| Solicitud aprobada | Indica la aprobación final y completa de la solicitud de compra, que queda habilitada para convertirse en una orden de compra. Este hito se infiere cuando el estado general de liberación alcanza el estado final de aprobación. | ||
| Por qué es importante Este es un hito clave de éxito y un punto final habitual para analizar el tiempo de ciclo. Indica que la solicitud ha superado todas las comprobaciones y está lista para que el departamento de compras actúe. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla EBAN, en concreto cuando el indicador general de liberación (FRGZU) o el estado de procesamiento (PROCSTAT) se actualiza al valor final 'Aprobado'. Capturar Identifique la fecha y hora en que se aplica el código de liberación final o el estado general de la solicitud cambia a 'Aprobado'. Tipo de evento inferred | |||
| Solicitud cerrada | Indica que la posición de la solicitud se considera totalmente procesada y que ya no se pueden crear más órdenes de compra a partir de ella. Por lo general, este estado se establece automáticamente cuando se ha pedido la cantidad completa. | ||
| Por qué es importante Esta actividad representa la finalización satisfactoria del ciclo de vida de la posición de la solicitud. Confirma que la necesidad del negocio se ha convertido por completo en una orden de compra. Dónde obtenerlo Se infiere a partir de la tabla EBAN. Se produce cuando se establece el indicador 'Cerrado' (EBAKZ), normalmente cuando la cantidad pedida en las órdenes de compra coincide con la cantidad solicitada. Capturar Identifique, mediante los documentos de modificación, el evento en que se establece el indicador 'Cerrado' (EBAKZ) en la tabla EBAN. Tipo de evento inferred | |||
| Solicitud creada | Indica la creación inicial del documento de solicitud de compra en el sistema. El evento se registra explícitamente cuando una persona usuaria guarda una solicitud nueva por primera vez, junto con la fecha y hora de creación. | ||
| Por qué es importante Esta actividad es el punto de partida principal para analizar el ciclo de vida de la solicitud. Es esencial para medir el tiempo de ciclo de principio a fin, desde la identificación de la necesidad inicial hasta la aprobación final o la conversión en una orden de compra. Dónde obtenerlo Este evento se registra explícitamente en la tabla EBAN mediante los campos de fecha de creación (ERDAT) y hora de creación (ERZEIT) correspondientes al número de solicitud de compra (BANFN). Capturar Utilice los campos de fecha y hora de creación (ERDAT, ERZEIT) de la tabla EBAN para cada solicitud (BANFN). Tipo de evento explicit | |||
| Solicitud rechazada | Representa el rechazo definitivo de la solicitud de compra por parte de una persona aprobadora, lo que detiene el proceso. Se registra mediante una actualización de estado específica que indica el rechazo. | ||
| Por qué es importante Esta actividad marca un punto final de fallo clave. Analizar la frecuencia y los motivos de rechazo, así como las etapas en que se producen, ayuda a detectar problemas de cumplimiento de políticas, presupuesto o calidad de las solicitudes. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla EBAN. El estado de procesamiento (PROCSTAT) o un indicador de liberación se establece en un valor que significa explícitamente 'Rechazado'. Capturar Identifique, mediante los documentos de modificación, la fecha y hora en que el estado general de EBAN se actualiza a 'Rechazado'. Tipo de evento inferred | |||
| Aprobación reiniciada | Representa el reinicio de todo el flujo de trabajo de aprobación, a menudo debido a una modificación importante de la solicitud. El proceso de aprobación debe comenzar de nuevo desde el primer nivel. | ||
| Por qué es importante Esta actividad pone de manifiesto un retrabajo importante que afecta considerablemente al tiempo de ciclo. Identificar las causas de los reinicios de aprobación es clave para agilizar el proceso y reducir las demoras. Dónde obtenerlo Se infiere a partir de los documentos de modificación (CDHDR/CDPOS) de la tabla EBAN. El evento se detecta cuando se borran los campos de estado de liberación (como FRGKZ o FRGZU) después de haberse completado parcial o totalmente. Capturar Busque en los registros de cambios una transición del estado de liberación, de liberado a no liberado. Tipo de evento inferred | |||
| Fuente de suministro asignada | Representa la acción de una persona compradora que asigna un proveedor, contrato o registro info específico a una posición de solicitud aprobada. Es un paso clave para preparar la solicitud y crear una orden de compra. | ||
| Por qué es importante Esta actividad conecta la aprobación con la realización del pedido. Medir el tiempo que se tarda en asignar una fuente ayuda a detectar demoras en la carga de trabajo de compras y en la eficiencia del abastecimiento. Dónde obtenerlo Se infiere cuando se introduce un valor en los campos de fuente de suministro de la tabla EBAN, como proveedor fijo (LIFNR), registro info (INFNR) o contrato (KONNR). Capturar Realice un seguimiento de la cumplimentación de campos como LIFNR, INFNR o KONNR en la tabla EBAN mediante los documentos de modificación. Tipo de evento inferred | |||
| Paso de aprobación iniciado | Indica que una solicitud está pendiente de la acción de una persona aprobadora o un grupo de aprobación específico. Se infiere cuando el estado de la solicitud indica que está pendiente de un código de liberación concreto. | ||
| Por qué es importante Esta actividad es esencial para localizar cuellos de botella en la cadena de aprobación. Analizar cuánto dura este estado ayuda a identificar solicitudes estancadas y personas aprobadoras sobrecargadas. Dónde obtenerlo Se infiere a partir de los campos de estado de liberación de la tabla EBAN (por ejemplo, FRGZU) y de la configuración subyacente de la estrategia de liberación. El evento comienza cuando un código de liberación específico pasa a ser el siguiente que debe procesarse. Capturar Determine cuándo una solicitud entra en un estado en el que un código de liberación específico está pendiente de aprobación, según los registros del flujo de trabajo o los campos de estado. Tipo de evento inferred | |||
| Solicitud enviada para aprobación | Representa el momento en que la persona solicitante envía formalmente la solicitud y activa el flujo de trabajo de aprobación. Por lo general, se infiere cuando se determina la estrategia de liberación de la solicitud y el estado cambia a 'En aprobación'. | ||
| Por qué es importante Este hito clave inicia el cómputo del tiempo de ciclo de aprobación de los KPI. Analizar el tiempo transcurrido entre la creación y el envío permite detectar demoras en la preparación de la solicitud. Dónde obtenerlo Se infiere a partir de los documentos de modificación (CDHDR/CDPOS) de la tabla EBAN, en concreto cuando se completan los campos de estrategia de liberación (por ejemplo, FRGST) o el estado general (PROCSTAT) cambia para indicar que la solicitud está en aprobación. Capturar Identifique la primera entrada del documento de modificación que indique el inicio del flujo de trabajo de aprobación o un cambio de estado a 'En aprobación'. Tipo de evento inferred | |||
| Solicitud modificada | Se produce cuando una persona usuaria modifica un campo clave de la solicitud después de su creación inicial, como la cantidad, el precio o el material. Esta acción queda registrada explícitamente en el sistema de documentos de modificación de SAP. | ||
| Por qué es importante Registrar las modificaciones es fundamental para identificar ciclos de retrabajo y su impacto en los tiempos de ciclo. Una frecuencia elevada de modificaciones puede indicar problemas de calidad de los datos o cambios en los requisitos, aspectos clave para mejorar el proceso. Dónde obtenerlo Se registra explícitamente en las tablas de documentos de modificación de SAP (CDHDR y CDPOS) para los cambios realizados en la tabla EBAN. Cada cambio en un campo supervisado genera una entrada. Capturar Extraiga los eventos de modificación de CDHDR/CDPOS cuando la clase de objeto sea BANF para las solicitudes de compra. Tipo de evento explicit | |||
| Solicitud retirada | Se produce cuando la persona solicitante original cancela o elimina la solicitud antes de que se procese por completo. Por lo general, se trata de una acción explícita que establece un indicador de eliminación en la posición de la solicitud. | ||
| Por qué es importante Registrar las retiradas ayuda a comprender la variabilidad de la demanda y los motivos de cancelación. La solicitud pasa a un estado terminal que impide que siga procesándose. Dónde obtenerlo Se registra explícitamente cuando se establece el indicador de eliminación (LOEKZ) en la tabla EBAN para una posición de solicitud. El cambio queda registrado en CDHDR/CDPOS. Capturar Identifique el evento en que el indicador de eliminación (LOEKZ) de la tabla EBAN se establece en 'L'. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Requisitos previos: Asegúrese de contar con un usuario que tenga las autorizaciones adecuadas en SAP S/4HANA para acceder a las vistas CDS necesarias. Por lo general, se requieren permisos para objetos como S_TABU_NAM y acceso a herramientas de visualización de datos.
- Identifique el método de acceso al sistema: Determine cómo se conectará a la base de datos de SAP S/4HANA para ejecutar consultas SQL. Entre las herramientas habituales se encuentran SAP HANA Studio, Eclipse IDE con ADT (ABAP Development Tools) y clientes SQL de terceros, como DBeaver, que pueden conectarse mediante el cliente de base de datos SAP HANA.
- Revise la consulta SQL: Familiarícese con el script SQL proporcionado. Utiliza expresiones de tabla comunes (CTE) para recopilar datos de distintas actividades y combinarlos en un registro de eventos unificado.
- Personalice los marcadores de posición: Localice y sustituya los marcadores de posición de la consulta. Debe definir el intervalo de fechas (formato
[YYYY-MM-DD]) del periodo de extracción y especificar los códigos de empresa correspondientes ([Your Company Code]). - Ejecute la consulta: Ejecute la consulta SQL completa y personalizada en la base de datos de SAP S/4HANA. Según el volumen de datos y el intervalo de fechas seleccionado, la ejecución puede tardar un tiempo.
- Revise los datos iniciales: Cuando termine la consulta, revise las primeras filas del resultado. Compruebe que todas las columnas, como PurchaseRequisitionId, ActivityName y EventTime, tengan los valores esperados y que los formatos de datos sean correctos.
- Revise las transformaciones de datos: La consulta proporcionada genera datos en un formato listo para Process Mining. Las funciones
CASTyCONCATgarantizan la coherencia de los tipos de datos. No debería ser necesario realizar transformaciones importantes después de la ejecución. - Exporte el registro de eventos: Exporte todo el conjunto de resultados desde el cliente SQL a un archivo CSV. Asegúrese de que la codificación sea UTF-8 para evitar problemas con los caracteres.
- Prepare la carga: Antes de cargar el archivo en una herramienta de Process Mining, compruebe que el CSV tenga los encabezados correctos (
PurchaseRequisitionId,ActivityName,EventTime, etc.) y que el formato de fecha y hora deEventTimesea coherente y compatible con la plataforma de destino. - Cargue los datos en ProcessMind: Cargue el archivo CSV final en su proyecto de ProcessMind. Configure el proyecto asignando
PurchaseRequisitionIdal ID del caso,ActivityNamea la actividad yEventTimea la marca de tiempo.
Configuración
- Vistas CDS principales: La extracción utiliza principalmente
I_PurchaseRequisitionAPI01para los datos básicos de las solicitudes,I_ChangeDocumentyI_ChangeDocumentItempara registrar cambios y actualizaciones de estado, yI_PurchaseOrderItemAPI01para vincular las solicitudes con los pedidos de compra. - Autorización: El usuario que ejecute la consulta necesita acceso de lectura a las vistas CDS mencionadas. Consulte con el equipo de seguridad de SAP qué roles y autorizaciones necesita.
- Filtro por intervalo de fechas: Es fundamental aplicar un filtro de fechas a la fecha de creación de la solicitud (
CreationDate) para limitar el volumen de datos. Para el análisis inicial, se recomienda utilizar datos de un periodo de entre 3 y 6 meses. - Filtro organizativo: Filtre los datos por
CompanyCodepara analizar el proceso de la entidad empresarial correcta. También puede filtrar porPurchaseRequisitionTypepara centrarse en procesos de compra específicos, como los de bienes estándar o servicios. - Configuración de documentos de modificación: El registro de actividades como «Solicitud de compra modificada» y de los distintos pasos de aprobación depende de que el registro de documentos de modificación esté activo para los campos pertinentes del sistema SAP. Si faltan estos eventos, compruebe la configuración de la tabla EBAN.
- Rendimiento: En sistemas muy grandes, con millones de solicitudes, ejecutar esta consulta para un periodo extenso puede afectar al rendimiento. Considere ejecutarla fuera de las horas de mayor actividad o en un entorno que no sea de producción y tenga datos actualizados recientemente.
Consulta de ejemplo sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Pasos
- Confirme que tiene acceso de lectura directa al esquema de SAP HANA que contiene EBAN y EBKN. Identifique también los objetos de documentos de modificación y documentos de compras que utiliza su sistema para los cambios en las solicitudes, el proceso de liberación, la asignación de origen, las referencias a pedidos de compra y el cierre. Como estos objetos y campos pueden variar según la versión y la configuración, sustituya cada marcador de posición entre corchetes de la consulta por el objeto o campo correspondiente de su sistema.
- En SAP GUI, utilice la transacción SE16H o una herramienta de administración de bases de datos aprobada para inspeccionar EBAN y EBKN, verificar los campos clave de las solicitudes y confirmar qué campos están disponibles para fecha, hora, usuario, estado, eliminación, liberación, imputación y referencia a documentos de compras. Utilice SE11 o el diccionario de datos de SAP para verificar las definiciones de los campos. No exponga datos de producción durante las pruebas.
- Identifique la fuente de documentos de modificación configurada para los cambios en las solicitudes y las aprobaciones. La consulta espera una fuente de cambios normalizada denominada [Your requisition change document source], con campos para el número de solicitud, el número de posición, el campo modificado, el valor anterior, el valor nuevo, la fecha y hora del cambio y el usuario. Antes de ejecutar la consulta, asigne esta fuente a las tablas de documentos de modificación o a la vista CDS pertinente de su sistema SAP.
- Identifique la fuente configurada de flujo de trabajo o liberación para el envío, el reinicio de la aprobación, el inicio y la finalización de cada paso de aprobación, la aprobación final y el rechazo. La consulta espera [Your requisition approval event source], con una fila por cada transición de estado o liberación y campos para el número de solicitud, el número de posición, el tipo de evento, el código de liberación o grupo de aprobación, el aprobador, la fecha y hora del evento y el estado. Asígnela a los datos persistentes de liberación o flujo de trabajo que utilice su configuración de S/4HANA.
- Identifique las fuentes de asignación de origen, referencia a pedidos de compra y cierre. La consulta espera [Your requisition source assignment source], [Your requisition purchase order reference source] y [Your requisition closure source]. Asigne estos marcadores de posición a las tablas o vistas aprobadas de su sistema. La creación de un pedido de compra debe representarse mediante una referencia explícita de la posición del pedido a la posición de la solicitud, no deducirse a partir de actividades de compra no relacionadas.
- Defina el periodo de extracción mediante [Start date] y [End date]. Para la primera ejecución, se recomienda un periodo de entre tres y seis meses. Utilice un periodo más amplio solo después de validar el rendimiento de la base de datos y el volumen de eventos. La consulta filtra por fechas de creación y de eventos, y conserva el identificador de la solicitud como identificador del caso.
- Ejecute la consulta en un cliente SQL aprobado y conectado a SAP HANA. Sustituya únicamente los datos de conexión que estén fuera de la consulta, los parámetros de fecha, los filtros específicos de la empresa y los marcadores de posición de fuentes y campos documentados explícitamente. Mantenga exactamente los nombres de las columnas de salida: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount y RequisitionStatus.
- Revise los eventos duplicados, la precisión de las marcas de tiempo, el tratamiento de las zonas horarias y el nivel de detalle por posición o documento. La consulta genera identificadores de caso a nivel de documento e incluye internamente el contexto de las posiciones. Si varias posiciones generan la misma actividad y marca de tiempo, conserve las filas por separado, a menos que el diseño de ProcessMind requiera expresamente eliminar duplicados.
- Compruebe que todas las actividades necesarias aparezcan como valores de ActivityName, que EventTime tenga un valor cronológicamente coherente y que el identificador de caso obligatorio no sea nulo. Compare los recuentos con los informes de SAP o con extracciones operativas aprobadas para el mismo periodo.
- Exporte el resultado como un archivo CSV UTF-8 o en otro formato tabular compatible con ProcessMind. Incluya una fila de encabezados, conserve marcas de tiempo compatibles con ISO, deje vacíos los valores nulos y cargue el archivo con PurchaseRequisitionId como identificador del caso, ActivityName como columna de actividad y EventTime como columna de marca de tiempo.
Configuración
- Identificador del caso: Utilice el número de documento de solicitud de compra de EBAN, representado como PurchaseRequisitionId. Si el proceso está configurado a nivel de posición, utilice en su lugar una clave compuesta documentada, como el número de solicitud y el número de posición, y aplique la misma clave a todos los eventos.
- Fuente principal: EBAN contiene los datos de las posiciones de solicitud. EBKN se utiliza para enriquecerlos con datos de imputación y de departamento o centro de coste. Antes de ejecutar la consulta, confirme los nombres exactos y los tipos de datos de los campos en el diccionario de datos de SAP.
- Fuentes de eventos: La consulta utiliza deliberadamente marcadores de posición descriptivos para las fuentes de cambios, aprobaciones, asignación de origen, referencias a pedidos de compra y cierre. Estas fuentes dependen de la versión de S/4HANA, el diseño del flujo de trabajo, el procedimiento de liberación, las funciones empresariales activadas y las extensiones del cliente.
- Intervalo de fechas: Comience con un periodo de entre tres y seis meses. Cuando sea posible, utilice un intervalo acotado en campos de fecha indexados o que permitan la eliminación de particiones. Para las cargas incrementales, solape los periodos de extracción lo suficiente para capturar los cambios que lleguen tarde y, después, elimine los duplicados utilizando el caso, la actividad, la marca de tiempo, la posición y la clave del evento de origen.
- Filtros empresariales: Configure [Company code filter], [Document type filter], [Purchasing group filter] y [Plant filter] solo si los campos están disponibles y se ha confirmado su significado empresarial. Si el objetivo es capturar todo el ciclo de vida, evite filtrar por estado.
- Asignación de estados: Configure los valores de En aprobación, aprobado definitivamente, rechazado, reiniciado, código de liberación pendiente y cerrado según la estrategia de liberación o la configuración del flujo de trabajo del sistema de destino. No dé por sentado que un mismo código de estado se aplica a todos los clientes SAP.
- Asignación de modificaciones: Incluya los cambios en cantidad, precio, material, fecha de entrega, imputación y otros campos que su proceso defina como clave. La consulta contiene condiciones explícitas para los campos clave enumerados y requiere que la fuente indique el nombre del campo modificado.
- Tratamiento de marcas de tiempo: Combine la fecha y la hora del evento en la zona horaria de la base de datos y documente cualquier conversión a UTC. Si una fuente solo almacena la fecha, utilice la medianoche únicamente cuando no haya una marca de tiempo más precisa y registre esa limitación.
- Rendimiento: Limite la extracción inicial por fecha y alcance empresarial, seleccione solo las columnas necesarias, evite las uniones sin restricciones con historiales extensos de cambios o flujos de trabajo y revise el plan de ejecución de HANA. Si necesita repetir la extracción, materialice o prepare las fuentes de eventos normalizadas.
- Autorizaciones y requisitos previos: Obtenga autorización de lectura para EBAN, EBKN, las fuentes configuradas de cambios y flujos de trabajo, los datos de asignación de origen, las referencias a pedidos de compra y los datos de cierre. Confirme que el acceso directo a la base de datos esté aprobado, que las funciones pertinentes de compras y flujos de trabajo estén activas y que se disponga de la licencia de base de datos SAP HANA o de las herramientas de administración necesarias.
- Seguridad: Aplique el principio de mínimo privilegio, proteja los identificadores de usuarios y aprobadores y siga las normas de la organización para extraer información de compras y financiera.
Consulta de ejemplo sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; ¿Todo listo para comenzar?
Utilice este Template para preparar los datos con confianza y aprovechar al máximo Process Mining en el proceso de solicitud de compra a pago. Comience hoy mismo a mejorar la eficiencia.
Reduzca las demoras en las solicitudes de compra a pago: ¡optimice ahora su flujo de trabajo!
Agilice los procesos, reduzca los tiempos de entrega y acorte el tiempo de ciclo un 30 %.
No se requiere tarjeta de crédito. La configuración toma 5 minutos.