> Mejora continua de procesos > De la compra al pago: solicitud de compra > SAP ECC > Template de datos

Su Template de datos para solicitudes de compra a pago

SAP ECC

Atributos de las solicitudes de compra a pago(19) Actividades de las solicitudes de compra a pago(13) Guías de extracción(2)

Su Template de datos para solicitudes de compra a pago

Este Template ofrece una guía completa para recopilar los datos esenciales que necesita para analizar el proceso de solicitudes de compra a pago. Describe los campos de datos clave que debe reunir, las actividades principales que debe registrar y cómo extraer esta información del sistema de origen. Utilice este recurso para preparar los datos para un análisis eficaz con Process Mining.

Atributos recomendados para recopilar
Actividades clave que debe registrar
Guía de extracción para SAP ECC

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos de las solicitudes de compra a pago

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en profundidad el proceso de solicitudes de compra a pago.

5 Obligatorio 5 Recomendado 9 Opcional

	Nombre	Descripción
	Hora del evento EventTime	Marca de tiempo que indica cuándo se produjo la actividad.
Descripción Hora del evento registra la fecha y hora exactas en que tuvo lugar una actividad específica. Esta marca de tiempo es fundamental para todos los análisis temporales de Process Mining, incluidos el cálculo de los tiempos de ciclo, la identificación de cuellos de botella y el análisis del rendimiento del proceso. En el contexto de las solicitudes de compra, este atributo permite calcular KPI clave, como «Tiempo promedio de aprobación de solicitudes» y «Tiempo hasta la creación del pedido de compra». También alimenta Dashboards que muestran duraciones, como el análisis del Tiempo de ciclo de aprobación de solicitudes, al proporcionar los datos necesarios para medir el tiempo entre dos puntos del proceso. Por qué es importante Esta marca de tiempo es esencial para calcular todas las duraciones, analizar el rendimiento del proceso y detectar cuellos de botella relacionados con el tiempo. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos de modificación CDHDR (campos UDATE y UTIME). Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID de solicitud de pedido PurchaseRequisitionId	Identificador único de un documento de solicitud de pedido.
Descripción El ID de solicitud de pedido es la clave principal que identifica de forma única cada solicitud de bienes o servicios en SAP ECC. Sirve como identificador central del caso y vincula todas las actividades y modificaciones relacionadas con una solicitud específica, desde su creación hasta su resolución final, por ejemplo, la conversión en un pedido de compra o el cierre. En Process Mining, este ID es esencial para reconstruir el ciclo de vida completo de cada solicitud. Al hacer un seguimiento de este identificador, los analistas pueden visualizar todo el flujo del proceso, medir la duración entre hitos y analizar las diferencias en la gestión de las solicitudes. Así se obtiene una visión coherente de todo el recorrido de cada solicitud. Por qué es importante Este es el identificador principal que reúne todos los eventos relacionados en un solo caso y permite analizar el proceso de principio a fin. Dónde obtenerlo Se encuentra en el campo BANFN de la tabla EBAN. Ejemplos 100234567810023456791002345680
	Nombre de la actividad ActivityName	Nombre de la actividad de negocio que tuvo lugar en un momento determinado.
Descripción Este atributo describe un paso o evento específico del ciclo de vida de una solicitud de pedido, como «Solicitud de pedido creada», «Aprobación enviada» o «Pedido de compra creado». Normalmente, estas actividades se obtienen de los cambios de estado, los registros del flujo de trabajo o los documentos de modificación de SAP. Analizar la secuencia y la frecuencia de las actividades es la base de Process Mining. Permite descubrir los flujos reales del proceso, incluidas las rutas habituales, las desviaciones y los cuellos de botella. Esto es fundamental para crear Dashboards, como el mapa del proceso de solicitudes de pedido de principio a fin, y calcular los KPI relacionados con el retrabajo y el cumplimiento. Por qué es importante Define los pasos del proceso y permite visualizar los mapas de procesos y analizar las variaciones del flujo. Dónde obtenerlo Se obtiene de las tablas de documentos de modificación CDHDR y CDPOS, los registros del flujo de trabajo o campos de estado como EBAN-STATU. Ejemplos Solicitud de pedido creadaPaso de aprobación aprobadoSolicitud de pedido rechazadaPedido de compra creado
	Sistema de origen SourceSystem	Identifica el sistema de origen del que se extrajeron los datos.
Descripción Este atributo especifica el origen de los datos del proceso, por ejemplo, «SAP ECC Production» o «S4HANA QA». Suele ser un valor estático que se añade durante la extracción de datos para aportar contexto, especialmente en entornos con varios sistemas de origen. En el análisis de procesos, permite distinguir los datos de distintas fuentes y evita que los resultados se distorsionen al combinar datos de entornos de producción, pruebas o desarrollo. Es un metadato fundamental para la gobernanza de datos y la trazabilidad. Por qué es importante Aporta contexto esencial sobre el origen de los datos, garantiza la trazabilidad y permite analizar varios sistemas. Dónde obtenerlo Suele ser un valor estático que se añade durante el proceso de extracción, transformación y carga de datos (ETL). Ejemplos SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Última actualización de datos LastDataUpdate	Marca de tiempo de la actualización o extracción más reciente de datos del sistema de origen.
Descripción Este atributo indica cuándo se actualizó el conjunto de datos por última vez. Es una marca de tiempo estática que se aplica a todo el conjunto de datos en cada carga y sirve como referencia para conocer la actualidad del análisis. Para tomar decisiones fundamentadas en cualquier análisis o Dashboard de Process Mining, es fundamental saber qué tan recientes son los datos. Este atributo permite que todas las partes interesadas conozcan el período que abarcan los datos que consultan y evita que se saquen conclusiones a partir de información desactualizada. Por qué es importante Indica qué tan recientes son los datos, algo fundamental para que el análisis del proceso sea pertinente y preciso. Dónde obtenerlo Es un valor estático que representa la marca de tiempo de la extracción de datos y se añade durante el proceso ETL. Ejemplos 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Departamento Department	Departamento del solicitante o centro de coste asociado a la solicitud de compra.
Descripción Este atributo representa la unidad de negocio o el departamento que inició la solicitud de compra. Suele obtenerse del perfil de usuario del solicitante o del centro de coste asignado a la partida de la solicitud. Analizar el proceso por departamento es fundamental para comprender las diferencias de rendimiento en la organización. Es la dimensión principal del Dashboard «Tiempo de ciclo de aprobación de solicitudes» y del KPI «Variación del tiempo de aprobación por departamento». Ayuda a identificar qué departamentos tienen procesos eficientes y cuáles podrían necesitar mejoras o recursos adicionales. Por qué es importante Permite comparar el rendimiento entre unidades de negocio y detectar cuellos de botella e inconsistencias en los procesos de cada departamento. Dónde obtenerlo Suele obtenerse vinculando el solicitante (EBAN-AFNAM) con los datos maestros de usuario (SU01) o utilizando el centro de coste (EBKN-KOSTL) asociado a la imputación de la solicitud. Ejemplos FinanzasOperaciones de TIMarketingManufactura
	Estado de la solicitud de compra RequisitionStatus	Estado actual de tramitación de la solicitud de compra.
Descripción Este atributo indica el estado general de la solicitud en un momento determinado, por ejemplo, «En proceso de liberación», «Aprobado», «Rechazado» o «Cerrado». En SAP, suele representarse mediante un código de estado. El seguimiento del estado es esencial para comprender el resultado de las solicitudes. Permite consultar directamente el Dashboard «Resultados y tasas de rechazo de solicitudes» y KPI como «Tasa de rechazo de solicitudes» y «Tasa de retirada de solicitudes». Analizar las transiciones entre estados ayuda a detectar ineficiencias y puntos de fallo en el proceso. Por qué es importante Define el resultado de una solicitud, un dato clave para analizar las tasas de éxito, los motivos de rechazo y los puntos finales del proceso. Dónde obtenerlo El estado de tramitación se encuentra en la tabla EBAN, campo STATU. El estado de liberación está en EBAN-FRGZU. Ejemplos N (Sin editar)B (Pedido de compra creado)A (Solicitud de oferta creada)K (Cerrado)
	Nombre de usuario User	ID del usuario que realizó la actividad.
Descripción Este atributo identifica al usuario que realizó un evento, como crear una solicitud de compra, aprobar un paso o modificar un documento. En SAP, suele registrarse como un ID de usuario. El análisis por usuario ayuda a detectar necesidades de formación, evaluar el rendimiento individual y encontrar posibles fuentes de errores de entrada de datos. Es esencial para Dashboards como «Volumen de solicitudes de compra creadas por solicitante» y para comprender la distribución de la carga de trabajo y el cumplimiento de las políticas de segregación de funciones. Por qué es importante Asocia las actividades con personas concretas y permite analizar el rendimiento de los usuarios, la carga de trabajo, el cumplimiento y las necesidades de formación. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos de modificación CDHDR (campo USERNAME) para los cambios y en EBAN (campo ERNAM) para la persona creadora. Ejemplos SMITHJR.DOEUSER123
	Tipo de documento RequisitionDocumentType	Clasificación que determina el tipo y las características de la solicitud de compra.
Descripción En SAP, el tipo de documento controla varios aspectos de una solicitud de compra, como el rango de numeración, la selección de campos y el proceso de compras que sigue. Algunos ejemplos son «Solicitud de compra estándar», «Traslado de stock» y «Solicitud de compra de servicios». Este atributo es una dimensión de análisis valiosa, ya que los distintos tipos de documento suelen tener flujos de proceso y requisitos de aprobación propios. Permite segmentar los datos para comparar el rendimiento de los diferentes procesos de solicitud, algo clave para evaluar el cumplimiento e identificar oportunidades de estandarización o especialización. Por qué es importante Permite segmentar las solicitudes por categoría de proceso y realizar análisis más precisos y pertinentes. Dónde obtenerlo Se encuentra en la tabla EBAN, campo BSART. Ejemplos NBUBRV
	Valor total de la solicitud de compra TotalRequisitionValue	Valor monetario total de todas las partidas de la solicitud de compra.
Descripción Este atributo representa el importe financiero total de la solicitud de compra. El valor suele ser un factor clave para determinar el flujo de aprobación requerido: las solicitudes de mayor importe suelen necesitar una revisión más exhaustiva y más pasos de aprobación. Analizar las solicitudes por valor es fundamental para comprender cómo influye el impacto financiero en el comportamiento del proceso. Permite descubrir si las solicitudes de mayor importe tardan más en aprobarse, se rechazan con más frecuencia o siguen rutas distintas. También es una métrica fundamental para evaluar el volumen financiero del proceso de compras. Por qué es importante Ayuda a relacionar el comportamiento del proceso con el impacto financiero, algo esencial para el análisis de riesgos y para comprender la complejidad de las aprobaciones. Dónde obtenerlo Suma del valor de todas las partidas. El valor de cada partida se encuentra en la tabla EBAN, campo GSWER. La moneda está en EBAN-WAERS. Ejemplos 1500.00250.50125000.00
	Centro Plant	Ubicación o centro de la empresa para el que se solicitan los bienes o servicios.
Descripción El centro es una unidad organizativa de la empresa que representa una ubicación física, como una fábrica, un almacén o una oficina. La solicitud especifica el centro donde se necesitan los artículos solicitados. El análisis por centro permite examinar el proceso de solicitud desde una perspectiva geográfica o por ubicación. Puede revelar diferencias de rendimiento entre centros, que podrían deberse a procedimientos locales, niveles de personal o necesidades del negocio distintos. Es una dimensión habitual en los Dashboards de rendimiento regional. Por qué es importante Aporta contexto geográfico o basado en la ubicación para identificar variaciones en los procesos y diferencias de rendimiento entre regiones. Dónde obtenerlo Se encuentra en la tabla EBAN, campo WERKS. Ejemplos 10002100DE01
	Es retrabajo IsRework	Indicador booleano que señala si la solicitud pasó por un ciclo de retrabajo, por ejemplo, si se modificó después de enviarla.
Descripción Este atributo derivado marca las actividades o los casos que implican retrabajo. Por ejemplo, una actividad «Solicitud de compra modificada» que se produzca después de «Aprobación enviada» se considera retrabajo. También puede activarse cuando un rechazo devuelve el proceso a una etapa anterior. Este indicador es esencial para el Dashboard «Análisis de modificaciones y retrabajo de solicitudes». Permite filtrar y cuantificar fácilmente el retrabajo, medir su impacto en los tiempos de ciclo generales e identificar las causas raíz de las ineficiencias del proceso. Una tasa elevada de retrabajo suele indicar problemas de calidad de los datos o requisitos poco claros. Por qué es importante Ayuda a cuantificar la frecuencia y el impacto del retrabajo, y facilita la identificación y el análisis de ineficiencias y ciclos en el proceso. Dónde obtenerlo Se obtiene del registro de eventos al identificar secuencias específicas de actividades, como «Solicitud de compra modificada» después de una actividad de aprobación. Ejemplos truefalse
	Grupo de compras PurchasingGroup	Grupo de compradores responsable de adquirir los artículos solicitados.
Descripción El grupo de compras es una unidad organizativa responsable de determinadas actividades de compras. Representa al equipo de compradores que se encargará de la solicitud una vez aprobada. Este atributo permite analizar la carga de trabajo y el rendimiento de los distintos equipos de compras. Ayuda a identificar si algunos grupos generan cuellos de botella al convertir solicitudes en pedidos de compra o si gestionan ciertos tipos de solicitudes con más eficiencia que otros. Es una dimensión clave para gestionar los recursos y el rendimiento de la función de compras. Por qué es importante Asigna la responsabilidad de las compras y permite analizar la carga de trabajo y comparar el rendimiento de los distintos equipos. Dónde obtenerlo Se encuentra en la tabla EBAN, campo EKGRP. Ejemplos 001002P01
	Grupo de materiales MaterialGroup	Grupo o categoría a la que pertenecen el material o el servicio solicitado.
Descripción El grupo de materiales es una clasificación que reúne materiales o servicios con características similares y permite analizar las actividades de compras por categoría. El análisis por grupo de materiales ayuda a tomar decisiones de abastecimiento estratégico y a analizar el gasto. En Process Mining, permite descubrir si las solicitudes de ciertas categorías, como «Hardware de TI» o «Servicios profesionales», siguen rutas distintas o tardan más en aprobarse. Esta información es útil para el «Informe de calidad de los datos de solicitudes» y para comprender las variaciones del proceso según lo que se compra. Por qué es importante Permite analizar el gasto y los procesos por categoría de compras, facilita el abastecimiento estratégico y ayuda a detectar cuellos de botella específicos de cada categoría. Dónde obtenerlo Se encuentra en la tabla EBAN, campo MATKL. Ejemplos 00101L001IT-SFTWR
	ID del pedido de compra PurchaseOrderId	ID del pedido de compra creado a partir de la solicitud.
Descripción Este atributo vincula una solicitud de compra con el pedido de compra posterior que se creó para atenderla. En algunos casos, una solicitud puede dar lugar a varios pedidos de compra. Este vínculo es fundamental para analizar el traspaso entre los procesos de solicitud y de compras. Se necesita para calcular el KPI «Tiempo desde la solicitud hasta la creación del pedido de compra» y consultar el Dashboard «Demora entre la aprobación de la solicitud y la creación del pedido de compra». Comprender esta relación es clave para medir la eficiencia de todo el ciclo de compras y pagos. Por qué es importante Conecta el proceso de solicitud con el proceso de compras posterior y permite analizar las demoras en el traspaso. Dónde obtenerlo El número del pedido de compra se almacena en la tabla EBAN, campo EBELN, una vez creado. Ejemplos 450001712345000171244500017125
	ID del proveedor VendorId	Identificador único del proveedor sugerido o establecido.
Descripción Este atributo contiene el ID del proveedor preferido o establecido por contrato para el artículo solicitado. Puede estar rellenado de antemano o ser sugerido por el solicitante. Analizar las solicitudes por proveedor ayuda a evaluar cómo influye la selección anticipada de proveedores en el proceso de compras. Por ejemplo, permite comprobar si las solicitudes con un proveedor especificado se aprueban más rápido o si ciertos proveedores se asocian con tasas de rechazo más altas. Ofrece una perspectiva sobre la relación con los proveedores en las primeras etapas del proceso. Por qué es importante Aporta información sobre las relaciones con los proveedores preferidos y su efecto en la velocidad y los resultados de la tramitación de solicitudes. Dónde obtenerlo Se encuentra en la tabla EBAN, campo LIFNR (proveedor fijo). Ejemplos 100030025V9876
	Motivo del rechazo RejectionReason	Motivo indicado al rechazar una solicitud o un paso de aprobación.
Descripción Este atributo recoge la justificación del rechazo de una solicitud de compra. Durante la actividad de rechazo, la persona responsable de aprobar suele introducirla como texto libre o seleccionarla de una lista predefinida de códigos. Analizar los motivos de rechazo es fundamental para mejorar el proceso. Proporciona información útil para la acción sobre las causas por las que se rechazan las solicitudes, como incumplimientos de políticas, datos incorrectos o falta de presupuesto. Estos datos son clave para el Dashboard «Resultados y tasas de rechazo de solicitudes» y ayudan a identificar las causas raíz de las ineficiencias del proceso. Por qué es importante Permite conocer directamente por qué se rechazan las solicitudes y orientar las mejoras del proceso y la formación de los usuarios. Dónde obtenerlo Estos datos suelen almacenarse en los registros del flujo de trabajo o en el texto largo asociado al evento de rechazo. EBAN no tiene un campo estándar para este dato. Ejemplos Centro de coste incorrectoPresupuesto excedidoSolicitud duplicadaIncumplimiento de políticas
	Nombre del solicitante RequesterName	Nombre de la persona que solicitó los bienes o servicios.
Descripción Este atributo identifica a la persona que inició la solicitud de compra, es decir, quien necesita los artículos solicitados para su actividad. El seguimiento del solicitante permite analizar los patrones de solicitud por persona o grupo. El Dashboard «Volumen de solicitudes de compra creadas por solicitante» utiliza este atributo para identificar a quienes realizan muchas solicitudes, a las personas que podrían necesitar más formación o a los departamentos con una actividad de compras elevada. Ofrece una perspectiva centrada en las personas sobre el inicio del proceso. Por qué es importante Identifica a la persona responsable de iniciar el proceso y permite analizar los patrones de creación de solicitudes y orientar la formación de los usuarios. Dónde obtenerlo Se encuentra en la tabla EBAN, campo AFNAM. Ejemplos Alice WilliamsBob JohnsonCharlie Brown
	Prioridad Priority	Nivel de urgencia asignado a la solicitud de compra.
Descripción Este atributo indica la prioridad de la solicitud, que suele clasificarse como «Urgente», «Alta» o «Normal». La marca permite avisar a las personas responsables de aprobar y comprar que una solicitud requiere una tramitación más rápida. Este atributo es esencial para el Dashboard «Rendimiento de la tramitación de solicitudes urgentes» y el KPI «Eficacia de la marca de urgencia». El análisis permite comprobar si las solicitudes marcadas como urgentes se tramitan realmente más rápido que las estándar, validar la eficacia del sistema de priorización y asegurar que las necesidades críticas para el negocio se atiendan a tiempo. Por qué es importante Permite analizar si las solicitudes urgentes se tramitan más rápido y validar la eficacia de los mecanismos de priorización. Dónde obtenerlo No es un campo estándar de EBAN. Suele implementarse como campo personalizado o inferirse a partir del número de seguimiento de requisitos (EBAN-BEDNR) o de un tipo de documento específico. Ejemplos 123

Obligatorio Recomendado Opcional

Actividades de las solicitudes de compra a pago

Estos son los pasos y los hitos clave que debe registrar en el Registro de eventos para descubrir y analizar con precisión el flujo de trabajo de solicitudes.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Aprobación enviada	Esta actividad indica que la solicitud ha entrado en el flujo formal de aprobación. Normalmente se infiere cuando el estado de la solicitud cambia y requiere una primera liberación o aprobación, según la estrategia de liberación configurada.
Por qué es importante Este evento marca el inicio del tiempo de ciclo de aprobación, un KPI clave para medir la eficiencia del proceso. Identificar este punto ayuda a aislar las demoras entre la creación y el inicio de las aprobaciones formales. Dónde obtenerlo Se infiere del primer cambio de estado relacionado con la estrategia de liberación en la tabla EBAN (por ejemplo, cuando el campo FRGZU pasa del estado inicial a uno pendiente) o de la primera entrada en los registros del flujo de trabajo asociados a la solicitud. Capturar Se infiere de la primera entrada del historial de modificaciones que indica la activación de una estrategia de liberación. Tipo de evento inferred
	Pedido de compra creado	Esta actividad marca la conversión correcta de una solicitud de pedido aprobada en un documento de pedido de compra. El evento se infiere para la solicitud al encontrar una posición de pedido de compra correspondiente que haga referencia a ella.
Por qué es importante Como principal resultado satisfactorio, esta actividad concluye el proceso de solicitud y da inicio a la fase de compras. El tiempo entre «Solicitud de pedido aprobada» y este evento es un KPI clave para medir la eficiencia del traspaso. Dónde obtenerlo Se infiere al encontrar un registro en la tabla EKPO (posición del pedido de compra) cuyos campos BANFN y BNFPO coinciden con el número y la posición de la solicitud de pedido de la tabla EBAN. La fecha de creación del pedido de compra (EKKO.AEDAT) proporciona la marca de tiempo. Capturar Se infiere al vincular las tablas EBAN y EKPO y usar la fecha de creación del pedido de compra de EKKO. Tipo de evento inferred
	Solicitud de pedido aprobada	Esta actividad marca el hito en que la solicitud de pedido ha superado correctamente todos los pasos de aprobación requeridos. Se infiere cuando se aplica el código de liberación final y el indicador general de liberación (FRGZU) de la tabla EBAN pasa a un estado aprobado.
Por qué es importante Este hito clave marca el final del ciclo de aprobación y el inicio de la fase de compras. Es esencial para calcular el tiempo total de aprobación como KPI y medir las demoras en el traspaso a la creación del pedido de compra. Dónde obtenerlo Se infiere de la marca de tiempo de la entrada del historial de modificaciones en CDPOS para la tabla EBAN y el campo FRGZU, cuando este cambia al valor que representa la aprobación final. Capturar Se infiere cuando el campo del indicador de liberación final de EBAN alcanza un estado terminal de «aprobado». Tipo de evento inferred
	Solicitud de pedido creada	Esta actividad marca la creación inicial y el guardado de una solicitud de pedido por parte de una persona usuaria. El evento se registra explícitamente cuando se crea un nuevo registro en la tabla EBAN, junto con la fecha y la hora de creación.
Por qué es importante Como punto de partida del proceso, esta actividad es esencial para calcular la duración total del ciclo de vida de la solicitud y analizar el volumen de creación. Ayuda a identificar quién crea las solicitudes y cuándo. Dónde obtenerlo Este evento se obtiene de la tabla EBAN mediante los campos de fecha de creación (ERDAT) y hora de creación (UZEIT) para un ID de solicitud de pedido (BANFN). Capturar Marca de tiempo de los campos ERDAT y UZEIT de la tabla EBAN al guardar el registro por primera vez. Tipo de evento explicit
	Solicitud de pedido rechazada	Esta actividad terminal indica que la solicitud de pedido se ha rechazado definitivamente y no puede continuar. Se infiere cuando una persona aprobadora establece el indicador de liberación de la tabla EBAN en un estado final de rechazo.
Por qué es importante Esta actividad es un punto final clave del proceso y resulta esencial para calcular el KPI de tasa de rechazo de solicitudes. Analizar estos casos ayuda a comprender las causas de los fallos y el desperdicio en las compras. Dónde obtenerlo Se infiere de la marca de tiempo de la entrada del historial de modificaciones en CDPOS para la tabla EBAN y el campo FRGZU, cuando este cambia al valor que representa el rechazo final. Capturar Se infiere cuando el campo del indicador de liberación final de EBAN alcanza un estado terminal de «rechazado». Tipo de evento inferred
	Solicitud de pedido retirada	Esta actividad terminal se produce cuando quien creó la solicitud u otra persona autorizada cancela la posición al establecer un indicador de borrado. La acción queda registrada explícitamente e indica que la necesidad del negocio ya no existe o que la solicitud se creó por error.
Por qué es importante Este es un punto final clave de fallo del proceso y resulta esencial para calcular la tasa de retirada. Una tasa elevada puede indicar que los largos tiempos de aprobación obligan a las personas usuarias a abandonar las solicitudes o que existen problemas sistémicos en la planificación de la demanda. Dónde obtenerlo Esta acción explícita se registra cuando se establece el campo «Indicador de borrado» (LOEKZ) de la tabla EBAN para la posición de la solicitud. El cambio queda registrado en CDHDR y CDPOS. Capturar Entrada del historial de modificaciones creada cuando el indicador de borrado (EBAN-LOEKZ) se establece en «L». Tipo de evento explicit
	Aprobación restablecida	Indica que se ha restablecido todo el flujo de aprobación de la solicitud, a menudo debido a una modificación importante. Se infiere cuando se borra un estado de liberación que antes estaba activo, lo que obliga a reiniciar el proceso de aprobación desde el principio.
Por qué es importante Los restablecimientos de aprobación son eventos de retrabajo importantes que afectan considerablemente al tiempo de ciclo. Identificarlos permite detectar ineficiencias del proceso y el efecto posterior de las modificaciones de solicitudes en el flujo de trabajo. Dónde obtenerlo Se infiere de los registros de modificaciones (CDHDR/CDPOS) de la tabla EBAN cuando los campos de estado de liberación, como FRGZU, cambian de un estado pendiente o aprobado a uno inicial o en blanco. Capturar Se infiere de los registros de modificaciones que muestran que se han borrado los campos de la estrategia de liberación. Tipo de evento inferred
	Paso de aprobación aprobado	Representa la acción explícita de una persona autorizada que aprueba un paso de la estrategia de liberación. Esta acción se registra como un cambio en el estado de liberación de la solicitud y la acerca a la aprobación final.
Por qué es importante Hacer un seguimiento de cada aprobación es necesario para medir la duración de cada paso y analizar el desempeño de las distintas personas aprobadoras. Es fundamental para comprender el cumplimiento del flujo de trabajo. Dónde obtenerlo Se obtiene de los registros de modificaciones (CDHDR/CDPOS) de los campos de estado de liberación de la tabla EBAN. La acción de aprobación realizada mediante la transacción ME54N u otro código de transacción similar genera este cambio registrado. Capturar Entrada del historial de modificaciones creada cuando una persona aprobadora ejecuta una transacción de liberación. Tipo de evento explicit
	Paso de aprobación iniciado	Indica que la solicitud está pendiente de la acción de una persona aprobadora o un grupo de aprobación específicos, según lo definido en la estrategia de liberación. Este evento se infiere cuando el estado de la solicitud indica que está a la espera de un código de liberación determinado.
Por qué es importante Esta actividad permite analizar en detalle cada paso de la cadena de aprobación. Ayuda a identificar qué personas aprobadoras o etapas provocan las demoras más largas. Dónde obtenerlo Se infiere al hacer un seguimiento de la secuencia de cambios en los campos de estado de liberación de la tabla EBAN. Cada cambio a un nuevo estado pendiente marca el inicio de un paso de aprobación. Capturar Se infiere de los cambios de estado que indican que un nuevo código de liberación está activo y pendiente de aprobación. Tipo de evento inferred
	Paso de aprobación rechazado	Una persona autorizada ha rechazado explícitamente un paso de la estrategia de liberación. Por lo general, la solicitud se devuelve a quien la creó para que la modifique. Esta acción se registra como un cambio en el estado de liberación de la solicitud.
Por qué es importante Los rechazos son una de las principales causas de retrabajo y demoras en el proceso. Analizar su frecuencia y sus causas ayuda a identificar malentendidos sobre las políticas, problemas de calidad de los datos o pasos de aprobación ineficientes. Dónde obtenerlo Se obtiene de los registros de modificaciones (CDHDR/CDPOS) de los campos de estado de liberación de la tabla EBAN. Una acción de rechazo mediante la transacción ME54N u otra similar genera el cambio de estado correspondiente. Capturar Entrada del historial de modificaciones creada cuando una persona aprobadora ejecuta una acción de rechazo. Tipo de evento explicit
	Solicitud de pedido bloqueada	Representa la acción explícita de bloquear una posición de una solicitud de pedido para impedir que se convierta en un pedido de compra. El bloqueo se establece mediante un indicador específico en la posición de la solicitud.
Por qué es importante Un bloqueo indica un posible problema o una pausa temporal en las compras. Hacer un seguimiento de estos eventos ayuda a identificar cuellos de botella en los que las solicitudes se aprueban, pero no se tramitan de inmediato. Dónde obtenerlo Se obtiene de un cambio en el campo «Indicador de bloqueo» (EBAKZ) de la tabla EBAN. El cambio queda registrado en CDHDR y CDPOS. Capturar Evento registrado en las tablas de modificaciones cuando se establece el campo EBAN-EBAKZ. Tipo de evento explicit
	Solicitud de pedido cerrada	Representa el cierre definitivo de una posición de solicitud de pedido e indica que no se espera ningún otro procesamiento. Se infiere cuando la posición se ha convertido por completo en un pedido de compra y se ha completado, o cuando se marca manualmente como cerrada.
Por qué es importante Este evento establece un punto final definitivo para las solicitudes completadas que no necesariamente se han eliminado. Permite calcular con precisión la duración del ciclo de vida de las solicitudes atendidas correctamente. Dónde obtenerlo Se infiere del indicador «Cerrado» (EBAKZ con el valor «S» u otro valor configurado) de la tabla EBAN. El sistema suele establecer este estado automáticamente cuando la conversión a pedido de compra y la recepción de mercancías se completan. Capturar Se infiere del cambio de estado del campo EBAN-EBAKZ a un valor de «cerrado». Tipo de evento inferred
	Solicitud de pedido modificada	Representa cualquier modificación de una solicitud de pedido después de su creación inicial, como cambiar la cantidad, el precio o el material. Estos cambios se registran en las tablas de historial de modificaciones de SAP, que ofrecen un registro de auditoría detallado.
Por qué es importante Hacer un seguimiento de las modificaciones es fundamental para identificar ciclos de retrabajo y problemas de calidad de los datos. Una frecuencia elevada de modificaciones puede indicar que los requisitos iniciales no estaban claros o que falta formación para las personas usuarias, lo que provoca demoras en el proceso. Dónde obtenerlo Se obtiene de las tablas de historial de modificaciones CDHDR (cabecera) y CDPOS (posición), donde la clase de objeto es EINKBELEG y el ID de objeto es el número de solicitud de pedido. Es posible analizar los cambios en campos específicos. Capturar Evento registrado en las tablas de modificaciones CDHDR y CDPOS para el documento de solicitud de pedido. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de SAP ECC

Pasos

Conceda acceso a la base de datos: Antes de comenzar, asegúrese de tener acceso de solo lectura a la base de datos subyacente de SAP ECC. Necesitará credenciales específicas (nombre de usuario, contraseña, host y puerto). Este nivel de acceso no es estándar y debe contar con la aprobación de los equipos de SAP Basis y seguridad.
Identifique el esquema de SAP: Conéctese a la base de datos con un cliente SQL estándar, como DBeaver, Toad o SQL Developer. Deberá identificar el esquema de SAP donde se almacenan las tablas, que suele llamarse SAPSR3 o SAPR3.
Prepare la consulta SQL: Utilice la consulta SQL completa que se proporciona en este documento. Está diseñada para extraer todas las actividades y los atributos necesarios mediante la unión de tablas de datos maestros y del historial de modificaciones.
Configure los parámetros de la consulta: Localice los valores de marcador de posición en la consulta y sustitúyalos por los requisitos específicos de su sistema y su negocio. Entre los principales se encuentran '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' y '{document_types}'.
Adapte la sintaxis a la base de datos: La consulta proporcionada utiliza una sintaxis SQL habitual. Sin embargo, es posible que deba hacer pequeños ajustes en las funciones para crear marcas de tiempo, como TO_TIMESTAMP, o para manipular cadenas, según la base de datos que utilice, por ejemplo, Oracle, SQL Server, DB2 o HANA.
Ejecute la extracción: Ejecute la consulta personalizada en su cliente SQL. Si el conjunto de datos es grande, se recomienda hacerlo fuera de las horas de mayor actividad para evitar afectar el rendimiento del sistema.
Revise los resultados preliminares: Cuando termine la consulta, compruebe brevemente que el resultado incluya las columnas esperadas (PurchaseRequisitionId, ActivityName, EventTime, etc.) y que haya filas para distintas actividades.
Exporte a CSV: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Asegúrese de que utilice la codificación UTF-8 para evitar problemas con caracteres especiales.
Prepare la carga: Compruebe que los encabezados de las columnas del CSV coincidan exactamente con los alias definidos en la consulta SQL. El archivo debe presentar los datos del Registro de eventos de forma tabular y ordenada.
Cargue el archivo en ProcessMind: Cargue el archivo CSV final en su proyecto de ProcessMind para analizar y visualizar los datos.

Configuración

Conexión a la base de datos: Se requiere una conexión directa a la base de datos de SAP ECC. Necesitará el nombre de host, el puerto, el nombre de la base de datos y las credenciales de usuario correspondientes.
Esquema de SAP: Debe conocer el nombre del esquema que contiene las tablas de SAP, por ejemplo, SAPSR3. La consulta debe ejecutarse en el contexto de este esquema.
Intervalo de fechas: Para controlar el rendimiento y el volumen de datos, es fundamental filtrar por un intervalo de fechas específico. Se recomienda comenzar con un período de entre 3 y 6 meses. Configure los marcadores de posición '{start_date}' y '{end_date}' con el formato YYYYMMDD.
Filtros organizativos: Para orientar mejor el análisis, filtre los datos por código de sociedad (BUKRS) y tipo de documento de solicitud de compra (BSART). Sustituya los marcadores de posición '{company_codes}' y '{document_types}' por listas de valores separados por comas, por ejemplo, '1000','2000'.
Requisitos previos: Este método requiere la aprobación de los equipos de SAP Basis y seguridad para obtener credenciales de acceso directo a la base de datos. No es una actividad habitual para usuarios finales.
Consideraciones de rendimiento: La consulta une tablas del historial de modificaciones (CDHDR, CDPOS), que pueden ser muy grandes. Sin los filtros adecuados, la consulta puede tardar y consumir muchos recursos del sistema. Ejecútela siempre con un intervalo de fechas restrictivo y otros filtros.

Consulta de ejemplo sql

WITH REQUISITION_BASE AS (
    SELECT 
        EBAN.MANDT,
        EBAN.BANFN,
        EBAN.BNFPO,
        EBAN.BSART AS RequisitionDocumentType,
        EBAN.ERNAM,
        EBAN.ERDAT,
        EBAN.ERZET,
        EBAN.FRGZU AS CurrentRequisitionStatus,
        EBAKN.KOSTL AS Department,
        EBAKN.GSWRT
    FROM EBAN
    LEFT JOIN EBAKN ON EBAN.MANDT = EBAKN.MANDT AND EBAN.BANFN = EBAKN.BANFN AND EBAN.BNFPO = EBAKN.BNFPO
    WHERE EBAN.ERDAT BETWEEN '{start_date}' AND '{end_date}'
      AND EBAN.BUKRS IN ('{company_codes}')
      AND EBAN.BSART IN ('{document_types}')
),
REQUISITION_AGG AS (
    SELECT 
        MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department,
        SUM(GSWRT) AS TotalRequisitionValue
    FROM REQUISITION_BASE
    GROUP BY MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department
)
-- 1. Requisition Created
SELECT
    R.BANFN AS PurchaseRequisitionId,
    'Requisition Created' AS ActivityName,
    TO_TIMESTAMP(R.ERDAT || R.ERZET, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    R.ERNAM AS User,
    R.Department AS Department,
    R.CurrentRequisitionStatus AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM REQUISITION_AGG R

UNION ALL

-- 2. Requisition Amended, Approval Steps, Status Changes from Change Logs
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    CASE 
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW > C.VALUE_OLD THEN 'Approval Step Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW < C.VALUE_OLD THEN 'Approval Step Rejected'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_approval_status_code}' THEN 'Requisition Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_rejection_status_code}' THEN 'Requisition Rejected'
        WHEN C.FNAME = 'FRGSX' AND C.VALUE_OLD IS NOT NULL AND C.VALUE_NEW IS NULL THEN 'Approval Reset'
        WHEN C.FNAME = 'FRGZU' AND C.CHNGIND = 'U' AND C.TCODE LIKE 'ME54%' THEN 'Approval Submitted' 
        WHEN C.FNAME = 'LOEKZ' AND C.VALUE_NEW IN ('L', 'X') THEN 'Requisition Withdrawn'
        WHEN C.FNAME = 'EBAKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Blocked'
        WHEN C.FNAME = 'STATU' AND C.VALUE_NEW = 'B' THEN 'Purchase Order Created'
        WHEN C.FNAME = 'EREKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Closed'
        ELSE 'Requisition Amended'
    END AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    C.VALUE_NEW AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF'
  AND C.UDATE || C.UTIME <> R.ERDAT || R.ERZET -- Exclude changes made at the exact time of creation
  AND NOT (C.TCODE IN ('ME51', 'ME51N') AND C.UDATE = R.ERDAT) -- Exclude initial creation events from being amendments

UNION ALL

-- 3. Approval Step Started (Inferred)
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    'Approval Step Started' AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    P.VALUE_OLD AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF' AND P.FNAME = 'FRGZU' AND P.CHNGIND = 'U'
  AND P.VALUE_OLD IS NOT NULL AND P.VALUE_NEW IS NOT NULL AND P.VALUE_NEW > P.VALUE_OLD; -- This logic infers that a step starts just before it is approved

Pasos

Configure el entorno de Python: Asegúrese de tener instalada la versión 3.6 o posterior de Python. Cree una carpeta para el proyecto y configure un entorno virtual para gestionar las dependencias. Instale las bibliotecas necesarias con pip: pip install pyrfc pandas numpy
SAP RFC SDK: Descargue SAP NetWeaver RFC SDK desde el portal de soporte de SAP. Extraiga el contenido y coloque los archivos de biblioteca (por ejemplo, sapnwrfc.dll en Windows o libsapnwrfc.so en Linux) en un directorio accesible desde la ruta del sistema o desde el script de Python.
Configure la conexión con SAP: Abra el script de Python proporcionado. Busque la sección de parámetros de conexión con SAP y sustituya los valores de marcador de posición (ashost, sysnr, client, usuario, passwd) por las credenciales reales de su sistema SAP. Asegúrese de que el usuario tenga las autorizaciones necesarias para ejecutar RFC y acceder a las tablas.
Defina los parámetros de extracción: En el script, configure las variables date_from y date_to para definir el intervalo de tiempo que desea extraer. Se recomienda comenzar con un período más corto, por ejemplo, un mes, para probar el proceso de extracción.
Ejecute el script de Python: Ejecute el script desde la terminal con el comando python your_script_name.py. El script se conectará a SAP mediante RFC, llamará a RFC_READ_TABLE para cada tabla necesaria (EBAN, EKKO, EKPO, CDHDR, CDPOS) y descargará los datos.
Recupere los datos: El script obtiene datos sin procesar de solicitudes de compra, pedidos de compra y documentos de modificación. Aplica criterios de filtrado, como intervalos de fechas y clases de objeto, para limitar el volumen de datos transferidos.
Transforme los datos localmente: Una vez descargados los datos, el script utiliza la biblioteca pandas para realizar todas las transformaciones de forma local. Procesa los datos sin procesar de las tablas para generar entradas diferenciadas del registro de eventos para cada una de las 13 actividades requeridas, como «Solicitud de compra creada», «Paso de aprobación aprobado» y «Pedido de compra creado».
Genere el registro de eventos: El script combina los eventos generados a partir de cada tabla en un único DataFrame. Calcula las marcas de tiempo de los eventos, asigna los nombres de usuario y organiza los datos con el formato requerido de ID del caso, actividad y marca de tiempo.
Asigne los atributos: Los atributos clave, como PurchaseRequisitionId, ActivityName, EventTime, Usuario y TotalRequisitionValue, se asignan a sus respectivas columnas en el DataFrame final.
Exporte los datos a CSV: El script guarda el registro de eventos final en un archivo CSV llamado event_log_pr.csv dentro del mismo directorio. El archivo está preparado para cargarse directamente en ProcessMind.
Revise y cargue los datos: Abra el archivo CSV generado para comprobar que los datos estén completos y sean correctos. Una vez validados, puede cargar el archivo en su proyecto de ProcessMind.

Configuración

Conexión a SAP: El script requiere los datos de conexión RFC directa al sistema SAP ECC, incluidos el servidor de aplicaciones, el número de sistema, el cliente, el usuario y la contraseña. El usuario indicado debe tener autorización para realizar llamadas RFC y acceso de visualización a las tablas EBAN, EKPO, EKKO, CDHDR y CDPOS.
Intervalo de fechas: La extracción se controla mediante los parámetros de fecha de inicio y de fin del script. Para las ejecuciones iniciales y para controlar el rendimiento, se recomienda extraer entre 3 y 6 meses de datos.
Filtros de tablas: Siempre que es posible, las llamadas RFC aplican filtros. Por ejemplo, las solicitudes se filtran por fecha de creación (EBAN-ERDAT) y los documentos de modificación, por fecha (CDHDR-UDATE) y clase de objeto (CDHDR-OBJECTCLAS = 'BANF').
Bibliotecas de Python: El script utiliza pyrfc para conectarse a SAP y pandas para manipular los datos. Asegúrese de instalar estas bibliotecas en su entorno de Python.
Rendimiento: La extracción de datos mediante RFC_READ_TABLE puede ser lenta con conjuntos de datos muy grandes, ya que los datos se recuperan secuencialmente, tabla por tabla. Se recomienda ejecutar la extracción fuera de las horas de mayor actividad para reducir la carga del sistema.
Tipos de documento: De forma predeterminada, el script extrae todos los tipos de documento de solicitud de compra. Para limitar el alcance, puede aplicar después de la extracción un filtro en el DataFrame de pandas basado en la columna BSART de la tabla EBAN.

Consulta de ejemplo python

import pandas as pd
from pyrfc import Connection
import datetime

class=class="hl-string">"hl-comment"># --- 1. Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your SAP system connection details
SAP_CONNECTION_PARAMS = {
    class="hl-string">"ashost": class="hl-string">"your_sap_host",      class=class="hl-string">"hl-comment"># Application server host
    class="hl-string">"sysnr": class="hl-string">"00",                 class=class="hl-string">"hl-comment"># System number
    class="hl-string">"client": class="hl-string">"100",               class=class="hl-string">"hl-comment"># Client
    class="hl-string">"user": class="hl-string">"your_rfc_user",       class=class="hl-string">"hl-comment"># RFC user
    class="hl-string">"passwd": class="hl-string">"your_password"      class=class="hl-string">"hl-comment"># Password
}

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYYMMDD format)
date_from = class="hl-string">'20230101'
date_to = class="hl-string">'20231231'

source_system = class="hl-string">"SAP ECC"
last_data_update = datetime.datetime.now().isoformat()

class=class="hl-string">"hl-comment"># --- 2. Helper function for RFC_READ_TABLE ---
def rfc_read_table(conn, table_name, fields, options):
    class="hl-string">"""Fetches data from an SAP table using RFC_READ_TABLE."""
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">',',
                           FIELDS=fields,
                           OPTIONS=options)
        
        data = result[class="hl-string">'DATA']
        if not data:
            return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

        records = [row[class="hl-string">'WA'].strip().split(class="hl-string">',') for row in data]
        df = pd.DataFrame(records, columns=[field[class="hl-string">'FIELDNAME'] for field in fields])
        class=class="hl-string">"hl-comment"># Trim whitespace from all cells
        df = df.apply(lambda x: x.str.strip() if x.dtype == class="hl-string">"object" else x)
        return df
    except Exception as e:
        print(fclass="hl-string">"Error reading table {table_name}: {e}")
        return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

class=class="hl-string">"hl-comment"># --- 3. Main Extraction Logic ---
def main():
    print(class="hl-string">"Starting SAP data extraction...")
    try:
        conn = Connection(**SAP_CONNECTION_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Failed to connect to SAP: {e}")
        return

    class=class="hl-string">"hl-comment"># --- EBAN (Purchase Requisitions) ---
    print(class="hl-string">"Extracting EBAN...")
    eban_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'BSART'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERNAM'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERDAT'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERFZEIT'}, {class="hl-string">'FIELDNAME': class="hl-string">'PREIS'}, {class="hl-string">'FIELDNAME': class="hl-string">'MENGE'}, {class="hl-string">'FIELDNAME': class="hl-string">'KOSTL'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGZU'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGSX'}]
    eban_options = [fclass="hl-string">"ERDAT >= '{date_from}' AND ERDAT <= '{date_to}'"]
    df_eban = rfc_read_table(conn, class="hl-string">'EBAN', eban_fields, eban_options)
    if df_eban.empty:
        print(class="hl-string">"No requisitions found in EBAN for the given date range. Exiting.")
        conn.close()
        return

    df_eban[class="hl-string">'PREIS'] = pd.to_numeric(df_eban[class="hl-string">'PREIS'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'MENGE'] = pd.to_numeric(df_eban[class="hl-string">'MENGE'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'TotalRequisitionValue'] = df_eban[class="hl-string">'PREIS'] * df_eban[class="hl-string">'MENGE']
    df_eban_grouped = df_eban.groupby(class="hl-string">'BANFN').agg(
        TotalRequisitionValue=(class="hl-string">'TotalRequisitionValue', class="hl-string">'sum'),
        RequisitionDocumentType=(class="hl-string">'BSART', class="hl-string">'first'),
        Department=(class="hl-string">'KOSTL', class="hl-string">'first')
    ).reset_index()
    df_eban = df_eban.merge(df_eban_grouped, on=class="hl-string">'BANFN', suffixes=(class="hl-string">'', class="hl-string">'_agg'))

    class=class="hl-string">"hl-comment"># --- EKPO/EKKO (Purchase Orders) ---
    print(class="hl-string">"Extracting EKPO and EKKO...")
    banfn_list = class="hl-string">"'" + class="hl-string">"', '".join(df_eban[class="hl-string">'BANFN'].unique()) + class="hl-string">"'"
    ekpo_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}]
    ekpo_options = [fclass="hl-string">"BANFN IN ({banfn_list})"]
    df_ekpo = rfc_read_table(conn, class="hl-string">'EKPO', ekpo_fields, ekpo_options)

    ekko_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}, {class="hl-string">'FIELDNAME': class="hl-string">'AEDAT'}]
    if not df_ekpo.empty:
        ebeln_list = class="hl-string">"'" + class="hl-string">"', '".join(df_ekpo[class="hl-string">'EBELN'].unique()) + class="hl-string">"'"
        ekko_options = [fclass="hl-string">"EBELN IN ({ebeln_list})"]
        df_ekko = rfc_read_table(conn, class="hl-string">'EKKO', ekko_fields, ekko_options)
        df_po = pd.merge(df_ekpo, df_ekko, on=class="hl-string">'EBELN')
    else:
        df_po = pd.DataFrame(columns=[class="hl-string">'BANFN', class="hl-string">'BNFPO', class="hl-string">'EBELN', class="hl-string">'AEDAT'])

    class=class="hl-string">"hl-comment"># --- CDHDR/CDPOS (Change Documents) ---
    print(class="hl-string">"Extracting CDHDR and CDPOS...")
    cdhdr_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'OBJECTID'}, {class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'USERNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'UDATE'}, {class="hl-string">'FIELDNAME': class="hl-string">'UTIME'}]
    cdhdr_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND UDATE >= '{date_from}' AND UDATE <= '{date_to}'"]
    df_cdhdr = rfc_read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_options)
    
    df_cdpos = pd.DataFrame()
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Process changenr in chunks to avoid overly long SQL queries
        changenr_chunks = [df_cdhdr[class="hl-string">'CHANGENR'][i:i + 100] for i in range(0, df_cdhdr.shape[0], 100)]
        cdpos_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'TABNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'FNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_NEW'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_OLD'}]
        cdpos_frames = []
        for chunk in changenr_chunks:
            changenr_list = class="hl-string">"'" + class="hl-string">"', '".join(chunk) + class="hl-string">"'"
            cdpos_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND CHANGENR IN ({changenr_list}) AND TABNAME = 'EBAN'"]
            cdpos_frames.append(rfc_read_table(conn, class="hl-string">'CDPOS', cdpos_fields, cdpos_options))
        if cdpos_frames:
            df_cdpos = pd.concat(cdpos_frames, ignore_index=True)

    conn.close()
    print(class="hl-string">"Extraction from SAP complete. Starting transformation...")

    class=class="hl-string">"hl-comment"># --- 4. Event Log Generation ---
    events = []

    class=class="hl-string">"hl-comment"># Activity: Requisition Created
    df_created = df_eban[[class="hl-string">'BANFN', class="hl-string">'ERNAM', class="hl-string">'ERDAT', class="hl-string">'ERFZEIT', class="hl-string">'RequisitionDocumentType', class="hl-string">'TotalRequisitionValue', class="hl-string">'Department']].drop_duplicates(subset=[class="hl-string">'BANFN'])
    for _, row in df_created.iterrows():
        events.append({
            class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': fclass="hl-string">"{row['ERDAT']} {row['ERFZEIT']}",
            class="hl-string">'User': row[class="hl-string">'ERNAM'],
            class="hl-string">'RequisitionDocumentType': row[class="hl-string">'RequisitionDocumentType'],
            class="hl-string">'TotalRequisitionValue': row[class="hl-string">'TotalRequisitionValue'],
            class="hl-string">'Department': row[class="hl-string">'Department'],
            class="hl-string">'RequisitionStatus': class="hl-string">'Created'
        })

    class=class="hl-string">"hl-comment"># Merge change documents
    df_changes = pd.DataFrame()
    if not df_cdhdr.empty and not df_cdpos.empty:
        df_changes = pd.merge(df_cdhdr, df_cdpos, on=class="hl-string">'CHANGENR')
        df_changes[class="hl-string">'PurchaseRequisitionId'] = df_changes[class="hl-string">'OBJECTID'].str[:10]
        df_changes[class="hl-string">'EventTime'] = pd.to_datetime(df_changes[class="hl-string">'UDATE'] + class="hl-string">' ' + df_changes[class="hl-string">'UTIME'], format=class="hl-string">'%Y%m%d %H%M%S')

    if not df_changes.empty:
        class=class="hl-string">"hl-comment"># Activities from Change Logs
        for _, row in df_changes.iterrows():
            activity = None
            status = None

            class=class="hl-string">"hl-comment"># Approval-related activities
            if row[class="hl-string">'FNAME'] in [class="hl-string">'FRGZU', class="hl-string">'FRGSX']:
                if row[class="hl-string">'VALUE_OLD'].strip() == class="hl-string">'' and row[class="hl-string">'VALUE_NEW'].strip() != class="hl-string">'':
                    activity = class="hl-string">'Approval Submitted'
                    status = class="hl-string">'In Approval'
                elif row[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    activity = class="hl-string">'Approval Reset'
                    status = class="hl-string">'In Progress'
                else:
                    class=class="hl-string">"hl-comment"># Logic to differentiate approve/reject might need config specifics
                    activity = class="hl-string">'Approval Step Approved' if row[class="hl-string">'VALUE_NEW'] > row[class="hl-string">'VALUE_OLD'] else class="hl-string">'Approval Step Rejected'
                    status = class="hl-string">'In Approval'
            class=class="hl-string">"hl-comment"># Final Approval/Rejection
            elif row[class="hl-string">'FNAME'] == class="hl-string">'FRGZU':
                 class=class="hl-string">"hl-comment"># This logic assumes specific final approval/rejection codes. Adjust if needed.
                 if row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'X', class="hl-string">'Y', class="hl-string">'Z']: class=class="hl-string">"hl-comment"># Placeholder for final approval states
                     activity = class="hl-string">'Requisition Approved'
                     status = class="hl-string">'Approved'
                 elif row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'R', class="hl-string">'S']: class=class="hl-string">"hl-comment"># Placeholder for final rejection states
                     activity = class="hl-string">'Requisition Rejected'
                     status = class="hl-string">'Rejected'
            class=class="hl-string">"hl-comment"># Other Amendments
            elif row[class="hl-string">'FNAME'] not in [class="hl-string">'FRGZU', class="hl-string">'FRGSX', class="hl-string">'LOEKZ', class="hl-string">'EBAKZ']:
                activity = class="hl-string">'Requisition Amended'
                status = class="hl-string">'Amended'
            class=class="hl-string">"hl-comment"># Blocked
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'B':
                activity = class="hl-string">'Requisition Blocked'
                status = class="hl-string">'Blocked'
            class=class="hl-string">"hl-comment"># Withdrawn
            elif row[class="hl-string">'FNAME'] == class="hl-string">'LOEKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Withdrawn'
                status = class="hl-string">'Withdrawn'
            class=class="hl-string">"hl-comment"># Closed
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Closed'
                status = class="hl-string">'Closed'

            if activity:
                events.append({
                    class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'PurchaseRequisitionId'],
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': row[class="hl-string">'EventTime'].strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'User': row[class="hl-string">'USERNAME'],
                    class="hl-string">'RequisitionStatus': status
                })

    class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
    if not df_po.empty:
        df_po_first = df_po.sort_values(class="hl-string">'AEDAT').drop_duplicates(class="hl-string">'BANFN', keep=class="hl-string">'first')
        for _, row in df_po_first.iterrows():
            events.append({
                class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': fclass="hl-string">"{row['AEDAT']} 00:00:00", class=class="hl-string">"hl-comment"># EKKO only has date
                class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User info not directly in EKKO/EKPO for this event
                class="hl-string">'RequisitionStatus': class="hl-string">'PO Created'
            })
            
    class=class="hl-string">"hl-comment"># Dummy activities for Approval Step Started (inferred before approval)
    class=class="hl-string">"hl-comment"># This is a simplified inference. Real logic can be much more complex.
    approval_events = [e for e in events if e[class="hl-string">'ActivityName'] == class="hl-string">'Approval Step Approved']
    for event in approval_events:
        event_time = pd.to_datetime(event[class="hl-string">'EventTime'])
        class=class="hl-string">"hl-comment"># Infer class="hl-string">'started' event one minute before class="hl-string">'approved' for demonstration
        start_time = event_time - datetime.timedelta(minutes=1)
        events.append({
            class="hl-string">'PurchaseRequisitionId': event[class="hl-string">'PurchaseRequisitionId'],
            class="hl-string">'ActivityName': class="hl-string">'Approval Step Started',
            class="hl-string">'EventTime': start_time.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
            class="hl-string">'User': None, class=class="hl-string">"hl-comment"># Approver user is not known until they approve
            class="hl-string">'RequisitionStatus': class="hl-string">'In Approval'
        })

    class=class="hl-string">"hl-comment"># --- 5. Final Formatting ---
    if not events:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df_event_log = pd.DataFrame(events)
    df_event_log = df_event_log.merge(df_eban_grouped, left_on=class="hl-string">'PurchaseRequisitionId', right_on=class="hl-string">'BANFN', how=class="hl-string">'left')
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log = df_event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Fill forward attributes within each case
    df_event_log[class="hl-string">'RequisitionDocumentType'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'RequisitionDocumentType_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'TotalRequisitionValue'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'TotalRequisitionValue_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'Department'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'Department_agg'].transform(lambda x: x.ffill().bfill())

    class=class="hl-string">"hl-comment"># Add standard columns
    df_event_log[class="hl-string">'SourceSystem'] = source_system
    df_event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and rename final columns
    final_columns = {
        class="hl-string">'PurchaseRequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName': class="hl-string">'ActivityName',
        class="hl-string">'EventTime': class="hl-string">'EventTime',
        class="hl-string">'SourceSystem': class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate': class="hl-string">'LastDataUpdate',
        class="hl-string">'User': class="hl-string">'User',
        class="hl-string">'Department': class="hl-string">'Department',
        class="hl-string">'RequisitionStatus': class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionDocumentType': class="hl-string">'RequisitionDocumentType',
        class="hl-string">'TotalRequisitionValue': class="hl-string">'TotalRequisitionValue'
    }
    df_event_log = df_event_log[final_columns.keys()].rename(columns=final_columns)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df_event_log.to_csv(class="hl-string">'event_log_pr.csv', index=False)
    print(class="hl-string">"Event log successfully created: event_log_pr.csv")

if __name__ == class="hl-string">'__main__':
    main()

¿Todo listo para comenzar?

Utilice este Template para estructurar correctamente los datos para Process Mining y obtener información útil sobre el proceso de solicitudes de compra a pago. Comience hoy mismo a optimizar sus procesos.

Volver a la guía de mejora

Descargar Template

Mejore la eficiencia de las solicitudes de compra a pago. Comience su prueba ahora.

Detecte y resuelva cuellos de botella en las solicitudes de compra a pago y reduzca el tiempo de ciclo un 30 % o más.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Acceso gratuito durante 14 días.

Su Template de datos para solicitudes de compra a pago

Su Template de datos para solicitudes de compra a pago

Atributos de las solicitudes de compra a pago

Actividades de las solicitudes de compra a pago

Guías de extracción

Consulta SQL directa a la base de datos subyacente de SAP ECC

Pasos

Configuración

Consulta de ejemplo sql

Script de Python que utiliza SAP RFC para extraer tablas

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Mejore la eficiencia de las solicitudes de compra a pago. Comience su prueba ahora.