Su Template de datos de Purchase to Pay - Solicitud de compra
Su Template de datos de Purchase to Pay - Solicitud de compra
- Atributos recomendados para recopilar datos detallados
- Actividades clave que debe seguir para descubrir el proceso
- Indicaciones para extraer datos de SAP S/4HANA
Del aprovisionamiento al pago: atributos de la solicitud
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | La fecha y hora exactas en las que tuvo lugar una actividad específica. | ||
| Descripción Event Time es la marca de tiempo que registra cuándo tuvo lugar una actividad. Estos datos son fundamentales para ordenar cronológicamente los eventos dentro de un caso y constituyen la base de todos los cálculos de duración y rendimiento en Process Mining. Por ejemplo, la diferencia de tiempo entre los eventos «Solicitud de pedido enviada» y «Solicitud de pedido aprobada» determina el tiempo de ciclo de aprobación. Las marcas de tiempo precisas son esenciales para analizar el rendimiento del proceso, identificar retrasos y supervisar el cumplimiento de los acuerdos de nivel de servicio. Este atributo permite crear Dashboards que visualizan los tiempos de ciclo, realizan el seguimiento de las solicitudes de pedido estancadas y comparan el rendimiento en distintos periodos. Por qué es importante Esta marca de tiempo es esencial para ordenar eventos, calcular tiempos de ciclo y analizar el rendimiento del proceso y los cuellos de botella. Dónde obtenerlo Las marcas de tiempo suelen obtenerse de las cabeceras de los documentos de modificación (CDHDR-UDATE, CDHDR-UTIME) o de los registros de eventos del Workflow. Ejemplos 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID de solicitud de compra PurchaseRequisitionId | El 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. Actúa como identificador central del caso y vincula todas las actividades y modificaciones relacionadas con una solicitud concreta, 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 único ID de solicitud de compra, los analistas pueden medir con precisión los tiempos de ciclo, realizar un seguimiento de 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 es el número de solicitud de compra, que se encuentra en la tabla EBAN, campo BANFN. Ejemplos 100178901001789110017892 | |||
| Nombre de la actividad ActivityName | El nombre de la actividad empresarial que tuvo lugar en un momento concreto 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 derivan de registros del sistema, como documentos de modificación e historiales del Workflow, y representan hitos clave del proceso, como «Solicitud creada», «Inicio del paso de aprobación» u «Orden de compra creada». El análisis de estas actividades permite visualizar el flujo del proceso, identificar cuellos de botella y medir el tiempo empleado en las distintas etapas. Comprender la secuencia y la frecuencia de actividades como «Solicitud modificada» o «Solicitud rechazada» es fundamental para detectar ineficiencias y áreas de mejora. Por qué es importante Define los pasos del proceso, forma la estructura básica del mapa de procesos y permite analizar el flujo, las variaciones y los cuellos de botella. Dónde obtenerlo Es un atributo derivado que normalmente se construye interpretando datos de las tablas de documentos de modificación (CDHDR, CDPOS) y de los registros del Workflow, como SWWLOGHIST. Ejemplos Solicitud creadaPaso de aprobación completadoSolicitud aprobadaOrden de compra creada | |||
| Departamento Department | El departamento o centro de costos al que se cargan los costos de la solicitud. | ||
| Descripción El atributo Departamento, representado a menudo por el centro de coste en SAP, identifica la unidad de negocio responsable de la compra solicitada. Es un dato financiero y organizativo fundamental que se asigna en el nivel de posición de una solicitud de pedido. En Process Mining, este atributo es esencial para analizar el rendimiento por departamento. Permite crear Dashboards que comparan métricas clave, como el tiempo de ciclo, las tasas de modificación y las tasas de rechazo, entre distintos departamentos. Esto ayuda a identificar los departamentos con mejor rendimiento, cuyas prácticas podrían adoptarse en otras áreas, así como aquellos que pueden necesitar formación o soporte adicional para el proceso. Por qué es importante Permite comparar el rendimiento entre unidades de negocio, pone de relieve las variaciones en los tiempos de ciclo o las tasas de rechazo e identifica buenas prácticas y áreas de mejora. Dónde obtenerlo Es el centro de costos, que normalmente se encuentra en la tabla de asignación de cuentas EBKN, campo KOSTL. Ejemplos FIN-1001IT-2005MKT-3010 | |||
| Estado de la solicitud de compra RequisitionStatus | El estado actual de procesamiento o aprobación de la solicitud de compra. | ||
| Descripción El estado de la solicitud de compra indica su situación actual dentro del ciclo de vida. En SAP, suele representarse mediante el indicador de liberación, que muestra si una solicitud está bloqueada, en proceso de aprobación, parcialmente aprobada o totalmente aprobada. Este estado cambia a medida que la solicitud avanza por el Workflow. El seguimiento del 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 obtener una visión detallada del proceso de aprobación y sus variantes. Por qué es importante Indica el estado actual de una solicitud de compra, un dato fundamental para realizar el seguimiento del progreso, 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 usuario UserId | El identificador del usuario que creó la solicitud o realizó una actividad específica. | ||
| Descripción El ID de usuario identifica al empleado o usuario del sistema responsable de un evento concreto del ciclo de vida de la solicitud. Puede ser la persona que creó la solicitud, el gerente que la aprobó o el agente que la modificó. En los pasos automatizados, puede corresponder al ID de un usuario del sistema o de un proceso por lotes. El análisis por ID de usuario ayuda a comprender el comportamiento individual, la distribución de la carga de trabajo y el rendimiento. Es clave para identificar necesidades de formación, reconocer a las personas con mejor desempeño y garantizar la responsabilidad dentro del proceso. También permite analizar el rendimiento por departamento cuando se combina con los datos maestros de usuarios. Por qué es importante Permite analizar el rendimiento de los usuarios, la distribución de la carga de trabajo y el cumplimiento del proceso. Es fundamental para identificar oportunidades de formación y cuellos de botella relacionados con los recursos. Dónde obtenerlo Se encuentra en EBAN-ERNAM para el creador. Para las modificaciones posteriores, aparece en CDHDR-USERNAME. Para las aprobaciones, se encuentra en los registros del Workflow. Ejemplos JSMITHRROEWF-BATCH | |||
| ID del aprobador ApproverId | El identificador del usuario que realizó un paso de aprobación o rechazo. | ||
| Descripción Approver ID identifica específicamente al Usuario que completó una actividad de aprobación o rechazo. Se diferencia del User ID general porque se centra exclusivamente en las personas que 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 de las aprobaciones, por ejemplo, identificar a los responsables con tiempos de aprobación prolongados o que rechazan solicitudes de pedido con frecuencia. Es esencial para los Dashboards centrados en los tiempos de ciclo de los pasos de aprobación y en el análisis de cuellos de botella del flujo de trabajo, ya que ayuda a localizar a las personas o roles concretos que pueden estar provocando retrasos. Por qué es importante Identifica al responsable concreto de la decisión en un paso de aprobación y permite analizar detalladamente los tiempos de ciclo y los cuellos de botella por persona o rol. Dónde obtenerlo Esta información suele extraerse de tablas de SAP Business Workflow, como SWW_WI2OBJ y SWWLOGHIST, que vinculan los elementos de trabajo con el usuario que los completa. Ejemplos MJOHNSONCWILLIAMSLBLACK | |||
| Importe de la solicitud RequisitionAmount | El valor monetario total de la solicitud de compra. | ||
| Descripción El importe de la solicitud representa el costo total estimado de los bienes o servicios solicitados. Este valor suele ser un factor clave para determinar la complejidad y la duración del Workflow de aprobación, ya que las solicitudes de mayor importe normalmente requieren más niveles de aprobación. Analizar este atributo permite segmentar el proceso según el valor. Puede ayudar a responder preguntas como «¿Las solicitudes de mayor importe tardan más en aprobarse?» o «¿Cuál es el valor de las solicitudes que se rechazan con frecuencia?». Es una dimensión fundamental para comprender el impacto financiero de las ineficiencias del proceso. Por qué es importante Ayuda a segmentar el proceso según su impacto financiero, que suele correlacionarse con la complejidad de la aprobación y el tiempo de ciclo. Es esencial para analizar el proceso según el 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 | Un 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 denominado tipo de documento en SAP, es un campo de configuración clave que categoriza las solicitudes de compra. Los distintos tipos pueden activar diferentes Workflows de aprobación, tener configuraciones de campos distintas y utilizarse para diferentes fines empresariales, como artículos estándar de inventario, servicios externos o compras de activos. Al analizar el proceso según el tipo de solicitud, las organizaciones pueden comprender cómo se gestionan las distintas solicitudes. Esto permite comparar el rendimiento, los tiempos de ciclo y las rutas de aprobación entre categorías, revelar si ciertos tipos de solicitud son más o menos eficientes y orientar mejor las mejoras del proceso. Por qué es importante Categoriza las solicitudes para permitir análisis comparativos y ayuda a comprender si los distintos tipos tienen flujos de proceso, cuellos de botella o tiempos de ciclo diferentes. Dónde obtenerlo Es el campo Tipo de documento, que se encuentra en la tabla EBAN, campo BSART. Ejemplos NBFORV | |||
| Es retrabajo IsRework | Indicador que señala si una actividad constituye retrabajo, como una modificación posterior al envío. | ||
| Descripción Es retrabajo es un indicador booleano calculado que identifica las actividades que representan trabajo repetitivo o que no aporta valor. Un ejemplo habitual en este proceso es la actividad «Solicitud 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 del proceso y su impacto en los tiempos de ciclo generales. El Dashboard de modificaciones y tasa de retrabajo de solicitudes utiliza este indicador para poner de relieve las ineficiencias del proceso. Reducir el retrabajo suele ser un objetivo prioritario de las iniciativas de mejora, ya que se traduce directamente en un ahorro de tiempo y esfuerzo. Por qué es importante Señala las actividades que representan esfuerzo desperdiciado o repetición y permite medir directamente el retrabajo y su impacto en la eficiencia del proceso. Dónde obtenerlo Es un atributo calculado. Normalmente, la lógica marcaría como retrabajo cualquier actividad «Solicitud modificada» que se produzca después de la primera actividad «Solicitud enviada para aprobación». Ejemplos truefalse | |||
| Está automatizado IsAutomated | Indicador que señala si una actividad fue realizada por una persona usuaria del sistema en lugar de una persona. | ||
| Descripción El atributo Está automatizado es un indicador booleano que tiene el valor verdadero cuando una actividad la ejecuta el sistema o una persona usuaria de tipo batch, como «WF-BATCH» en las acciones del Workflow. Ayuda a distinguir entre los pasos manuales y automatizados del proceso. Este atributo es esencial para medir el nivel de automatización del proceso de solicitudes y calcular el KPI de la tasa de aprobaciones automatizadas. Al filtrar los pasos automatizados o manuales, las personas analistas pueden comparar su eficiencia e identificar oportunidades para automatizar más tareas, reducir los tiempos de procesamiento y disminuir el esfuerzo manual. Por qué es importante Distingue entre actividades realizadas por personas y actividades impulsadas por el sistema, algo clave para medir las tasas de automatización e identificar oportunidades de automatizar tareas manuales. Dónde obtenerlo Es un atributo derivado, normalmente basado en una regla que comprueba si el ID de usuario de un evento pertenece a una lista de personas usuarias del sistema o de tipo batch conocidas. Ejemplos truefalse | |||
| Fecha límite requerida RequiredByDate | La fecha en la que la persona solicitante necesita los bienes o servicios solicitados. | ||
| Descripción La fecha límite requerida, denominada fecha de entrega en SAP, especifica cuándo se necesitan los bienes o servicios de la posición de la solicitud. La persona solicitante establece esta fecha, que sirve como objetivo para todo el proceso de compras. Este atributo es esencial para calcular el KPI de la tasa de finalización puntual de solicitudes. Al comparar la fecha límite requerida con la fecha de aprobación final o de creación del pedido de compra, la organización puede medir su capacidad para cumplir los niveles de servicio internos y las necesidades del negocio. Analizar las solicitudes que no cumplen esta fecha puede revelar retrasos sistémicos en el proceso de compras. Por qué es importante Define la fecha objetivo de finalización de una solicitud y permite medir las entregas puntuales 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 | La fecha y hora exactas en las que se completó una actividad concreta. | ||
| Descripción EndTime es la marca de tiempo que registra cuándo finalizó una actividad. Aunque muchos eventos generados por el sistema son instantáneos, lo que significa que StartTime es igual a EndTime, las tareas realizadas por personas, como las aprobaciones, pueden tener una hora de inicio y otra de finalización distintas. Esta marca de tiempo señala la finalización del trabajo. Disponer de un EndTime independiente permite medir con mayor precisión el tiempo de procesamiento activo frente al 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 recursos y la eficiencia de las tareas manuales. Por qué es importante Marca la finalización de una actividad, permite calcular el tiempo de procesamiento activo y proporciona una visión más detallada de la duración de la tarea. Dónde obtenerlo Se deriva de los registros del Workflow, que pueden capturar 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 | El código de moneda del importe de la solicitud de compra. | ||
| Descripción Este atributo especifica la moneda en la que se expresa el importe de la solicitud de compra, por ejemplo, USD, EUR o JPY. Proporciona el contexto necesario para el atributo Importe de la solicitud de compra, especialmente en organizaciones multinacionales que operan con varias monedas. Para realizar análisis e informes financieros precisos, es fundamental tener en cuenta la moneda. Al agregar o comparar valores de solicitudes de compra, todos los importes deben convertirse a una moneda común para garantizar resultados significativos. Este atributo es un requisito previo para realizar esas conversiones. Por qué es importante Proporciona el contexto esencial para el Importe de la solicitud de compra y permite realizar análisis y comparaciones financieras precisas en entornos con varias monedas. Dónde obtenerlo Se encuentra en la tabla EBAN, campo WAERS. Ejemplos USDEURGBP | |||
| Motivo del rechazo RejectionReason | El 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 pueden estar superar el presupuesto, incluir información incorrecta, incumplir una política o duplicar otra solicitud. Esta información proporciona un contexto esencial para comprender los fallos del proceso. Analizar los motivos del rechazo ayuda a identificar las causas raíz de las ineficiencias y del retrabajo. Por ejemplo, si «Centro de coste incorrecto» es un motivo frecuente, puede indicar la necesidad de mejorar la formación de las personas usuarias o la validación del sistema. Este atributo es la base del Dashboard de análisis de rechazos de solicitudes y resulta fundamental para aplicar mejoras específicas al proceso. Por qué es importante Proporciona la causa raíz de los fallos del proceso y permite aplicar mejoras específicas para reducir el retrabajo y aumentar la tasa de solicitudes correctas a la primera. Dónde obtenerlo A menudo no es un campo estándar. Puede capturarse en elementos del contenedor del Workflow, 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 la 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 suele existir un campo estándar específico, algunas organizaciones utilizan campos como el número de seguimiento de la necesidad para capturar esta información. Esto permite a las personas solicitantes señalar necesidades críticas que pueden requerir un procesamiento acelerado. Analizar el impacto de la urgencia es importante para evaluar si el proceso prioriza correctamente las solicitudes críticas. 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 estándar, y ayuda a determinar si la gestión prioritaria funciona según lo previsto. Por qué es importante Permite analizar cómo varía el rendimiento del proceso en las solicitudes de alta prioridad y comprobar si los elementos urgentes reciben realmente un tratamiento acelerado. Dónde obtenerlo No existe un campo estándar de urgencia. Algunas empresas utilizan el número de seguimiento de la necesidad (EBAN-BEDAR) para este fin. También puede tratarse de un campo personalizado. Ejemplos AltaMediaBaja | |||
| Nombre del paso de aprobación ApprovalStepName | El nombre o la descripción específicos de un paso de aprobación del Workflow. | ||
| Descripción El nombre del paso de aprobación proporciona una descripción comprensible para las personas de una etapa concreta del Workflow de aprobación, como «Aprobación del gerente» o «Aprobación de la vicepresidencia 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 de los pasos de aprobación y de análisis de cuellos de botella del Workflow. Permite examinar el proceso de aprobación con un alto nivel de detalle, identificar exactamente qué etapas provocan los retrasos más importantes y detectar dónde se acumula el trabajo. Este nivel de detalle resulta necesario para aplicar medidas específicas y agilizar la cadena de aprobación. Por qué es importante Proporciona un nivel de detalle preciso sobre las etapas de aprobación y permite identificar con exactitud los cuellos de botella del Workflow de aprobación multinivel. Dónde obtenerlo Esta información se deriva de la descripción de la tarea del Workflow, que puede encontrarse vinculando el registro del Workflow 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 pedido de compra PurchaseOrderNumber | El número del pedido de compra creado a partir de la solicitud. | ||
| Descripción El número del pedido de compra es el identificador del documento oficial de compras creado a partir de una solicitud aprobada. La creación de un pedido de compra suele ser el resultado final satisfactorio de una solicitud, ya que indica que la petición se ha convertido en un pedido formal para un proveedor. Este atributo es fundamental para medir el KPI del plazo desde la solicitud hasta el pedido de compra y la tasa de conversión general. Conecta el proceso de solicitud con el proceso de compras posterior y permite obtener una visión integral del ciclo Purchase-to-Pay. Por qué es importante Vincula la solicitud con el documento de compras posterior y permite medir la tasa de conversión y el plazo desde la solicitud hasta el pedido de compra. Dónde obtenerlo Se encuentra en la tabla EBAN, campo EBELN, una vez creado un pedido 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 de procedencia en el que se generaron los datos del proceso. En organizaciones con varias instancias de SAP, como sistemas distintos para desarrollo, aseguramiento de la calidad y producción, o sistemas separados para diferentes regiones, este campo es fundamental para la gobernanza y el contexto de los datos. Garantiza que los datos de distintas fuentes puedan distinguirse, evita agregaciones incorrectas y permite realizar análisis específicos de cada sistema. Es un atributo obligatorio para mantener la trazabilidad de los datos y garantizar el seguimiento del origen del proceso. Por qué es importante Proporciona un contexto esencial sobre el origen y la gobernanza de los datos, especialmente en entornos con varios sistemas, y garantiza su trazabilidad. Dónde obtenerlo Normalmente es el 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 datos LastDataUpdate | La marca de tiempo que indica 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 desde el sistema de origen. Es un elemento de metadatos fundamental para conocer la actualidad de los datos analizados. Los analistas y usuarios de negocio utilizan esta marca de tiempo para saber si los datos del proceso reflejan el estado operativo más reciente. En cualquier análisis de procesos, conocer la vigencia de los datos es fundamental para tomar decisiones informadas. Este atributo ayuda a gestionar las expectativas de los usuarios y garantiza que las conclusiones se basen en datos tan actualizados como exige cada análisis. Por qué es importante Indica la actualidad de los datos, un aspecto crucial para confiar en el análisis y tomar decisiones empresariales oportunas. Dónde obtenerlo Esta marca de tiempo se genera y añade durante el proceso de extracción, transformación y carga (ETL) de datos. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Del aprovisionamiento al pago: actividades de la solicitud
| Actividad | Descripción | ||
|---|---|---|---|
| Orden de compra creada | Indica que se ha generado una orden de compra que hace referencia a la posición de la solicitud. Es un evento explícito del sistema que vincula 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 transcurrido entre la aprobación de la solicitud y la creación de la orden de compra es un KPI fundamental 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 compra (BANFN) y el número de posición (BNFPO). Recopilar Una 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 un aprobador realiza una acción positiva sobre una solicitud y completa un paso del Workflow 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 detalladamente el Workflow de aprobación y medir el tiempo empleado en cada paso. Ayuda a distinguir a los aprobadores eficientes de 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. Recopilar 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 | Marca la aprobación final y completa de la solicitud de compra, lo que permite convertirla en una orden de compra. Este hito se infiere cuando el estado general de liberación alcanza su estado final de aprobado. | ||
| Por qué es importante Este es un hito crítico de éxito y un punto final habitual para analizar el tiempo de ciclo. Significa 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, concretamente cuando el indicador general de liberación (FRGZU) o el estado de procesamiento (PROCSTAT) se actualiza al valor final «Aprobado». Recopilar Identifique la marca de tiempo en la que se aplica el código de liberación final o cambia a «Aprobado» el estado general de la solicitud. Tipo de evento inferred | |||
| Solicitud cerrada | Indica que la posición de la solicitud se considera completamente procesada y que ya no pueden crearse más órdenes de compra a partir de ella. Este estado suele establecerse automáticamente cuando se ha pedido la cantidad total. | ||
| 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 empresarial se ha convertido por completo en una orden de compras. 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 equivale a la cantidad solicitada. Recopilar Identifique, mediante los documentos de modificación, el evento en el que se establece el indicador «Cerrado» (EBAKZ) en la tabla EBAN. Tipo de evento inferred | |||
| Solicitud creada | Marca la creación inicial del documento de solicitud de compra en el sistema. Este evento se captura explícitamente cuando un usuario guarda una solicitud nueva por primera vez y registra la fecha y hora de creación. | ||
| Por qué es importante Esta actividad sirve como punto de inicio 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 es un evento explícito capturado de la tabla EBAN, utilizando los campos de fecha de creación (ERDAT) y hora de creación (ERZEIT) para el número de solicitud de compra específico (BANFN). Recopilar 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 final de la solicitud de compra por parte de un aprobador, lo que detiene el proceso. Se captura mediante una actualización de estado específica que indica el rechazo. | ||
| Por qué es importante Esta actividad constituye un punto final crítico de fallo. Analizar la frecuencia y los motivos de rechazo, así como los puntos del proceso en los que se producen, ayuda a identificar 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». Recopilar Identifique la marca de tiempo en la que el estado general de EBAN se actualiza a «Rechazado» mediante los documentos de modificación. Tipo de evento inferred | |||
| Fuente de suministro asignada | Representa la acción de un comprador 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 para la creación de una orden de compra. | ||
| Por qué es importante Esta actividad conecta la aprobación con el pedido. Medir el tiempo necesario para asignar una fuente ayuda a identificar retrasos en la carga de trabajo del comprador y en la eficiencia del abastecimiento. Dónde obtenerlo Se infiere a partir de la introducción de un valor en los campos relacionados con la fuente de suministro de la tabla EBAN, como proveedor fijo (LIFNR), registro info (INFNR) o contrato (KONNR). Recopilar Realice un seguimiento, mediante los documentos de modificación, de la cumplimentación de campos como LIFNR, INFNR o KONNR en la tabla EBAN. Tipo de evento inferred | |||
| Inicio del paso de aprobación | Indica que una solicitud está pendiente de la acción de un aprobador o grupo de aprobadores 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 la duración de este estado ayuda a identificar solicitudes estancadas y aprobadores sobrecargados. Dónde obtenerlo Se infiere a partir de los campos de estado de liberación de la tabla EBAN, como 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. Recopilar Determine cuándo una solicitud entra en un estado en el que un código de liberación específico queda pendiente de aprobación, según los registros del Workflow o los campos de estado. Tipo de evento inferred | |||
| Restablecimiento de la aprobación | Representa un evento en el que se restablece todo el Workflow de aprobación, normalmente debido a una modificación importante de la solicitud. Esto obliga a reiniciar el proceso de aprobación desde el primer nivel. | ||
| Por qué es importante Esta actividad pone de manifiesto un retrabajo importante que afecta gravemente al tiempo de ciclo. Identificar las causas de los restablecimientos de aprobación es fundamental para agilizar el proceso y reducir los retrasos. Dónde obtenerlo Se infiere a partir de los documentos de modificación (CDHDR/CDPOS) de la tabla EBAN. Este evento se detecta cuando los campos de estado de liberación, como FRGKZ o FRGZU, se borran después de haber sido establecidos parcial o totalmente. Recopilar Busque en los registros de cambios una modificación del estado de liberación, de liberado a no liberado. Tipo de evento inferred | |||
| Solicitud enviada para aprobación | Representa el momento en que el solicitante envía formalmente la solicitud y activa el Workflow de aprobación. Normalmente 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 es un hito fundamental que inicia el conteo de los KPI del tiempo de ciclo de aprobación. Analizar el tiempo transcurrido entre la creación y el envío puede revelar retrasos en la fase de preparación de la solicitud. Dónde obtenerlo Se infiere a partir de los documentos de modificación (CDHDR/CDPOS) de la tabla EBAN, concretamente cuando se rellenan los campos de la estrategia de liberación, como FRGST, o cuando el estado general (PROCSTAT) cambia para reflejar un estado «En aprobación». Recopilar Identifique la primera entrada del documento de modificación que indique el inicio del Workflow de aprobación o un cambio de estado a «En aprobación». Tipo de evento inferred | |||
| Solicitud modificada | Se produce cuando un usuario 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 El seguimiento de las modificaciones es fundamental para identificar los ciclos de retrabajo y su impacto en los tiempos de ciclo. Una frecuencia elevada de modificaciones sugiere problemas de calidad de datos o cambios en los requisitos, áreas 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. Recopilar Extraiga los eventos de modificación de CDHDR/CDPOS cuyo objeto sea BANF para las solicitudes de compra. Tipo de evento explicit | |||
| Solicitud retirada | Se produce cuando el solicitante original cancela o elimina la solicitud antes de que se procese por completo. Normalmente 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 El seguimiento de las retiradas ayuda a comprender la volatilidad de la demanda y los motivos de las cancelaciones. Representa un estado terminal para la solicitud e impide que continúe su procesamiento. Dónde obtenerlo Se captura explícitamente cuando se establece el campo del indicador de eliminación (LOEKZ) en la tabla EBAN para una posición de solicitud. El cambio queda registrado en CDHDR/CDPOS. Recopilar Identifique el evento en el 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 disponer de una persona usuaria con las autorizaciones adecuadas en SAP S/4HANA para acceder a las vistas CDS necesarias. Normalmente, esto incluye 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) o 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 Common Table Expressions (CTE) para recopilar datos de distintas actividades y unirlos en un registro de eventos unificado.
- Personalice los marcadores de posición: Localice y sustituya los marcadores de posición de la consulta. Deberá establecer el intervalo de fechas, con el formato
[YYYY-MM-DD], del periodo de extracción y especificar los códigos de empresa pertinentes,[Your Company Code], de su organización. - 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 algún tiempo.
- Revise inicialmente los datos: Cuando finalice la consulta, revise las primeras filas del resultado. Compruebe que todas las columnas, como PurchaseRequisitionId, ActivityName y EventTime, estén completas según lo previsto y que los formatos de datos sean correctos.
- Gestione la transformación de datos: La consulta proporcionada está diseñada para generar datos en un formato listo para Process Mining. Las funciones
CASTyCONCATgarantizan la coherencia de los tipos de datos. No debería ser necesaria una transformación posterior importante. - Exporte el registro de eventos: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Asegúrese de que la codificación del archivo sea UTF-8 para evitar problemas con los caracteres.
- Prepárese para la carga: Antes de cargar el archivo en una herramienta de Process Mining, compruebe que el archivo CSV tenga los encabezados correctos, como
PurchaseRequisitionId,ActivityNameyEventTime, 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
PurchaseRequisitionIdcomo ID de caso,ActivityNamecomo actividad yEventTimecomo marca de tiempo.
Configuración
- Vistas CDS principales: La extracción utiliza principalmente
I_PurchaseRequisitionAPI01para los datos principales de las solicitudes,I_ChangeDocumenteI_ChangeDocumentItempara seguir los cambios y las actualizaciones de estado, eI_PurchaseOrderItemAPI01para vincular las solicitudes con los pedidos de compra. - Autorización: La persona usuaria que ejecute la consulta necesita acceso de lectura a las vistas CDS mencionadas. Consulte al equipo de seguridad de SAP para conocer los roles y las autorizaciones necesarios.
- Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de intervalo 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 3 a 6 meses. - Filtrado organizativo: Filtre los datos por
CompanyCodepara asegurarse de analizar el proceso de la entidad empresarial correcta. También puede filtrar porPurchaseRequisitionTypepara centrarse en procesos de compras específicos, como bienes estándar frente a servicios. - Configuración de documentos de modificación: La captura de actividades como «Solicitud modificada» y de distintas etapas 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 del sistema para la tabla EBAN.
- Rendimiento: En sistemas muy grandes, con millones de solicitudes, ejecutar esta consulta durante un periodo prolongado puede afectar al rendimiento. Considere ejecutarla fuera de las horas punta o en un entorno que no sea de producción con datos actualizados recientemente.
a 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 dispone de acceso directo de lectura al esquema de SAP HANA que contiene EBAN y EBKN, e identifique los objetos de documentos de modificación y de compras utilizados en su sistema para las modificaciones de solicitudes, el procesamiento de liberaciones, la asignación de fuentes, 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 la solicitud y confirmar los campos disponibles de 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 las modificaciones de solicitudes y los cambios de aprobación. La consulta espera una fuente de modificaciones 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 de modificación, la hora de modificación y la persona usuaria. Asigne esta fuente a las tablas de documentos de modificación de SAP o a la vista CDS correspondiente de su sistema antes de ejecutarla.
- Identifique la fuente de Workflow o de liberación configurada para el envío, el restablecimiento de la aprobación, el inicio y la finalización de los pasos 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, la persona aprobadora, la fecha del evento, la hora del evento y el estado. Asigne esta fuente al almacenamiento persistente de liberaciones o Workflow utilizado por su configuración de S/4HANA.
- Identifique las fuentes de asignación de fuentes, 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 del pedido de compra debe representarse mediante una referencia explícita desde la posición del pedido de compra hasta la posición de la solicitud, no inferirse a partir de actividades de compras no relacionadas.
- Establezca la ventana de extracción mediante [Start date] y [End date]. Para la primera ejecución, se recomienda un periodo de tres a 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 las fechas de creación y de los eventos, y conserva el identificador de la solicitud como identificador de caso.
- Ejecute la consulta en un cliente SQL aprobado conectado a SAP HANA. Sustituya únicamente los datos de conexión externos a 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, la gestión de zonas horarias y el nivel de granularidad de posición frente a documento. La consulta genera identificadores de caso a nivel de documento e incluye internamente el contexto de la posición. Si varias posiciones generan la misma actividad y marca de tiempo, conserve filas independientes, salvo que el diseño de ProcessMind requiera explícitamente deduplicarlas.
- Valide que cada actividad necesaria aparezca como valor de ActivityName, que EventTime esté completo y sea cronológicamente coherente, y que el identificador de caso obligatorio no sea nulo. Concilie los recuentos con los informes de SAP o las extracciones operativas aprobadas para el mismo intervalo de fechas.
- Exporte el resultado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Incluya una fila de encabezados, conserve marcas de tiempo compatibles con ISO, mantenga los valores nulos como campos vacíos y cargue el archivo utilizando PurchaseRequisitionId como identificador de caso, ActivityName como columna de actividad y EventTime como columna de marca de tiempo.
Configuración
- Identificador de caso: Utilice el número de documento de la 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 se utiliza para los datos de las posiciones de la solicitud. EBKN se utiliza para enriquecer los datos de imputación y de departamento o centro de coste. Confirme los nombres exactos y los tipos de datos de los campos en el diccionario de datos de SAP antes de ejecutar la consulta.
- Fuentes de eventos: La consulta utiliza deliberadamente marcadores de posición profesionales para las fuentes de modificaciones, aprobaciones, asignación de fuentes, referencias a pedidos de compra y cierre, ya que estas fuentes dependen de la versión de S/4HANA, el diseño del Workflow, el procedimiento de liberación, las funciones empresariales activadas y las extensiones del cliente.
- Intervalo de fechas: Comience con un periodo de tres a seis meses. Cuando sea posible, utilice un intervalo acotado sobre campos de fecha indexados o que permitan podar particiones. Para las cargas incrementales, solape suficientemente las ventanas de extracción para capturar los cambios que lleguen tarde y, después, elimine duplicados mediante la combinación de caso, actividad, marca de tiempo, posición y clave del evento de origen.
- Filtros empresariales: Configure [Company code filter], [Document type filter], [Purchasing group filter] y [Plant filter] únicamente cuando estos campos estén disponibles y se haya confirmado su significado empresarial. Evite filtrar por estado cuando el objetivo sea capturar el ciclo de vida completo.
- Asignación de estados: Configure los valores de En aprobación, aprobado definitivamente, rechazado, restablecido, código de liberación pendiente y cerrado según la estrategia de liberación o la configuración del Workflow del sistema de destino. No dé por supuesto que un código de estado es universal en todos los clientes SAP.
- Asignación de modificaciones: Incluya los cambios de cantidad, precio, material, fecha de entrega, imputación y otros campos que su proceso defina como campos clave. La consulta incluye predicados explícitos para los campos clave enumerados y requiere que la fuente exponga el nombre del campo modificado.
- Gestión 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 una fecha, utilice la medianoche únicamente cuando no exista una marca de tiempo más precisa y deje constancia de esa limitación.
- Rendimiento: Limite la extracción inicial por fecha y alcance empresarial, seleccione únicamente las columnas necesarias, evite las uniones sin restricciones con historiales extensos de modificaciones o Workflow y revise el plan de ejecución de HANA. Materialice o prepare fuentes de eventos normalizadas si necesita repetir la extracción.
- Autorizaciones y requisitos previos: Obtenga autorización de lectura para EBAN, EBKN, las fuentes configuradas de modificaciones y Workflow, los datos de asignación de fuentes, los datos de referencia de 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 Workflow estén activas y que estén disponibles las licencias necesarias de la base de datos SAP HANA o las herramientas de administración correspondientes.
- Seguridad: Aplique el principio de mínimo privilegio, proteja los identificadores de las personas usuarias y aprobadoras y siga las normas de su organización para extraer información de compras y financiera.
a 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; ¿Listo para empezar?
Utilice este Template para preparar sus datos con confianza y aprovechar todo el potencial de Process Mining en su proceso Purchase to Pay - Solicitud de compra. ¡Empiece hoy mismo a optimizar la eficiencia!
Detenga los retrasos de las solicitudes P2P: ¡optimice su Workflow ahora!
Agilice los procesos, reduzca los plazos y disminuya el tiempo de ciclo un 30 %.
No necesita tarjeta de crédito; la configuración tarda 5 minutos.