Su Template de datos para la tramitación de devoluciones y reembolsos
Su Template de datos para la tramitación de devoluciones y reembolsos
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Recomendaciones para la extracción
Atributos del procesamiento de devoluciones y reembolsos
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | Marca de tiempo precisa que indica cuándo ocurrió una actividad específica. | ||
| Descripción La hora del evento registra la fecha y la hora en que el sistema registró un evento empresarial. Esta marca de tiempo es fundamental para ordenar cronológicamente las actividades y realizar 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 detectar cuellos de botella, supervisar el cumplimiento de los SLA y comprender la dinámica temporal del proceso de devolución. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular todas las duraciones y los tiempos de ciclo, e identificar demoras en el proceso. Dónde obtenerlo Suele obtenerse 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 los 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 de devolución de un 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 de una devolución. Cada solicitud de devolución de un cliente recibe un ID único, que permite hacer 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, las variantes del proceso y los cuellos de botella, al conectar eventos distintos como «Solicitud de devolución iniciada», «Productos recibidos» y «Reembolso procesado» en una cronología coherente para cada devolución. Por qué es importante Es la clave esencial para hacer un seguimiento de la devolución de principio a fin y realizar análisis de cada caso, como calcular el tiempo de ciclo y descubrir variantes del proceso. Dónde obtenerlo Por lo general, es el número del documento de ventas (VBELN) de la tabla de cabecera de pedidos de devolución VBAK, donde la categoría del documento (VBTYP) indica que se trata de una devolución. Ejemplos 600001896000019060000191 | |||
| Nombre de la actividad ActivityName | Nombre de una actividad o evento empresarial específico que tuvo lugar durante el proceso de devolución y reembolso. | ||
| Descripción Este atributo describe un paso o hito 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 la frecuencia de estas actividades es fundamental en Process Mining. Permite visualizar el mapa del proceso, identificar las rutas habituales y poco frecuentes, y detectar actividades que se repiten con frecuencia, lo que puede indicar retrabajo o ineficiencias. Por qué es importante Las actividades son la base del mapa del proceso y permiten visualizar y analizar el flujo, los cuellos de botella y las variaciones. Dónde obtenerlo Los nombres de las actividades suelen derivarse de una combinación de datos, como los cambios de estado de documentos en tablas como VBUK/VBUP, los eventos de creación en tablas de cabecera como VBAK (documentos de ventas) y BKPF (documentos contables), y los estados de movimientos de mercancías en MSEG. Ejemplos Solicitud de devolución iniciadaProductos recibidos en el almacénNota de crédito creadaReembolso 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 donde se originaron los datos del evento. En este proceso, normalmente sería el ID de la instancia de SAP S/4HANA. En entornos con varios sistemas, este campo es fundamental para el linaje de datos, la resolución de problemas y la integridad de los datos. Permite distinguir 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 Aporta contexto esencial sobre el origen y el linaje de los datos, especialmente en entornos con varios sistemas, y garantiza su trazabilidad y fiabilidad. 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 los 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 la hora de la última extracción o actualización de los datos. Proporciona metadatos sobre la actualidad del conjunto de datos analizado. Es importante para saber si el análisis de Process Mining se basa en datos recientes. Los usuarios pueden comprobar qué tan actualizados están los datos, algo especialmente relevante para la supervisión operativa y los Dashboards que hacen seguimiento de casos en curso. Por qué es importante Indica qué tan actualizados están los datos, un aspecto fundamental para garantizar que los análisis y los Dashboards se basen en información reciente. Dónde obtenerlo Por lo general, la herramienta ETL o de canalización de datos genera y asigna esta marca de tiempo al 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 cuándo terminó una actividad y se utiliza para calcular su duración. | ||
| Descripción Mientras que StartTime (EventTime) marca el inicio de una actividad, EventEndTime indica cuándo termina. En muchos eventos generados por el sistema, las horas de inicio y fin coinciden porque el evento ocurre de forma instantánea. Sin embargo, este atributo es fundamental para las actividades que tienen una duración medible, como «Inspección del artículo». Este atributo permite calcular directamente el tiempo de procesamiento de una actividad. Es fundamental para analizar el rendimiento y determinar qué pasos concretos, 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, algo clave para identificar ineficiencias en pasos específicos del proceso. Dónde obtenerlo A menudo se calcula a partir de otros datos. Algunas actividades pueden tener un campo independiente. Lo más habitual es que corresponda a la hora de inicio 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 entidad específica de los datos maestros de clientes. Analizar las devoluciones por cliente ayuda a identificar patrones, como tasas de devolución inusualmente altas, que podrían indicar un comportamiento fraudulento o insatisfacción. También permite segmentar el proceso de devolución según el tipo, el valor o el historial del cliente y adaptar el nivel de servicio. Por qué es importante Vincula las devoluciones con clientes específicos 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 de pedidos 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 específico 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 poco claras o problemas de fabricación. Estos datos ayudan a las empresas a tomar decisiones informadas 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 específicos 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 | Importe final del reembolso emitido al cliente. | ||
| Descripción Este atributo representa el importe que se abonó o reembolsó realmente al cliente al finalizar el proceso de devolución. Este valor se registra en documentos financieros, como las notas de crédito. Es una métrica financiera clave para distintos análisis. El Dashboard «Análisis de discrepancias en el importe del reembolso» la utiliza para compararla con el importe solicitado. También permite segmentar las devoluciones por valor e identificar si las de importe elevado siguen un proceso distinto o tardan más en resolverse. Por qué es importante Registra el impacto financiero de las devoluciones y es esencial para analizar la precisión de los reembolsos, identificar casos de importe elevado y comprender los costes generales. Dónde obtenerlo Se obtiene del campo de valor neto (NETWR) del documento de nota de crédito, 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 la devolución ReturnReason | Motivo que indica el cliente para devolver el artículo. | ||
| Descripción Este atributo registra el motivo que indica el cliente para devolver el artículo, como «Artículo defectuoso», «Talla incorrecta» o «Ya no lo necesita». Por lo general, 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 venta. Ofrece información directa sobre la insatisfacción de los clientes y ayuda a priorizar las mejoras para reducir la tasa general de devoluciones. Por qué es importante Aporta información clave sobre los motivos de las devoluciones y permite analizar las causas raíz para abordar problemas de calidad de los productos, errores de preparación de pedidos o diferencias entre las expectativas de los clientes y el producto. Dónde obtenerlo Suele almacenarse en el campo ABGRU (motivo de rechazo de documentos de ventas) de la tabla de posiciones de pedidos de ventas de devolución (VBAP). Ejemplos 001 - Calidad deficiente002 - Daños durante el transporte005 - Artículo enviado incorrectamente | |||
| 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 una nota de crédito. En SAP, suele registrarse en campos que indican quién creó o modificó un documento. El análisis por usuario ayuda a identificar a las personas o los equipos con mejor rendimiento, las necesidades de formación y la distribución de la carga de trabajo. También es esencial para investigar desviaciones, ya que vincula las acciones del proceso con personas específicas y facilita las tareas de cumplimiento y auditoría. Por qué es importante Asocia las actividades del proceso con usuarios específicos 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, por ejemplo, en ERNAM (creado por) de VBAK (pedidos de ventas), LIKP (entregas) y BKPF (documentos contables). Los datos de usuario pueden complementarse con la tabla maestra de usuarios USR21. Ejemplos CBROWNASMITHWF_BATCH | |||
| Agente de tramitación ProcessingAgent | Agente o grupo de recursos específico responsable de realizar una actividad manual. | ||
| Descripción Este atributo identifica a la persona o al equipo que realizó una tarea. 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. Resulta útil para el Dashboard «Eficiencia en la aprobación de reembolsos», que permite analizar el desempeño de distintos agentes o equipos. Ayuda a comprender cómo se distribuye la carga de trabajo, detectar necesidades de formación y reconocer a los agentes o equipos con mejores resultados, que pueden compartir sus buenas prácticas. Por qué es importante Permite analizar el desempeño de cada agente o equipo, gestionar la carga de trabajo, detectar oportunidades de formación y mejorar la eficiencia. Dónde obtenerlo Esta información puede estar disponible en las funciones de interlocutor comercial de SAP si se asignan agentes. También puede obtenerse del departamento o el 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 de la política aplicable. Por ejemplo, la lógica puede comprobar si la devolución se inició dentro del plazo permitido o si el motivo es válido para el producto. Este atributo respalda directamente el Dashboard «Resumen del cumplimiento de la política de devoluciones». Cuantifica las tasas de cumplimiento y permite examinar los casos que no cumplen la política para entender las causas de las desviaciones y aplicar las políticas con mayor eficacia. Por qué es importante Cuantifica el cumplimiento de las reglas de negocio y ayuda a identificar y reducir las infracciones de las políticas que pueden afectar a la rentabilidad o generar 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 tramitó dentro del plazo objetivo del acuerdo de nivel de servicio (SLA). | ||
| Descripción Este atributo calculado comprueba si la actividad «Reembolso tramitado» tuvo lugar en la fecha objetivo del SLA de reembolso o antes. Para cada caso, indica de forma sencilla si se cumplió el SLA. Es la métrica principal del Dashboard «Seguimiento del cumplimiento del SLA de reembolsos» y del KPI «Tasa de cumplimiento del SLA de reembolsos». Ayuda a medir el desempeño respecto a los compromisos con los clientes e identifica los casos que no cumplieron las expectativas, lo que permite analizar las causas de las demoras. Por qué es importante Mide directamente el desempeño respecto 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 la hora del evento de la actividad «Reembolso tramitado» con la «Fecha objetivo del SLA de reembolso» de cada caso. Ejemplos truefalse | |||
| Es automatizada IsAutomated | Indicador que señala si una actividad la realizó un sistema o una persona. | ||
| Descripción Este atributo booleano distingue las actividades que un sistema ejecuta automáticamente, como un flujo de trabajo o un proceso en segundo plano, de las que realiza manualmente una persona usuaria. Es esencial para calcular el KPI «Tasa de aprobación automatizada de reembolsos» y detectar oportunidades para aumentar la automatización. Al filtrar las tareas manuales, las empresas pueden centrar sus iniciativas de mejora de procesos en las áreas donde la automatización podría aportar mayores beneficios en rapidez, coste y precisión. Por qué es importante Distingue las tareas manuales de las automatizadas, algo fundamental para detectar oportunidades de automatización y medir el impacto de la transformación digital. Dónde obtenerlo Normalmente se obtiene 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 | |||
| Es retrabajo IsRework | Indicador que señala si una actividad de un caso repite 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 una nota de crédito, se cancela y luego se vuelve a crear. Este atributo es esencial para el Dashboard «Análisis del retrabajo en la tramitación de reembolsos» y el KPI «Tasa de retrabajo en reembolsos». Ayuda a cuantificar las ineficiencias del proceso al señalar las actividades propensas a errores o que requieren varios intentos, y permite detectar áreas que necesitan mejores controles o formación. Por qué es importante Señala las ineficiencias y los errores del proceso al identificar el trabajo repetido, lo que permite aplicar mejoras específicas para reducir el desperdicio y las demoras. Dónde obtenerlo Esta marca suele calcularla la herramienta de Process Mining o puede calcularse previamente durante la transformación de datos. Comprueba si el nombre de la misma actividad ya apareció antes en el mismo caso. Ejemplos truefalse | |||
| Estado de la orden de devolución ReturnOrderStatus | Estado general actual del caso de devolución. | ||
| Descripción Este atributo muestra el estado general del caso de devolución en un momento determinado, por ejemplo, «Abierto», «En curso» o «Cerrado». A menudo se trata de un estado agregado que se obtiene del último hito importante completado. Es esencial para el Dashboard «Estado actual de los casos de devolución», que ofrece una vista operativa de la carga de trabajo y la distribución de los casos en curso. Ayuda a los responsables a saber cuántos casos hay en cada etapa del proceso y facilita una mejor asignación de recursos y gestión de la carga de trabajo. Por qué es importante Muestra en qué etapa del proceso se encuentra cada caso, algo esencial para los Dashboards operativos que hacen seguimiento de la carga de trabajo y el estado actuales. Dónde obtenerlo Se obtiene de los campos de estado de los documentos pertinentes. Por ejemplo, del estado de cabecera (GBSTK) o del estado de posición (LFSTK) de la orden de venta relacionada (VBUK/VBUP) o de los documentos de entrega. Ejemplos Pendiente de recepción de mercancíasPendiente de inspecciónPendiente de reembolsoCerrado | |||
| Fecha objetivo del SLA de reembolso RefundSlaTargetDate | Fecha límite para tramitar el reembolso del caso de devolución. | ||
| Descripción Este atributo define la fecha límite del acuerdo de nivel de servicio (SLA) para tramitar el reembolso. Por lo general, esta fecha se calcula según las reglas de negocio, por ejemplo, a partir de un número determinado de días desde la aprobación de la devolución o la recepción de los productos. Este campo sirve de base para el Dashboard «Seguimiento del cumplimiento del SLA de reembolsos» y el KPI asociado. Permite hacer un seguimiento proactivo de los casos que corren el riesgo de incumplir el SLA y analizar las causas de las demoras, lo que contribuye a mejorar la satisfacción del cliente. Por qué es importante Proporciona una referencia para medir el cumplimiento del SLA, hacer un seguimiento del desempeño, priorizar los casos pendientes desde hace más tiempo y mejorar la satisfacción del cliente. Dónde obtenerlo Casi siempre es un campo calculado. La lógica se basa en una fecha clave, como la fecha de creación de la solicitud de devolución, más un plazo definido por las reglas de negocio. Este plazo puede depender de factores como el tipo de cliente o el motivo de la 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 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 si se cumplen reglas como los plazos de devolución o los requisitos sobre el estado del artículo, y señalar las desviaciones para analizarlas. Por qué es importante Permite comprobar automáticamente el cumplimiento de las reglas de negocio y ayuda a garantizar que las devoluciones se tramiten 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 calcularlo según la lógica de negocio, 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 al inicio del proceso. | ||
| Descripción Este atributo registra el valor de los productos que se devuelven según la solicitud inicial. Sirve como referencia para compararlo con el importe final del reembolso. Este campo es necesario para el Dashboard «Análisis de discrepancias en el importe del reembolso». Comparar el importe solicitado con el importe realmente reembolsado ayuda a identificar situaciones como reembolsos parciales por daños en los artículos, cargos por reposición de existencias u otros ajustes, y garantiza la precisión y la transparencia financieras. Por qué es importante Sirve como referencia para medir la precisión de los reembolsos y ayuda a identificar y analizar las diferencias entre los importes previstos y los reales. Dónde obtenerlo Suele obtenerse del valor neto de los artículos de la orden de venta inicial de devolución. Corresponde al valor neto (NETWR) de las posiciones correspondientes de la tabla VBAP. Ejemplos 125.501050.0049.99 | |||
| Número de entrega de devolución ReturnDeliveryNumber | Identificador único del documento de entrega de devolución. | ||
| Descripción Cuando un cliente devuelve productos físicamente, SAP crea un documento de entrega de devolución para gestionar la logística de entrada. Este atributo contiene el número único de ese documento. Este ID es importante para hacer un seguimiento del movimiento físico de los productos devueltos. Conecta los aspectos financieros y logísticos de la devolución y permite analizar en detalle las fases de recepción de mercancías e inspección del proceso. Por qué es importante Vincula el pedido de devolución con la recepción física de los productos, algo fundamental para analizar la logística y los tiempos de procesamiento en el 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 del documento indica que se trata de una entrega de devolución. Ejemplos 840000128400001384000014 | |||
| Número de nota de crédito CreditMemoNumber | Identificador único del documento de nota de crédito que autoriza el reembolso. | ||
| Descripción La nota de crédito es el documento de facturación que abona oficialmente en la cuenta del cliente el importe de los artículos devueltos. Este atributo contiene el número único de ese documento financiero. El seguimiento del número de nota de crédito es esencial para analizar la liquidación financiera del proceso de devolución. Marca un hito importante, ya que suele dar inicio al pago 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 hacer un seguimiento de las etapas finales del proceso y realizar 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 del documento indica que se trata de una nota de crédito. Ejemplos 900003459000034690000347 | |||
| 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 a la unidad responsable de vender y distribuir productos y servicios. Se asigna a la transacción de devolución. Este atributo permite filtrar y comparar el proceso de devolución entre distintas unidades de negocio, regiones o divisiones. Ayuda a identificar si algunas organizaciones de ventas tienen tasas de devolución más altas o gestionan las devoluciones con menor eficiencia, y sirve de base para analizar el rendimiento de la organización. Por qué es importante Permite comparar el rendimiento y las tasas del proceso de devolución entre distintas unidades de negocio, regiones o canales de venta. Dónde obtenerlo Se encuentra en el campo de la organización de ventas (VKORG) de la tabla de cabecera de pedidos 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 de la inspección realizada después de recibir los productos en el almacén. Algunos resultados habituales son «Aceptado», «Rechazado - Dañado» o «Aceptado - Reacondicionable». Estos datos aportan un contexto fundamental para los pasos posteriores del proceso. Determinan si se concede un reembolso total, parcial o ninguno. Analizar el resultado ayuda a identificar los motivos de rechazo y puede aportar retroalimentación sobre el embalaje de los productos o las empresas de transporte si los artículos sufren daños frecuentes durante el envío. Por qué es importante Explica cómo se decide aprobar o rechazar los reembolsos y aporta datos valiosos sobre el estado de los artículos y los motivos de los ajustes en los importes. Dónde obtenerlo Esta información puede registrarse en un lote de inspección del módulo de gestión de calidad (QM), como estado o código de motivo en la posición de entrega de devolución (LIPS), o en un campo personalizado. Ejemplos Aceptado - ReacondicionableAceptado - Para reacondicionarRechazado - Daño causado por el clienteRechazado - Se devolvió un artículo incorrecto | |||
Actividades del procesamiento de devoluciones y reembolsos
| Actividad | Descripción | ||
|---|---|---|---|
| Caso de devolución cerrado | Esta es la actividad final: indica que el proceso de devolución ha concluido y que no se esperan más acciones para el caso. Por lo general, se infiere cuando el documento del pedido de devolución alcanza un estado final de cierre en el sistema. | ||
| Por qué es importante Este evento marca el final del ciclo de vida del proceso y permite calcular el tiempo de ciclo total de principio a fin. Confirma que el caso se resolvió por completo. Dónde obtenerlo Se infiere cuando el estado general del pedido de devolución en la tabla VBAK o de sus posiciones en VBAP alcanza el estado «Completo» o «Cerrado». Esto depende de la configuración de gestión de estados del sistema. Capturar Se infiere cuando el estado del documento del pedido de devolución cambia a «Completo». 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 desechar el artículo. | ||
| 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 las inspecciones y el retrabajo. Dónde obtenerlo En SAP Advanced Returns Management (ARM), puede registrarse como un evento explícito desde la transacción de inspección. También puede inferirse a partir de un cambio de estado en la posición del pedido de devolución que indique el resultado de la inspección. Capturar Se registra 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 | |||
| Nota de crédito creada | 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 registra cuando se genera la nota de crédito a partir de la solicitud correspondiente. | ||
| Por qué es importante La creación de la nota de crédito es un hito financiero crítico. Confirma el importe que se reembolsará y autoriza el inicio del proceso de pago. Dónde obtenerlo Se registra 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 es una nota de crédito. El documento se vincula a la solicitud de nota de crédito en la tabla VBFA. Capturar El evento se registra al guardar un nuevo documento de facturación de nota de crédito (por ejemplo, mediante la transacción VF01). Tipo de evento explicit | |||
| Productos recibidos 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 registra explícitamente cuando se contabiliza una entrada de mercancías (PGR) para 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 determinación del destino. Las demoras anteriores a este punto dependen del cliente; las posteriores son internas. Dónde obtenerlo Se registra a partir de los documentos de material de las tablas 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 cuándo ocurrió el evento. Capturar 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 paso final del proceso de reembolso: se compensa el abono financiero, lo que indica que se envió el pago 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 en la cuenta del cliente. | ||
| Por qué es importante Este es el momento en que el cliente recibe 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 de los SLA. Dónde obtenerlo Se infiere a partir de la información del documento de compensación en la tabla de partidas individuales de contabilidad financiera BSEG. La fecha de compensación (BSEG-AUGDT) de la partida del cliente asociada a la nota de crédito indica cuándo se procesó el reembolso. Capturar Se infiere cuando se completa el campo de fecha de compensación del documento contable asociado a la nota de crédito. Tipo de evento inferred | |||
| Solicitud de devolución iniciada | Este es el punto de partida del proceso de devolución: aquí se crea formalmente en el sistema un pedido de devolución. SAP S/4HANA registra explícitamente este evento cuando se guarda un nuevo documento de ventas del tipo pedido 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 entre este evento y el cierre es fundamental para medir el tiempo de ciclo total de la devolución y la experiencia del cliente. Dónde obtenerlo Este evento explícito se registra al crear un documento de ventas en la tabla VBAK, cuando la categoría del documento (VBAK-VBTYP) indica que se trata de un pedido de devolución. La fecha de creación se encuentra en VBAK-ERDAT. Capturar El evento se registra al guardar un nuevo pedido de ventas de devolución (por ejemplo, mediante la transacción VA01). Tipo de evento explicit | |||
| Solicitud de nota de crédito creada | Después de una inspección satisfactoria, esta actividad marca la creación de una solicitud para emitir un abono al cliente. Se registra como un nuevo documento de ventas, una solicitud de nota de crédito que hace referencia al pedido de devolución original. | ||
| Por qué es importante Este paso inicia la liquidación financiera del proceso de devolución. Analizar el tiempo transcurrido desde la inspección hasta este punto permite evaluar la eficiencia del traspaso de logística a finanzas. Dónde obtenerlo Se registra 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 nota de crédito. El vínculo con la devolución se mantiene en la tabla de flujo de documentos VBFA. Capturar El evento se registra al guardar un nuevo documento de solicitud de nota de crédito. Tipo de evento explicit | |||
| Devolución rechazada | Indica que el artículo devuelto no cumple los criterios de la política de devoluciones y que se denegó la solicitud de reembolso o abono. Por lo general, se registra al asignar un estado o código de motivo específico a la posición del pedido 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 habituales de denegación. Es una ruta de excepción importante del proceso. Dónde obtenerlo Se infiere cuando se asigna un motivo de rechazo (VBAP-ABGRU) a la posición del pedido de devolución o un estado específico durante la inspección en Advanced Returns Management. Capturar Se infiere cuando se asigna un motivo de rechazo o un estado específico de «rechazado» a la posición del documento de devolución. Tipo de evento inferred | |||
| Documento contable creado | Este evento ocurre cuando la nota de crédito se contabiliza correctamente en el módulo de contabilidad financiera. Se crean los asientos correspondientes en el libro mayor y el abono queda registrado oficialmente desde el punto de vista contable. | ||
| Por qué es importante Esta actividad confirma que el abono se integró en el sistema financiero. El tiempo transcurrido entre la creación de la nota de crédito y su contabilización puede revelar problemas en la interfaz entre facturación y finanzas. Dónde obtenerlo Se registra a partir de la creación de una cabecera de documento en la tabla contable BKPF, vinculada a la nota de crédito en VBRK (VBRK-BELNR). Capturar El evento se registra cuando el documento de facturación se contabiliza correctamente en Contabilidad financiera. Tipo de evento explicit | |||
| Entrega de devolución creada | Esta actividad indica que se creó un documento de entrega entrante, que se utiliza para gestionar la recepción física de los productos devueltos. El sistema registra explícitamente la creación de un documento de entrega que hace referencia al pedido de devolución. | ||
| Por qué es importante Este paso es un hito logístico importante. El tiempo transcurrido entre la aprobación de la devolución y la creación de la entrega permite evaluar 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 registra a partir de la creación de una cabecera de entrega en la tabla LIKP, vinculada al pedido de devolución anterior mediante la tabla de flujo de documentos VBFA. Capturar 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 | |||
| Pedido de cambio creado | Esta actividad representa una alternativa al reembolso: se crea un nuevo pedido de ventas para enviar al cliente un artículo de reemplazo. Se registra cuando se crea un nuevo pedido de ventas que hace referencia a la devolución original. | ||
| Por qué es importante Esta actividad permite distinguir las devoluciones con reembolso de 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 registra 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). Capturar El evento se registra al guardar un nuevo documento de pedido de ventas designado como reemplazo. Tipo de evento explicit | |||
| Pedido de devolución aprobado | Representa la aprobación o liberación formal del pedido de devolución, que permite avanzar a la siguiente etapa. Por lo general, se infiere a partir de un cambio de estado en la cabecera o en la posición del documento de ventas que indica que se han eliminado los bloqueos. | ||
| Por qué es importante Las etapas de aprobación pueden ser una fuente importante de demoras. El seguimiento de esta actividad ayuda a identificar cuellos de botella en la fase inicial de autorización del proceso de devolución. Dónde obtenerlo Se infiere a partir de las tablas de gestión de estados o de los campos de estado de 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 que se aprobó el pedido. Capturar Se infiere a partir de un cambio en los campos de estado de la cabecera o de la posición del pedido de devolución que indique su liberación o aprobación. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Verifique los 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 de Core Data Services (CDS) requeridas. Entre las vistas principales se incluyen I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Acceda a la herramienta de consulta: Inicie sesión en el cliente SQL o la herramienta de integración de datos que prefiera y que tenga conexión con la base de datos de SAP S/4HANA. Puede utilizar herramientas de SAP, como SAP Analytics Cloud, o una plataforma ETL de terceros.
- Configure los parámetros de consulta: Antes de ejecutarla, debe modificar la consulta SQL proporcionada. Busque 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 empresa. - Ejecute la consulta de extracción: Copie la consulta SQL completa y ejecútela en su herramienta. La consulta reúne todas las actividades especificadas en un único conjunto de datos mediante la unión de los resultados de varias instrucciones select.
- Comprenda la lógica de la consulta: Cada bloque
SELECTde la estructuraUNION ALLextrae una actividad específica. Combina varias vistas CDS para obtener los atributos necesarios, asigna una cadena fija aActivityNamey selecciona la marca de tiempo correspondiente paraEventTime. - Revise los datos sin procesar: Cuando termine la consulta, revise brevemente los resultados. Compruebe que haya una cantidad razonable de filas y que las columnas clave, como
ReturnCaseId,ActivityNameyEventTime, tengan los valores esperados. - Transforme los datos: La consulta genera un registro de eventos con formato plano, por lo que normalmente no se necesitan transformaciones estructurales importantes. Sin embargo, quizá deba ajustar los formatos de marca de tiempo o los tipos de datos según los requisitos del sistema de destino.
- Exporte el registro de eventos: Exporte el resultado de la consulta como un archivo CSV. Asegúrese de que el archivo use codificación UTF-8 para evitar problemas con caracteres, especialmente en nombres de usuario o descripciones de productos.
- Cargue los datos en una 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 ID del caso,ActivityNamea Actividad yEventTimea la marca de tiempo.
Configuración
- Requisitos previos: El usuario que ejecute 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 indispensable tener acceso a las vistas CDS subyacentes.
- Filtros del alcance de los 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'), las solicitudes de nota de crédito (por ejemplo, 'G2') y los pedidos de cambio (por ejemplo, 'SO'). También se recomienda filtrar por
CompanyCodeoSalesOrganizationpara limitar el alcance de los datos. - Filtro por intervalo de fechas: Para controlar el rendimiento y el volumen de datos, aplique siempre un filtro por intervalo de fechas. Comience con datos de los últimos 3 a 6 meses. La consulta utiliza como filtro principal la fecha de creación del pedido de devolución inicial (
I_SalesDocument.CreationDate). - Consideraciones de rendimiento: Esta consulta completa combina varias vistas CDS de gran tamaño. Su ejecución puede consumir muchos recursos del sistema S/4HANA de origen. Programe la extracción fuera de las horas de mayor actividad para reducir el impacto. Si el conjunto de datos es muy grande, considere estrategias de carga incremental.
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 de lectura directo al esquema de SAP HANA que contiene los datos pertinentes 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 ello, sustituya cada marcador de posición entre corchetes por los objetos y campos configurados en su sistema.
- Defina el alcance de la extracción con
[Start date],[End date],[Company Code filter]y[Return document type filter]. Para la extracción inicial, utilice un período móvil de tres a seis meses y amplíelo solo después de validar el rendimiento y la integridad de los datos. - Identifique los pedidos de devolución en
[Your sales document header table]y[Your sales document item table]. Limite el conjunto 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. - Determine el flujo documental 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 sentado que el flujo documental se almacena en VBAK o VBAP. Configure los campos de relación según el modelo de flujo documental del sistema. - Extraiga los eventos de creación explícitos de los registros pertinentes de cabecera y posición de los documentos. Extraiga los eventos de aprobación, rechazo, inspección, cierre, recepción de mercancías, contabilidad y compensación de las fuentes configuradas de estados, inspecciones, documentos de material, contabilidad y compensación. Cada actividad debe generarse como una fila de evento independiente, ya que ProcessMind no infiere eventos.
- Normalice las marcas de tiempo para que utilicen un tipo de marca de tiempo y una zona horaria coherentes. Aplique la prioridad de marcas de tiempo configurada para cada actividad. Si solo dispone de fecha y hora, combínelas usando la zona horaria del sistema configurada en
[Your system time zone]. - Asigne un valor a ReturnCaseId para cada evento. Utilice el número del pedido de devolución de origen o el identificador de caso configurado si Advanced Returns Management almacena una clave de caso independiente. Excluya los eventos que no puedan vincularse a un caso de devolución o inclúyalos en un archivo de excepciones para corregirlos.
- Incluya las columnas obligatorias ReturnCaseId, ActivityName, EventTime, SourceSystemId y LastDataUpdateTimestamp. Añada las columnas recomendadas cuando estén disponibles, como EventEndTime, UserName, ReturnReason, RefundAmount, ProductId y CustomerId. Mantenga una fila por cada ocurrencia de actividad y no agrupe las actividades en una sola fila por caso.
- Valide los resultados con las comprobaciones de validationSteps. Confirme que estén presentes los doce nombres de actividad, que las marcas de tiempo sigan un orden plausible en cada caso y que las referencias a documentos coincidan con las tablas de origen.
- Exporte el resultado como CSV con codificación UTF-8 u otro formato tabular compatible con ProcessMind. Conserve los nombres exactos de las columnas, use una sola 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 un período de tres a seis meses. Utilice los parámetros
[Start date]y[End date]e incluya suficiente historial para captar los casos iniciados antes del período seleccionado que se hayan completado durante este. - Conjunto de devoluciones: Filtre por los tipos de documento de pedido de devolución configurados en
[Your return order document type configuration]. No establezca un tipo de documento fijo sin verificarlo en el sistema de destino. - Filtros organizativos: Aplique filtros de
[Company Code filter], organización de ventas, canal de distribución, división, centro o cliente solo cuando sea necesario. Confirme que los filtros no excluyan documentos posteriores entre sociedades o dentro de una misma sociedad. - Objetos de origen: Sustituya los marcadores de posición
[Your table name]y[Your view name]por tablas o vistas CDS aprobadas de SAP S/4HANA. Es posible que la implementación incluya VBAK, VBAP, VBRK y VBRP, pero debe verificar su uso y sus extensiones antes de ejecutar la extracción. - Gestión de marcas de tiempo: Configure los campos de marca de tiempo de origen y la zona horaria para cada actividad. Mantenga un formato coherente para EventTime y EventEndTime, preferiblemente UTC o la zona horaria acordada para ProcessMind.
- 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 que utiliza la plataforma de extracción. - Marca de tiempo de actualización: Sustituya
[Extraction timestamp]por la marca de tiempo en que comenzó la ejecución de la consulta o se creó la instantánea de origen. Use el mismo valor en todas las filas de una ejecución, salvo que se requieran marcas de tiempo de actualización por fila. - Rendimiento: Limite el conjunto inicial de devoluciones antes de combinarlo con fuentes grandes de flujo documental, contabilidad, documentos de material y estados. Utilice campos indexados o que permitan podar particiones, evite los escaneos sin restricciones y materialice resultados intermedios solo con la aprobación de la persona administradora de la base de datos.
- Extracción incremental: Para ejecuciones periódicas, utilice
[Last successful extraction timestamp]y un intervalo de solapamiento controlado para captar actualizaciones tardías. Elimine duplicados usando 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 de SAP y las funciones de Advanced Returns Management necesarias estén activos, cuando corresponda.
- Protección de datos: Limite los campos de clientes y financieros a lo estrictamente necesario, siga los controles de privacidad de la organización y proteja los archivos exportados.
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; ¿Todo listo para comenzar?
Con este Template, cuenta con los conocimientos básicos para extraer y analizar los datos del procesamiento de devoluciones y reembolsos. Comience hoy mismo a mejorar sus procesos.
Optimice ahora el procesamiento de devoluciones y reembolsos en SAP S/4HANA
Detecte ineficiencias, reduzca el tiempo de ciclo un 30 % y aumente la satisfacción.
No se requiere tarjeta de crédito. Comience a optimizar hoy mismo.