Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta
Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta
- Atributos recomendados para recopilar
- Actividades clave que debe registrar
- Guía para extraer datos de SAP ECC
Atributos del proceso de pedido a cobro: procesamiento de pedidos de venta
| Nombre | Descripción | ||
|---|---|---|---|
| Pedido de ventas SalesOrder | Identificador único de un documento de pedido de ventas, que se utiliza como caso principal para hacer el seguimiento de todo el proceso de pedido a cobro. | ||
| Descripción El pedido de ventas es el documento central del proceso de ventas y representa la solicitud de productos o servicios de un cliente. Contiene toda la información necesaria para gestionar esa solicitud de principio a fin. En Process Mining, este atributo se utiliza como ID del caso. Cada número de pedido de ventas único representa una instancia completa del proceso. Analizar los procesos por pedido de ventas permite seguir todo su ciclo de vida, medir los tiempos de ciclo e identificar variaciones en cada pedido de cliente. Por qué es importante Es la clave esencial para vincular todas las actividades y eventos relacionados, lo que permite analizar de principio a fin el recorrido de cada pedido de cliente. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo VBELN. Ejemplos 900001234590000123469000012347 | |||
| Actividad Activity | Nombre de un paso o evento empresarial específico que tuvo lugar durante el proceso del pedido de ventas. | ||
| Descripción Este atributo describe un paso del proceso de pedido a cobro, como «Pedido de ventas creado», «Entrega creada» o «Pago recibido». Estas actividades son los elementos que permiten reconstruir el flujo del proceso de cada pedido de ventas. Analizar la secuencia y el momento en que ocurren estas actividades es fundamental en Process Mining. Permite visualizar el mapa del proceso, identificar cuellos de botella, descubrir variantes del proceso y comprobar el cumplimiento de un modelo estándar. Por lo general, las actividades se derivan de una combinación de eventos de creación de documentos, cambios de estado o códigos de transacción específicos registrados en el sistema. Por qué es importante Las actividades son la base del mapa del proceso y permiten visualizar y analizar el flujo, las desviaciones y los cuellos de botella. Dónde obtenerlo Este atributo se deriva de los datos y suele generarse durante la extracción al asignar nombres de actividad fáciles de entender a los códigos de transacción de SAP (T-Codes), los cambios de estado de los documentos (por ejemplo, en las tablas VBUK y VBUP) o los registros de cambios (tablas CDHDR y CDPOS). Ejemplos Pedido de venta creadoEntrega creadaSalida de mercancías registradaFactura creadaPago recibido | |||
| Hora de inicio StartTime | Marca de tiempo que indica cuándo comenzó una actividad o un evento. | ||
| Descripción La hora de inicio, también conocida como marca de tiempo del evento, registra la fecha y hora exactas en que tuvo lugar una actividad específica. Por ejemplo, indica cuándo se creó un pedido de ventas, cuándo se contabilizó la salida de mercancías o cuándo se contabilizó una factura. Esta marca de tiempo es fundamental para todos los análisis temporales de Process Mining. Se utiliza para calcular los tiempos de ciclo entre actividades, medir la duración total de un caso e identificar retrasos o cuellos de botella. Las marcas de tiempo precisas son esenciales para los Dashboards de análisis del rendimiento, como los que supervisan las entregas a tiempo o los tiempos de entrega del cumplimiento de pedidos. Por qué es importante Este atributo es fundamental para calcular todas las métricas de rendimiento, como los tiempos de ciclo y las duraciones, que permiten identificar cuellos de botella. Dónde obtenerlo Este atributo compuesto suele derivarse de la combinación de un campo de fecha (por ejemplo, ERDAT) y uno de hora (por ejemplo, ERZET) de distintas tablas de SAP, como VBAK (pedido de ventas), LIKP (entrega) y VBRK (factura). Ejemplos 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Sistema de origen SourceSystem | Identifica el sistema de origen del que se extrajeron los datos. | ||
| Descripción Este atributo especifica el sistema de origen, por ejemplo, el nombre de una instancia concreta de SAP ECC o el número de cliente. Aporta contexto a los datos, especialmente en entornos con varios sistemas de producción o con datos de sistemas heredados. En los análisis, se utiliza para filtrar o segmentar los datos según su origen. Esto resulta especialmente útil para comparar procesos entre distintos sistemas o durante proyectos de migración, a fin de garantizar la integridad y la coherencia de los datos. Por qué es importante Aporta contexto esencial, sobre todo en entornos con varios sistemas, permite comparar procesos y facilita el seguimiento del origen de los datos. Dónde obtenerlo Este valor suele añadirse durante la extracción de datos y, a menudo, es un valor estático que representa el ID del sistema SAP (SAPSID) o el cliente (MANDT). Ejemplos ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Última actualización de datos LastDataUpdate | 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 de un evento o caso. Permite saber si los datos analizados están actualizados. En los Dashboards y los informes, esta información ayuda a comprender la actualidad de los datos. Permite confirmar si el análisis refleja el estado más reciente de las operaciones o si se basa en datos anteriores, y así establecer expectativas claras sobre su vigencia. Por qué es importante Permite saber si los datos están actualizados, algo esencial para tomar decisiones oportunas y fundamentadas a partir del análisis de Process Mining. Dónde obtenerlo Este atributo de metadatos lo completa la herramienta o el proceso de extracción de datos durante la ingesta. No se almacena en las tablas de origen de SAP. Ejemplos 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Bloqueo de entrega DeliveryBlock | Código que indica si un pedido de ventas está bloqueado para la entrega, lo que impide crear el documento de entrega. | ||
| Descripción El bloqueo de entrega es un estado que se asigna a un pedido de ventas, en la cabecera o en una partida, para detener temporalmente el proceso antes de la entrega. Una persona usuaria puede establecerlo manualmente o el sistema puede hacerlo automáticamente por motivos como un límite de crédito excedido o datos incompletos. Este atributo es clave para el Dashboard «Análisis de bloqueos y retrabajo de pedidos de ventas». Analizar la frecuencia, la duración y los motivos de los bloqueos de entrega ayuda a identificar los principales cuellos de botella del proceso de cumplimiento. Reducir estos bloqueos es fundamental para mejorar las entregas a tiempo y el tiempo de ciclo general. Por qué es importante Permite identificar directamente los cuellos de botella del proceso de cumplimiento. Analizar por qué y con qué frecuencia se bloquean los pedidos es fundamental para mejorar la eficiencia del flujo. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo LIFSK. Ejemplos 0102Z1 | |||
| Importe neto NetAmount | Valor total del pedido de ventas, sin incluir impuestos ni descuentos en el nivel de cabecera. | ||
| Descripción El importe neto representa el valor monetario del pedido de ventas. Es una métrica financiera clave asociada a cada instancia del proceso. Este atributo es esencial para analizar los procesos según su valor. Permite priorizar las iniciativas de mejora y centrarse en los pedidos de mayor valor. Los analistas pueden relacionar problemas del proceso, como retrasos o retrabajo, con su impacto financiero, lo que ayuda a fundamentar mejor los cambios. Por ejemplo, permite analizar si los pedidos de mayor valor se procesan con más o menos eficiencia que los de menor valor. Por qué es importante Permite analizar los procesos según su valor y priorizar las mejoras en los pedidos con mayor impacto financiero para la empresa. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo NETWR. Ejemplos 1500.0012550.75850.50 | |||
| Motivo de rechazo RejectionReason | Código que indica por qué se rechazó o canceló una partida del pedido de ventas. | ||
| Descripción El motivo de rechazo explica por qué no se completó un pedido de ventas o una partida específica. Puede deberse a la cancelación del cliente, a la falta de disponibilidad del producto o a otros motivos comerciales. Este atributo es esencial para el Dashboard «Tendencias de cancelación de pedidos de ventas». Analizar los motivos de rechazo más frecuentes permite identificar las causas principales de la pérdida de ventas. Esta información puede impulsar mejoras en la gestión del inventario, la estrategia de precios o la comunicación con los clientes para reducir las cancelaciones de pedidos. Por qué es importante Explica por qué se cancelan los pedidos y permite analizar las causas principales para reducir la pérdida de ventas y mejorar la precisión de las previsiones. Dónde obtenerlo Se encuentra en la tabla de datos de partidas del documento de ventas (VBAP), en el campo ABGRU. Ejemplos 0215Z5 | |||
| Número de cliente CustomerNumber | Identificador único del cliente que realizó el pedido de ventas. | ||
| Descripción Este atributo representa al «destinatario de la factura», es decir, la cuenta del cliente principal asociada al pedido de ventas. Vincula la transacción con un cliente específico de los datos maestros. Analizar los datos por número de cliente permite segmentar el proceso para comprender el comportamiento y el rendimiento de cada cliente. Ayuda a responder preguntas como qué clientes tienen los tiempos de ciclo más largos, más retrabajo o más cambios de pedido. Esto es fundamental para mejorar la gestión de las relaciones con los clientes y los niveles de servicio. Por qué es importante Permite analizar los procesos desde la perspectiva del cliente, detectar problemas que afectan a clientes específicos y medir el rendimiento para cada uno. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo KUNNR. Ejemplos 100234100567200112 | |||
| Número de material MaterialNumber | Identificador único del producto o servicio que se vende. | ||
| Descripción El número de material identifica el artículo específico de una partida del pedido de ventas. Como un pedido puede incluir varios materiales, este atributo suele analizarse en el nivel de partida. Analizar el proceso por número de material ayuda a detectar problemas específicos de cada producto. Puede revelar si ciertos productos se asocian con tiempos de cumplimiento más largos, más bloqueos de entrega o más discrepancias en las facturas. Esto es fundamental para que los equipos de cadena de suministro y gestión de productos optimicen el proceso para cada línea de productos. Por qué es importante Permite analizar los procesos por producto y descubrir cuáles se asocian con ineficiencias, como retrasos, bloqueos o retrabajo. Dónde obtenerlo Se encuentra en la tabla de datos de partidas del documento de ventas (VBAP), en el campo MATNR. Ejemplos FG-1001-ARAW-205BSERV-INSTALL | |||
| Organización de ventas SalesOrganization | Unidad organizativa responsable de la venta de productos o servicios. | ||
| Descripción La organización de ventas es una entidad organizativa clave de SAP que estructura la empresa según sus necesidades comerciales. Se encarga de negociar las condiciones de venta y distribuir productos y servicios. En Process Mining, este atributo es una dimensión clave para el análisis. Permite comparar el rendimiento, la eficiencia y el cumplimiento de distintas unidades de ventas, regiones o divisiones. Así se pueden identificar las buenas prácticas de las unidades con mejor rendimiento y las áreas que necesitan mejorar. Por qué es importante Permite comparar el rendimiento entre distintas unidades de negocio o regiones y evaluar la eficiencia de sus procesos y su cumplimiento. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo VKORG. Ejemplos 100025003100 | |||
| Usuario User | ID del usuario que creó o modificó por última vez el documento, o que realizó la actividad. | ||
| Descripción Este atributo registra el ID del usuario de SAP responsable de un evento concreto del proceso. Por ejemplo, identifica a la persona del equipo de ventas que creó el pedido o al personal del almacén que contabilizó la salida de mercancías. Analizar el proceso por usuario ayuda a comprender cómo se distribuye la carga de trabajo, detectar necesidades de formación e identificar diferencias en la forma en que distintas personas realizan la misma tarea. Es esencial para los Dashboards centrados en el rendimiento de los recursos, el cumplimiento y la detección de intervenciones manuales. Por qué es importante Permite conocer el rendimiento de los recursos y la carga de trabajo, ayuda a detectar desviaciones del proceso asociadas a usuarios específicos y es clave para el cumplimiento y el análisis de automatización. Dónde obtenerlo Se encuentra en muchas tablas de cabecera de SAP, en el campo «Creado por» (ERNAM) o «Modificado por» (AENAM), por ejemplo, en VBAK, LIKP y VBRK. Ejemplos CBURKEJSMITHRWILLIAMS | |||
| Condiciones de envío ShippingConditions | Define la estrategia general para enviar los productos al cliente. | ||
| Descripción Las condiciones de envío determinan cómo se enviará un pedido, por ejemplo, mediante envío estándar, exprés o recogida. Se acuerdan con el cliente e influyen en la planificación logística. Este atributo se utiliza en el análisis «Eficiencia y coste del método de envío». Al segmentar el proceso por condiciones de envío, las empresas pueden analizar si ciertos métodos suelen sufrir más retrasos o tienen tiempos de ciclo más largos. Estos datos ayudan a optimizar la logística y a gestionar las expectativas de los clientes sobre los tiempos de entrega. Por qué es importante Permite analizar el rendimiento logístico y determinar si ciertos métodos de envío se relacionan con retrasos o una mayor eficiencia. Dónde obtenerlo Se encuentra en la tabla de datos de cabecera del documento de ventas (VBAK), en el campo VSBED. Ejemplos 011020 | |||
| Entrega a tiempo IsOnTimeDelivery | Indicador booleano que señala si los productos se enviaron en la fecha de entrega confirmada o antes. | ||
| Descripción Este atributo calculado compara la fecha real de salida de mercancías con la «ConfirmedDeliveryDate» de un pedido de ventas. Si la fecha de salida es igual o anterior a la fecha confirmada, el valor es verdadero; de lo contrario, es falso. Este atributo simplifica la creación del Dashboard «Rendimiento de las entregas a tiempo» y el cálculo del KPI de porcentaje de entregas a tiempo. Permite agregar y visualizar fácilmente el rendimiento sin tener que comparar fechas sobre la marcha en cada análisis o gráfico. Así ofrece una medida clara e inmediata de la fiabilidad de las entregas. Por qué es importante Ofrece una medida clara y sencilla del rendimiento de las entregas y facilita el cálculo del KPI general de porcentaje de entregas a tiempo. Dónde obtenerlo Este atributo se calcula comparando la marca de tiempo de la actividad «Salida de mercancías» con el valor del atributo «ConfirmedDeliveryDate». Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador booleano que señala si un pedido de ventas tuvo cambios importantes o actividades de retrabajo después de su creación inicial. | ||
| Descripción Este atributo calculado identifica las instancias del proceso que tuvieron retrabajo, por ejemplo, una o más actividades de «Pedido de ventas modificado». La lógica específica para determinar qué se considera retrabajo, como un cambio de precio, cantidad o fecha de entrega, se define durante la configuración del proyecto. Este atributo es fundamental para el Dashboard «Retrabajo y frecuencia de cambios en pedidos de ventas» y para el KPI de porcentaje de retrabajo de pedidos de ventas. Simplifica el análisis al permitir filtrar y comparar directamente los pedidos que siguieron un proceso sin interrupciones con los que requirieron cambios manuales. Así se puede cuantificar el impacto del retrabajo en los tiempos de ciclo y los costes. Por qué es importante Cuantifica directamente la frecuencia del retrabajo y permite analizar sus causas y su impacto en la eficiencia general del proceso y en el tiempo de ciclo. Dónde obtenerlo Este atributo calculado se deriva del registro de eventos. La lógica comprueba si hay actividades de «Pedido de ventas modificado» o eventos de cambio específicos en las tablas CDHDR/CDPOS. Ejemplos truefalse | |||
| Estado de la comprobación de crédito CreditCheckStatus | Indica el estado de la comprobación de crédito del documento de ventas. | ||
| Descripción Este atributo muestra el resultado de la comprobación de crédito manual o automatizada de un pedido de ventas. Entre los estados habituales se encuentran «Aprobado», «Rechazado» y «Bloqueado». Es un atributo clave para el Dashboard «Análisis del tiempo de procesamiento de la comprobación de crédito». Los retrasos o bloqueos en esta etapa pueden afectar considerablemente al tiempo de ciclo total del cumplimiento de pedidos. Analizar este estado ayuda a comprender la eficiencia del proceso de gestión de crédito y su impacto en la velocidad de las ventas. Por qué es importante Afecta directamente a la velocidad de procesamiento de los pedidos. Analizar este estado ayuda a identificar cuellos de botella en la gestión de crédito que retrasan el cumplimiento de los pedidos. Dónde obtenerlo Se encuentra en la tabla de estados de cabecera del documento de ventas (VBUK) o directamente en VBAK, en el campo de estado de crédito (por ejemplo, CMGST). Ejemplos ABD | |||
| Fecha de entrega confirmada ConfirmedDeliveryDate | Fecha en la que se confirmó al cliente la entrega de los productos o servicios. | ||
| Descripción Es la fecha de entrega acordada con el cliente, según la disponibilidad de materiales y la planificación. Sirve como referencia para medir el rendimiento de las entregas. Este atributo es la base del Dashboard «Rendimiento de las entregas a tiempo» y del KPI de porcentaje de entregas a tiempo. Al comparar la fecha de entrega confirmada con la fecha real de «Salida de mercancías», el análisis determina si el pedido se entregó a tiempo, antes o después de lo previsto. Es una medida clave de la fiabilidad de la cadena de suministro y de la satisfacción del cliente. Por qué es importante Es la referencia para medir el rendimiento de las entregas a tiempo, un KPI clave para la satisfacción del cliente y la eficiencia de la cadena de suministro. Dónde obtenerlo Se encuentra en la tabla de líneas de programación del documento de ventas (VBEP), en el campo EDATU. Ejemplos 2023-05-102023-06-202023-07-01 | |||
Actividades del proceso de pedido a cobro: procesamiento de pedidos de venta
| Actividad | Descripción | ||
|---|---|---|---|
| Factura creada | Indica la creación de la factura del cliente o del documento de facturación. Este evento explícito genera un nuevo documento en el sistema e inicia la etapa de pago del proceso. | ||
| Por qué es importante Este es un hito clave que inicia el cómputo del «Tiempo del ciclo de facturación a pago». Los retrasos en la facturación afectan directamente al flujo de caja. Dónde obtenerlo Se registra en la tabla VBRK (documento de facturación: datos de cabecera) según la fecha de creación (ERDAT). El vínculo con el pedido de ventas o la entrega se encuentra en la tabla VBFA. Capturar Evento basado en la marca de tiempo de creación (ERDAT) de la tabla VBRK. Tipo de evento explicit | |||
| Pago recibido | Este evento indica que se recibió el pago del cliente y se aplicó a la factura, con lo que se salda la partida abierta de cuentas por cobrar. Es un evento contable que se infiere a partir de la compensación de un documento financiero. | ||
| Por qué es importante Este es el último paso para recibir el dinero de la venta. Marca el final del «Tiempo del ciclo de facturación a pago» y del «Tiempo de ciclo del cumplimiento de pedidos». Dónde obtenerlo Se infiere a partir de la información del documento de compensación en la tabla BSEG para la partida del cliente. Cuando se completan BSEG-AUGBL (documento de compensación) y BSEG-AUGDT (fecha de compensación), se considera que se recibió el pago. Capturar Se infiere cuando se completa la fecha de compensación (AUGDT) en la tabla BSEG para la partida de cuentas por cobrar. Tipo de evento inferred | |||
| Partida del pedido cerrada | Esta actividad marca el cierre definitivo de una partida del pedido de ventas e indica que se entregó por completo, se facturó y se considera finalizada. Se infiere a partir del estado general de la partida. | ||
| Por qué es importante Marca el evento de fin satisfactorio del proceso. Analizar cuándo se cierran las partidas ayuda a comprender la duración total del proceso y a detectar pedidos que permanecen abiertos sin necesidad. Dónde obtenerlo Se infiere a partir del campo de estado general de la tabla VBUP (documento de ventas: estado de la partida). Cuando VBUP-GBSTA es «C» (Procesado por completo), la partida se considera cerrada. Capturar Se infiere cuando el estado de la partida (VBUP-GBSTA) cambia a «C» (Procesado por completo). Tipo de evento inferred | |||
| Pedido confirmado | Esta actividad indica que el pedido de venta ha superado todas las comprobaciones iniciales y está confirmado para su preparación. Normalmente se deduce cuando el pedido ya no está bloqueado y tiene cantidades confirmadas en sus líneas de programación. | ||
| Por qué es importante Es un hito importante que separa la entrada del pedido de su preparación. Marca el inicio de la medición de los tiempos de entrega de los pedidos y del rendimiento de las entregas a tiempo. Dónde obtenerlo Se puede deducir cuando las líneas de programación de VBEP tienen una cantidad confirmada (BMENG > 0) y el pedido no está bloqueado para la entrega (por ejemplo, cuando VBUK-LIFSK está vacío). Capturar Se deduce de la confirmación de las líneas de programación (VBEP-BMENG > 0) y de la eliminación de los bloqueos a nivel de cabecera. Tipo de evento inferred | |||
| Pedido de venta creado | Indica la creación de un nuevo documento de pedido de venta. Este evento explícito se registra cuando un usuario guarda un pedido nuevo, normalmente mediante la transacción VA01 de SAP. | ||
| Por qué es importante Es el evento de inicio principal del proceso Order-to-Cash. Analizar cuándo se produce es fundamental para medir el tiempo de ciclo total y el volumen de pedidos recibidos. Dónde obtenerlo Se registra en la tabla VBAK (datos de cabecera del documento de ventas) mediante la fecha de creación (ERDAT) y la hora (ERZET). El código de transacción se almacena en VBAK-TCODE. Capturar Evento basado en la marca de tiempo de creación (ERDAT, ERZET) de la tabla VBAK. Tipo de evento explicit | |||
| Salida de mercancías registrada | Es un evento crítico en el que se transfiere la propiedad de los productos y estos salen oficialmente del almacén. Se trata de un asiento financiero explícito que crea un documento de material y actualiza el inventario. | ||
| Por qué es importante Este es el evento de «envío» y un hito clave para medir las entregas a tiempo y los tiempos de entrega de los pedidos. Activa actualizaciones financieras y marca un punto de no retorno en el proceso de preparación física. Dónde obtenerlo Creación de un documento de material (MKPF/MSEG) con un tipo de movimiento de salida de mercancías (por ejemplo, 601), vinculado al documento de entrega. Capturar Creación de un documento de material (MKPF/MSEG) con un tipo de movimiento de salida de mercancías, vinculado a la entrega. Tipo de evento explicit | |||
| Bloqueo de entrega establecido | Representa la acción de aplicar un bloqueo de entrega al pedido de venta, lo que impide crear un documento de entrega. Puede registrarse explícitamente en los historiales de modificaciones o deducirse de las tablas de estado. | ||
| Por qué es importante Esta actividad está directamente relacionada con el KPI «Tasa de bloqueos de pedidos de venta». Identificar por qué y con qué frecuencia se establecen bloqueos ayuda a descubrir las causas de las demoras en la preparación de pedidos. Dónde obtenerlo Puede encontrarse en los historiales de modificaciones (CDHDR/CDPOS) del campo VBAK-LIFSK. También puede deducirse al observar cuándo se completa el campo VBAK-LIFSK. Capturar Evento obtenido de los documentos de modificación del campo VBAK-LIFSK o VBAP-LIFSP. Tipo de evento explicit | |||
| Comprobación de crédito realizada | Indica que se ha completado la comprobación de crédito automática o manual del cliente para el pedido de venta. Normalmente se deduce de un cambio en el estado de crédito general del documento. | ||
| Por qué es importante La comprobación de crédito suele ser un cuello de botella crítico. Medir cuánto tarda este paso es esencial para el «Análisis del tiempo de tramitación de las comprobaciones de crédito» y para agilizar la tramitación de pedidos. Dónde obtenerlo Se deduce de los campos de estado de crédito de la tabla VBUK (estado de cabecera del documento de ventas). Un cambio en VBUK-CMGST de bloqueado a liberado marca esta actividad. Capturar Se deduce de los cambios en el campo de estado de crédito general (VBUK-CMGST). Tipo de evento inferred | |||
| Entrega confirmada | Esta actividad representa la confirmación de que el cliente recibió los productos. Se registra cuando se introduce en el sistema el comprobante de entrega, lo que suele actualizar el estado del documento de entrega. | ||
| Por qué es importante Este evento proporciona la fecha real de entrega, esencial para medir con precisión el «Porcentaje de entregas a tiempo» en comparación con la fecha prometida. Dónde obtenerlo Se infiere cuando el estado del comprobante de entrega (VBUK-PODAT) cambia a «C» (Confirmado). La fecha de confirmación se almacena en VLPOD-PODAT. No siempre se implementa. Capturar Se infiere a partir de la actualización del estado del comprobante de entrega (VBUK-PODAT) o de una entrada en la tabla VLPOD. Tipo de evento inferred | |||
| Entrega creada | Este evento marca la creación del documento de entrega saliente, que indica al almacén que inicie la preparación y el envío de los productos. Es un evento explícito que se registra en el flujo de documentos. | ||
| Por qué es importante Es el primer paso del proceso de preparación física del pedido. El tiempo entre la confirmación del pedido y la creación de la entrega indica con qué rapidez se inicia el proceso logístico. Dónde obtenerlo Creación de un registro en la tabla LIKP (datos de cabecera del documento de entrega de SD). El vínculo con el pedido de venta se mantiene en la tabla de flujo de documentos VBFA. Capturar Evento basado en la marca de tiempo de creación de la tabla LIKP, vinculado mediante la tabla VBFA. Tipo de evento explicit | |||
| Factura anulada | Representa la reversión de un documento de facturación creado anteriormente. Esta transacción explícita crea un nuevo documento de anulación para compensar el original. | ||
| Por qué es importante El seguimiento de las anulaciones de facturas ayuda a detectar problemas de precios, discrepancias en los envíos o errores en los datos. Esto permite calcular el KPI «Porcentaje de discrepancias en facturas». Dónde obtenerlo Evento explícito que se registra al crear un documento de facturación de anulación (VBRK-VBTYP = 'N' o 'O'). La factura original se indica en VBRK-SFAKN. Capturar Creación de un documento de anulación en VBRK que hace referencia a la factura original. Tipo de evento explicit | |||
| Pedido cancelado | Indica que un pedido de ventas se canceló antes de completarse. Por lo general, se registra al asignar un «motivo de rechazo» a todas las partidas pertinentes del pedido. | ||
| Por qué es importante Este es un punto final crítico que permite calcular directamente el KPI «Porcentaje de cancelación de pedidos». Comprender cuándo y por qué se cancelan los pedidos ayuda a detectar problemas en el proceso de ventas. Dónde obtenerlo Se infiere cuando se completa el campo VBAP-ABGRU (motivo de rechazo) para todas las partidas activas de un pedido de ventas. La fecha del cambio se encuentra en CDHDR/CDPOS. Capturar Se infiere cuando se completa el campo «Motivo de rechazo» (VBAP-ABGRU) en todas las partidas. Tipo de evento inferred | |||
| Pedido de venta modificado | Representa una modificación de un pedido de venta existente después de su creación inicial. Estos cambios se registran en las tablas específicas del historial de modificaciones (CDHDR, CDPOS) cuando se alteran campos como la cantidad, el precio o las fechas. | ||
| Por qué es importante El seguimiento de los cambios ayuda a detectar retrabajo, inestabilidad del proceso y problemas de calidad de los datos. Una frecuencia elevada de cambios puede indicar problemas en la entrada inicial del pedido y provocar demoras. Dónde obtenerlo Se obtiene de las tablas de documentos de modificación CDHDR (cabecera) y CDPOS (posición) para OBJECTCLAS = 'VERKBELEG'. Se pueden identificar la marca de tiempo y el campo modificado. Capturar Evento obtenido de las tablas de documentos de modificación (CDHDR, CDPOS) para objetos de documentos de ventas. Tipo de evento explicit | |||
| Preparación de productos completada | Indica que se han recogido físicamente del almacén todos los artículos de la entrega. Si se utiliza Warehouse Management (WM), puede deducirse del estado de la orden de traslado. | ||
| Por qué es importante Analizar el tiempo de preparación ayuda a optimizar las operaciones del almacén. Las demoras en esta etapa afectan directamente al calendario de envío y al ciclo de preparación del pedido. Dónde obtenerlo Se deduce cuando el estado de preparación de la posición de entrega en la tabla LIPS-KOSTA cambia a 'C' (preparación completa). Si WM está activo, puede deducirse de la confirmación de la orden de traslado (tablas LTAK/LTAP). Capturar Se deduce de un cambio en el estado de preparación (LIPS-KOSTA) o de la confirmación de la orden de traslado de WM. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Desarrollar el programa: Utilice la transacción SE38 o SE80 para crear un programa ABAP ejecutable. El programa contendrá toda la lógica de extracción.
- Definir la pantalla de selección: Cree una pantalla de selección para filtrar los datos. Incluya parámetros para la fecha de creación del documento de ventas (VBAK-ERDAT), la organización de ventas (VBAK-VKORG) y el tipo de documento de ventas (VBAK-AUART). Así podrá reutilizar y gestionar la extracción.
- Declarar los datos: Defina las tablas internas y las estructuras necesarias para almacenar los datos de distintas tablas SAP (por ejemplo, VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK y BSAD). Defina también la estructura de salida final del Registro de eventos, con los atributos requeridos.
- Seleccionar los pedidos de venta base: Escriba la instrucción SELECT inicial para recuperar las cabeceras (VBAK) y las posiciones (VBAP) de los pedidos de venta según los valores introducidos en la pantalla de selección. Este será el conjunto de casos que se analizará.
- Extraer el evento de creación: Recorra los registros VBAK seleccionados. Para cada uno, rellene la estructura del Registro de eventos con la actividad 'Pedido de venta creado' y utilice VBAK-ERDAT y VBAK-ERZET para StartTime.
- Extraer los eventos del registro de cambios: Seleccione en CDHDR y CDPOS los registros cuyo OBJECTCLAS sea 'VERKBELEG' para los pedidos de venta seleccionados. Recorra los resultados para identificar cambios en campos específicos. Por ejemplo, un cambio en VBAK-LIFSK indica 'Bloqueo de entrega establecido', y un cambio en VBUK-CMGST indica 'Comprobación de crédito realizada'. Puede registrar cualquier otro cambio pertinente como 'Pedido de venta modificado'.
- Extraer los datos del flujo de documentos: Consulte la tabla de flujo de documentos (VBFA) para los pedidos de venta seleccionados. Esta tabla vincula los pedidos con documentos posteriores, como entregas, movimientos de mercancías y facturas. Seleccione todos los documentos relacionados para procesarlos.
- Extraer los eventos de entrega y cumplimiento: Utilice los números de documento de entrega de VBFA para consultar LIKP y LIPS y registrar los eventos 'Entrega creada'. Consulte MKPF y MSEG para obtener los documentos de salida de mercancías (tipo de movimiento '601') y registrar el evento 'Mercancías despachadas'. Si la gestión de almacenes está activa, consulte LTAK y LTAP para encontrar la hora de confirmación de la última posición de la orden de traslado y determinar cuándo se completó la preparación del pedido. Compruebe el estado de cabecera de entrega VBUK-PODAT para registrar 'Entrega confirmada'.
- Extraer los eventos de facturación y pago: Utilice los números de documento de facturación de VBFA para consultar VBRK y VBRP y registrar los eventos 'Factura creada' y 'Factura cancelada' (cuando VBRK-FKSTO = 'X'). Para encontrar el evento 'Pago recibido', vincule la factura de VBRK con el documento contable de BKPF y, después, busque el documento y la fecha de compensación en BSAD.
- Extraer eventos basados en el estado: Utilice las tablas de estado VBUP (estado de posición) y VBUK (estado de cabecera) para inferir eventos de negocio. Por ejemplo, una posición se considera 'Posición del pedido cerrada' cuando VBUP-GBSTA es igual a 'C'. Un pedido se considera 'Pedido cancelado' cuando se establece un 'Motivo de rechazo' (VBAP-ABGRU) para todas las posiciones pertinentes.
- Consolidar y dar formato: Combine todos los eventos capturados en una única tabla interna final. Compruebe que todos los atributos (SalesOrder, Activity, StartTime, User, etc.) estén correctamente rellenados en cada registro de evento. Añada las marcas de tiempo SourceSystem y LastDataUpdate.
- Generar el archivo de salida: Utilice el módulo de función GUI_DOWNLOAD o el método cl_gui_frontend_services=>gui_download para exportar la tabla interna final a un archivo CSV en el equipo local de la persona usuaria. Asegúrese de guardar el archivo con codificación UTF-8.
Configuración
- Requisitos previos: Se requieren autorizaciones de desarrollo ABAP (por ejemplo, acceso a la transacción SE38) y permisos de lectura para todas las tablas SAP necesarias, incluidas VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG y BSAD.
- Parámetros de selección: El programa debe incluir una pantalla de selección con parámetros de filtrado. Los principales son:
- Intervalo de fechas: Es obligatorio indicar un intervalo para la fecha de creación del pedido de venta (VBAK-ERDAT). Comience con un periodo reciente de 3 a 6 meses para mantener un volumen de datos manejable.
- Organización de ventas: Filtre por VBAK-VKORG para centrar el análisis en unidades de negocio específicas.
- Tipo de documento de ventas: Filtre por VBAK-AUART para incluir solo los tipos de pedido pertinentes (por ejemplo, pedidos estándar) y excluir los demás (por ejemplo, cotizaciones y devoluciones).
- Consideraciones de rendimiento: La extracción de grandes volúmenes de las tablas de registro de cambios (CDHDR, CDPOS) y de flujo de documentos (VBFA) puede tardar mucho. Optimice el programa para utilizar campos de índice en las cláusulas WHERE. Para extracciones muy grandes, programe su ejecución como proceso en segundo plano durante las horas de menor actividad mediante la transacción SM36.
- Activación del registro de cambios: Este método depende de la funcionalidad de documentos de cambio de SAP. Compruebe que el registro de cambios esté habilitado para los elementos de datos clave (por ejemplo, LIFSK, CMGST y ABGRU). Puede verificarlo en la transacción SCDO para el objeto VERKBELEG.
Consulta de ejemplo abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM. Pasos
- Requisitos previos: Asegúrese de tener acceso directo y de solo lectura a la base de datos subyacente de SAP ECC. Necesitará una herramienta cliente de bases de datos, como DBeaver, SQL Server Management Studio u Oracle SQL Developer, para conectarse y ejecutar consultas.
- Obtener el script SQL: Copie la consulta SQL completa incluida en la sección 'query' de este documento.
- Conectarse a la base de datos: Abra el cliente de bases de datos y conéctese a la instancia de la base de datos de SAP ECC. Necesitará la dirección del servidor, el puerto, el nombre de la base de datos y las credenciales de acceso correspondientes.
- Configurar la consulta: Pegue el script SQL en una nueva ventana del editor de consultas. Busque la sección de configuración dentro de la expresión de tabla común (CTE) principal llamada SalesOrders. Sustituya los valores de ejemplo para la fecha de inicio ('{StartDate}'), la fecha de fin ('{EndDate}'), las organizaciones de ventas ('{SalesOrgs}') y los tipos de documento ('{DocTypes}') por los valores que correspondan a su análisis.
- Ejecutar la consulta: Ejecute el script SQL configurado. Según el intervalo de fechas y el tamaño de la base de datos SAP, la consulta puede tardar varios minutos.
- Revisar los resultados: Al finalizar la consulta, se mostrará un conjunto de resultados. Revise rápidamente los datos para comprobar que incluyan las columnas esperadas (SalesOrder, Activity, StartTime, etc.) y que se devuelvan filas para distintas actividades.
- Exportar los datos: Utilice la función de exportación del cliente de bases de datos para guardar los resultados en un archivo CSV. Asígnele un nombre descriptivo, como SAP_O2C_Event_Log.csv.
- Preparar los datos para ProcessMind: Abra el archivo CSV en un editor de hojas de cálculo. Compruebe que los encabezados de columna coincidan exactamente con los atributos requeridos (por ejemplo, SalesOrder, Activity y StartTime). Verifique que el formato de fecha y hora de StartTime y LastDataUpdate sea uniforme y compatible con ProcessMind, por ejemplo, YYYY-MM-DD HH:MI:SS.
- Cargar los datos en ProcessMind: Cargue el archivo CSV final, con el formato correcto, en su proyecto de ProcessMind para analizarlo.
Configuración
- Intervalo de fechas: La consulta utiliza los valores de ejemplo ('{StartDate}' y '{EndDate}') para filtrar los pedidos de venta por fecha de creación (VBAK.ERDAT). Para obtener una muestra representativa sin sobrecargar la base de datos, suele ser adecuado analizar entre 3 y 6 meses de datos.
- Filtro de organización de ventas: Utilice el valor '{SalesOrgs}' para limitar la extracción a organizaciones de ventas específicas (por ejemplo, '1000' y '2000'). Esto permite centrar el análisis y mejorar el rendimiento de la consulta.
- Filtro de tipo de documento: Utilice el valor '{DocTypes}' para seleccionar tipos específicos de pedidos de venta (por ejemplo, 'OR' para un pedido estándar). Así podrá excluir del flujo principal documentos irrelevantes, como entregas gratuitas o devoluciones.
- Identificador del sistema de origen: Se utiliza el valor fijo '{SourceSystemName}' para identificar el sistema de origen de cada registro. Sustitúyalo por un nombre representativo de su instancia de SAP ECC (por ejemplo, SAP_ECC_PRD).
- Compatibilidad con la base de datos: La función para combinar los campos de fecha y hora, [Your DB-specific timestamp function], es un valor de ejemplo. Debe sustituirla por la función adecuada para su base de datos (por ejemplo, TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') para SAP HANA o CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) para SQL Server).
- Requisitos previos: Este método requiere credenciales de acceso directo y de solo lectura a la base de datos. El usuario de la base de datos debe tener autorización para acceder a todas las tablas mencionadas en la consulta, incluidas VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK y BSAD.
Consulta de ejemplo sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''; ¿Listo para comenzar?
Aproveche todo el potencial del proceso de pedido a cobro y procesamiento de pedidos de venta con este Template de datos. Comience hoy a mejorar la eficiencia y acelerar el flujo de caja.
Optimice hoy el proceso de pedido a cobro y procesamiento de ventas
Elimine cuellos de botella, reduzca el tiempo de ciclo un 30 % y mejore rápidamente el flujo de caja.
No se requiere tarjeta de crédito. La configuración toma solo unos minutos.