Seu Template de dados de processamento de devoluções e reembolsos
Seu Template de dados de 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 | O registro de data e hora preciso que indica quando 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 para todas as análises baseadas em tempo. No Process Mining, esse 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 o cumprimento do SLA e entender a dinâmica temporal do processo de devoluções. Por que isso importa Esse registro de data e hora é essencial para ordenar eventos, calcular todas as durações e tempos de ciclo e identificar atrasos no processo. Onde obter Normalmente, é obtido de 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 contabilização (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 | O identificador exclusivo de um único processo de devolução do cliente, vinculando todas as atividades relacionadas desde o início até o encerramento. | ||
| Descrição O ID do caso de devolução funciona como o identificador principal que agrupa todos os eventos e atividades pertencentes a uma única devolução. Cada solicitação de devolução do cliente recebe um ID exclusivo, permitindo acompanhar todo o processo de ponta a ponta. No Process Mining, esse 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”, “Mercadorias recebidas” 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, permitindo todas as análises no nível do caso, incluindo o tempo de ciclo e a descoberta de variantes do processo. Onde obter Normalmente, é 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 | O nome de uma atividade ou evento de negócio específico que ocorreu no processo de devolução e reembolso. | ||
| Descrição Este atributo descreve uma única etapa ou marco no ciclo de vida das devoluções. 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 que são repetidas com frequência, indicando retrabalho ou ineficiências. Por que isso importa As atividades formam a base do mapa do processo, permitindo visualizar e analisar o fluxo do processo, os gargalos e as variações. Onde obter Os nomes das atividades normalmente 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), além de status de movimentação de mercadorias em MSEG. Exemplos Solicitação de devolução iniciadaMercadorias recebidas no armazémNota de crédito criadaReembolso processado | |||
| ID do sistema de origem SourceSystemId | Identificador do sistema de origem do qual os dados foram extraídos. | ||
| Descrição Este atributo especifica o sistema de registro em que os dados do evento tiveram origem. Para este processo, normalmente seria o ID da instância do SAP S/4HANA. Em ambientes com vários sistemas, esse campo é essencial para a linhagem dos dados, a solução de problemas e a garantia da integridade dos dados. Ele ajuda a diferenciar dados quando as devoluções são processadas em diferentes instâncias de ERP ou integradas a sistemas externos, como um sistema de gerenciamento de armazém. Por que isso importa Fornece um contexto essencial sobre a origem e a linhagem dos dados, especialmente em ambientes com vários sistemas, garantindo rastreabilidade e confiança nos dados. Onde obter Esse valor normalmente é 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 | O registro de data e hora que indica quando os dados deste evento foram atualizados ou extraídos pela última vez. | ||
| 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. Isso é importante para entender o quanto a análise de Process Mining está atualizada. Os usuários podem verificar quão recentes são os dados, o que é especialmente relevante para o monitoramento operacional e os Dashboards que acompanham casos em andamento. Por que isso importa Indica a atualidade dos dados, algo essencial para garantir que as análises e os Dashboards usem informações atualizadas. Onde obter Normalmente, é gerado e registrado no conjunto de dados no momento da extração pelo ETL ou pela ferramenta de pipeline de dados. Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Horário de término do evento EventEndTime | O registro de data e hora que marca a conclusão de uma atividade, usado para calcular sua duração. | ||
| Descrição Enquanto StartTime (EventTime) marca o início de uma atividade, EventEndTime marca sua conclusão. Para muitos eventos gerados pelo sistema, os horários de início e término são idênticos, representando uma ocorrência instantânea. No entanto, para atividades com duração mensurável, como “Inspeção do item”, esse atributo é essencial. Esse atributo permite calcular diretamente o tempo de processamento da atividade. Isso é fundamental para a análise de performance, ajudando a identificar quais etapas específicas, e não apenas os intervalos entre elas, estão consumindo mais tempo. Por que isso importa Permite calcular com precisão a duração de cada atividade, algo essencial para localizar ineficiências em etapas específicas do processo. Onde obter Muitas vezes, esse valor é derivado. Para algumas atividades, pode haver um campo separado. Com mais frequência, 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 | O 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 clientes com taxas de devolução incomumente altas, o que pode indicar comportamento fraudulento ou insatisfação. Também permite segmentar o processo de devoluções por tipo, valor ou histórico do cliente, possibilitando níveis de serviço personalizados. Por que isso importa Conecta as devoluções a clientes específicos, permitindo analisar o comportamento dos clientes, criar segmentações e identificar clientes que devolvem produtos com frequência. Onde obter Encontrado no campo de número do cliente (KUNNR) da tabela de cabeçalho do pedido de devolução (VBAK). Exemplos CUST-001234CUST-005678CUST-009012 | |||
| ID do produto ProductId | O identificador exclusivo do item que está sendo devolvido. | ||
| Descrição Este atributo especifica o material ou produto relacionado à devolução. 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 mais informadas sobre design de produtos, gestão de fornecedores e 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 obter Encontrado no campo de número do material (MATNR) da tabela de itens do pedido de devolução (VBAP) ou da tabela de itens da entrega de devolução (LIPS). Exemplos FG-10023HW-45981SW-LICENSE-PREM | |||
| Motivo da devolução ReturnReason | O motivo informado pelo cliente para devolver o item. | ||
| Descrição Este atributo registra o motivo declarado pelo cliente para a devolução, como “Item com defeito”, “Tamanho incorreto” ou “Não é mais necessário”. Normalmente, ele é selecionado em uma lista predefinida de códigos de motivo durante o início da devolução. Analisar os motivos das devoluções é essencial para identificar problemas de qualidade dos produtos, melhorar as descrições dos produtos ou aperfeiçoar os processos de vendas. Isso fornece um insight direto sobre a insatisfação dos clientes e ajuda a priorizar áreas de melhoria para reduzir a taxa geral de devoluções. Por que isso importa Fornece um insight essencial sobre os motivos das devoluções, permitindo analisar as causas-raiz e corrigir problemas de qualidade dos produtos, erros de atendimento ou lacunas nas expectativas dos clientes. Onde obter Normalmente armazenado na tabela de itens do pedido de vendas de devolução (VBAP), no campo ABGRU (Motivo da rejeição de documentos de vendas). Exemplos 001 - Baixa qualidade002 - Danificado durante o transporte005 - Item incorreto enviado | |||
| Nome do usuário UserName | O ID do usuário responsável por executar a atividade. | ||
| Descrição Este atributo identifica o usuário específico ou o agente do sistema responsável por concluir uma tarefa, como aprovar uma devolução ou criar uma nota de crédito. No SAP, isso costuma ser registrado em campos que armazenam o usuário que criou ou alterou um documento. Analisar os dados por usuário ajuda a identificar pessoas ou equipes com alta performance, necessidades de treinamento e distribuição de carga de trabalho. Também é essencial para investigar desvios, pois vincula as ações do processo a pessoas específicas, apoiando a conformidade e as auditorias. Por que isso importa Atribui atividades do processo a usuários específicos, permitindo analisar a performance da equipe, a carga de trabalho e a conformidade. Onde obter Normalmente encontrado em tabelas de cabeçalho de documentos, como ERNAM (Criado por) na VBAK (Pedidos de vendas), LIKP (Entregas) e BKPF (Documentos contábeis). Os dados dos usuários podem ser enriquecidos a partir da tabela mestre de usuários USR21. Exemplos CBROWNASMITHWF_BATCH | |||
| Valor do reembolso RefundAmount | O 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. Essa é uma métrica financeira importante para várias análises. Ela é essencial para o Dashboard “Análise de divergências no valor do reembolso”, que compara o valor efetivo com o valor solicitado. Também permite segmentar as devoluções por valor para identificar se devoluções de alto valor seguem um processo diferente ou demoram mais para ser resolvidas. Por que isso importa Acompanha 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 obter 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 | |||
| Adesão à política de devoluções ReturnPolicyAdherence | Um indicador que mostra se o caso de devolução está em conformidade com a política de devolução definida. | ||
| Descrição Este atributo booleano calculado indica se uma devolução atende aos critérios definidos na 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 da devolução é válido para o produto. Este atributo apoia diretamente o Dashboard “Panorama da conformidade com a política de devolução”. Ele quantifica as taxas de conformidade e permite detalhar os casos não conformes para entender os motivos dos desvios, ajudando a aplicar as políticas com mais eficiência. Por que isso importa Quantifica a conformidade com as regras de negócio, ajudando a identificar e reduzir violações de políticas que podem afetar a lucratividade ou criar exceções no processo. Onde obter Calculado com base em regras de negócio. Por exemplo, (Data de início da devolução - Data da compra original) <= [Dias permitidos para devolução]. Isso exige a Data da compra original e as regras da política. Exemplos truefalse | |||
| Agente de processamento ProcessingAgent | O agente específico ou grupo de recursos responsável por tratar uma atividade manual. | ||
| Descrição Este atributo identifica a pessoa ou a equipe que executou determinada tarefa. Ele pode ser mais específico do que o “Nome do usuário”, referindo-se a uma função ou equipe, especialmente em um ambiente de serviços compartilhados. Isso é valioso para o Dashboard “Eficiência da 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 de alta performance que podem compartilhar boas práticas. Por que isso importa Permite analisar a performance no nível do agente ou da equipe, ajudando a gerenciar a carga de trabalho, identificar oportunidades de treinamento e melhorar a eficiência. Onde obter Essas informações podem estar disponíveis nas funções de Business Partner do SAP, caso os agentes estejam atribuídos, ou podem ser derivadas 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 do SLA de reembolso RefundSlaAdherence | Um indicador que mostra se o reembolso foi processado dentro da meta do Acordo de Nível de Serviço (SLA). | ||
| Descrição Este atributo calculado verifica se a atividade 'Reembolso processado' ocorreu na data ou antes da 'Data-alvo do SLA de reembolso'. Ele fornece um indicador simples de verdadeiro ou falso sobre o cumprimento do SLA em cada caso. Esta é a métrica principal do Dashboard 'Monitoramento do cumprimento do SLA de reembolso' e do KPI 'Taxa de cumprimento do SLA de reembolso'. Ela ajuda a medir a performance em relação aos compromissos com os clientes e a identificar 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 do cliente. Onde obter Calculado comparando o EventTime da atividade 'Reembolso processado' com o 'RefundSlaTargetDate' de cada caso. Exemplos truefalse | |||
| Data-alvo do SLA de reembolso RefundSlaTargetDate | A data-alvo até a qual o reembolso do caso de devolução deve ser processado. | ||
| Descrição Este atributo define o prazo do Acordo de Nível de Serviço (SLA) para processar o reembolso. Essa data normalmente é calculada com base em regras de negócio, por exemplo, um determinado número de dias após a aprovação da devolução ou o recebimento das mercadorias. Este campo é a base do Dashboard “Monitoramento do cumprimento do SLA de reembolsos” e do KPI associado. Ele permite acompanhar proativamente os casos em risco de violar o SLA e analisar as causas-raiz dos atrasos, ajudando a melhorar a satisfação do cliente. Por que isso importa Fornece a referência para medir a conformidade com o SLA, ajudando a monitorar a performance, priorizar casos antigos e melhorar a satisfação do cliente. Onde obter Quase sempre, este é um campo derivado. A lógica se basearia em uma data-chave, como a data de criação da solicitação de devolução, somada a uma duração definida pelas regras de negócio, que pode depender de fatores como tipo de cliente ou motivo da devolução. Exemplos 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| É automatizado IsAutomated | Um indicador que mostra se uma atividade foi executada por um sistema ou por uma pessoa. | ||
| Descrição Este atributo booleano diferencia as atividades executadas automaticamente por um sistema, como um Workflow ou um job 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 de ampliar a automação. Ao filtrar as tarefas manuais, as empresas podem concentrar os esforços de melhoria do processo nas áreas em que a automação pode gerar os maiores benefícios em velocidade, custo e precisão. Por que isso importa Diferencia tarefas manuais e automatizadas, algo essencial para identificar oportunidades de automação e medir o impacto da transformação digital. Onde obter Normalmente, é derivado com base no Nome do 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 | Um indicador que mostra se uma atividade em um caso é uma repetição de uma atividade anterior. | ||
| Descrição Este atributo booleano calculado identifica ocorrências de retrabalho, quando uma atividade é executada mais de uma vez no mesmo caso. Por exemplo, quando a inspeção de um item precisa ser repetida ou 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 a ineficiência do processo, destacando atividades sujeitas a erros ou que exigem várias tentativas e apontando áreas que precisam de controles ou treinamentos melhores. Por que isso importa Destaca ineficiências e erros do processo ao sinalizar trabalhos repetidos, permitindo melhorias direcionadas para reduzir desperdícios e atrasos. Onde obter Esse indicador normalmente é 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 anteriormente no mesmo caso. Exemplos truefalse | |||
| ID da política de devolução ReturnPolicyId | O 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 específica ou conjunto de regras se aplica à transação. As políticas podem variar conforme o tipo de produto, o segmento do cliente ou o tempo desde a compra. Esses dados são essenciais para o “Panorama da conformidade com a política de devolução”. Ao associar cada caso a uma política, o sistema pode verificar automaticamente o cumprimento de regras, como prazos de devolução ou requisitos de condição do item, 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 obter Muitas vezes, esse não é um campo padrão do SAP e pode precisar ser derivado com base na lógica de negócio, usando dados como tipo de produto, cliente e data da venda. Se implementado, ele pode ser armazenado em um campo personalizado. Exemplos STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Número da entrega de devolução ReturnDeliveryNumber | O identificador exclusivo do documento de entrega de devolução. | ||
| Descrição Quando um cliente devolve fisicamente as mercadorias, um documento de entrega de devolução é criado no SAP para gerenciar a logística de entrada. Este atributo é o número exclusivo desse documento. Esse ID é importante para acompanhar a movimentação física das mercadorias devolvidas. Ele conecta os aspectos financeiros e logísticos da devolução, permitindo analisar detalhadamente as etapas de recebimento e inspeção das mercadorias. Por que isso importa Fornece um vínculo essencial entre o pedido de devolução e o recebimento físico das mercadorias, sendo fundamental para analisar a logística e os tempos de processamento no armazém. Onde obter É o número do documento de entrega (VBELN) da tabela de cabeçalho da entrega (LIKP), em que a categoria do documento indica uma entrega de devolução. Exemplos 840000128400001384000014 | |||
| Número da nota de crédito CreditMemoNumber | O identificador exclusivo do documento de nota de crédito que autoriza o reembolso. | ||
| Descrição Uma 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ções. Ele marca um marco crítico, muitas vezes acionando o pagamento efetivo do reembolso, e é necessário para a reconciliação financeira e as auditorias. Por que isso importa Representa a transação financeira oficial do reembolso, sendo essencial para acompanhar as etapas finais do processo e realizar auditorias financeiras. Onde obter É 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 | A unidade organizacional responsável pela venda original e pela devolução. | ||
| Descrição A Organização de vendas é um elemento essencial da estrutura organizacional no SAP, representando 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ções 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 de devoluções menos eficientes, fornecendo uma base para analisar a performance organizacional. Por que isso importa Permite comparar a performance e as taxas do processo de devoluções entre diferentes unidades de negócio, regiões ou canais de vendas. Onde obter Encontrado no campo de organização de vendas (VKORG) da tabela de cabeçalho do pedido de devolução (VBAK). Exemplos 10002100US01 | |||
| Resultado da inspeção do item ItemInspectionOutcome | O resultado da inspeção física do item devolvido. | ||
| Descrição Este atributo registra o resultado do processo de inspeção realizado depois que as mercadorias são recebidas no armazém. Os resultados comuns incluem “Aceito”, “Rejeitado: danificado” ou “Aceito: pode ser revendível”. Esses dados fornecem um contexto essencial para as etapas seguintes do processo. Eles determinam se será concedido um reembolso integral, parcial ou nenhum reembolso. Analisar esse resultado ajuda a identificar os motivos das rejeições e pode fornecer feedback sobre a embalagem dos produtos ou os parceiros de transporte quando os itens são danificados com frequência durante o transporte. Por que isso importa Explica o processo de decisão por trás das aprovações ou rejeições de reembolsos, fornecendo dados valiosos sobre a condição dos itens e os motivos dos ajustes nos reembolsos. Onde obter Essas informações podem ser registradas em um lote de inspeção do módulo de gerenciamento da qualidade (QM) ou como um status ou código de motivo no item da linha da entrega de devolução (LIPS). Também podem existir em um campo personalizado. Exemplos Aceito - Pode ser revendidoAceito - Será recondicionadoRejeitado - Dano causado pelo clienteRejeitado - Item incorreto devolvido | |||
| Status do pedido de devolução ReturnOrderStatus | O status geral atual do caso de devolução. | ||
| Descrição Este atributo fornece o status geral do caso de devolução em determinado momento, como “Aberto”, “Em processamento” ou “Encerrado”. Muitas vezes, esse é um status agregado, derivado do último marco importante concluído. Ele é 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. Isso ajuda os gestores a entender quantos casos estão em cada etapa do processo, permitindo alocar melhor os recursos e gerenciar a carga de trabalho. Por que isso importa Fornece uma visão de onde cada caso está no processo, algo essencial para Dashboards operacionais que acompanham a carga de trabalho e o status atual. Onde obter Derivado dos campos de status dos documentos relevantes. Por exemplo, do status do cabeçalho (GBSTK) ou do status do item (LFSTK) no pedido de vendas relacionado (VBUK/VBUP) ou nos documentos de entrega. Exemplos Aguardando recebimento da mercadoriaAguardando inspeçãoAguardando reembolsoEncerrado | |||
| Valor do reembolso solicitado RequestedRefundAmount | O valor do reembolso solicitado ou esperado inicialmente no começo do processo. | ||
| Descrição Este atributo registra o valor das mercadorias devolvidas conforme a solicitação inicial de devolução. Ele serve como referência para comparar o valor final reembolsado. 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 no item, 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, ajudando a identificar e analisar divergências entre os valores esperados e os valores efetivamente reembolsados. Onde obter Normalmente obtido do valor líquido dos itens no pedido de vendas de devolução inicial. Esse seria o valor líquido (NETWR) dos itens correspondentes 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, indicando que o processo de devolução foi concluído e que não são esperadas outras ações para o caso. Normalmente, isso é inferido quando o documento do pedido de devolução alcança um status final ou encerrado no sistema. | ||
| Por que isso importa Este evento define o fim do ciclo de vida do processo, permitindo calcular o tempo total do ciclo de ponta a ponta. Ele confirma que o caso foi totalmente resolvido. Onde obter Inferido quando o status geral do pedido de devolução na tabela VBAK ou de seus itens na VBAP alcança o estado “Concluído” ou “Encerrado”. Isso é determinado pela configuração de gerenciamento de status do sistema. Captura 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 condição das mercadorias devolvidas. 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 reembolso ou descarte. | ||
| Por que isso importa A duração e o resultado da inspeção afetam diretamente o tempo de processamento do reembolso e o gerenciamento do estoque. Essa atividade é essencial para analisar a eficiência da inspeção e os retrabalhos. Onde obter No SAP Advanced Returns Management (ARM), este pode ser um evento explícito da transação de inspeção. Ele também pode ser inferido a partir de uma mudança de status no item do pedido de devolução que indique o resultado da inspeção. Captura Capturado nos logs de transações ou nas mudanças de status relacionadas às atividades de acompanhamento logístico no ARM. Tipo de evento explicit | |||
| Mercadorias recebidas no armazém | Esse evento marca o recebimento físico do item devolvido no armazém ou centro de processamento. Ele é capturado explicitamente quando um Post Goods Receipt (PGR) é executado para a entrega de devolução, criando 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 esse ponto são causados pelo cliente, enquanto os atrasos posteriores são internos. Onde obter Capturado nas tabelas de documentos de material MSEG e MKPF para o tipo de movimento de recebimento de mercadorias associado às devoluções. A data de lançamento (MKPF-BUDAT) indica o horário do evento. Captura O evento corresponde ao lançamento de um recebimento de mercadorias para a entrega de devolução. 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. É um evento explícito, capturado 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 obter Capturado a partir da criação de um documento de faturamento na tabela VBRK, com uma categoria de documento que indica uma nota de crédito. Esse documento é vinculado à solicitação de nota de crédito na tabela VBFA. Captura O evento é registrado ao salvar um novo documento de faturamento de nota de crédito, por exemplo, usando a transação VF01. 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 recebe o pagamento de fato. O tempo entre o início da devolução e esta etapa é um dos principais fatores de satisfação do cliente e é essencial para medir o cumprimento do SLA. Onde obter 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. Captura 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ções, quando um pedido de devolução é criado formalmente no sistema. Esse evento é capturado explicitamente quando um novo documento de vendas do tipo pedido de devolução é salvo no SAP S/4HANA. | ||
| Por que isso importa Essa atividade marca o início oficial do ciclo de vida do caso de devolução. Analisar o tempo entre esse evento e o encerramento é essencial para medir o tempo total do ciclo de devolução e a experiência do cliente. Onde obter Este é um evento explícito capturado na criação de um documento de vendas na tabela VBAK, em que a categoria do documento (VBAK-VBTYP) indica um pedido de devolução. O registro de data e hora da criação é VBAK-ERDAT. Captura O evento é registrado ao salvar um novo pedido de vendas de devolução, 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 registra a criação de uma solicitação para conceder um crédito ao cliente. Ela é capturada como um novo documento de vendas, uma solicitação de nota de crédito, que faz referência ao pedido de devolução original. | ||
| Por que isso importa Esse é o gatilho para a etapa de liquidação financeira do processo de devolução. Analisar o tempo entre a inspeção e esta etapa revela a eficiência da transferência do processo entre logística e finanças. Onde obter Capturado a partir da 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. Captura O evento é registrado ao salvar um novo documento de solicitação de nota de crédito. Tipo de evento explicit | |||
| Devolução rejeitada | Indica que o item devolvido não atendeu aos critérios da política de devoluções e que a solicitação de reembolso ou crédito foi negada. Normalmente, isso é capturado 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 identificar os motivos mais comuns de recusa. Esse é um caminho de exceção importante no processo. Onde obter 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. Captura Inferido quando um motivo de rejeição ou um status específico de “rejeitado” é 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 é contabilizada com sucesso no módulo de contabilidade financeira. Ele cria lançamentos correspondentes no razão geral, tornando o crédito oficial 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 a contabilização pode revelar problemas na interface entre faturamento e finanças. Onde obter Capturado a partir da criação de um cabeçalho de documento na tabela contábil BKPF, vinculado à nota de crédito na VBRK (VBRK-BELNR). Captura O evento é registrado após a contabilização bem-sucedida do documento de faturamento na Contabilidade Financeira. Tipo de evento explicit | |||
| Entrega de devolução criada | Essa atividade representa a criação de um documento de entrega de entrada, usado para gerenciar o recebimento físico das mercadorias devolvidas. O sistema captura esse evento explícito de criação de um documento de entrega referenciado ao pedido de devolução. | ||
| Por que isso importa Essa 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 da devolução ao armazém ou ao departamento de recebimento. Onde obter Capturado 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. Captura O evento é registrado ao salvar um novo documento de entrega de devolução, 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. Normalmente, isso é inferido a partir de 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 ser uma fonte significativa de atrasos. Acompanhar essa atividade ajuda a identificar gargalos na fase inicial de autorização do processo de devoluções. Onde obter Inferido a partir das tabelas de gerenciamento de status ou dos campos de status diretamente 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 aprovação. Captura 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 resolução alternativa em que, em vez de um reembolso, um novo pedido de vendas é criado para enviar um item substituto ao cliente. Ela é capturada quando um novo pedido de vendas é criado com referência à devolução original. | ||
| Por que isso importa Esta atividade ajuda a diferenciar devoluções com reembolso de devoluções com troca, que seguem caminhos de processo e geram resultados diferentes para o cliente. Ela é essencial para a análise de variantes. Onde obter Capturado a partir da criação de um novo documento de vendas na VBAK, vinculado ao pedido de devolução na tabela de fluxo de documentos (VBFA). Captura O evento é registrado ao salvar um novo documento de pedido de vendas designado como substituição. Tipo de evento explicit | |||
Guias de extração
Etapas
- Verifique os pré-requisitos: confirme se a conta de usuário que executará a extração tem as autorizações necessárias no SAP S/4HANA para acessar as CDS Views exigidas do Core Data Services (CDS). Entre as principais Views estão I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Acesse a ferramenta de consulta: faça login no seu cliente SQL ou ferramenta de integração de dados preferida que tenha uma conexão estabelecida com o banco de dados do SAP S/4HANA. Podem ser 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, modifique a consulta SQL fornecida. Localize os valores de espaço reservado e substitua-os pelos parâmetros corretos do seu ambiente. Isso inclui definir
[Data de início],[Data de término],[ID do sistema de origem],[Tipo de pedido de devolução]e outros 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 sua ferramenta. A consulta foi projetada para reunir todas as atividades especificadas em um único conjunto de dados, unindo os resultados de várias instruções select.
- Entenda a lógica da consulta: cada bloco
SELECTna estruturaUNION ALLé responsável por extrair uma atividade específica. Ele combina várias CDS Views para coletar os atributos necessários, atribui uma string fixa aActivityNamee seleciona o timestamp relevante paraEventTime. - Revise os dados brutos: após a conclusão da consulta, faça uma breve revisão do resultado. Verifique se há uma quantidade razoável de linhas e confirme se colunas importantes, como
ReturnCaseId,ActivityNameeEventTime, foram preenchidas conforme esperado. - Transforme os dados: a consulta está estruturada para produzir um formato de Event Log plano. Normalmente, não são necessárias transformações estruturais significativas. No entanto, talvez você precise ajustar os formatos de timestamp ou os tipos de dados conforme os requisitos do sistema de destino.
- Exporte o Event Log: exporte o conjunto de resultados da consulta como um arquivo CSV. Verifique se o arquivo usa codificação UTF-8 para evitar problemas com caracteres, especialmente em nomes de usuários ou descrições de produtos.
- Faça o upload para a ferramenta de Process Mining: o arquivo CSV resultante já 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,
ReturnCaseIdpara Case ID,ActivityNamepara Activity eEventTimepara Timestamp.
Configuração
- Pré-requisitos: o usuário que executará 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). O acesso às CDS Views subjacentes é essencial.
- Filtros de escopo dos dados: é fundamental filtrar a consulta por tipos de documento específicos para isolar o processo de devolução. Configure os espaços reservados para tipos de pedido de devolução, por exemplo, 'RE', tipos de solicitação de nota de crédito, por exemplo, 'G2', e tipos de pedido 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 recentes de 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 é uma consulta abrangente que combina várias CDS Views grandes. A execução pode consumir muitos recursos no sistema S/4HANA de origem. Agende a extração fora do horário de pico para minimizar o impacto. Para conjuntos de dados muito grandes, considere estratégias de carregamento incremental.
a 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 schema do SAP HANA que contém os dados relevantes de vendas, entregas, faturamento, documentos de material, inspeção, status e contabilidade. O schema, as Views e os nomes dos campos exatos variam conforme a implantação do SAP S/4HANA. Portanto, substitua cada espaço reservado entre colchetes pelos objetos e campos configurados no seu sistema.
- Defina o escopo da extração usando [Data de início], [Data de término], [Filtro de código da empresa] e [Filtro de tipo de documento de devolução]. Use um período móvel de três a seis meses na extração inicial e amplie o período somente depois de validar a performance e a integridade dos dados.
- Identifique a população de pedidos de devolução em [Sua tabela de cabeçalho de documentos de vendas] e [Sua tabela de itens de documentos de vendas]. Restrinja a população aos tipos de documento de pedido de devolução configurados em [Sua configuração de tipos de documento de pedido de devolução]. Preserve o número e o número do item do pedido de devolução como vínculo principal com os documentos posteriores.
- Resolva o fluxo de documentos dos pedidos de devolução para entregas de devolução de entrada, solicitações de nota de crédito, pedidos de troca e notas de crédito usando [Sua tabela ou View de fluxo de documentos]. 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, contabilidade e compensação das fontes configuradas de status, inspeção, documentos de material, contabilidade e compensação. Cada atividade deve ser emitida como uma linha de evento separada, porque o ProcessMind não infere eventos.
- Normalize os timestamps para um tipo de timestamp e um fuso horário consistentes no banco de dados. Use a precedência de timestamp de evento configurada para cada atividade. Se houver apenas data e hora, combine-as usando o fuso horário do sistema configurado em [Seu fuso horário do sistema].
- Preencha ReturnCaseId para todos os eventos. Use o número do pedido de devolução de origem ou o identificador de caso de devolução configurado, caso o Advanced Returns Management armazene uma chave de caso separada. Eventos que não puderem ser vinculados a um caso de devolução devem ser excluídos ou colocados em uma saída de exceções para correção.
- Preencha as colunas obrigatórias ReturnCaseId, ActivityName, EventTime, SourceSystemId e LastDataUpdateTimestamp. Preencha as colunas recomendadas quando disponíveis, incluindo EventEndTime, UserName, ReturnReason, RefundAmount, ProductId e CustomerId. Mantenha uma linha por ocorrência de atividade e não agregue as atividades em uma única linha por caso.
- Valide o resultado usando as verificações em validationSteps. Confirme se os doze nomes de atividade estão presentes, se os timestamps estão ordenados de forma plausível em cada caso e se as referências dos documentos são conciliadas com as tabelas de origem.
- Exporte o resultado como CSV UTF-8 ou 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 não ambíguo e faça o upload do Event Log com ReturnCaseId configurado como identificador do caso e ActivityName configurado como coluna de atividade.
Configuração
- Período: comece com três a seis meses. Use os parâmetros [Data de início] e [Data de término] 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 [Sua configuração de tipos de documento de pedido de devolução]. Não fixe um tipo de documento sem verificá-lo no sistema de destino.
- Filtros organizacionais: aplique [Filtro de código da empresa], organização de vendas, canal de distribuição, divisão, centro ou filtros de cliente somente quando necessário. Confirme se os filtros não excluem documentos posteriores entre empresas ou dentro do mesmo grupo.
- Objetos de origem: substitua os espaços reservados [Nome da sua tabela] e [Nome da sua View] por tabelas ou CDS Views aprovadas do SAP S/4HANA. VBAK, VBAP, VBRK e VBRP podem estar disponíveis na implantação, mas seu uso e suas extensões devem ser verificados antes da execução.
- Tratamento de timestamps: configure os campos de timestamp de origem e o fuso horário de cada atividade. Armazene EventTime e EventEndTime de forma consistente, preferencialmente em UTC ou no fuso horário do ProcessMind acordado.
- 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 [Identificador do sistema de origem] por um valor estável, como o identificador do sistema SAP usado pela plataforma de extração.
- Timestamp de atualização: substitua [Timestamp da extração] pelo timestamp em que a execução da consulta começou ou o snapshot da origem foi criado. Use o mesmo valor em todas as linhas de uma execução de extraçã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 fontes grandes de fluxo de documentos, contabilidade, documentos de material e status. Use campos indexados ou que permitam eliminação de partições, evite varreduras irrestritas e materialize resultados intermediários somente quando aprovado pelo administrador do banco de dados.
- Extração incremental: em execuções recorrentes, use [Timestamp da última extração bem-sucedida] e uma janela de sobreposição controlada para capturar atualizações tardias. Remova duplicidades usando ReturnCaseId, ActivityName, chave do documento de origem e EventTime.
- 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: restrinja os campos de clientes e financeiros ao mínimo necessário, siga os controles de privacidade da organização e proteja os arquivos exportados.
a 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 o conhecimento básico necessário para extrair e analisar seus dados de processamento de devoluções e reembolsos. Comece hoje sua jornada rumo à excelência operacional.
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 cartão de crédito. Comece a otimizar hoje.