Su Template de datos para el procesamiento de devoluciones y reembolsos
Su Template de datos para el procesamiento de devoluciones y reembolsos
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía de extracción
Atributos del procesamiento de devoluciones y reembolsos
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | Marca de tiempo exacta que indica cuándo tuvo lugar una actividad específica. | ||
| Descripción Event Time registra la fecha y hora en que se registró un evento empresarial en el sistema. Esta marca de tiempo es esencial para ordenar cronológicamente las actividades y para todos los análisis basados en el tiempo. En Process Mining, este atributo se utiliza para calcular los tiempos de ciclo entre actividades, determinar la duración de cada paso y analizar el rendimiento del proceso a lo largo del tiempo. Es la base para descubrir cuellos de botella, supervisar el cumplimiento del SLA y comprender la dinámica temporal del proceso de devoluciones. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular todas las duraciones y tiempos de ciclo e identificar retrasos en el proceso. Dónde obtenerlo Normalmente procede de los campos de fecha y hora asociados a la creación de documentos o a cambios de estado, como ERDAT (fecha de creación) y ERZET (hora de creación) en tablas como VBAK, LIKP y BKPF, o la fecha de contabilización (BUDAT) en documentos contables. Ejemplos 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID del caso de devolución ReturnCaseId | Identificador único de un proceso individual de devolución de cliente, que vincula todas las actividades relacionadas desde el inicio hasta el cierre. | ||
| Descripción El ID del caso de devolución es el identificador principal que agrupa todos los eventos y actividades pertenecientes a una única instancia de devolución. Cada solicitud de devolución del cliente recibe un ID único, lo que permite realizar un seguimiento integral de todo el proceso. En Process Mining, este atributo es fundamental para reconstruir el flujo del proceso. Permite analizar la duración de los casos y las variantes y cuellos de botella del proceso, al conectar eventos independientes como «Solicitud de devolución iniciada», «Mercancía recibida» y «Reembolso procesado» en una cronología coherente para cada devolución. Por qué es importante Es la clave esencial para realizar el seguimiento de una devolución de principio a fin y permite todos los análisis a nivel de caso, incluido el tiempo de ciclo y el descubrimiento de variantes del proceso. Dónde obtenerlo Normalmente es el número de documento de ventas (VBELN) de la tabla de cabecera de pedidos de devolución VBAK, donde la categoría de documento (VBTYP) indica que se trata de una devolución. Ejemplos 600001896000019060000191 | |||
| Nombre de la actividad ActivityName | Nombre de una actividad empresarial o evento específico que tuvo lugar dentro del proceso de devolución y reembolso. | ||
| Descripción Este atributo describe un paso o hito individual del ciclo de vida de la devolución. Las actividades representan el trabajo realizado, como «Pedido de devolución aprobado» o «Inspección del artículo completada». Se derivan de cambios de estado, creación de documentos o acciones específicas de usuarios registradas en SAP S/4HANA. Analizar la secuencia y frecuencia de estas actividades es la base de Process Mining. Ayuda a visualizar el mapa del proceso, identificar rutas frecuentes y poco habituales y localizar actividades que se repiten con frecuencia, lo que puede indicar retrabajo o ineficiencias. Por qué es importante Las actividades forman la estructura central del mapa del proceso y permiten visualizar y analizar el flujo del proceso, los cuellos de botella y las variaciones. Dónde obtenerlo Los nombres de las actividades suelen derivarse de una combinación de datos, como cambios de estado de documentos en tablas como VBUK/VBUP, eventos de creación en tablas de cabecera como VBAK (documentos de ventas) y BKPF (documentos contables), y estados de movimientos de mercancías en MSEG. Ejemplos Solicitud de devolución iniciadaMercancía recibida en el almacénAbono creadoReembolso procesado | |||
| ID del sistema de origen SourceSystemId | Identificador del sistema de origen del que se extrajeron los datos. | ||
| Descripción Este atributo especifica el sistema de registro en el que se originaron los datos del evento. Para este proceso, normalmente sería el ID de la instancia de SAP S/4HANA. En entornos con varios sistemas, este campo es fundamental para garantizar la trazabilidad de los datos, resolver problemas y asegurar su integridad. Ayuda a diferenciar los datos cuando las devoluciones se procesan en distintas instancias de ERP o se integran con sistemas externos, como un sistema de gestión de almacenes. Por qué es importante Proporciona un contexto esencial sobre el origen y la trazabilidad de los datos, especialmente en entornos con varios sistemas, y garantiza que los datos sean rastreables y confiables. Dónde obtenerlo Este valor suele ser estático y se configura durante la extracción de datos. Puede obtenerse de la información administrativa del sistema SAP, como el ID del sistema (SID). Ejemplos S4H_PROD_100S4Q_DEV_200 | |||
| Última actualización de datos LastDataUpdateTimestamp | Marca de tiempo que indica cuándo se actualizaron o extrajeron por última vez los datos de este evento. | ||
| Descripción Este atributo registra la fecha y hora de la última extracción o actualización de datos. Proporciona metadatos sobre la actualidad del conjunto de datos analizado. Es importante para comprender la actualidad del análisis de Process Mining. Los usuarios pueden ver hasta qué punto están actualizados los datos, algo especialmente relevante para la supervisión operativa y los Dashboards que realizan el seguimiento de los casos en curso. Por qué es importante Indica la actualidad de los datos, un aspecto fundamental para garantizar que los análisis y los Dashboards se basen en información actualizada. Dónde obtenerlo Normalmente, la herramienta de ETL o de canalización de datos lo genera y registra en el conjunto de datos durante la extracción. Ejemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Hora de finalización del evento EventEndTime | Marca de tiempo que indica la finalización de una actividad y se utiliza para calcular su duración. | ||
| Descripción Mientras que StartTime (EventTime) marca el inicio de una actividad, EventEndTime marca su finalización. En muchos eventos generados por el sistema, las horas de inicio y finalización son idénticas, ya que representan una ocurrencia instantánea. Sin embargo, este atributo es fundamental para las actividades con una duración medible, como «Inspección del artículo». Permite calcular directamente el tiempo de procesamiento de una actividad. Esto es fundamental para analizar el rendimiento, ya que ayuda a identificar qué pasos concretos, y no solo los intervalos entre ellos, consumen más tiempo. Por qué es importante Permite calcular con precisión la duración de cada actividad, un aspecto clave para localizar ineficiencias en pasos específicos del proceso. Dónde obtenerlo A menudo se deriva. Para algunas actividades, puede existir como un campo independiente. Lo más habitual es que corresponda al StartTime de la actividad siguiente del caso. Ejemplos 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| ID del cliente CustomerId | Identificador único del cliente que inicia la devolución. | ||
| Descripción Este atributo identifica al cliente que solicitó la devolución. Vincula la instancia del proceso con una parte concreta de los datos maestros de clientes. Analizar las devoluciones por cliente ayuda a identificar patrones, como clientes con tasas de devolución inusualmente elevadas, lo que podría indicar un comportamiento fraudulento o insatisfacción. También permite segmentar el proceso de devoluciones según el tipo, el valor o el historial del cliente y ofrecer niveles de servicio adaptados. Por qué es importante Conecta las devoluciones con clientes concretos y permite analizar su comportamiento, segmentarlos e identificar a quienes devuelven artículos con frecuencia. Dónde obtenerlo Se encuentra en el campo del número de cliente (KUNNR) de la tabla de cabecera del pedido de devolución (VBAK). Ejemplos CUST-001234CUST-005678CUST-009012 | |||
| ID del producto ProductId | Identificador único del artículo que se devuelve. | ||
| Descripción Este atributo especifica el material o producto objeto de la devolución. Vincula el proceso de devolución con un artículo concreto del catálogo de productos. Analizar las devoluciones por producto es fundamental para identificar artículos con tasas de devolución elevadas, lo que puede indicar defectos de calidad, descripciones deficientes o problemas de fabricación. Estos datos ayudan a las empresas a tomar decisiones fundamentadas sobre el diseño de productos, la gestión de proveedores y la estrategia de inventario. Por qué es importante Vincula el proceso de devolución con productos concretos y permite analizar las tasas de devolución por artículo e identificar problemas de calidad o de descripción. Dónde obtenerlo Se encuentra en el campo del número de material (MATNR) de la tabla de posiciones del pedido de devolución (VBAP) o de la tabla de posiciones de la entrega de devolución (LIPS). Ejemplos FG-10023HW-45981SW-LICENSE-PREM | |||
| Importe del reembolso RefundAmount | Valor monetario final del reembolso emitido al cliente. | ||
| Descripción Este atributo representa el importe real abonado o reembolsado al cliente al completar el proceso de devolución. Este valor se registra en documentos financieros, como los abonos. Es una métrica financiera clave para diversos análisis. Resulta esencial para el panel «Análisis de discrepancias del importe del reembolso», donde se compara con el importe solicitado. También permite segmentar las devoluciones por valor para identificar si las devoluciones de alto importe siguen un proceso diferente o tardan más en resolverse. Por qué es importante Registra el impacto financiero de las devoluciones y es esencial para analizar la exactitud de los reembolsos, identificar casos de alto importe y comprender los costes generales. Dónde obtenerlo Procede del campo de valor neto (NETWR) del documento de abono, que se encuentra en tablas como VBRK (cabecera del documento de facturación) o BSEG (segmento del documento contable). Ejemplos 125.50999.0049.99 | |||
| Motivo de devolución ReturnReason | Motivo que el cliente proporciona para devolver el artículo. | ||
| Descripción Este atributo registra el motivo indicado por el cliente para la devolución, como «Artículo defectuoso», «Talla incorrecta» o «Ya no lo necesita». Normalmente se selecciona de una lista predefinida de códigos de motivo al iniciar la devolución. Analizar los motivos de devolución es fundamental para identificar problemas de calidad de los productos, mejorar sus descripciones o perfeccionar los procesos de ventas. Proporciona información directa sobre la insatisfacción del cliente y ayuda a priorizar áreas de mejora para reducir la tasa general de devoluciones. Por qué es importante Proporciona información esencial sobre las causas de las devoluciones y permite analizar las causas raíz para abordar problemas de calidad de los productos, errores de preparación o diferencias entre las expectativas del cliente y la realidad. Dónde obtenerlo Normalmente se almacena en la tabla de posiciones de pedidos de ventas de devolución (VBAP), en el campo ABGRU (motivo de rechazo de documentos de ventas). Ejemplos 001 - Mala calidad002 - Dañado durante el transporte005 - Se envió el artículo equivocado | |||
| Nombre de usuario UserName | ID del usuario que ejecutó la actividad. | ||
| Descripción Este atributo identifica al usuario o agente del sistema responsable de completar una tarea, como aprobar una devolución o crear un abono. En SAP, suele capturarse en campos que registran al usuario que creó o modificó un documento. Analizar los datos por usuario ayuda a identificar personas o equipos con un alto rendimiento, necesidades de formación y distribución de la carga de trabajo. También es esencial para investigar desviaciones, ya que vincula las acciones del proceso con personas concretas y respalda el cumplimiento y las auditorías. Por qué es importante Atribuye las actividades del proceso a usuarios concretos y permite analizar el rendimiento de los equipos, la carga de trabajo y el cumplimiento. Dónde obtenerlo Suele encontrarse en tablas de cabecera de documentos, como ERNAM (creado por) en VBAK (pedidos de ventas), LIKP (entregas) y BKPF (documentos contables). Los datos de usuario pueden enriquecerse a partir de la tabla maestra de usuarios USR21. Ejemplos CBROWNASMITHWF_BATCH | |||
| Agente de procesamiento ProcessingAgent | Agente o grupo de recursos específico responsable de gestionar una actividad manual. | ||
| Descripción Este atributo identifica a la persona o al equipo que realizó una tarea determinada. Puede ser más específico que «Nombre de usuario», ya que hace referencia a un rol o equipo, especialmente en un entorno de servicios compartidos. Es útil para el panel «Eficiencia de la aprobación de reembolsos», ya que permite analizar el rendimiento de distintos agentes o equipos. Ayuda a comprender la distribución de la carga de trabajo, identificar necesidades de formación y reconocer a los profesionales o equipos con mejor rendimiento, que pueden compartir buenas prácticas. Por qué es importante Permite analizar el rendimiento a nivel de agente o equipo, gestionar la carga de trabajo, identificar oportunidades de formación y mejorar la eficiencia. Dónde obtenerlo Esta información puede estar disponible mediante las funciones de SAP Business Partner si se han asignado agentes, o puede derivarse del departamento o rol del usuario en la estructura organizativa de RR. HH. Ejemplos Soporte de nivel 1Equipo de inspección del almacénDepartamento de finanzas - cuentas por pagar | |||
| Cumplimiento de la política de devoluciones ReturnPolicyAdherence | Indicador que señala si el caso de devolución cumple la política de devoluciones definida. | ||
| Descripción Este atributo booleano calculado indica si una devolución cumple los criterios establecidos en la política aplicable. La lógica podría comprobar, por ejemplo, si la devolución se inició dentro del plazo permitido o si el motivo de devolución es válido para el producto. Este atributo respalda directamente el panel «Resumen del cumplimiento de la política de devoluciones». Cuantifica las tasas de cumplimiento y permite profundizar en los casos que no cumplen los requisitos para comprender los motivos de las desviaciones, lo que ayuda a aplicar las políticas con mayor eficacia. Por qué es importante Cuantifica el cumplimiento de las reglas empresariales y ayuda a identificar y reducir las infracciones de las políticas que pueden afectar a la rentabilidad o crear excepciones en el proceso. Dónde obtenerlo Se calcula según las reglas de negocio. Por ejemplo, (Fecha de inicio de la devolución - Fecha de compra original) <= [Días permitidos para la devolución]. Para ello se necesitan la Fecha de compra original y las reglas de la política. Ejemplos truefalse | |||
| Cumplimiento del SLA de reembolso RefundSlaAdherence | Indicador que señala si el reembolso se procesó dentro del objetivo del Acuerdo de Nivel de Servicio (SLA). | ||
| Descripción Este atributo calculado comprueba si la actividad «Reembolso procesado» tuvo lugar en la Fecha objetivo del SLA de reembolso o antes. Proporciona un indicador sencillo de verdadero o falso sobre el cumplimiento del SLA para cada caso. Es la métrica principal del Dashboard «Supervisión del cumplimiento del SLA de reembolso» y del KPI «Tasa de cumplimiento del SLA de reembolso». Ayuda a medir el rendimiento frente a los compromisos con los clientes e identifica los casos que no cumplieron las expectativas, lo que permite analizar las causas raíz de los retrasos. Por qué es importante Mide directamente el rendimiento frente a los compromisos con los clientes, por lo que es un indicador clave de la calidad del servicio y la satisfacción del cliente. Dónde obtenerlo Se calcula comparando el EventTime de la actividad «Reembolso procesado» con la «RefundSlaTargetDate» de cada caso. Ejemplos truefalse | |||
| Es retrabajo IsRework | Indicador que señala si una actividad de un caso es una repetición de una actividad anterior. | ||
| Descripción Este atributo booleano calculado identifica los casos de retrabajo, en los que una actividad se realiza más de una vez dentro del mismo caso. Por ejemplo, cuando es necesario repetir la inspección de un artículo o se crea, cancela y vuelve a crear una nota de crédito. Este atributo es esencial para el Dashboard «Análisis del retrabajo en el procesamiento de reembolsos» y el KPI «Tasa de retrabajo en reembolsos». Ayuda a cuantificar la ineficiencia del proceso al destacar las actividades propensas a errores o que requieren varios intentos, y señala las áreas que necesitan mejores controles o capacitación. Por qué es importante Pone de relieve las ineficiencias y los errores del proceso al señalar el trabajo repetido, lo que permite aplicar mejoras específicas para reducir el desperdicio y los retrasos. Dónde obtenerlo Normalmente, este indicador lo calcula la propia herramienta de Process Mining o se calcula previamente durante la transformación de datos. Comprueba si el mismo nombre de actividad ya apareció antes en el mismo caso. Ejemplos truefalse | |||
| Está automatizado IsAutomated | Indicador que señala si una actividad fue realizada por un sistema o por una persona. | ||
| Descripción Este atributo booleano distingue entre las actividades ejecutadas automáticamente por un sistema, como un Workflow o un trabajo en segundo plano, y las realizadas manualmente por un usuario. Es esencial para calcular el KPI «Tasa de aprobación automatizada de reembolsos» e identificar oportunidades para aumentar la automatización. Al filtrar las tareas manuales, las empresas pueden centrar sus iniciativas de mejora en las áreas donde la automatización puede aportar mayores beneficios en velocidad, costes y precisión. Por qué es importante Distingue entre tareas manuales y automatizadas, algo fundamental para identificar oportunidades de automatización y medir el impacto de la transformación digital. Dónde obtenerlo Normalmente se deriva a partir del nombre de usuario. Por ejemplo, si el usuario es «WF_BATCH» u otro ID de sistema, la actividad se marca como automatizada. Ejemplos truefalse | |||
| Estado del pedido de devolución ReturnOrderStatus | Estado general actual del caso de devolución. | ||
| Descripción Este atributo proporciona el estado general del caso de devolución en un momento determinado, como «Abierto», «En proceso» o «Cerrado». A menudo es un estado agregado que se deriva del último hito importante completado. Es esencial para el «Panel del estado actual de los casos de devolución», que ofrece una visión operativa de la carga de trabajo y la distribución actuales de los casos. Ayuda a los responsables a saber cuántos casos se encuentran en cada fase del proceso, lo que permite asignar mejor los recursos y gestionar la carga de trabajo. Por qué es importante Proporciona una instantánea del punto en el que se encuentra cada caso dentro del proceso, algo esencial para los Dashboards operativos que realizan el seguimiento de la carga de trabajo y del estado actuales. Dónde obtenerlo Se deriva de los campos de estado de los documentos pertinentes. Por ejemplo, del estado de cabecera (GBSTK) o de posición (LFSTK) del pedido de ventas relacionado (VBUK/VBUP) o de los documentos de entrega. Ejemplos En espera de recepción de mercancíasPendiente de inspecciónPendiente de reembolsoCerrado | |||
| Fecha objetivo del SLA de reembolso RefundSlaTargetDate | Fecha límite en la que debería procesarse el reembolso del caso de devolución. | ||
| Descripción Este atributo define la fecha límite del Acuerdo de Nivel de Servicio (SLA) para procesar el reembolso. Normalmente se calcula según reglas empresariales, por ejemplo, un número determinado de días después de aprobar la devolución o recibir la mercancía. Este campo es la base del panel «Supervisión del cumplimiento del SLA de reembolsos» y del KPI asociado. Permite realizar un seguimiento proactivo de los casos en riesgo de incumplir el SLA y analizar las causas raíz de los retrasos, lo que ayuda a mejorar la satisfacción del cliente. Por qué es importante Proporciona la referencia para medir el cumplimiento del SLA, supervisar el rendimiento, priorizar los casos antiguos y mejorar la satisfacción del cliente. Dónde obtenerlo Casi siempre es un campo derivado. La lógica se basaría en una fecha clave, como la fecha de creación de la solicitud de devolución, más una duración definida por las reglas empresariales, que podría depender de factores como el tipo de cliente o el motivo de devolución. Ejemplos 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| ID de la política de devoluciones ReturnPolicyId | Identificador de la política de devoluciones aplicable a este caso concreto. | ||
| Descripción Este atributo indica qué política de devoluciones o conjunto de reglas específico se aplica a la transacción. Las políticas pueden variar según el tipo de producto, el segmento de clientes o el tiempo transcurrido desde la compra. Estos datos son esenciales para el «Resumen del cumplimiento de la política de devoluciones». Al asociar cada caso con una política, el sistema puede comprobar automáticamente el cumplimiento de reglas, como los plazos de devolución o los requisitos sobre el estado del artículo, y señalar las desviaciones para su análisis. Por qué es importante Permite comprobar automáticamente el cumplimiento de las reglas empresariales y ayuda a garantizar que las devoluciones se procesen de forma coherente y conforme a la política. Dónde obtenerlo A menudo no es un campo estándar de SAP y puede ser necesario derivarlo mediante lógica empresarial a partir de datos como el tipo de producto, el cliente y la fecha de venta. Si se ha implementado, podría almacenarse en un campo personalizado. Ejemplos STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Importe del reembolso solicitado RequestedRefundAmount | Importe del reembolso solicitado o previsto inicialmente al comienzo del proceso. | ||
| Descripción Este atributo registra el valor de la mercancía devuelta según la solicitud de devolución inicial. Sirve como referencia para comparar el importe final reembolsado. Este campo es necesario específicamente para el panel «Análisis de discrepancias del importe del reembolso». Comparar el importe solicitado con el importe real del reembolso ayuda a identificar problemas como reembolsos parciales por daños en el artículo, gastos de reposición u otros ajustes, y garantiza la exactitud y transparencia financieras. Por qué es importante Sirve como referencia para medir la exactitud de los reembolsos y ayuda a identificar y analizar las discrepancias entre los importes previstos y los reales. Dónde obtenerlo Normalmente procede del valor neto de los artículos del pedido de ventas de devolución inicial. Sería el valor neto (NETWR) de las posiciones correspondientes de la tabla VBAP. Ejemplos 125.501050.0049.99 | |||
| Número de abono CreditMemoNumber | Identificador único del documento de abono que autoriza el reembolso. | ||
| Descripción Un abono es el documento de facturación que abona oficialmente en la cuenta del cliente el importe de los artículos devueltos. Este atributo es el número único de ese documento financiero. Realizar el seguimiento del número de abono es esencial para analizar la fase de liquidación financiera del proceso de devoluciones. Marca un hito crítico, ya que a menudo desencadena el pago efectivo del reembolso, y es necesario para la conciliación financiera y las auditorías. Por qué es importante Representa la transacción financiera oficial del reembolso y es fundamental para realizar el seguimiento de las últimas fases del proceso y para las auditorías financieras. Dónde obtenerlo Es el número del documento de facturación (VBELN) de la tabla de cabecera de documentos de facturación (VBRK), donde la categoría de documento indica que se trata de un abono. Ejemplos 900003459000034690000347 | |||
| Número de entrega de devolución ReturnDeliveryNumber | Identificador único del documento de entrega de devolución. | ||
| Descripción Cuando un cliente devuelve físicamente la mercancía, en SAP se crea un documento de entrega de devolución para gestionar la logística de entrada. Este atributo es el número único de ese documento. Este ID es importante para realizar el seguimiento del movimiento físico de la mercancía devuelta. Conecta los aspectos financieros y logísticos de la devolución y permite analizar en detalle las fases de recepción e inspección de la mercancía. Por qué es importante Proporciona un vínculo clave entre el pedido de devolución y la recepción física de la mercancía, algo fundamental para analizar los tiempos de procesamiento logístico y de almacén. Dónde obtenerlo Es el número del documento de entrega (VBELN) de la tabla de cabecera de entregas (LIKP), donde la categoría de documento indica que se trata de una entrega de devolución. Ejemplos 840000128400001384000014 | |||
| Organización de ventas SalesOrganization | Unidad organizativa responsable de la venta original y de la devolución. | ||
| Descripción La organización de ventas es un elemento clave de la estructura organizativa de SAP que representa una unidad responsable de la venta y distribución de productos y servicios. Se asigna a la transacción de devolución. Este atributo permite filtrar y comparar el proceso de devoluciones entre distintas unidades de negocio, regiones o divisiones. Ayuda a identificar si determinadas organizaciones de ventas tienen tasas de devolución más elevadas o procesos de gestión de devoluciones menos eficientes, lo que proporciona una base para analizar el rendimiento organizativo. Por qué es importante Permite comparar el rendimiento y las tasas del proceso de devoluciones entre distintas unidades de negocio, regiones o canales de ventas. Dónde obtenerlo Se encuentra en el campo de organización de ventas (VKORG) de la tabla de cabecera del pedido de devolución (VBAK). Ejemplos 10002100US01 | |||
| Resultado de la inspección del artículo ItemInspectionOutcome | Resultado de la inspección física del artículo devuelto. | ||
| Descripción Este atributo registra el resultado del proceso de inspección realizado después de recibir la mercancía en el almacén. Entre los resultados habituales se incluyen «Aceptado», «Rechazado: dañado» o «Aceptado: apto para la venta». Estos datos proporcionan un contexto esencial para los pasos posteriores del proceso. Determinan si se emite un reembolso completo, parcial o ningún reembolso. Analizar este resultado ayuda a identificar los motivos de los rechazos y puede proporcionar información útil sobre el embalaje de los productos o los socios de transporte si los artículos sufren daños con frecuencia durante el envío. Por qué es importante Explica el proceso de toma de decisiones que conduce a la aprobación o el rechazo de los reembolsos y proporciona datos valiosos sobre el estado de los artículos y los motivos de los ajustes del reembolso. Dónde obtenerlo Esta información puede registrarse en un lote de inspección del módulo de gestión de calidad (QM), como un estado o código de motivo en la posición de la entrega de devolución (LIPS), o en un campo personalizado. Ejemplos Aceptado - apto para la reventaAceptado - se reacondicionaráRechazado - daño causado por el clienteRechazado - se devolvió el artículo equivocado | |||
Actividades del procesamiento de devoluciones y reembolsos
| Actividad | Descripción | ||
|---|---|---|---|
| Abono creado | Esta actividad corresponde a la creación del documento de facturación oficial que abona en la cuenta del cliente el importe del artículo devuelto. Es un evento explícito que se captura cuando el abono se genera a partir de la solicitud de abono. | ||
| Por qué es importante La creación del abono es un hito financiero crítico. Confirma el importe que se reembolsará y autoriza el inicio del proceso de pago. Dónde obtenerlo Se captura a partir de la creación de un documento de facturación en la tabla VBRK, con una categoría de documento que indica que se trata de un abono. Este documento se vincula a la solicitud de abono en la tabla VBFA. Recopilar El evento se registra al guardar un nuevo documento de facturación de abono, por ejemplo, mediante la transacción VF01. Tipo de evento explicit | |||
| Caso de devolución cerrado | Esta es la actividad final, que indica que el proceso de devolución ha terminado y que no se esperan más acciones para el caso. Normalmente se infiere cuando el documento del pedido de devolución alcanza un estado final o cerrado en el sistema. | ||
| Por qué es importante Este evento define el final del ciclo de vida del proceso y permite calcular el tiempo total de ciclo de principio a fin. Confirma que el caso se ha resuelto por completo. Dónde obtenerlo Se infiere cuando el estado general del pedido de devolución en la tabla VBAK o el de sus posiciones en VBAP alcanza el estado «Completado» o «Cerrado». Esto se determina mediante la configuración de gestión de estados del sistema. Recopilar Se infiere cuando el estado del documento del pedido de devolución cambia a «Completado». Tipo de evento inferred | |||
| Inspección del artículo completada | Representa la finalización de la evaluación de calidad y estado de los productos devueltos. En Advanced Returns Management, suele ser un paso explícito que registra el resultado de la inspección y determina la acción posterior, como emitir un reembolso o enviar el artículo a desguace. | ||
| Por qué es importante La duración y el resultado de la inspección afectan directamente al tiempo de procesamiento del reembolso y a la gestión del inventario. Esta actividad es fundamental para analizar la eficiencia de la inspección y los reprocesos. Dónde obtenerlo En SAP Advanced Returns Management (ARM), puede tratarse de un evento explícito procedente de la transacción de inspección. También puede inferirse a partir de un cambio de estado en la posición de la orden de devolución que indique el resultado de la inspección. Recopilar Se captura a partir de los registros de transacciones o de los cambios de estado relacionados con las actividades de seguimiento logístico en ARM. Tipo de evento explicit | |||
| Mercancía recibida en el almacén | Este evento marca la recepción física del artículo devuelto en el almacén o centro de procesamiento. Se captura explícitamente cuando se ejecuta un Post Goods Receipt (PGR) contra la entrega de devolución y se crea un documento de material. | ||
| Por qué es importante Este es un hito crítico que inicia el cómputo del tiempo de inspección y disposición. Los retrasos anteriores a este punto dependen del cliente, mientras que los posteriores son internos. Dónde obtenerlo Se captura a partir de las tablas de documentos de material MSEG y MKPF para el tipo de movimiento de entrada de mercancías asociado a las devoluciones. La fecha de contabilización (MKPF-BUDAT) indica el momento del evento. Recopilar El evento corresponde a la contabilización de una entrada de mercancías para la entrega de devolución. Tipo de evento explicit | |||
| Reembolso procesado | Esta actividad marca el último paso del proceso de reembolso: se compensa el abono financiero, lo que indica que el pago se ha enviado al cliente. Se infiere a partir de la creación de un documento de compensación en el módulo financiero que liquida el abono pendiente de la cuenta del cliente. | ||
| Por qué es importante Este es el momento en que el cliente recibe realmente el pago. El tiempo transcurrido desde el inicio de la devolución hasta este paso influye considerablemente en la satisfacción del cliente y es clave para medir el cumplimiento del SLA. Dónde obtenerlo Se infiere a partir de la información del documento de compensación en la tabla de posiciones contables BSEG. La fecha de compensación (BSEG-AUGDT) de la posición del cliente asociada al abono indica cuándo se procesó el reembolso. Recopilar Se infiere cuando se completa el campo de fecha de compensación del documento contable asociado al abono. Tipo de evento inferred | |||
| Solicitud de abono creada | Tras una inspección satisfactoria, esta actividad indica la creación de una solicitud para emitir un abono al cliente. Se registra como un nuevo documento de ventas, una solicitud de abono que hace referencia al pedido de devolución original. | ||
| Por qué es importante Este es el desencadenante de la fase de liquidación financiera del proceso de devoluciones. Analizar el tiempo transcurrido entre la inspección y este paso permite evaluar la eficiencia de la transferencia de logística a finanzas. Dónde obtenerlo Se captura a partir de la creación de un documento de ventas en la tabla VBAK con una categoría de documento correspondiente a una solicitud de abono. El vínculo con la devolución se mantiene en la tabla de flujo de documentos VBFA. Recopilar El evento se registra al guardar un nuevo documento de solicitud de abono. Tipo de evento explicit | |||
| Solicitud de devolución iniciada | Este es el punto de partida del proceso de devoluciones, en el que se crea formalmente una orden de devolución en el sistema. El evento se registra explícitamente cuando se guarda en SAP S/4HANA un nuevo documento de ventas del tipo de orden de devolución. | ||
| Por qué es importante Esta actividad marca el inicio oficial del ciclo de vida del caso de devolución. Analizar el tiempo transcurrido desde este evento hasta el cierre es fundamental para medir el tiempo total del ciclo de devolución y la experiencia del cliente. Dónde obtenerlo Este es un evento explícito capturado al crear un documento de ventas en la tabla VBAK, donde la categoría del documento (VBAK-VBTYP) indica que se trata de una orden de devolución. La fecha y hora de creación se encuentran en VBAK-ERDAT. Recopilar El evento se registra al guardar una nueva orden de ventas de devolución, por ejemplo, mediante la transacción VA01. Tipo de evento explicit | |||
| Devolución rechazada | Indica que el artículo devuelto no cumplía los criterios de la política de devoluciones y que se ha denegado la solicitud de reembolso o abono. Normalmente, se captura mediante la aplicación de un estado o código de motivo específico a la posición de la orden de devolución después de la inspección. | ||
| Por qué es importante El seguimiento de los rechazos ayuda a analizar el cumplimiento de las políticas de devolución e identificar los motivos más frecuentes de denegación. Es una ruta de excepción clave del proceso. Dónde obtenerlo Se infiere cuando se establece un motivo de rechazo (VBAP-ABGRU) en la posición del pedido de devolución o cuando se asigna un estado específico durante el proceso de inspección en Advanced Returns Management. Recopilar Se infiere al establecer un motivo de rechazo o un estado específico de «rechazado» en la posición del documento de devolución. Tipo de evento inferred | |||
| Documento contable creado | Este evento ocurre cuando el abono se contabiliza correctamente en el módulo de contabilidad financiera. Crea los asientos correspondientes en el libro mayor y convierte el abono en oficial desde el punto de vista contable. | ||
| Por qué es importante Esta actividad confirma que el abono se ha integrado en el sistema financiero. El tiempo transcurrido entre la creación del abono y su contabilización puede poner de manifiesto problemas en la interfaz entre facturación y finanzas. Dónde obtenerlo Se captura a partir de la creación de una cabecera de documento en la tabla contable BKPF, vinculada al abono en VBRK (VBRK-BELNR). Recopilar El evento se registra cuando el documento de facturación se contabiliza correctamente en Financial Accounting. Tipo de evento explicit | |||
| Entrega de devolución creada | Esta actividad indica la creación de un documento de entrega entrante, que se utiliza para gestionar la recepción física de los productos devueltos. El sistema lo registra como un evento explícito de creación de un documento de entrega que hace referencia a la orden de devolución. | ||
| Por qué es importante Este paso es un hito logístico clave. El tiempo transcurrido entre la aprobación de la devolución y la creación de la entrega muestra la eficiencia con la que se comunica la información de la devolución al almacén o al departamento de recepción. Dónde obtenerlo Se captura a partir de la creación de una cabecera de entrega en la tabla LIKP, vinculada a la orden de devolución anterior mediante la tabla de flujo de documentos VBFA. Recopilar El evento se registra al guardar un nuevo documento de entrega de devolución, por ejemplo, mediante la transacción VL01N. Tipo de evento explicit | |||
| Orden de devolución aprobada | Representa la aprobación o liberación formal de la orden de devolución, lo que permite que avance a la siguiente etapa. Normalmente, se infiere a partir de un cambio de estado en la cabecera o la posición del documento de ventas que indica que se han eliminado los bloqueos. | ||
| Por qué es importante Los pasos de aprobación pueden ser una fuente importante de retrasos. Realizar un seguimiento de esta actividad ayuda a identificar cuellos de botella en la fase inicial de autorización del proceso de devoluciones. Dónde obtenerlo Se infiere a partir de las tablas de gestión de estados o de los campos de estado directamente en las tablas VBAK o VBAP. Un cambio en el estado de liberación o la eliminación de un bloqueo de entrega (VBAP-LIFSP) puede indicar la aprobación. Recopilar Se infiere a partir de un cambio en los campos de estado de la cabecera o la posición de la orden de devolución que indique su liberación o aprobación. Tipo de evento inferred | |||
| Pedido de cambio creado | Esta actividad representa una resolución alternativa en la que, en lugar de emitir un reembolso, se crea un nuevo pedido de ventas para enviar al cliente un artículo de sustitución. Se captura cuando se crea un nuevo pedido de ventas con referencia a la devolución original. | ||
| Por qué es importante Esta actividad ayuda a diferenciar entre las devoluciones con reembolso y las devoluciones con cambio, que siguen rutas de proceso y generan resultados distintos para el cliente. Es clave para analizar las variantes. Dónde obtenerlo Se captura a partir de la creación de un nuevo documento de ventas en VBAK vinculado al pedido de devolución en la tabla de flujo de documentos (VBFA). Recopilar El evento se registra al guardar un nuevo documento de pedido de ventas designado como sustitución. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Verificación de requisitos previos: Asegúrese de que la cuenta de usuario que ejecuta la extracción tenga las autorizaciones necesarias en SAP S/4HANA para acceder a las vistas Core Data Services (CDS) requeridas. Entre las vistas clave se incluyen I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Acceso a la herramienta de consulta: Inicie sesión en su cliente SQL o herramienta de integración de datos preferida que tenga una conexión establecida con la base de datos de SAP S/4HANA. Puede tratarse de herramientas propias de SAP, como SAP Analytics Cloud, o de una plataforma ETL de terceros.
- Definición de los parámetros de consulta: Antes de ejecutar la consulta, debe modificar el SQL proporcionado. Localice los valores de marcador de posición y sustitúyalos por los parámetros correctos de su entorno. Esto incluye definir
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]y otros filtros de tipo de documento o código de sociedad. - Ejecución de la consulta de extracción: Copie la consulta SQL completa y ejecútela en su herramienta. La consulta está diseñada para recopilar todas las actividades especificadas en un único conjunto de datos, uniendo los resultados de varias instrucciones select.
- Comprensión de la lógica de la consulta: Cada bloque
SELECTde la estructuraUNION ALLse encarga de extraer una actividad específica. Une varias vistas CDS para recopilar los atributos necesarios, asigna una cadena fija aActivityNamey selecciona la marca de tiempo relevante paraEventTime. - Revisión de los datos sin procesar: Cuando finalice la consulta, revise brevemente el resultado. Compruebe que el número de filas sea razonable y que las columnas clave, como
ReturnCaseId,ActivityNameyEventTime, estén completas según lo esperado. - Transformación de datos: La consulta está estructurada para producir un formato plano de Registro de eventos. Normalmente no se necesitan transformaciones estructurales importantes. Sin embargo, puede que deba ajustar los formatos de marca de tiempo o los tipos de datos según los requisitos del sistema de destino.
- Exportación del Registro de eventos: Exporte el conjunto de resultados de la consulta como un archivo CSV. Asegúrese de que el archivo utilice codificación UTF-8 para evitar problemas con los caracteres, especialmente en nombres de usuario o descripciones de productos.
- Carga en la herramienta de Process Mining: El archivo CSV resultante ya está listo para cargarse en su plataforma de Process Mining, como ProcessMind. Asigne las columnas del archivo a los campos correspondientes de la herramienta, por ejemplo,
ReturnCaseIda Case ID,ActivityNamea Activity yEventTimea Timestamp.
Configuración
- Requisitos previos: El usuario que ejecuta la extracción necesita autorizaciones de visualización para los objetos relacionados con documentos de ventas (VBAK), entregas (LIKP), facturación (VBRK) y contabilidad (BSEG, BKPF). Es esencial tener acceso a las vistas CDS subyacentes.
- Filtros del alcance de datos: Es fundamental filtrar la consulta por tipos de documento específicos para aislar el proceso de devoluciones. Configure los marcadores de posición para los tipos de pedido de devolución, por ejemplo, «RE», los tipos de solicitud de nota de crédito, por ejemplo, «G2», y los tipos de pedido de cambio, por ejemplo, «SO». También se recomienda filtrar por
CompanyCodeoSalesOrganizationpara limitar el alcance de los datos. - Filtrado por intervalo de fechas: Para controlar el rendimiento y el volumen de datos, aplique siempre un filtro de intervalo de fechas. Comience con un periodo reciente de 3 a 6 meses. La consulta utiliza la fecha de creación del pedido de devolución inicial (
I_SalesDocument.CreationDate) como condición de filtro principal. - Consideraciones de rendimiento: Esta es una consulta completa que une varias vistas CDS de gran tamaño. Su ejecución puede consumir muchos recursos en el sistema S/4HANA de origen. Programe la extracción fuera del horario de mayor actividad para minimizar el impacto. Para conjuntos de datos muy grandes, considere estrategias de carga incremental.
a Consulta de ejemplo sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Pasos
- Confirme que dispone de acceso directo de lectura al esquema de SAP HANA que contiene los datos relevantes de ventas, entregas, facturación, documentos de material, inspecciones, estados y contabilidad. El esquema, las vistas y los nombres de campo exactos varían según la implementación de SAP S/4HANA, por lo que debe sustituir cada marcador entre corchetes por los objetos y campos configurados en su sistema.
- Defina el alcance de la extracción mediante [Start date], [End date], [Company Code filter] y [Return document type filter]. Utilice inicialmente un periodo móvil de tres a seis meses y amplíelo solo después de validar el rendimiento y la integridad de los datos.
- Identifique la población de pedidos de devolución en [Your sales document header table] y [Your sales document item table]. Restrinja la población a los tipos de documento de pedido de devolución configurados en [Your return order document type configuration]. Conserve el número y la posición del pedido de devolución como vínculo principal con los documentos posteriores.
- Resuelva el flujo de documentos desde los pedidos de devolución hasta las entregas entrantes de devolución, las solicitudes de nota de crédito, los pedidos de cambio y las notas de crédito mediante [Your document flow table or view]. No dé por hecho que el flujo de documentos se almacena en VBAK o VBAP. Configure los campos de relación según el modelo de flujo de documentos utilizado en el sistema.
- Extraiga los eventos explícitos de creación de los registros de cabecera y posición de documentos pertinentes. Extraiga los eventos de aprobación, rechazo, inspección, cierre, entrada de mercancías, contabilidad y compensación de las fuentes configuradas de estados, inspecciones, documentos de material, contabilidad y compensación. Cada actividad debe emitirse como una fila de evento independiente, ya que ProcessMind no infiere eventos.
- Normalice las marcas de tiempo a un tipo de marca de tiempo y una zona horaria coherentes en la base de datos. Utilice la precedencia de marcas de tiempo de eventos configurada para cada actividad. Si solo hay disponibles una fecha y una hora, combínelas utilizando la zona horaria del sistema configurada en [Your system time zone].
- Complete ReturnCaseId para cada evento. Utilice el número del pedido de devolución de origen o el identificador de caso de devolución configurado si Advanced Returns Management almacena una clave de caso independiente. Los eventos que no puedan vincularse a un caso de devolución deben excluirse o enviarse a una salida de excepciones para su corrección.
- Complete las columnas obligatorias ReturnCaseId, ActivityName, EventTime, SourceSystemId y LastDataUpdateTimestamp. Complete las columnas recomendadas cuando estén disponibles, incluidas EventEndTime, UserName, ReturnReason, RefundAmount, ProductId y CustomerId. Mantenga una fila por cada aparición de actividad y no agregue las actividades en una única fila por caso.
- Valide el resultado mediante las comprobaciones de validationSteps. Confirme que estén presentes los doce nombres de actividad, que las marcas de tiempo estén ordenadas de forma plausible dentro de cada caso y que las referencias de documentos coincidan con las tablas de origen.
- Exporte el resultado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Conserve los nombres exactos de las columnas, utilice una única fila de encabezado, mantenga las marcas de tiempo en un formato ISO inequívoco y cargue el Registro de eventos con ReturnCaseId configurado como identificador del caso y ActivityName como columna de actividad.
Configuración
- Intervalo de fechas: Comience con tres a seis meses. Utilice los parámetros [Start date] y [End date] e incluya suficiente historial para capturar los casos iniciados antes del periodo seleccionado pero completados dentro de él.
- Población de devoluciones: Filtre por los tipos de documento de pedido de devolución configurados en [Your return order document type configuration]. No codifique un tipo de documento de forma fija a menos que se haya verificado en el sistema de destino.
- Filtros organizativos: Aplique [Company Code filter], organización de ventas, canal de distribución, división, centro o filtros de cliente solo cuando sea necesario. Confirme que los filtros no excluyan documentos posteriores entre sociedades o dentro de un grupo empresarial.
- Objetos de origen: Sustituya los marcadores [Your table name] y [Your view name] por tablas SAP S/4HANA o vistas CDS aprobadas. VBAK, VBAP, VBRK y VBRP pueden estar disponibles en la implementación, pero su uso y sus ampliaciones deben verificarse antes de la ejecución.
- Gestión de marcas de tiempo: Configure los campos de marca de tiempo de origen y la zona horaria para cada actividad. Almacene EventTime y EventEndTime de forma coherente, preferiblemente en UTC o en la zona horaria de ProcessMind acordada.
- Interpretación de estados: Configure los valores de estado, códigos de motivo, resultados de inspección e indicadores de cierre exactos que representan la aprobación, el rechazo, la finalización de la inspección y el cierre del caso en el sistema.
- Identificador del sistema de origen: Sustituya [Source system identifier] por un valor estable, como el identificador del sistema SAP utilizado por la plataforma de extracción.
- Marca de tiempo de actualización: Sustituya [Extraction timestamp] por la marca de tiempo en la que comenzó la ejecución de la consulta o se creó la instantánea del origen. Utilice el mismo valor para todas las filas de una ejecución de extracción, salvo que se necesiten marcas de tiempo de actualización por fila.
- Rendimiento: Restrinja la población inicial de devoluciones antes de unir fuentes grandes de flujo de documentos, contabilidad, documentos de material y estados. Utilice campos indexados o que permitan podar particiones, evite los análisis sin restricciones y materialice resultados intermedios solo cuando el administrador de la base de datos lo haya aprobado.
- Extracción incremental: Para las ejecuciones periódicas, utilice [Last successful extraction timestamp] y una ventana de solapamiento controlada para capturar actualizaciones tardías. Elimine duplicados mediante ReturnCaseId, ActivityName, la clave del documento de origen y EventTime.
- Autorizaciones y requisitos previos: Obtenga autorización de lectura para todos los objetos y campos de origen configurados, aprobación para el acceso directo a la base de datos y confirmación de que los componentes SAP y las funciones de Advanced Returns Management necesarios están activos, cuando corresponda.
- Protección de datos: Restrinja los campos de clientes y financieros al mínimo necesario, siga los controles de privacidad de su organización y proteja los archivos exportados.
a Consulta de ejemplo sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; ¿Listo para comenzar?
Con este Template, cuenta con los conocimientos básicos necesarios para extraer y analizar sus datos de procesamiento de devoluciones y reembolsos. Comience hoy su camino hacia la excelencia operativa.
Optimice ahora el procesamiento de devoluciones y reembolsos en SAP S/4HANA
Identifique las ineficiencias, reduzca el tiempo de ciclo un 30 % y aumente la satisfacción.
No necesita tarjeta de crédito. Comience a optimizar hoy.