Su plantilla de datos de Order to Cash: procesamiento de pedidos de venta
Su plantilla de datos de Order to Cash: procesamiento de pedidos de venta
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía de extracción para SAP ECC
Atributos del procesamiento de pedidos de venta de Order to Cash
| Nombre | Descripción | ||
|---|---|---|---|
| Pedido de venta SalesOrder | Identificador único de un documento de pedido de venta, que actúa como caso principal para realizar el seguimiento de todo el proceso de pedido a cobro. | ||
| Descripción El pedido de venta es el documento central del proceso de ventas y representa la solicitud de mercancías o servicios de un cliente. Contiene toda la información necesaria para procesar la solicitud del cliente de principio a fin. En Process Mining, este atributo se utiliza como ID de caso. Cada número de pedido de venta único representa una instancia del proceso integral. Analizar los procesos por pedido de venta permite realizar el seguimiento de todo el ciclo de vida, medir los tiempos de ciclo e identificar variaciones en cada pedido individual del 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 del 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 dentro del proceso del pedido de venta. | ||
| Descripción Este atributo describe un único paso del proceso de pedido a cobro, como «Pedido de venta creado», «Entrega creada» o «Pago recibido». Estas actividades son los componentes básicos que se utilizan para reconstruir el flujo del proceso de cada pedido de venta. Analizar la secuencia y el momento de estas actividades constituye el núcleo de Process Mining. Ayuda a visualizar el mapa del proceso, identificar cuellos de botella, descubrir variantes del proceso y comprobar el cumplimiento respecto a un modelo estándar. Normalmente, 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 forman la estructura básica del mapa del proceso y permiten visualizar y analizar el flujo, las desviaciones y los cuellos de botella. Dónde obtenerlo Es un atributo derivado que normalmente se genera durante la extracción de datos al asignar códigos de transacción de SAP (T-Codes), cambios de estado de documentos (por ejemplo, de las tablas VBUK y VBUP) o registros de cambios de documentos (tablas CDHDR y CDPOS) a nombres de actividad fáciles de entender. 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 ocurrió una actividad concreta. Por ejemplo, registra cuándo se creó una orden de venta, cuándo se expidieron las mercancías o cuándo se contabilizó una factura. Esta marca de tiempo es fundamental para todos los análisis basados en el tiempo 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 puntuales o los tiempos de entrega del cumplimiento de pedidos. Por qué es importante Es un atributo crítico para calcular todas las métricas de rendimiento, como los tiempos de ciclo y las duraciones, esenciales para identificar cuellos de botella. Dónde obtenerlo Es un atributo compuesto que normalmente se obtiene combinando un campo de fecha (por ejemplo, ERDAT) y un campo de hora (por ejemplo, ERZET) de varias tablas de SAP, como VBAK (pedido de venta), 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 un número de cliente. Proporciona contexto para los datos, especialmente en entornos con varios sistemas productivos o datos procedentes de sistemas heredados. En el análisis, se utiliza para filtrar o segmentar los datos según su origen. Resulta especialmente útil para comparar procesos entre distintos sistemas o durante proyectos de migración, con el fin de garantizar la integridad y coherencia de los datos. Por qué es importante Proporciona un contexto esencial, especialmente en entornos con varios sistemas, permite comparar procesos y garantiza la trazabilidad clara de los datos. Dónde obtenerlo Este valor normalmente se añade durante el proceso de extracción de datos y suele ser 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 de datos más reciente para un evento o caso determinado. Proporciona transparencia sobre la actualidad de los datos analizados. En los Dashboards y los informes, esta información es fundamental para que las personas usuarias comprendan la vigencia de la información. Ayuda a confirmar si el análisis refleja el estado operativo más reciente o si se basa en datos antiguos, y permite gestionar las expectativas sobre la actualidad de los datos. Por qué es importante Garantiza que los usuarios conozcan la actualidad de los datos, algo fundamental para tomar decisiones oportunas y fundamentadas a partir del análisis de Process Mining. Dónde obtenerlo Es un atributo de metadatos que la herramienta o el proceso de extracción de datos completa durante la ingesta de datos. 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 venta está bloqueado para la entrega, lo que impide crear un documento de entrega. | ||
| Descripción El bloqueo de entrega es un estado establecido en un pedido de venta, en el nivel de cabecera o de partida, para detener temporalmente el proceso antes de la entrega. Un usuario puede establecer los bloqueos manualmente o el sistema puede aplicarlos automáticamente por motivos como el incumplimiento del límite de crédito o datos incompletos. Este atributo es fundamental para el panel «Análisis de bloqueos y retrabajos de pedidos de venta». Analizar la frecuencia, duración y motivos de los bloqueos de entrega ayuda a identificar los principales cuellos de botella del proceso de cumplimiento. Reducir estos bloqueos es clave para mejorar la entrega puntual y el tiempo de ciclo general. Por qué es importante Identifica directamente los cuellos de botella del proceso de cumplimiento. Analizar por qué y con qué frecuencia se bloquean los pedidos es crucial 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 venta, sin incluir impuestos ni descuentos en el nivel de cabecera. | ||
| Descripción El importe neto representa el valor monetario del pedido de venta. Es una métrica financiera clave asociada a cada instancia del proceso. Este atributo es esencial para realizar Process Mining basado en el valor. Permite priorizar las iniciativas de mejora del proceso centrándose en los pedidos de mayor valor. Los analistas pueden correlacionar problemas del proceso, como retrasos o retrabajos, con su impacto financiero y reforzar así el caso de negocio para el cambio. Por ejemplo, puede utilizarse para analizar si los pedidos de alto valor se procesan con mayor o menor eficiencia que los de bajo valor. Por qué es importante Permite realizar análisis basados en el valor y priorizar los esfuerzos de mejora 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 el motivo por el que se rechazó o canceló una partida del pedido de venta. | ||
| Descripción El motivo de rechazo proporciona contexto sobre por qué no se cumplió un pedido de venta o una partida concreta. Puede deberse a la cancelación por parte del cliente, la falta de disponibilidad del producto u otros motivos empresariales. Este atributo es esencial para el panel «Tendencias de cancelación de pedidos de venta». Al analizar los motivos de rechazo más frecuentes, la empresa puede identificar las causas raíz de las ventas perdidas. 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 el índice de cancelación de pedidos. Por qué es importante Explica el motivo de las cancelaciones de pedidos y permite analizar las causas raíz para reducir las ventas perdidas 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 venta. | ||
| Descripción Este atributo representa al «interlocutor solicitante», la cuenta de cliente principal asociada al pedido de venta. Vincula la transacción con un cliente concreto de los datos maestros. Analizar por número de cliente permite segmentar el proceso para comprender los comportamientos y el rendimiento específicos de cada cliente. Ayuda a responder preguntas como qué clientes tienen los tiempos de ciclo más largos, los índices de retrabajo más altos o los cambios de pedido más frecuentes. Es fundamental para mejorar la gestión de las relaciones con los clientes y los niveles de servicio. Por qué es importante Permite realizar análisis centrados en el cliente, identificar problemas del proceso que afectan a clientes concretos y medir el rendimiento específico de cada cliente. 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 la partida específica de una línea del pedido de venta. Como un mismo pedido puede contener varios materiales, este atributo normalmente se analiza en el nivel de partida. Analizar el proceso por número de material ayuda a descubrir problemas específicos de cada producto. Puede revelar si determinados productos están asociados a plazos de cumplimiento más largos, índices más altos de bloqueos de entrega o discrepancias de facturación más frecuentes. Esto es fundamental para la gestión de la cadena de suministro y de los productos, ya que permite optimizar el proceso para distintas líneas de productos. Por qué es importante Permite analizar el proceso por producto y descubrir qué productos están asociados a ineficiencias como retrasos, bloqueos o retrabajos. 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 Una organización de ventas es una entidad organizativa clave de SAP que estructura la empresa según sus necesidades comerciales. Es responsable de negociar las condiciones de venta y distribuir bienes y servicios. En Process Mining, este atributo es una dimensión crítica para el análisis. Permite comparar el rendimiento, la eficiencia y el cumplimiento del proceso entre distintas unidades de ventas, regiones o divisiones. Esto ayuda a identificar las mejores prácticas en las organizaciones con mejor rendimiento y las áreas de mejora en otras. Por qué es importante Permite realizar comparaciones de referencia entre organizaciones y comparar la eficiencia y el cumplimiento de los procesos entre distintas unidades de negocio o regiones. 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 de usuario del empleado que creó o modificó por última vez el documento o realizó la actividad. | ||
| Descripción Este atributo registra el ID de usuario de SAP responsable de un evento concreto del proceso. Por ejemplo, identifica a la persona encargada de ventas que creó la orden o al personal del almacén que contabilizó la salida de mercancías. Analizar el proceso por usuario ayuda a comprender la distribución de la carga de trabajo, identificar necesidades de formación y detectar variaciones 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 identificación de intervenciones manuales. Por qué es importante Proporciona visibilidad sobre el rendimiento y la carga de trabajo de los recursos, ayuda a identificar desviaciones del proceso específicas de cada usuario y es clave para analizar el cumplimiento y la automatización. Dónde obtenerlo Se encuentra en muchas tablas de cabecera de SAP como campo «Creado por» (ERNAM) o «Modificado por» (AENAM), por ejemplo, en VBAK, LIKP y VBRK. Ejemplos CBURKEJSMITHRWILLIAMS | |||
| Condiciones de expedición ShippingConditions | Define la estrategia general de expedición de las mercancías al cliente. | ||
| Descripción Las condiciones de expedición determinan cómo se enviará un pedido, por ejemplo, «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 expedición». Al segmentar el proceso por condiciones de expedición, las empresas pueden analizar si determinados métodos son más propensos a sufrir retrasos o tienen tiempos de ciclo más largos. Estos datos ayudan a optimizar la logística y gestionar las expectativas del cliente sobre los plazos de entrega. Por qué es importante Permite analizar el rendimiento logístico y determinar si ciertos métodos de expedición se relacionan con retrasos o con 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 | |||
| Es entrega puntual IsOnTimeDelivery | Indicador booleano que señala si las mercancías se expidieron en la fecha de entrega confirmada o antes. | ||
| Descripción Este atributo calculado compara la fecha real de salida de mercancías con «ConfirmedDeliveryDate» para un pedido de venta. Si la fecha de salida de mercancías es igual o anterior a la fecha confirmada, se marca como verdadero; de lo contrario, como falso. Este atributo simplifica la creación del panel «Rendimiento de las entregas puntuales» y el cálculo del KPI de índice de entregas puntuales. Permite agregar y visualizar fácilmente el rendimiento sin tener que comparar fechas sobre la marcha en cada análisis o gráfico. Así proporciona una medida clara y rápida de la fiabilidad de las entregas. Por qué es importante Proporciona una medida clara y sencilla del rendimiento de las entregas y facilita el cálculo del KPI general de índice de entregas puntuales. Dónde obtenerlo Es un atributo calculado. La lógica compara 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 venta ha experimentado un cambio significativo o una actividad de retrabajo después de su creación inicial. | ||
| Descripción Este atributo calculado identifica las instancias del proceso que han experimentado retrabajo, como una o varias actividades de «Pedido de venta modificado». La lógica específica que define el retrabajo, por ejemplo, un cambio en el precio, la cantidad o la fecha de entrega, se establece durante la configuración del proyecto. Este atributo es fundamental para el panel «Retrabajo y frecuencia de cambios de pedidos de venta» y para el KPI de índice de retrabajo de pedidos de venta. Simplifica el análisis al permitir filtrar y comparar directamente los pedidos que siguieron un recorrido directo con los que requirieron cambios manuales. Esto ayuda a 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 y el tiempo de ciclo del proceso. Dónde obtenerlo Es un atributo calculado derivado del registro de eventos. La lógica comprueba la presencia de actividades de «Pedido de venta modificado» o de eventos de cambio específicos de 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 automática o manual realizada sobre un pedido de venta. Entre los estados habituales se incluyen «Aprobado», «Rechazado» o «Bloqueado». Es un atributo clave para el panel «Análisis del tiempo de procesamiento de la comprobación de crédito». Los retrasos o bloqueos en esta etapa pueden afectar significativamente al tiempo de ciclo general del cumplimiento del pedido. Analizar este estado ayuda a comprender la eficiencia del proceso de gestión del 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 del 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 del crédito (por ejemplo, CMGST). Ejemplos ABD | |||
| Fecha de entrega confirmada ConfirmedDeliveryDate | Fecha en la que se ha confirmado al cliente la entrega de las mercancías o los servicios. | ||
| Descripción Es la fecha de entrega comprometida con el cliente, basada en la disponibilidad de materiales y la planificación. Sirve como referencia para medir el rendimiento de las entregas. Este atributo es la base del panel «Rendimiento de las entregas puntuales» y del KPI de índice de entregas puntuales. Al comparar la fecha de entrega confirmada con la fecha real de «salida de mercancías», el análisis puede determinar si un pedido se entregó a tiempo, antes o después de lo previsto. Es una medida principal de la fiabilidad de la cadena de suministro y la satisfacción del cliente. Por qué es importante Es la referencia para medir el rendimiento de las entregas puntuales, un KPI crítico 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 procesamiento de pedidos de venta de Order to Cash
| Actividad | Descripción | ||
|---|---|---|---|
| Factura creada | Marca la creación de la factura del cliente o del documento de facturación. Es un evento explícito que genera un documento nuevo en el sistema e inicia la parte de cobro del proceso. | ||
| Por qué es importante Este es un hito crucial que inicia el cómputo del «tiempo de ciclo de factura 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) a partir de su fecha de creación (ERDAT). El vínculo con el pedido de venta o la entrega se encuentra en la tabla VBFA. Recopilar 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 ha recibido el pago del cliente y se ha aplicado a la factura, saldando 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 paso final para convertir la venta en efectivo. Es el punto final para medir el «tiempo de ciclo de factura a pago» y el «tiempo de ciclo total de cumplimiento del pedido de venta». Dónde obtenerlo Se infiere a partir de la información del documento de compensación en la tabla BSEG para la partida individual del cliente. Cuando BSEG-AUGBL (documento de compensación) y BSEG-AUGDT (fecha de compensación) están cumplimentados, el pago se considera recibido. Recopilar Se infiere cuando se cumplimenta 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 final de una partida del pedido de venta e indica que se ha entregado y facturado por completo y que se considera finalizada. Se infiere a partir del estado general de la partida. | ||
| Por qué es importante Actúa como evento final satisfactorio del proceso. Analizar cuándo se cierran las partidas ayuda a comprender la duración integral del proceso e identificar pedidos que permanecen abiertos innecesariamente. Dónde obtenerlo Se infiere a partir del campo de estado general de la tabla VBUP (Documento de ventas: estado de la partida) correspondiente a la partida. Cuando VBUP-GBSTA es «C» (Procesado completamente), la partida se considera cerrada. Recopilar Se infiere cuando el estado de la partida (VBUP-GBSTA) cambia a «C» (Procesado completamente). Tipo de evento inferred | |||
| Pedido confirmado | Esta actividad indica que el pedido de venta ha superado todas las verificaciones iniciales y está confirmado para su cumplimiento. Normalmente se infiere cuando el pedido ya no está bloqueado y tiene cantidades confirmadas en sus líneas de programación. | ||
| Por qué es importante Este es un hito importante que separa la entrada del pedido de su cumplimiento. Es el punto de partida para medir los plazos de cumplimiento y el rendimiento de las entregas a tiempo. Dónde obtenerlo Se puede inferir 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, VBUK-LIFSK está vacío). Recopilar Se infiere a partir de la confirmación de las líneas de programación (VBEP-BMENG > 0) y la eliminación de los bloqueos a nivel de cabecera. Tipo de evento inferred | |||
| Pedido de venta creado | Marca la creación de un nuevo documento de pedido de venta. Es un evento explícito que se registra cuando un usuario guarda un pedido nuevo, normalmente mediante la transacción VA01 en SAP. | ||
| Por qué es importante Este es el evento inicial principal del proceso Order-to-Cash. Analizar su momento de ocurrencia es fundamental para medir el tiempo total del ciclo y las tasas de entrada de pedidos. 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. Recopilar 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 | Un evento crítico en el que la propiedad de las mercancías se transfiere y estas salen oficialmente del almacén. Es una contabilización financiera explícita que crea un documento de material y actualiza el inventario. | ||
| Por qué es importante Este es el evento de «expedición» y un hito clave para medir la entrega puntual y los plazos de cumplimiento. Activa actualizaciones financieras y marca un punto de no retorno en el proceso físico de cumplimiento. 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. Recopilar 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 capturarse explícitamente en los registros de modificaciones o inferirse a partir de las tablas de estado. | ||
| Por qué es importante Esta actividad está directamente relacionada con el KPI «Sales Order Blockage Rate». Identificar por qué y con qué frecuencia se establecen bloqueos ayuda a descubrir las causas de los retrasos en el cumplimiento. Dónde obtenerlo Puede encontrarse en los registros de modificaciones (CDHDR/CDPOS) del campo VBAK-LIFSK. También puede inferirse al observar cuándo el campo VBAK-LIFSK contiene un valor. Recopilar Evento procedente de los documentos de modificación de los campos VBAK-LIFSK o VBAP-LIFSP. Tipo de evento explicit | |||
| Comprobación de crédito realizada | Indica que se ha completado la verificación de crédito automática o manual del cliente asociado al pedido de venta. Normalmente se infiere a partir de un cambio en el estado crediticio general del documento. | ||
| Por qué es importante La verificación de crédito suele ser un cuello de botella crítico. Medir el tiempo necesario para este paso es esencial para el «Credit Check Processing Time Analysis» y para acelerar el procesamiento de pedidos. Dónde obtenerlo Se infiere a partir de los campos de estado crediticio de la tabla VBUK (documento de ventas: estado de cabecera). Un cambio en VBUK-CMGST de bloqueado a liberado marca esta actividad. Recopilar Se infiere a partir de los cambios en el campo de estado crediticio general (VBUK-CMGST). Tipo de evento inferred | |||
| Entrega creada | Este evento marca la creación del documento de entrega saliente, que indica al almacén que debe iniciar las actividades de preparación y envío. Es un evento explícito que se captura del flujo de documentos. | ||
| Por qué es importante Este es el primer paso del proceso de cumplimiento físico. El tiempo entre la confirmación del pedido y la creación de la entrega indica la rapidez con la que se inicia el proceso logístico. Dónde obtenerlo Corresponde a la creación de un registro en la tabla LIKP (datos de cabecera de entrega del documento SD). El vínculo con el pedido de venta se mantiene en la tabla de flujo de documentos VBFA. Recopilar Evento basado en la marca de tiempo de creación de la tabla LIKP, vinculado mediante la tabla VBFA. Tipo de evento explicit | |||
| Factura cancelada | Representa la reversión de un documento de facturación creado anteriormente. Es una transacción explícita que crea un documento de cancelación nuevo para compensar el original. | ||
| Por qué es importante El seguimiento de las cancelaciones de facturas ayuda a identificar problemas de precios, discrepancias en los envíos o errores de datos. Esto respalda el KPI «índice de discrepancias de facturas». Dónde obtenerlo Evento explícito capturado mediante la creación de un documento de facturación de cancelación (VBRK-VBTYP = «N» u «O»). La factura original se referencia en VBRK-SFAKN. Recopilar Creación de un documento de cancelación en VBRK que referencia la factura original. Tipo de evento explicit | |||
| Pedido cancelado | Indica que un pedido de venta se ha cancelado antes del cumplimiento. Normalmente se captura asignando un «motivo de rechazo» a todas las partidas pertinentes del pedido. | ||
| Por qué es importante Este es un punto final de fallo crítico que respalda directamente el KPI «índice de cancelación de pedidos». Comprender cuándo y por qué se cancelan los pedidos proporciona información sobre los problemas del proceso de ventas. Dónde obtenerlo Se infiere cuando el campo VBAP-ABGRU (motivo de rechazo) está cumplimentado para todas las partidas activas de un pedido de venta. La fecha del cambio puede consultarse en CDHDR/CDPOS. Recopilar Se infiere cuando se cumplimenta el campo «Motivo de rechazo» (VBAP-ABGRU) en todas las partidas. Tipo de evento inferred | |||
| Pedido de venta modificado | Representa una modificación realizada en un pedido de venta existente después de su creación inicial. Estos cambios se registran en 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 identificar el retrabajo, la inestabilidad del proceso y los problemas de calidad de los datos. Una frecuencia elevada de cambios puede indicar problemas en la introducción inicial del pedido y provocar retrasos. 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. Recopilar Evento procedente de las tablas de documentos de modificación (CDHDR, CDPOS) para objetos de documentos de ventas. Tipo de evento explicit | |||
| Preparación completada | Indica que todos los artículos de la entrega se han recogido físicamente del almacén. Si se utiliza Warehouse Management (WM), puede inferirse a partir del estado de la Transfer Order. | ||
| Por qué es importante Analizar el tiempo de preparación ayuda a optimizar las operaciones del almacén. Los retrasos en esta etapa afectan directamente al calendario general de envíos y al ciclo de cumplimiento. Dónde obtenerlo Se infiere a partir del cambio del estado de preparación de la posición de entrega en la tabla LIPS-KOSTA a «C» (preparación completa). Si WM está activo, puede inferirse a partir de la confirmación de la Transfer Order (tablas LTAK/LTAP). Recopilar Se infiere a partir del cambio en el estado de preparación (LIPS-KOSTA) o de la confirmación de la Transfer Order de WM. Tipo de evento inferred | |||
| Prueba de entrega confirmada | Esta actividad representa la confirmación de que el cliente ha recibido las mercancías. Se registra cuando la prueba de entrega se incorpora al sistema y, a menudo, actualiza 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 «índice de entregas puntuales» frente a la fecha prometida. Dónde obtenerlo Se infiere cuando el estado de la prueba de entrega (VBUK-PODAT) se establece en «C» (Confirmado). La fecha de confirmación se almacena en VLPOD-PODAT. No siempre se implementa. Recopilar Se infiere a partir de la actualización del estado de la prueba de entrega en la entrega (VBUK-PODAT) o de una entrada en la tabla VLPOD. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Desarrollo del programa: Mediante la transacción SE38 o SE80, cree un nuevo programa ABAP ejecutable. Este programa contendrá toda la lógica de extracción.
- Definir la pantalla de selección: En el programa, 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). Esto hará que la extracción sea reutilizable y fácil de gestionar.
- Declaraciones de datos: Defina las tablas internas y las estructuras necesarias para contener los datos de las distintas tablas de SAP, como VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK y BSAD. Defina también la estructura de salida final del registro de eventos, que debe coincidir 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 datos principal de los casos que se analizarán.
- Extraer el evento «Creación»: Recorra los registros VBAK seleccionados. Para cada registro, rellene la estructura del registro de eventos con la actividad «Sales Order Created», utilizando VBAK-ERDAT y VBAK-ERZET para StartTime.
- Extraer los eventos del registro de cambios: Seleccione registros de CDHDR y CDPOS donde OBJECTCLAS sea «VERKBELEG» para los pedidos de venta seleccionados. Recorra los resultados para identificar cambios específicos en los campos. Por ejemplo, un cambio en VBAK-LIFSK indica «Delivery Block Set», y un cambio en VBUK-CMGST indica «Credit Check Performed». Cualquier otro cambio relevante puede registrarse como «Sales Order Changed».
- Extraer los datos del flujo de documentos: Para los pedidos de venta seleccionados, consulte la tabla de flujo de documentos (VBFA). Esta tabla vincula los pedidos de venta con documentos posteriores, como entregas, movimientos de mercancías y facturas. Seleccione todos los documentos relacionados para procesarlos posteriormente.
- Extraer eventos de entrega y cumplimiento: Utilizando los números de documento de entrega de VBFA, consulte LIKP y LIPS para obtener los eventos «Delivery Created». Consulte MKPF y MSEG para los documentos de salida de mercancías (tipo de movimiento «601») y capture el evento «Goods Issued». Si Warehouse Management está activo, consulte LTAK y LTAP para encontrar la hora de confirmación de la última posición de la orden de transferencia y determinar «Picking Completed». Compruebe el estado de cabecera de la entrega VBUK-PODAT para obtener «Proof of Delivery Confirmed».
- Extraer eventos de facturación y pago: Utilizando los números de documento de facturación de VBFA, consulte VBRK y VBRP para capturar los eventos «Invoice Created» e «Invoice Cancelled» (cuando VBRK-FKSTO = «X»). Para encontrar «Payment Received», vincule la factura de VBRK con el documento contable de BKPF y, después, localice el documento de compensación y la fecha de compensación en BSAD.
- Extraer eventos basados en estados: Utilice las tablas de estado VBUP (estado de posición) y VBUK (estado de cabecera) para inferir eventos empresariales. Por ejemplo, una posición se considera «Order Item Closed» cuando VBUP-GBSTA es igual a «C». Un pedido se considera «Order Cancelled» cuando se establece un «Reason for Rejection» (VBAP-ABGRU) para todas las posiciones relevantes.
- Consolidar y dar formato: Combine todos los eventos capturados en una única tabla interna final. Asegúrese de que todos los atributos (SalesOrder, Activity, StartTime, User, etc.) estén correctamente rellenados en cada registro de evento. Añada las marcas de tiempo de SourceSystem y LastDataUpdate.
- Generar el archivo de salida: Utilice el módulo de funciones 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 del usuario. Asegúrese de guardar el archivo con codificación UTF-8.
Configuración
- Requisitos previos: Se necesitan autorizaciones de desarrollador ABAP, por ejemplo, acceso a la transacción SE38, y permisos de lectura para todas las tablas de SAP requeridas, 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 parámetros clave son:
- Intervalo de fechas: un intervalo obligatorio para la creación de pedidos de venta (VBAK-ERDAT). Comience con un periodo reciente de 3-6 meses para mantener el conjunto de datos bajo control.
- 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 únicamente los tipos de pedido relevantes, por ejemplo, pedidos estándar, y excluir otros, como ofertas y devoluciones.
- Consideraciones de rendimiento: La extracción de las tablas de registros de cambios (CDHDR, CDPOS) y del flujo de documentos (VBFA) puede ser muy lenta con grandes volúmenes de datos. El programa debe optimizarse para utilizar campos de índice en las cláusulas WHERE. Para extracciones muy grandes, programe el programa como un trabajo 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 modificación de SAP. Verifique que el registro de cambios esté habilitado para los elementos de datos clave, como LIFSK, CMGST y ABGRU. Puede comprobarlo mediante la transacción SCDO para el objeto VERKBELEG.
a 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 proporcionada en la sección «query» de este documento.
- Conectarse a la base de datos: Abra su cliente de bases de datos y establezca una conexión con 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. Localice la sección de configuración dentro de la Common Table Expression (CTE) principal denominada SalesOrders. Sustituya los valores de marcador de posición para la fecha inicial ('{StartDate}'), la fecha final ('{EndDate}'), las organizaciones de ventas ('{SalesOrgs}') y los tipos de documento ('{DocTypes}') por los valores reales de su análisis.
- Ejecutar la consulta: Ejecute el script SQL configurado. Según el intervalo de fechas y el tamaño de su base de datos SAP, la consulta puede tardar varios minutos.
- Revisar los resultados: Cuando finalice la consulta, se mostrará un conjunto de resultados. Revise brevemente los datos para comprobar que contienen las columnas esperadas (SalesOrder, Activity, StartTime, etc.) y que se devuelven filas para distintas actividades.
- Exportar los datos: Utilice la función de exportación de su cliente de bases de datos para guardar el conjunto de resultados como un archivo CSV. Asigne al archivo un nombre descriptivo, como SAP_O2C_Event_Log.csv.
- Dar formato para ProcessMind: Abra el archivo CSV en un editor de hojas de cálculo. Verifique que las cabeceras de columna coincidan exactamente con los atributos requeridos, por ejemplo, SalesOrder, Activity y StartTime. Asegúrese de que el formato de fecha y hora de StartTime y LastDataUpdate sea coherente y compatible con ProcessMind, como YYYY-MM-DD HH:MI:SS.
- Cargar en ProcessMind: Cargue el archivo CSV final, ya formateado, en su proyecto de ProcessMind para analizarlo.
Configuración
- Intervalo de fechas: La consulta utiliza los marcadores de posición («{StartDate}» y «{EndDate}») para filtrar los pedidos de venta según su fecha de creación (VBAK.ERDAT). Un periodo de análisis habitual es de 3 a 6 meses de datos, para garantizar una muestra representativa sin generar una carga excesiva en la base de datos.
- Filtro de organización de ventas: Utilice el marcador de posición «{SalesOrgs}» para limitar la extracción a organizaciones de ventas específicas (por ejemplo, «1000» y «2000»). Esto es fundamental para centrar el análisis y mejorar el rendimiento de la consulta.
- Filtro de tipo de documento: Utilice el marcador de posición «{DocTypes}» para seleccionar tipos específicos de pedidos de venta (por ejemplo, «OR» para pedido estándar). Esto ayuda a excluir documentos irrelevantes, como entregas gratuitas o devoluciones, del flujo principal del proceso.
- Identificador del sistema de origen: Se utiliza el marcador de posición codificado «{SourceSystemName}» para etiquetar cada registro con su sistema de origen. Debe establecerse con un nombre significativo para su instancia de SAP ECC (por ejemplo, SAP_ECC_PRD).
- Compatibilidad de la base de datos: La función utilizada para combinar los campos de fecha y hora, [Your DB-specific timestamp function], es un marcador de posición. Debe sustituirla por la función correcta para su base de datos específica (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 base de datos directas y de solo lectura. El usuario de la base de datos debe tener autorización para acceder a todas las tablas referenciadas en la consulta, incluidas VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK y BSAD.
a 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 de su proceso de Order to Cash: procesamiento de pedidos de venta con esta plantilla de datos. Comience hoy su camino hacia una eficiencia optimizada y un flujo de caja más rápido.
Optimice hoy su procesamiento de ventas de Order to Cash
Elimine los cuellos de botella, reduzca el tiempo de ciclo en un 30 % y mejore rápidamente el flujo de caja.
No necesita tarjeta de crédito. Configúrelo en minutos.