Seu Template de dados para processamento de devoluções e reembolsos
Seu Template de dados para processamento de devoluções e reembolsos
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração
Atributos do processamento de devoluções e reembolsos
| Nome | Descrição | ||
|---|---|---|---|
| Horário do evento EventTime | Data e hora exatas em que uma atividade específica ocorreu. | ||
| Descrição O horário do evento registra a data e a hora em que um evento de negócio foi registrado no sistema. Esse registro é essencial para ordenar as atividades cronologicamente e realizar todas as análises baseadas em tempo. No Process Mining, este atributo é usado para calcular os tempos de ciclo entre atividades, identificar a duração de cada etapa e analisar a performance do processo ao longo do tempo. Ele é a base para descobrir gargalos, monitorar a aderência ao SLA e entender a dinâmica temporal do processo de devolução. Por que isso importa Este registro de data e hora é essencial para ordenar eventos, calcular durações e tempos de ciclo e identificar atrasos no processo. Onde encontrar Geralmente, vem dos campos de data e hora associados à criação de documentos ou a mudanças de status, como ERDAT (data de criação) e ERZET (hora de criação) em tabelas como VBAK, LIKP e BKPF, ou da data de lançamento (BUDAT) em documentos contábeis. Exemplos 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID do caso de devolução ReturnCaseId | Identificador exclusivo de um processo de devolução de cliente, que vincula todas as atividades relacionadas, do início ao encerramento. | ||
| Descrição O ID do caso de devolução é o identificador principal que reúne todos os eventos e atividades de uma única devolução. Cada solicitação de devolução de cliente recebe um ID exclusivo, que permite acompanhar o processo de ponta a ponta. No Process Mining, este atributo é fundamental para reconstruir o fluxo do processo. Ele permite analisar a duração dos casos, as variantes do processo e os gargalos, conectando eventos distintos, como “Solicitação de devolução iniciada”, “Produtos recebidos” e “Reembolso processado”, em uma linha do tempo coerente para cada devolução. Por que isso importa Esta é a chave essencial para acompanhar uma devolução do início ao fim e viabilizar análises por caso, incluindo o tempo de ciclo e a descoberta de variantes do processo. Onde encontrar Em geral, é o número do documento de vendas (VBELN) do cabeçalho do pedido de devolução na tabela VBAK, em que a categoria do documento (VBTYP) indica uma devolução. Exemplos 600001896000019060000191 | |||
| Nome da atividade ActivityName | Nome de uma atividade ou evento específico do negócio que ocorreu no processo de devolução e reembolso. | ||
| Descrição Este atributo descreve uma etapa ou um marco do ciclo de vida da devolução. As atividades representam o trabalho realizado, como “Pedido de devolução aprovado” ou “Inspeção do item concluída”. Elas são derivadas de mudanças de status, criação de documentos ou ações específicas de usuários registradas no SAP S/4HANA. Analisar a sequência e a frequência dessas atividades é a base do Process Mining. Isso ajuda a visualizar o mapa do processo, identificar caminhos comuns e raros e localizar atividades repetidas com frequência, que podem indicar retrabalho ou ineficiências. Por que isso importa As atividades formam a base do mapa do processo e permitem visualizar e analisar o fluxo de trabalho, os gargalos e as variações. Onde encontrar Os nomes das atividades geralmente são derivados de uma combinação de dados, como mudanças de status de documentos em tabelas como VBUK/VBUP, eventos de criação em tabelas de cabeçalho como VBAK (documentos de vendas) e BKPF (documentos contábeis), e status de movimentação de mercadorias em MSEG. Exemplos Solicitação de devolução iniciadaProdutos recebidos no armazémNota de crédito criadaReembolso processado | |||
| ID do sistema de origem SourceSystemId | Identificador do sistema de origem de onde os dados foram extraídos. | ||
| Descrição Este atributo especifica o sistema de registro de onde vieram os dados do evento. Neste processo, geralmente é o ID da instância SAP S/4HANA. Em ambientes com vários sistemas, este campo é essencial para a linhagem dos dados, a solução de problemas e a garantia da integridade dos dados. Ele ajuda a diferenciar os dados quando as devoluções são processadas em diferentes instâncias de ERP ou integradas a sistemas externos, como um sistema de gestão de armazém. Por que isso importa Fornece contexto essencial sobre a origem e a linhagem dos dados, especialmente em ambientes com vários sistemas, garantindo a rastreabilidade e a confiabilidade dos dados. Onde encontrar Este valor costuma ser estático e configurado durante a extração dos dados. Ele pode ser obtido nas informações administrativas do sistema SAP, como o ID do sistema (SID). Exemplos S4H_PROD_100S4Q_DEV_200 | |||
| Última atualização dos dados LastDataUpdateTimestamp | Data e hora da última atualização ou extração dos dados deste evento. | ||
| Descrição Este atributo registra a data e a hora da última extração ou atualização dos dados. Ele fornece metadados sobre a atualidade do conjunto de dados analisado. É importante para entender se a análise de Process Mining está atualizada. Os usuários podem verificar a atualidade dos dados, algo especialmente relevante para o monitoramento operacional e os Dashboards que acompanham casos em andamento. Por que isso importa Indica a atualidade dos dados, essencial para garantir que as análises e os Dashboards usem informações atualizadas. Onde encontrar Em geral, essa informação é gerada e registrada no conjunto de dados durante a extração, pela ferramenta de ETL ou pelo pipeline de dados. Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Horário de término do evento EventEndTime | Registro de data e hora que marca a conclusão de uma atividade e permite calcular sua duração. | ||
| Descrição Enquanto StartTime (EventTime) marca o início de uma atividade, EventEndTime marca seu término. Em muitos eventos gerados pelo sistema, os horários de início e término são iguais, pois o evento ocorre instantaneamente. No entanto, este atributo é essencial para atividades com duração mensurável, como “Inspeção do item”. Este atributo permite calcular diretamente o tempo de processamento da atividade. Isso é fundamental para a análise de performance e ajuda a identificar quais etapas específicas, e não apenas os intervalos entre elas, consomem mais tempo. Por que isso importa Permite calcular com precisão a duração de cada atividade, o que é essencial para identificar ineficiências em etapas específicas do processo. Onde encontrar Muitas vezes, esse valor é derivado. Para algumas atividades, pode haver um campo separado. Mais comumente, ele corresponde ao StartTime da atividade seguinte no caso. Exemplos 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| ID do cliente CustomerId | Identificador exclusivo do cliente que iniciou a devolução. | ||
| Descrição Este atributo identifica o cliente que solicitou a devolução. Ele vincula a instância do processo a uma parte específica dos dados mestres de clientes. Analisar as devoluções por cliente ajuda a identificar padrões, como taxas de devolução excepcionalmente altas, que podem indicar fraude ou insatisfação. Também permite segmentar o processo de devolução por tipo, valor ou histórico do cliente e oferecer níveis de serviço adequados a cada perfil. Por que isso importa Vincula as devoluções a clientes específicos, permitindo analisar o comportamento dos clientes, fazer segmentações e identificar quem devolve produtos com frequência. Onde encontrar Encontrado no campo de número do cliente (KUNNR) na tabela de cabeçalho do pedido de devolução (VBAK). Exemplos CUST-001234CUST-005678CUST-009012 | |||
| ID do produto ProductId | Identificador exclusivo do item devolvido. | ||
| Descrição Este atributo especifica o material ou produto devolvido. Ele vincula o processo de devolução a um item específico do catálogo de produtos. Analisar as devoluções por produto é fundamental para identificar itens com altas taxas de devolução, o que pode indicar defeitos de qualidade, descrições inadequadas ou problemas de fabricação. Esses dados ajudam as empresas a tomar decisões fundamentadas sobre o design dos produtos, a gestão de fornecedores e a estratégia de estoque. Por que isso importa Vincula o processo de devolução a produtos específicos, permitindo analisar as taxas de devolução por item e identificar problemas de qualidade ou descrição. Onde encontrar Encontrado no campo de número do material (MATNR) na tabela de itens do pedido de devolução (VBAP) ou na tabela de itens da entrega de devolução (LIPS). Exemplos FG-10023HW-45981SW-LICENSE-PREM | |||
| Motivo da devolução ReturnReason | Motivo informado pelo cliente para devolver o item. | ||
| Descrição Este atributo registra o motivo informado pelo cliente para a devolução, como “Item com defeito”, “Tamanho incorreto” ou “Não preciso mais”. Em geral, o cliente seleciona uma opção de uma lista predefinida de códigos de motivo ao iniciar a devolução. Analisar os motivos das devoluções é essencial para identificar problemas de qualidade dos produtos, melhorar as descrições ou aperfeiçoar os processos de vendas. Isso oferece insights diretos sobre a insatisfação dos clientes e ajuda a priorizar melhorias para reduzir a taxa geral de devoluções. Por que isso importa Fornece insights importantes sobre os motivos das devoluções e permite fazer uma análise de causa raiz para tratar problemas de qualidade dos produtos, erros de atendimento ou diferenças entre as expectativas dos clientes e os produtos. Onde encontrar Geralmente armazenado na tabela de itens do pedido de venda de devolução (VBAP), no campo ABGRU (motivo de rejeição de documentos de vendas). Exemplos 001 - Qualidade ruim002 - Danificado no transporte005 - Item enviado incorretamente | |||
| Nome do usuário UserName | ID do usuário que executou a atividade. | ||
| Descrição Este atributo identifica o usuário ou agente do sistema responsável por concluir uma tarefa, como aprovar uma devolução ou criar uma nota de crédito. No SAP, essa informação costuma ser registrada em campos que indicam quem criou ou alterou um documento. A análise por usuário ajuda a identificar profissionais ou equipes com alta performance, necessidades de treinamento e distribuição da carga de trabalho. Também é essencial para investigar desvios, pois vincula as ações do processo a pessoas específicas e apoia as iniciativas de conformidade e auditoria. Por que isso importa Vincula as atividades do processo a usuários específicos, permitindo analisar a performance da equipe, a carga de trabalho e a conformidade. Onde encontrar Geralmente encontrado em tabelas de cabeçalho de documentos, como ERNAM (criado por) na VBAK (pedidos de venda), na LIKP (entregas) e na BKPF (documentos contábeis). Os dados dos usuários podem ser complementados com a tabela mestre de usuários USR21. Exemplos CBROWNASMITHWF_BATCH | |||
| Valor do reembolso RefundAmount | Valor monetário final do reembolso concedido ao cliente. | ||
| Descrição Este atributo representa o valor efetivamente creditado ou reembolsado ao cliente após a conclusão do processo de devolução. Esse valor é registrado em documentos financeiros, como notas de crédito. Esta é uma métrica financeira importante para várias análises. Ela é essencial no Dashboard “Análise de divergências no valor do reembolso”, que compara o valor final com o valor solicitado. Também permite segmentar as devoluções por valor e identificar se as de maior valor seguem um fluxo diferente ou demoram mais para serem resolvidas. Por que isso importa Registra o impacto financeiro das devoluções e é essencial para analisar a precisão dos reembolsos, identificar casos de alto valor e entender os custos gerais. Onde encontrar Obtido do campo de valor líquido (NETWR) do documento de nota de crédito, encontrado em tabelas como VBRK (cabeçalho do documento de faturamento) ou BSEG (segmento do documento contábil). Exemplos 125.50999.0049.99 | |||
| Agente responsável pelo processamento ProcessingAgent | Agente ou grupo de recursos responsável por realizar uma atividade manual. | ||
| Descrição Este atributo identifica a pessoa ou equipe que realizou uma determinada tarefa. Ele pode ser mais específico que «Nome de usuário», pois indica uma função ou equipe, especialmente em um ambiente de serviços compartilhados. Esse dado é útil no Dashboard «Eficiência na aprovação de reembolsos», que analisa a performance de diferentes agentes ou equipes. Ele ajuda a entender a distribuição da carga de trabalho, identificar necessidades de treinamento e reconhecer profissionais ou equipes com boas práticas que podem ser compartilhadas. Por que isso importa Permite analisar a performance por agente ou equipe, ajudando a gerenciar a carga de trabalho, identificar oportunidades de treinamento e melhorar a eficiência. Onde encontrar Essas informações podem estar disponíveis nas funções de Business Partner do SAP, caso os agentes estejam atribuídos, ou podem ser obtidas a partir do departamento ou da função do usuário na estrutura organizacional de RH. Exemplos Suporte de nível 1Equipe de inspeção do armazémDepartamento financeiro - contas a pagar | |||
| Cumprimento da política de devolução ReturnPolicyAdherence | Indicador que informa se o caso de devolução está em conformidade com a política definida. | ||
| Descrição Este atributo booleano calculado indica se uma devolução atende aos critérios da política aplicável. A lógica pode verificar, por exemplo, se a devolução foi iniciada dentro do prazo permitido ou se o motivo informado é válido para o produto. Este atributo dá suporte direto ao Dashboard «Visão geral da conformidade com a política de devolução». Ele quantifica os índices de conformidade e permite aprofundar a análise dos casos fora da política para entender os motivos dos desvios, ajudando a aplicar as regras com mais eficácia. Por que isso importa Quantifica a conformidade com as regras de negócio e ajuda a identificar e reduzir violações de políticas que podem afetar a lucratividade ou gerar exceções no processo. Onde encontrar Calculado com base nas regras de negócio. Por exemplo: (data de início da devolução - data da compra original) <= [prazo permitido para devolução]. Para isso, são necessárias a data da compra original e as regras da política. Exemplos truefalse | |||
| Cumprimento do SLA de reembolsos RefundSlaAdherence | Indicador que informa se o reembolso foi processado dentro do prazo definido no Acordo de Nível de Serviço (SLA). | ||
| Descrição Este atributo calculado verifica se a atividade «Reembolso processado» ocorreu até a «Data-limite do SLA do reembolso». Para cada caso, ele indica de forma simples se o SLA foi cumprido ou não. Esta é a métrica principal do Dashboard «Monitoramento do cumprimento do SLA de reembolsos» e do KPI «Taxa de cumprimento do SLA de reembolsos». Ela ajuda a medir a performance em relação aos compromissos com os clientes e identifica os casos que não atenderam às expectativas, permitindo analisar as causas raiz dos atrasos. Por que isso importa Mede diretamente a performance em relação aos compromissos assumidos com os clientes, sendo um indicador essencial da qualidade do serviço e da satisfação dos clientes. Onde encontrar Calculado comparando o EventTime da atividade «Reembolso processado» com o campo «RefundSlaTargetDate» de cada caso. Exemplos truefalse | |||
| Data-limite do SLA do reembolso RefundSlaTargetDate | Data-limite para processar o reembolso do caso de devolução. | ||
| Descrição Este atributo define o prazo do Acordo de Nível de Serviço (SLA) para processar o reembolso. Em geral, essa data é calculada com base nas regras de negócio, por exemplo, um determinado número de dias após a aprovação da devolução ou o recebimento dos produtos. Este campo é a base do Dashboard «Monitoramento do cumprimento do SLA de reembolsos» e do KPI associado. Ele permite acompanhar proativamente os casos com risco de descumprir o SLA e analisar as causas raiz dos atrasos, ajudando, em última instância, a melhorar a satisfação dos clientes. Por que isso importa Serve de referência para medir a conformidade com o SLA, ajudando a monitorar a performance, priorizar casos antigos e melhorar a satisfação dos clientes. Onde encontrar Quase sempre, esse campo é calculado. A lógica usa uma data-chave, como a data de criação da solicitação de devolução, e soma um período definido pelas regras de negócio, que pode variar conforme fatores como o tipo de cliente ou o motivo da devolução. Exemplos 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| É automatizado IsAutomated | Indicador que informa se uma atividade foi realizada por um sistema ou por uma pessoa. | ||
| Descrição Este atributo booleano diferencia as atividades executadas automaticamente por um sistema, como um fluxo de trabalho ou uma tarefa em segundo plano, daquelas realizadas manualmente por um usuário. Ele é essencial para calcular o KPI «Taxa de aprovação automatizada de reembolsos» e identificar oportunidades para ampliar a automação. Ao filtrar as tarefas manuais, as empresas podem concentrar os esforços de melhoria de processos nas áreas em que a automação pode trazer mais benefícios em velocidade, custo e precisão. Por que isso importa Diferencia tarefas manuais de automatizadas, o que é essencial para identificar oportunidades de automação e medir o impacto da transformação digital. Onde encontrar Geralmente, esse dado é obtido com base no nome de usuário. Por exemplo, se o usuário for «WF_BATCH» ou outro ID de sistema, a atividade será marcada como automatizada. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador que informa se uma atividade do caso é a repetição de uma atividade anterior. | ||
| Descrição Este atributo booleano calculado identifica ocorrências de retrabalho, quando uma atividade é realizada mais de uma vez no mesmo caso. Por exemplo, quando é preciso repetir a inspeção de um item ou quando uma nota de crédito é criada, cancelada e criada novamente. Este atributo é essencial para o Dashboard «Análise de retrabalho no processamento de reembolsos» e para o KPI «Taxa de retrabalho em reembolsos». Ele ajuda a quantificar as ineficiências do processo, destacando atividades sujeitas a erros ou que exigem várias tentativas e apontando áreas que precisam de controles ou treinamento melhores. Por que isso importa Evidencia ineficiências e erros no processo ao sinalizar tarefas repetidas, permitindo melhorias direcionadas para reduzir desperdícios e atrasos. Onde encontrar Em geral, esse indicador é calculado pela própria ferramenta de Process Mining ou pode ser pré-calculado na transformação dos dados. Ele verifica se o mesmo nome de atividade já apareceu antes no mesmo caso. Exemplos truefalse | |||
| ID da política de devolução ReturnPolicyId | Identificador da política de devolução aplicável a este caso específico. | ||
| Descrição Este atributo indica qual política de devolução ou conjunto de regras se aplica à transação. As políticas podem variar conforme o tipo de produto, o segmento de clientes ou o tempo decorrido desde a compra. Esses dados são essenciais para a «Visão geral da conformidade com a política de devolução». Ao associar cada caso a uma política, o sistema pode verificar automaticamente se as regras estão sendo cumpridas, como os prazos de devolução e as condições exigidas para os itens, e sinalizar desvios para análise. Por que isso importa Permite verificar automaticamente a conformidade com as regras de negócio, ajudando a garantir que as devoluções sejam processadas de forma consistente e de acordo com a política. Onde encontrar Esse campo geralmente não é padrão no SAP e pode precisar ser calculado com base na lógica de negócio e em dados como tipo de produto, cliente e data da venda. Se houver uma implementação personalizada, ele poderá ser armazenado em um campo customizado. Exemplos PADRÃO-30DIASELETRÔNICOS-GARANTIA-90DIASVENDA FINAL-DEFEITO | |||
| Número da entrega de devolução ReturnDeliveryNumber | Identificador exclusivo do documento de entrega de devolução. | ||
| Descrição Quando um cliente devolve produtos fisicamente, uma entrega de devolução é criada no SAP para gerenciar a logística de entrada. Este atributo é o número exclusivo desse documento. Este ID é importante para acompanhar a movimentação física dos produtos devolvidos. Ele conecta os aspectos financeiros e logísticos da devolução e permite analisar detalhadamente as etapas de recebimento e inspeção. Por que isso importa Faz a ligação entre o pedido de devolução e o recebimento físico dos produtos, essencial para analisar a logística e os tempos de processamento no armazém. Onde encontrar Este é o número do documento de entrega (VBELN) da tabela de cabeçalho de entrega (LIKP), em que a categoria do documento indica uma entrega de devolução. Exemplos 840000128400001384000014 | |||
| Número da nota de crédito CreditMemoNumber | Identificador exclusivo do documento de nota de crédito, que autoriza o reembolso. | ||
| Descrição A nota de crédito é o documento de faturamento que credita oficialmente a conta do cliente pelos itens devolvidos. Este atributo é o número exclusivo desse documento financeiro. Acompanhar o número da nota de crédito é essencial para analisar a etapa de liquidação financeira do processo de devolução. Ele marca um marco crítico, muitas vezes dando início ao pagamento do reembolso, e é necessário para a conciliação financeira e as auditorias. Por que isso importa Representa a transação financeira oficial do reembolso. É essencial para acompanhar as etapas finais do processo e realizar auditorias financeiras. Onde encontrar Este é o número do documento de faturamento (VBELN) da tabela de cabeçalho do documento de faturamento (VBRK), em que a categoria do documento indica uma nota de crédito. Exemplos 900003459000034690000347 | |||
| Organização de vendas SalesOrganization | Unidade organizacional responsável pela venda original e pela devolução. | ||
| Descrição A organização de vendas é um elemento importante da estrutura organizacional do SAP, que representa uma unidade responsável pela venda e distribuição de produtos e serviços. Ela é atribuída à transação de devolução. Este atributo permite filtrar e comparar o processo de devolução entre diferentes unidades de negócio, regiões ou divisões. Ele ajuda a identificar se determinadas organizações de vendas têm taxas de devolução mais altas ou processos de tratamento menos eficientes, servindo de base para a análise de performance organizacional. Por que isso importa Permite comparar a performance e as taxas do processo de devolução entre diferentes unidades de negócio, regiões ou canais de venda. Onde encontrar Encontrado no campo de organização de vendas (VKORG) na tabela de cabeçalho do pedido de devolução (VBAK). Exemplos 10002100US01 | |||
| Resultado da inspeção do item ItemInspectionOutcome | Resultado da inspeção física do item devolvido. | ||
| Descrição Este atributo registra o resultado da inspeção realizada após o recebimento dos produtos no armazém. Entre os resultados mais comuns estão «Aceito - pode ser revendido», «Rejeitado - danificado» e «Aceito - precisa de recondicionamento». Esses dados fornecem um contexto importante para as etapas seguintes do processo. O resultado determina se o reembolso será integral, parcial ou se não haverá reembolso. Analisá-lo ajuda a identificar os motivos das rejeições e pode gerar feedback sobre a embalagem dos produtos ou as transportadoras, caso os itens sofram danos frequentes durante o transporte. Por que isso importa Explica os critérios usados para aprovar ou rejeitar reembolsos e fornece dados importantes sobre as condições dos itens e os motivos dos ajustes nos valores reembolsados. Onde encontrar Essas informações podem ser registradas em um lote de inspeção do módulo de gestão da qualidade (QM) ou como um status ou código de motivo no item da entrega de devolução (LIPS). Também podem estar em um campo customizado. Exemplos Aceito - pode ser revendidoAceito - precisa de recondicionamentoRejeitado - danos causados pelo clienteRejeitado - item devolvido incorreto | |||
| Status do pedido de devolução ReturnOrderStatus | Status geral atual do caso de devolução. | ||
| Descrição Este atributo mostra o status geral do caso de devolução em determinado momento, como «Aberto», «Em andamento» ou «Fechado». Em geral, ele é um status agregado, calculado com base na última etapa importante concluída. Esse dado é essencial para o Dashboard «Status atual dos casos de devolução», que oferece uma visão operacional da carga de trabalho e da distribuição dos casos. Ele ajuda os gestores a entender quantos casos estão em cada etapa do processo, facilitando a alocação de recursos e o gerenciamento da carga de trabalho. Por que isso importa Mostra em que etapa do processo cada caso está, informação essencial para os Dashboards operacionais que acompanham a carga de trabalho e o status atual. Onde encontrar Obtido a partir dos campos de status dos documentos relevantes. Por exemplo, do status do cabeçalho (GBSTK) ou do item (LFSTK) no pedido de venda relacionado (VBUK/VBUP) ou nos documentos de entrega. Exemplos Aguardando recebimento dos produtosAguardando inspeçãoAguardando reembolsoFechado | |||
| Valor do reembolso solicitado RequestedRefundAmount | Valor do reembolso solicitado ou previsto no início do processo. | ||
| Descrição Este atributo registra o valor dos produtos devolvidos conforme a solicitação inicial de devolução. Ele serve de referência para comparar com o valor final do reembolso. Este campo é necessário especificamente para o Dashboard “Análise de divergências no valor do reembolso”. Comparar o valor solicitado com o valor efetivamente reembolsado ajuda a identificar problemas, como reembolsos parciais devido a danos nos itens, taxas de reposição de estoque ou outros ajustes, garantindo precisão e transparência financeiras. Por que isso importa Serve como referência para medir a precisão dos reembolsos e ajuda a identificar e analisar diferenças entre os valores esperados e os efetivamente reembolsados. Onde encontrar Geralmente, é obtido a partir do valor líquido dos itens no pedido de venda inicial da devolução. Esse valor corresponde ao valor líquido (NETWR) dos itens relacionados na tabela VBAP. Exemplos 125.501050.0049.99 | |||
Atividades do processamento de devoluções e reembolsos
| Atividade | Descrição | ||
|---|---|---|---|
| Caso de devolução encerrado | Esta é a atividade final, que indica que o processo de devolução foi concluído e que não são esperadas outras ações para o caso. Em geral, isso é inferido quando o documento do pedido de devolução chega a um status final de encerramento no sistema. | ||
| Por que isso importa Este evento define o fim do ciclo de vida do processo e permite calcular o tempo total de ciclo de ponta a ponta. Ele confirma que o caso foi totalmente resolvido. Onde encontrar Inferido quando o status geral do pedido de devolução na tabela VBAK ou de seus itens na VBAP chega a um estado de conclusão ou encerramento. Isso é determinado pela configuração de gerenciamento de status do sistema. Coleta Inferido quando o status do documento do pedido de devolução muda para concluído. Tipo de evento inferred | |||
| Inspeção do item concluída | Representa a conclusão da avaliação de qualidade e das condições dos produtos devolvidos. No Advanced Returns Management, essa costuma ser uma etapa explícita que registra o resultado da inspeção e determina a ação seguinte, como reembolsar ou descartar o item. | ||
| Por que isso importa A duração e o resultado da inspeção afetam diretamente o tempo de processamento do reembolso e a gestão do estoque. Esta atividade é essencial para analisar a eficiência da inspeção e o retrabalho. Onde encontrar No SAP Advanced Returns Management (ARM), este pode ser um evento explícito da transação de inspeção. Também pode ser inferido por uma mudança de status no item do pedido de devolução que indique o resultado da inspeção. Coleta Registrado nos logs de transação ou nas mudanças de status relacionadas às atividades de acompanhamento logístico no ARM. Tipo de evento explicit | |||
| Nota de crédito criada | Esta é a criação do documento oficial de faturamento que credita a conta do cliente pelo item devolvido. O evento é registrado explicitamente quando a nota de crédito é gerada a partir da solicitação de nota de crédito. | ||
| Por que isso importa A criação da nota de crédito é um marco financeiro crítico. Ela confirma o valor a ser reembolsado e autoriza o início do processo de pagamento. Onde encontrar Registrado na criação de um documento de faturamento na tabela VBRK, com uma categoria de documento que indica uma nota de crédito. O documento é vinculado à solicitação de nota de crédito na tabela VBFA. Coleta O evento é registrado quando um novo documento de faturamento de nota de crédito é salvo, por exemplo, usando a transação VF01. Tipo de evento explicit | |||
| Produtos recebidos no armazém | Este evento marca o recebimento físico do item devolvido no armazém ou centro de processamento. Ele é registrado explicitamente quando uma entrada de mercadorias (PGR) é lançada para a entrega de devolução, gerando um documento de material. | ||
| Por que isso importa Este é um marco crítico, que inicia a contagem do tempo para inspeção e destinação. Os atrasos anteriores a este ponto dependem do cliente; os posteriores são internos. Onde encontrar Registrado nas tabelas de documentos de material MSEG e MKPF para o tipo de movimento de entrada de mercadorias associado às devoluções. A data de lançamento (MKPF-BUDAT) indica o momento do evento. Coleta O evento corresponde ao lançamento de uma entrada de mercadorias para a entrega de devolução. Tipo de evento explicit | |||
| Reembolso processado | Esta atividade marca a etapa final do processo de reembolso, quando o crédito financeiro é compensado, indicando que o pagamento foi enviado ao cliente. Isso é inferido pela criação de um documento de compensação no módulo financeiro, que liquida o crédito em aberto na conta do cliente. | ||
| Por que isso importa Este é o momento em que o cliente efetivamente recebe o pagamento. O tempo entre o início da devolução e esta etapa influencia muito a satisfação do cliente e é essencial para medir a aderência ao SLA. Onde encontrar Inferido a partir das informações do documento de compensação na tabela de itens de linha da contabilidade financeira BSEG. A data de compensação (BSEG-AUGDT) no item de linha do cliente associado à nota de crédito indica quando o reembolso foi processado. Coleta Inferido quando o campo de data de compensação é preenchido no documento contábil associado à nota de crédito. Tipo de evento inferred | |||
| Solicitação de devolução iniciada | Este é o ponto de partida do processo de devolução, quando um pedido de devolução é criado formalmente no sistema. O evento é registrado explicitamente quando um novo documento de vendas do tipo pedido de devolução é salvo no SAP S/4HANA. | ||
| Por que isso importa Esta atividade marca o início oficial do ciclo de vida do caso de devolução. Analisar o tempo entre este evento e o encerramento é essencial para medir o tempo total de ciclo da devolução e a experiência do cliente. Onde encontrar Este é um evento explícito, registrado na criação de um documento de vendas na tabela VBAK, quando a categoria do documento (VBAK-VBTYP) indica um pedido de devolução. A data de criação é VBAK-ERDAT. Coleta O evento é registrado quando um novo pedido de venda de devolução é salvo, por exemplo, usando a transação VA01. Tipo de evento explicit | |||
| Solicitação de nota de crédito criada | Após uma inspeção bem-sucedida, esta atividade marca a criação de uma solicitação para conceder crédito ao cliente. Ela é registrada como um novo documento de vendas, uma solicitação de nota de crédito vinculada ao pedido de devolução original. | ||
| Por que isso importa Esta etapa dá início à parte de liquidação financeira do processo de devolução. Analisar o tempo entre a inspeção e esta etapa revela a eficiência do handoff entre logística e finanças. Onde encontrar Registrado na criação de um documento de vendas na tabela VBAK com uma categoria de documento de solicitação de nota de crédito. O vínculo com a devolução é mantido na tabela de fluxo de documentos VBFA. Coleta O evento é registrado quando um novo documento de solicitação de nota de crédito é salvo. Tipo de evento explicit | |||
| Devolução rejeitada | Indica que o item devolvido não atende aos critérios da política de devolução e que a solicitação de reembolso ou crédito foi negada. Em geral, isso é registrado pela aplicação de um status ou código de motivo específico ao item do pedido de devolução após a inspeção. | ||
| Por que isso importa Acompanhar as rejeições ajuda a analisar a conformidade com as políticas de devolução e a identificar motivos frequentes para a negativa. Este é um caminho de exceção importante no processo. Onde encontrar Inferido quando um motivo de rejeição (VBAP-ABGRU) é definido no item do pedido de devolução ou quando um status específico é atribuído durante o processo de inspeção no Advanced Returns Management. Coleta Inferido quando um motivo de rejeição ou um status específico de rejeição é definido no item do documento de devolução. Tipo de evento inferred | |||
| Documento contábil criado | Este evento ocorre quando a nota de crédito é lançada com sucesso no módulo de contabilidade financeira. Isso cria os lançamentos correspondentes no razão geral e oficializa o crédito do ponto de vista contábil. | ||
| Por que isso importa Esta atividade confirma que o crédito foi integrado ao sistema financeiro. O tempo entre a criação da nota de crédito e o lançamento contábil pode revelar problemas na interface entre faturamento e finanças. Onde encontrar Registrado na criação de um cabeçalho de documento na tabela contábil BKPF, vinculado à nota de crédito na VBRK (VBRK-BELNR). Coleta O evento é registrado quando o documento de faturamento é lançado com sucesso na contabilidade financeira. Tipo de evento explicit | |||
| Entrega de devolução criada | Esta atividade indica a criação de um documento de entrega de entrada, usado para gerenciar o recebimento físico dos produtos devolvidos. O sistema registra explicitamente a criação de um documento de entrega vinculado ao pedido de devolução. | ||
| Por que isso importa Esta etapa é um marco logístico importante. O tempo entre a aprovação da devolução e a criação da entrega mostra a eficiência da comunicação das informações sobre a devolução ao armazém ou à área de recebimento. Onde encontrar Registrado na criação de um cabeçalho de entrega na tabela LIKP, vinculado ao pedido de devolução anterior por meio da tabela de fluxo de documentos VBFA. Coleta O evento é registrado quando um novo documento de entrega de devolução é salvo, por exemplo, usando a transação VL01N. Tipo de evento explicit | |||
| Pedido de devolução aprovado | Representa a aprovação ou liberação formal do pedido de devolução, permitindo que ele avance para a próxima etapa. Em geral, isso é inferido por uma mudança de status no cabeçalho ou no item do documento de vendas, indicando que os bloqueios foram removidos. | ||
| Por que isso importa As etapas de aprovação podem causar atrasos significativos. Acompanhar esta atividade ajuda a identificar gargalos na fase inicial de autorização do processo de devolução. Onde encontrar Inferido a partir das tabelas de gerenciamento de status ou dos campos de status nas tabelas VBAK ou VBAP. Uma mudança no status de liberação ou a remoção de um bloqueio de entrega (VBAP-LIFSP) pode indicar a aprovação. Coleta Inferido a partir de uma mudança nos campos de status do cabeçalho ou do item do pedido de devolução que indique liberação ou aprovação. Tipo de evento inferred | |||
| Pedido de troca criado | Esta atividade representa uma solução alternativa: em vez de um reembolso, é criado um novo pedido de venda para enviar um item substituto ao cliente. O evento é registrado quando um novo pedido de venda é criado com referência à devolução original. | ||
| Por que isso importa Esta atividade ajuda a diferenciar devoluções com reembolso das devoluções com troca, que seguem fluxos de trabalho diferentes e geram resultados distintos para os clientes. É essencial para analisar variantes. Onde encontrar Registrado na criação de um novo documento de vendas na VBAK, vinculado ao pedido de devolução na tabela de fluxo de documentos (VBFA). Coleta O evento é registrado quando um novo documento de pedido de venda, identificado como substituição, é salvo. Tipo de evento explicit | |||
Guias de extração
Etapas
- Verifique os pré-requisitos: confirme se a conta de usuário que fará a extração tem as autorizações necessárias no SAP S/4HANA para acessar as Core Data Services (CDS) Views exigidas. Entre as principais estão I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Acesse a ferramenta de consulta: entre no cliente SQL ou na ferramenta de integração de dados de sua preferência, com conexão estabelecida ao banco de dados do SAP S/4HANA. Você pode usar ferramentas da própria SAP, como o SAP Analytics Cloud, ou uma plataforma ETL de terceiros.
- Defina os parâmetros da consulta: antes de executar a consulta SQL fornecida, ajuste os valores de espaço reservado e substitua-os pelos parâmetros corretos do seu ambiente. Informe
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]e os demais filtros de tipo de documento ou código da empresa. - Execute a consulta de extração: copie a consulta SQL completa e execute-a na ferramenta. Ela reúne todas as atividades especificadas em um único conjunto de dados, combinando os resultados de várias instruções SELECT.
- Entenda a lógica da consulta: cada bloco
SELECTda estruturaUNION ALLextrai uma atividade específica. Ele combina várias CDS Views para reunir os atributos necessários, define um texto fixo paraActivityNamee seleciona o timestamp correspondente paraEventTime. - Revise os dados brutos: quando a consulta terminar, faça uma breve revisão dos resultados. Confira se o número de linhas é razoável e se colunas importantes, como
ReturnCaseId,ActivityNameeEventTime, foram preenchidas como esperado. - Transforme os dados: a consulta gera um Event Log em formato tabular. Em geral, não são necessárias transformações estruturais importantes. Talvez você precise ajustar o formato dos timestamps ou os tipos de dados de acordo com os requisitos do sistema de destino.
- Exporte o Event Log: exporte o resultado da consulta como um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres, especialmente em nomes de usuários ou descrições de produtos.
- Carregue os dados na ferramenta de Process Mining: o arquivo CSV resultante está pronto para ser carregado na sua plataforma de Process Mining, como o ProcessMind. Mapeie as colunas do arquivo para os campos correspondentes na ferramenta. Por exemplo, associe
ReturnCaseIda ID do caso,ActivityNamea Atividade eEventTimea Timestamp.
Configuração
- Pré-requisitos: o usuário que fará a extração precisa de autorizações de exibição para objetos relacionados a documentos de vendas (VBAK), entregas (LIKP), faturamento (VBRK) e contabilidade (BSEG, BKPF). Também é essencial ter acesso às CDS Views subjacentes.
- Filtros de escopo dos dados: é fundamental filtrar a consulta por tipos específicos de documentos para isolar o processo de devoluções. Configure os espaços reservados para tipos de pedido de devolução (por exemplo, 'RE'), solicitações de nota de crédito (por exemplo, 'G2') e pedidos de troca (por exemplo, 'SO'). Também é altamente recomendável filtrar por
CompanyCodeouSalesOrganizationpara limitar o escopo dos dados. - Filtro por período: para controlar a performance e o volume de dados, sempre aplique um filtro de período. Comece com dados dos últimos 3 a 6 meses. A consulta usa a data de criação do pedido de devolução inicial (
I_SalesDocument.CreationDate) como condição principal do filtro. - Considerações de performance: esta consulta abrangente combina várias CDS Views de grande porte. Sua execução pode consumir muitos recursos do sistema S/4HANA de origem. Programe a extração fora dos horários de pico para reduzir o impacto. Para conjuntos de dados muito grandes, considere estratégias de carregamento incremental.
Consulta de exemplo 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' Etapas
- Confirme se há acesso direto de leitura ao esquema SAP HANA que contém os dados relevantes de vendas, entregas, faturamento, documentos de materiais, inspeção, status e contabilidade. O esquema, as views e os nomes dos campos variam conforme a implantação do SAP S/4HANA. Substitua cada espaço reservado entre colchetes pelos objetos e campos configurados no seu sistema.
- Defina o escopo da extração usando [Start date], [End date], [Company Code filter] e [Return document type filter]. Na extração inicial, use um período móvel de três a seis meses e amplie-o somente depois de validar a performance e a integridade dos dados.
- Identifique os pedidos de devolução em [Your sales document header table] e [Your sales document item table]. Restrinja a seleção aos tipos de documento de pedido de devolução configurados em [Your return order document type configuration]. Preserve o número do pedido de devolução e o número do item como vínculos principais com os documentos subsequentes.
- Use [Your document flow table or view] para identificar o fluxo de documentos dos pedidos de devolução até as entregas de devolução recebidas, solicitações de nota de crédito, pedidos de troca e notas de crédito. Não presuma que o fluxo de documentos esteja armazenado em VBAK ou VBAP. Configure os campos de relacionamento de acordo com o modelo de fluxo de documentos usado no sistema.
- Extraia eventos explícitos de criação dos registros relevantes de cabeçalho e item dos documentos. Extraia eventos de aprovação, rejeição, inspeção, encerramento, recebimento de mercadorias, contabilização e compensação das fontes configuradas de status, inspeção, documentos de materiais, contabilidade e compensação. Cada atividade deve ser registrada em uma linha de evento separada, pois o ProcessMind não infere eventos.
- Normalize os timestamps para usar um tipo de timestamp e um fuso horário consistentes no banco de dados. Use a precedência de timestamps configurada para cada atividade. Se houver apenas data e hora, combine os valores usando o fuso horário do sistema definido em [Your system time zone].
- Preencha
ReturnCaseIdem todos os eventos. Use o número do pedido de devolução de origem ou o identificador de caso configurado, caso o Advanced Returns Management armazene uma chave de caso separada. Exclua os eventos que não puderem ser vinculados a um caso de devolução ou envie-os para uma saída de exceções para correção. - Preencha as colunas obrigatórias
ReturnCaseId,ActivityName,EventTime,SourceSystemIdeLastDataUpdateTimestamp. Quando disponíveis, preencha também as colunas recomendadas, incluindoEventEndTime,UserName,ReturnReason,RefundAmount,ProductIdeCustomerId. Mantenha uma linha por ocorrência de atividade e não agregue as atividades em uma única linha por caso. - Valide os resultados usando as verificações em
validationSteps. Confirme se os doze nomes de atividade estão presentes, se a ordem dos timestamps em cada caso é plausível e se as referências dos documentos correspondem às tabelas de origem. - Exporte os resultados como CSV em UTF-8 ou em outro formato tabular compatível com o ProcessMind. Preserve os nomes exatos das colunas, use uma única linha de cabeçalho, mantenha os timestamps em um formato ISO inequívoco e carregue o Event Log com
ReturnCaseIdconfigurado como identificador do caso eActivityNamecomo coluna de atividade.
Configuração
- Período: comece com três a seis meses. Use os parâmetros [Start date] e [End date] e inclua histórico suficiente para capturar casos iniciados antes do período selecionado, mas concluídos dentro dele.
- População de devoluções: filtre pelos tipos de documento de pedido de devolução configurados em [Your return order document type configuration]. Não fixe um tipo de documento sem antes confirmar que ele está configurado no sistema de destino.
- Filtros organizacionais: aplique filtros de [Company Code filter], organização de vendas, canal de distribuição, divisão, centro ou cliente somente quando necessário. Confirme que os filtros não excluem documentos subsequentes entre empresas ou entre unidades da mesma empresa.
- Objetos de origem: substitua os espaços reservados [Your table name] e [Your view name] por tabelas ou CDS Views aprovadas do SAP S/4HANA. VBAK, VBAP, VBRK e VBRP podem estar disponíveis na implantação, mas confirme se o uso e as extensões são adequados antes de executar a consulta.
- Tratamento de timestamps: configure os campos de timestamp de origem e o fuso horário de cada atividade. Armazene
EventTimeeEventEndTimede forma consistente, de preferência em UTC ou no fuso horário acordado para o ProcessMind. - Interpretação de status: configure os valores exatos de status, códigos de motivo, resultados de inspeção e indicadores de encerramento que representam aprovação, rejeição, conclusão da inspeção e encerramento do caso no sistema.
- Identificador do sistema de origem: substitua [Source system identifier] por um valor estável, como o identificador do sistema SAP usado pela plataforma de extração.
- Timestamp de atualização: substitua [Extraction timestamp] pelo timestamp do início da execução da consulta ou da criação do snapshot da origem. Use o mesmo valor em todas as linhas de uma execução, a menos que sejam necessários timestamps de atualização por linha.
- Performance: restrinja a população inicial de devoluções antes de combinar grandes fontes de fluxo de documentos, contabilidade, documentos de materiais e status. Use campos indexados ou que permitam eliminar partições, evite varreduras sem restrições e materialize resultados intermediários somente com a aprovação do administrador do banco de dados.
- Extração incremental: em execuções recorrentes, use [Last successful extraction timestamp] e uma janela de sobreposição controlada para capturar atualizações tardias. Elimine duplicatas usando
ReturnCaseId,ActivityName, a chave do documento de origem eEventTime. - Autorizações e pré-requisitos: obtenha autorização de leitura para todos os objetos e campos de origem configurados, aprovação para acesso direto ao banco de dados e confirmação de que os componentes SAP e as funções do Advanced Returns Management necessários estão ativos, quando aplicável.
- Proteção de dados: limite os campos de clientes e financeiros ao mínimo necessário, siga os controles de privacidade da organização e proteja os arquivos exportados.
Consulta de exemplo 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; Pronto para começar?
Com este Template, você tem os conhecimentos básicos para extrair e analisar os dados de processamento de devoluções e reembolsos. Comece hoje sua jornada rumo à excelência em processos.
Otimize agora o processamento de devoluções e reembolsos no SAP S/4HANA
Identifique ineficiências, reduza o tempo de ciclo em 30% e aumente a satisfação.
Não é necessário informar cartão de crédito. Comece a otimizar hoje.