Seu Template de dados para processamento de devoluções e reembolsos
Seu Template de dados para processamento de devoluções e reembolsos
- Campos de dados recomendados para coleta
- Principais etapas do processo a acompanhar
- Orientações para extração de dados
Atributos do processamento de devoluções e reembolsos
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTime | Data e hora que indicam quando uma atividade ou um evento específico ocorreu. | ||
| Descrição A data e hora do evento registram o momento exato em que uma atividade ocorreu. Cada atividade no Event Log tem uma data e hora correspondente, que determina a ordem cronológica dos eventos. Este atributo é essencial para todas as análises de Process Mining baseadas em tempo. Ele é usado para calcular os tempos de ciclo entre atividades, identificar tempos de espera e gargalos, medir a duração total dos casos e verificar a conformidade com os acordos de nível de serviço (SLAs). A precisão desses registros afeta diretamente a confiabilidade de qualquer análise de performance. Por que isso importa Esses dados são essenciais para calcular todas as métricas de duração, como tempos de ciclo e de espera, fundamentais para a análise de performance. Onde encontrar Corresponde aos campos de data de criação ou modificação em várias tabelas, como 'SalesTable.createdDateTime' para a criação do pedido ou 'WMSJournalTrans.createdDateTime' para os diários do armazém. Exemplos 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| ID do caso de devolução ReturnCaseId | Identificador exclusivo do caso de devolução e reembolso de um cliente, que conecta todas as atividades relacionadas. | ||
| Descrição O ID do caso de devolução é o identificador principal de cada instância única do processo de devolução. Ele conecta todas as atividades relacionadas a uma devolução ou solicitação de reembolso específica, desde a criação inicial do pedido de devolução até o encerramento final. Na análise de processos, esse ID é fundamental para reconstruir a jornada completa de cada devolução. Ele permite acompanhar todo o ciclo, medir os tempos totais de ciclo e analisar as variações entre diferentes casos. Todos os eventos, dados e métricas são agregados e relacionados por meio desse identificador. Por que isso importa Este é o identificador essencial do caso, que conecta todas as etapas do processo e permite rastrear e analisar cada devolução do início ao fim. Onde encontrar Geralmente, é o número da autorização de devolução de material (RMA) ou o número do pedido de venda do tipo 'Returned Order' no módulo 'Sales and marketing'. Ele pode ser encontrado em tabelas como 'SalesTable', em que 'SalesType' é 'Returned Order'. Exemplos RMA-001234RMA-001235RMA-001236 | |||
| Nome da atividade ActivityName | Nome do evento de negócio ou da tarefa específica que ocorreu no processo de devolução e reembolso. | ||
| Descrição Este atributo descreve uma etapa ou um evento específico do ciclo de devolução e reembolso, como 'Pedido de devolução criado', 'Item recebido' ou 'Nota de crédito lançada'. Cada atividade representa um ponto distinto do processo, registrado no sistema. Analisar a sequência e a frequência dessas atividades é a base do Process Mining. Isso permite visualizar mapas do processo, identificar gargalos entre etapas e descobrir variantes comuns e incomuns. O conjunto de atividades define o escopo do processo analisado. Por que isso importa Ele define as etapas do processo, permitindo visualizar o fluxo e identificar gargalos, retrabalho e desvios. Onde encontrar Este é um atributo conceitual derivado de eventos do sistema. Ele pode ser gerado mapeando mudanças de status em tabelas como 'SalesTable' e 'WMSJournalTable' ou eventos específicos para nomes fáceis de entender. Exemplos Pedido de devolução criadoItem recebidoCódigo de destinação aplicadoNota de crédito lançada | |||
| Canal de devolução ReturnChannel | Método ou canal usado pelo cliente para iniciar a devolução. | ||
| Descrição Este atributo especifica o canal usado pelo cliente para iniciar a devolução, como “Portal online”, “Loja física”, “Ligação para o atendimento ao cliente” ou “Correio”. Segmentar a análise do processo por canal de devolução ajuda a avaliar a performance e a eficiência de cada canal. A empresa pode comparar o tempo de ciclo, os custos e a satisfação dos clientes entre os canais para identificar boas práticas e oportunidades de investimento ou melhoria. Esse dado é essencial para o Dashboard “Performance de utilização dos canais de devolução”. Por que isso importa Permite comparar a performance dos diferentes canais de devolução e ajuda a otimizar os mais eficientes e econômicos. Onde encontrar Essa informação pode estar armazenada no cabeçalho do pedido de devolução ('SalesTable') ou ser identificada a partir do usuário que criou o pedido. Talvez seja necessário usar uma lógica personalizada ou um campo específico. Exemplos Portal onlineQuiosque na lojaAtendimento ao cliente | |||
| Código de destinação DispositionCode | Código que indica o resultado da inspeção do item e a próxima ação a ser tomada. | ||
| Descrição O código de destinação é atribuído durante a inspeção de qualidade de um item devolvido. Ele determina a próxima etapa do processo, como 'Credit', 'Replace', 'Scrap' ou 'Return to Customer'. Este atributo é um ponto de decisão essencial no processo de devolução. A análise por código de destinação ajuda as empresas a entender os resultados das devoluções, acompanhar o impacto financeiro do descarte de itens e avaliar a eficiência de diferentes caminhos de resolução, como reposição ou reembolso. Por que isso importa Este código determina o caminho que um caso de devolução seguirá após a inspeção, por isso é essencial para analisar as variantes do processo e seus resultados para o negócio. Onde encontrar Este é um campo importante do módulo de gestão da qualidade. Ele está associado ao processamento de ordens de qualidade ou ordens de inspeção. Exemplos CRDTREPL-DSCRAPRTV | |||
| Código do motivo da devolução ReturnReasonCode | Motivo informado pelo cliente para devolver o item. | ||
| Descrição O código do motivo da devolução registra o motivo informado pelo cliente, como “Item com defeito”, “Tamanho incorreto”, “Diferente do anunciado” ou “Não preciso mais”. Em geral, essa informação é coletada quando a devolução é iniciada. Analisar os motivos das devoluções é essencial para identificar as causas raiz. Isso ajuda as empresas a detectar problemas de qualidade dos produtos, descrições incorretas ou falhas logísticas. Os insights obtidos com esses dados podem orientar melhorias no design dos produtos, no marketing e nas operações da cadeia de suprimentos, reduzindo as devoluções futuras. Por que isso importa Ajuda a entender por que as devoluções acontecem e permite analisar as causas raiz para reduzir o volume de devoluções e melhorar a satisfação dos clientes. Onde encontrar Em geral, essa informação fica no nível da linha do pedido de devolução. Procure campos de código do motivo na tabela 'SalesLine' dos pedidos de devolução. Exemplos DEFEITOITEM_INCORRETONAO_DESEJADODANIFICADO_NO_TRANSPORTE | |||
| ID do produto ProductId | Identificador exclusivo do produto que está sendo devolvido. | ||
| Descrição O ID do produto, geralmente o código SKU (Stock Keeping Unit), identifica o item específico que o cliente está devolvendo. Cada linha do pedido de devolução está associada a um ID do produto. Analisar as devoluções por produto é essencial para identificar itens com altas taxas de devolução. Isso pode indicar problemas no controle de qualidade, descrições imprecisas ou defeitos de fabricação. Essa análise ajuda a priorizar investigações e melhorias relacionadas aos produtos. Por que isso importa Permite analisar as devoluções por produto e identificar itens com problemas de qualidade ou alto volume de devoluções. Onde encontrar Corresponde ao campo 'ItemId' na tabela 'SalesLine' do pedido de devolução. Exemplos SKU-A-123SKU-B-456SKU-C-789 | |||
| Usuário responsável ResponsibleUser | Usuário ou funcionário que realizou ou é responsável por uma atividade específica. | ||
| Descrição Este atributo identifica a pessoa responsável por executar uma etapa do processo. Pode ser o funcionário do armazém que recebeu o item, o inspetor de qualidade ou o profissional de finanças que lançou a nota de crédito. Analisar o processo por usuário ajuda a entender a distribuição da carga de trabalho, identificar quem tem melhor performance e detectar possíveis necessidades de treinamento. Também permite investigar casos tratados por pessoas ou equipes específicas e garantir a segregação adequada de funções. Por que isso importa Ele permite analisar a distribuição da carga de trabalho e a performance de cada pessoa ou equipe, além de identificar oportunidades de treinamento ou alocação de recursos. Onde encontrar Encontrado nos campos 'created by' ou 'modified by' dos registros de transação, como 'SalesTable.createdBy' ou IDs de usuário vinculados em tabelas de diário. Exemplos Alice.WBob.JChris.P | |||
| Data e hora de término EndTime | Data e hora que indicam quando uma atividade específica foi concluída. | ||
| Descrição A data e hora de término indicam quando uma atividade foi concluída. Enquanto StartTime marca o início, EndTime marca a conclusão e permite calcular o tempo de processamento daquela tarefa específica. Este atributo é essencial para análises detalhadas de performance, especialmente em tarefas com duração mensurável, como 'Inspeção do item'. Ao comparar StartTime e EndTime, os analistas podem medir com precisão o tempo efetivo de processamento das tarefas e diferenciá-lo do tempo de espera entre elas. Isso ajuda a localizar ineficiências em atividades específicas, não apenas nos intervalos entre elas. Por que isso importa Ele permite calcular o tempo efetivo de processamento de cada atividade e diferenciar o tempo de espera do tempo de trabalho. Onde encontrar Muitas vezes, esse dado precisa ser derivado. Por exemplo, pode ser o 'modifiedDateTime' de uma mudança de status que conclui uma atividade ou o StartTime da atividade seguinte. Exemplos 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| Data-limite do SLA do reembolso RefundSlaTargetDate | Data-limite para resolver completamente o caso de devolução e reembolso. | ||
| Descrição Este atributo define o prazo do Acordo de Nível de Serviço (SLA) para resolver um caso de devolução. Até essa data, espera-se que o cliente receba uma solução final, como um reembolso lançado ou um produto substituto enviado. Essa data é essencial para monitorar a performance em relação aos compromissos de atendimento. Ela é usada para calcular o KPI “Taxa de cumprimento do SLA de resolução” e alimentar o Dashboard “Performance do SLA de resolução de reembolsos”. Ao comparar essa data com a data real de conclusão do processo, a empresa pode identificar violações do SLA e gerenciar proativamente os casos em aberto há mais tempo. Por que isso importa É a referência para medir a performance do processo, acompanhar o cumprimento do SLA e identificar casos atrasados. Onde encontrar Talvez esse não seja um campo padrão. Muitas vezes, ele é calculado somando um período de SLA predefinido (por exemplo, 14 dias) à data de criação da devolução. Também pode ser armazenado em um campo personalizado. Exemplos 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| Está de acordo com a política IsPolicyAdherent | Indicador que mostra se a aprovação da devolução está de acordo com as políticas estabelecidas. | ||
| Descrição Este atributo booleano calculado indica se uma devolução atende a todos os critérios definidos na política da empresa. A avaliação pode considerar fatores como o prazo para devolução, o estado do item ou o motivo da devolução. Este atributo dá suporte direto ao Dashboard “Visão geral da conformidade das aprovações de devolução” e ao KPI “Taxa de aprovação de devoluções em conformidade”. Ele permite quantificar o cumprimento das políticas, identificar casos aprovados como exceção e analisar os motivos e a frequência dessas exceções. Isso é essencial para a governança e o controle de custos. Por que isso importa Mede diretamente a conformidade com as regras do negócio e ajuda a identificar e reduzir aprovações de devolução fora das políticas, que podem causar perda de receita. Onde encontrar Este atributo é derivado. A lógica precisa comparar os atributos da devolução, como a data e o motivo da devolução, com a data da compra e as regras de negócio predefinidas. Exemplos truefalse | |||
| ID da nota de crédito CreditNoteId | Identificador exclusivo do documento de nota de crédito criado para um reembolso. | ||
| Descrição Quando um reembolso é processado, é gerado um documento financeiro chamado nota de crédito. Este atributo armazena o ID exclusivo desse documento. Esse ID vincula diretamente o processo operacional de devolução aos registros financeiros do sistema contábil. Ele é útil para auditorias e análises detalhadas de divergências financeiras, pois permite rastrear um caso de devolução até a transação financeira específica que o liquidou. Por que isso importa Vincula o processo operacional de devolução à transação financeira correspondente, algo essencial para auditorias e conciliações financeiras. Onde encontrar O número da nota de crédito geralmente fica no campo 'InvoiceId' da tabela 'CustInvoiceJour', onde o tipo de transação é 'Credit note'. Esse dado pode ser vinculado ao pedido de devolução. Exemplos CN-10056CN-10057CN-10058 | |||
| ID do armazém WarehouseId | Identificador do armazém ou local onde o item devolvido é recebido. | ||
| Descrição Este atributo identifica o armazém físico ou centro de devoluções específico que processa o item devolvido. Cada local pode ter processos, recursos ou níveis de performance diferentes. Analisar o processo por armazém permite comparar a performance entre locais. Isso ajuda a identificar quais instalações processam as devoluções com mais eficiência, destacar gargalos regionais e orientar decisões sobre alocação de recursos e padronização de processos na rede logística. Por que isso importa Permite comparar a performance entre armazéns ou centros de devolução e identificar gargalos regionais ou boas práticas. Onde encontrar Essa informação fica no campo 'InventLocationId' das transações relacionadas ao estoque, como o diário de recebimento ('WMSJournalTable') ou a tabela 'SalesLine'. Exemplos WH-EASTWH-WESTCENTRAL-DC | |||
| ID do cliente CustomerId | Identificador exclusivo do cliente que iniciou a devolução. | ||
| Descrição O ID do cliente é o identificador exclusivo da conta associada à devolução. Ele vincula a transação de devolução a um cliente específico no CRM ou no banco de dados de clientes. Analisar as devoluções por cliente ajuda a identificar quem apresenta um volume de devoluções fora do padrão, o que pode indicar fraude ou insatisfação recorrente. Também permite segmentar os clientes, por exemplo, para oferecer serviços de devolução premium aos clientes de maior valor. Por que isso importa Vincula o processo de devolução a um cliente específico, permitindo analisar os dados por cliente e identificar padrões de devolução ou possíveis fraudes. Onde encontrar Este é o campo 'CustAccount' na tabela 'SalesTable' do pedido de devolução. Exemplos CUST-00045CUST-00192CUST-00315 | |||
| Sistema de origem SourceSystem | Sistema de informação do qual os dados dos eventos foram extraídos. | ||
| Descrição Este atributo identifica o sistema de informação de origem dos dados. Neste contexto, será principalmente o 'Microsoft Dynamics 365'. Em organizações maiores, um processo pode envolver vários sistemas. Especificar o sistema de origem de cada evento é essencial para a governança de dados, a investigação de problemas na extração e a compreensão do ambiente tecnológico do processo. Isso confirma a origem dos dados analisados. Por que isso importa Ele fornece um contexto essencial sobre a origem dos dados, necessário para a governança e a validação dos dados e para entender o ambiente de sistemas do processo. Onde encontrar Geralmente, é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) para identificar a origem do conjunto de dados. Exemplos Microsoft Dynamics 365 F&OD365-PROD | |||
| Status do pedido de devolução ReturnOrderStatus | Status geral do pedido de devolução no momento do evento. | ||
| Descrição Este atributo indica o status atual do cabeçalho do pedido de devolução, como “Aberto”, “Faturado” ou “Cancelado”. Ele oferece uma visão geral da etapa do ciclo de vida em que o caso se encontra. As atividades mostram as etapas detalhadas do processo, enquanto o status geral é útil para filtrar e segmentar os casos. Por exemplo, um analista pode se concentrar apenas nos casos “Abertos” para entender a carga de trabalho atual ou analisar o fluxo dos casos que acabam sendo “Cancelados”. Por que isso importa Resume o estado geral do caso, facilitando a filtragem e a análise de resultados como cancelamentos. Onde encontrar Essa informação está no campo 'SalesStatus' ou 'DocumentStatus' da tabela 'SalesTable'. Exemplos Pedido abertoEntregueFaturadoCancelado | |||
| Status do SLA SlaStatus | Indica se o caso foi resolvido dentro do prazo definido no Acordo de Nível de Serviço. | ||
| Descrição Este atributo calculado apresenta um status simples de cumprimento do SLA, geralmente “No prazo” ou “Atrasado”. Ele é determinado pela comparação entre a data e hora da atividade final, como “Pedido de devolução encerrado”, e 'RefundSlaTargetDate'. Este atributo simplifica os relatórios de performance em Dashboards como “Performance do SLA de resolução de reembolsos”. Em vez de exigir que os usuários comparem datas, ele apresenta um status direto e fácil de entender. Assim, fica mais fácil filtrar e agregar os dados para calcular a “Taxa de cumprimento do SLA de resolução”. Por que isso importa Apresenta de forma simples e imediata o cumprimento do SLA, facilitando a filtragem dos casos atrasados e a análise das causas raiz dos atrasos. Onde encontrar Este atributo é derivado e calculado pela comparação entre a data e hora da atividade de resolução final e o atributo 'RefundSlaTargetDate'. Exemplos No prazoAtrasado | |||
| Tipo de devolução ReturnType | Classifica a devolução de acordo com o resultado esperado, como reembolso ou substituição. | ||
| Descrição Este atributo classifica o caso de devolução de acordo com o tipo de solução solicitado pelo cliente ou oferecido pela empresa. As opções mais comuns incluem reembolso em dinheiro, troca por um item substituto ou reparo. Essa classificação ajuda a analisar diferentes caminhos do processo. O processo de emissão de um reembolso é bem diferente do processo de envio de um item substituto. Segmentar os dados por tipo de devolução permite analisar com mais precisão o tempo de ciclo e os gargalos específicos de cada tipo de solução. Por que isso importa Permite segmentar a análise pelo resultado esperado, já que os processos de reembolso e substituição têm etapas e tempos de ciclo diferentes. Onde encontrar Pode ser um campo personalizado no cabeçalho do pedido de devolução ou ser identificado com base no código de destinação ou em transações posteriores, como a criação de um pedido de venda para o item substituto. Exemplos ReembolsoSubstituiçãoCrédito na loja | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados do processo foram atualizados pela última vez. | ||
| Descrição Este atributo registra a data e a hora em que os dados foram extraídos pela última vez do sistema de origem e atualizados na ferramenta de Process Mining. Ele indica o quão recentes são os dados analisados. Saber quando os dados foram atualizados pela última vez é importante para entender a atualidade da análise. Isso ajuda você a interpretar corretamente os Dashboards e os KPIs, sabendo se está consultando dados em tempo real ou um retrato de um momento específico. Esse dado é essencial para o monitoramento operacional. Por que isso importa Indica o quão recentes são os dados e ajuda os analistas a saber até que ponto os insights sobre o processo estão atualizados. Onde encontrar Este é um atributo de metadados gerado e armazenado durante o fluxo de ingestão de dados, que geralmente representa a data e a hora de conclusão do processo ETL. Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Valor efetivo do reembolso ActualRefundAmount | Valor final do reembolso concedido ao cliente. | ||
| Descrição Este atributo registra o valor final confirmado que foi reembolsado ao cliente. O valor é registrado quando a nota de crédito é criada e lançada. Este é um atributo essencial para a análise financeira e é usado diretamente no Dashboard “Análise de divergência do valor do reembolso” e no KPI “Taxa de precisão do valor do reembolso”. Analisar esses dados ajuda a entender o impacto financeiro das devoluções e os ajustes feitos durante o processo. Por que isso importa Representa o impacto financeiro real da devolução e é essencial para calcular a precisão dos reembolsos e entender os resultados financeiros. Onde encontrar Esse valor pode ser encontrado nos detalhes da transação da nota de crédito lançada. Ele está relacionado às tabelas 'CustTrans' e 'CustInvoiceJour' da nota de crédito. Exemplos 99.99135.000.00 | |||
| Valor solicitado do reembolso RequestedRefundAmount | Valor total do reembolso solicitado pelo cliente. | ||
| Descrição Este atributo representa o valor inicial do reembolso solicitado ou previsto no início do processo de devolução. Em geral, ele se baseia no preço de compra original dos itens devolvidos. Esse valor serve de referência para a “Análise de divergência do valor do reembolso”. Ao comparar o valor solicitado com o valor efetivamente reembolsado, a empresa pode identificar diferenças causadas por taxas de reposição de estoque, reembolsos parciais de produtos danificados ou outros ajustes. Isso ajuda a monitorar a precisão financeira e o cumprimento das políticas. Por que isso importa Serve de referência para avaliar a precisão financeira, comparando o valor solicitado com o valor efetivamente reembolsado. Onde encontrar Em geral, corresponde ao valor da linha ou ao valor total da linha do pedido de venda original que está sendo devolvida. Você encontra esse dado em 'SalesLine.LineAmount'. Exemplos 99.99150.0024.50 | |||
Atividades do processamento de devoluções e reembolsos
| Atividade | Descrição | ||
|---|---|---|---|
| Código de destinação aplicado | Esta atividade representa a conclusão da inspeção e a decisão sobre o que fazer com o item devolvido. Um código de destinação, como 'Credit', 'Scrap' ou 'Replace', é atribuído à linha da devolução. | ||
| Por que isso importa Este é um ponto de decisão importante, que determina o caminho seguinte do processo: reembolso, troca ou rejeição. Atrasos nesta etapa podem aumentar significativamente o tempo total de resolução. Onde encontrar Este evento é registrado quando o campo DispositionCode é preenchido na transação de estoque da linha do pedido de devolução ou em um diário relacionado. Coleta Evento de atualização em que um DispositionCode é definido para a linha do pedido de devolução. Tipo de evento explicit | |||
| Item recebido | Marca o recebimento físico do item devolvido no armazém ou no centro de devoluções designado. O evento é registrado quando o diário de chegada associado ao pedido de devolução é lançado. | ||
| Por que isso importa Este é um marco crítico que transfere o processo da ação do cliente para o processamento interno. É o ponto de partida para calcular todos os tempos de processamento interno, como inspeção e destinação. Onde encontrar Data e hora do lançamento do WMS Journal ou do Item Arrival Journal associado à linha ReturnOrder. Isso atualiza as transações de estoque para o status 'Registered' ou 'Received'. Coleta Evento de lançamento do Item Arrival Journal vinculado à linha do pedido de devolução. Tipo de evento explicit | |||
| Nota de crédito lançada | A nota de crédito é lançada oficialmente nos livros contábeis, disponibilizando o crédito ao cliente. Isso indica que, do ponto de vista da empresa, o reembolso foi concluído. | ||
| Por que isso importa Este é um marco financeiro essencial, que confirma que o reembolso foi processado no sistema. Muitas vezes, é uma atividade importante para medir a conformidade com o SLA de reembolso. Onde encontrar Data e hora do lançamento do diário de fatura do pedido de devolução, que finaliza a nota de crédito. O status do pedido de devolução muda para 'Invoiced'. Coleta Lançamento do diário de fatura do pedido de devolução. Tipo de evento explicit | |||
| Pedido de devolução criado | Esta atividade marca o início do processo de devolução, quando uma autorização de devolução de material (RMA) ou um pedido de devolução é criado no sistema. É um evento explícito, registrado quando um novo registro ReturnOrder é criado no Dynamics 365. | ||
| Por que isso importa Este é o principal evento de início de todo o processo de devolução. Analisar o tempo entre esta atividade e as demais revela o tempo total de atravessamento do processo e ajuda a identificar gargalos nas etapas iniciais. Onde encontrar Este evento é registrado com base na data e hora de criação do cabeçalho ReturnOrder. Em geral, ele é encontrado na SalesTable, quando SalesType é 'Returned Order'. Coleta Evento de criação do registro SalesTable com SalesType = 'Returned Order'. Tipo de evento explicit | |||
| Pedido de devolução encerrado | O pedido de devolução chegou ao estado final, ou seja, todas as transações físicas e financeiras foram concluídas. Isso geralmente ocorre após o lançamento da nota de crédito ou o envio do item de reposição. | ||
| Por que isso importa Este é o principal evento final de um processo de devolução concluído com sucesso. O tempo entre a criação e este ponto representa o tempo total de ciclo do caso. Onde encontrar Inferido pela mudança do campo de status ReturnOrder para um valor final, como 'Invoiced' ou 'Closed'. Isso indica que não são esperadas outras etapas de processamento. Coleta Mudança do campo SalesTable.Status ou SalesTable.DocumentStatus para um estado final. Tipo de evento inferred | |||
| Diário de chegada criado | Esta atividade indica que o armazém está aguardando a chegada do item devolvido. Ela corresponde à criação de um diário de chegada, que prepara o sistema para o recebimento físico dos produtos. | ||
| Por que isso importa Esta etapa separa a preparação logística do recebimento físico. Ela ajuda a analisar a prontidão do armazém e o planejamento para as devoluções que estão chegando. Onde encontrar Criação de um registro na WMSJournalTable com JournalType 'Arrival'. O diário é vinculado à linha do pedido de devolução. Coleta Data e hora de criação do registro WMSJournalTable da devolução. Tipo de evento explicit | |||
| Item de reposição enviado | A guia de remessa do item de reposição é lançada, indicando que ele foi enviado ao cliente. Isso marca a conclusão do processo de atendimento da troca. | ||
| Por que isso importa Este é um marco importante na variante de troca, pois representa o cumprimento da obrigação da empresa com o cliente. É essencial acompanhá-lo para medir os tempos de ciclo das trocas. Onde encontrar Data de lançamento do diário da guia de remessa do pedido de venda de reposição. Isso atualiza o status do pedido para 'Delivered'. Coleta Lançamento da guia de remessa do pedido de venda de reposição. Tipo de evento explicit | |||
| Nota de crédito criada | Uma nota de crédito é gerada com base na destinação 'Credit', autorizando o reembolso ao cliente. Esta etapa marca o início formal da liquidação financeira do processo. | ||
| Por que isso importa Esta atividade marca a aprovação do reembolso. O tempo entre a definição da destinação e a criação da nota de crédito revela atrasos administrativos no início do reembolso. Onde encontrar Este evento pode ser inferido pela criação de um novo registro SalesTable com valor negativo, vinculado ao pedido de devolução original, ou pela execução do processo em lote 'Create credit note'. Coleta Criação de uma nota de crédito, geralmente pelo lançamento da fatura do pedido de devolução. Tipo de evento explicit | |||
| Ordem de qualidade gerada | Uma ordem formal de qualidade é criada, indicando que o item devolvido deve passar por uma inspeção estruturada. Isso é comum quando as devoluções exigem testes detalhados ou verificações com base em padrões de qualidade. | ||
| Por que isso importa Esta atividade marca o início de um processo formal de inspeção. Acompanhar o tempo a partir deste ponto ajuda a medir a eficiência e a duração do fluxo de trabalho de garantia da qualidade. Onde encontrar Data e hora de criação de um registro na InventQualityOrderTable vinculado ao pedido de devolução. Coleta Criação de um registro na InventQualityOrderTable. Tipo de evento explicit | |||
| Pedido de devolução cancelado | O pedido de devolução é cancelado antes da conclusão. Isso pode ocorrer a pedido do cliente ou porque o item nunca foi devolvido. | ||
| Por que isso importa Este é um desfecho alternativo e malsucedido do processo. Analisar os motivos dos cancelamentos pode revelar insights sobre o comportamento dos clientes ou falhas no processo. Onde encontrar Inferido pela mudança do campo de status ReturnOrder para 'Cancelled'. Este é um estado final distinto do encerramento bem-sucedido de um pedido. Coleta Mudança do campo SalesTable.Status para 'Cancelled'. Tipo de evento inferred | |||
| Pedido de devolução confirmado | Indica a confirmação formal do pedido de devolução no sistema, que muitas vezes aciona etapas subsequentes. Em geral, é registrado como uma ação explícita ou uma mudança de status no cabeçalho ReturnOrder. | ||
| Por que isso importa A confirmação é uma etapa essencial antes do início da logística. Atrasos entre a criação e a confirmação podem indicar acúmulo de trabalho administrativo ou problemas no sistema. Onde encontrar Este evento pode ser identificado pelo lançamento do diário 'Confirmation' do pedido de devolução ou por uma mudança no campo DocumentStatus da SalesTable. Coleta Execução da função 'Confirm sales order' para o pedido de devolução. Tipo de evento explicit | |||
| Pedido de reposição criado | Um novo pedido de venda é criado para enviar um item de reposição ao cliente. Esta atividade ocorre quando a ação de destinação é 'Replace and Credit' ou 'Replace and Scrap'. | ||
| Por que isso importa Esta atividade inicia a variante do processo de troca. Acompanhar esse caminho separadamente do caminho de reembolso é essencial para entender a complexidade e os custos das trocas. Onde encontrar Criação de um novo registro SalesTable para o item de reposição, muitas vezes gerado automaticamente e vinculado ao pedido de devolução original. Coleta Criação de um novo pedido de venda vinculado ao pedido de devolução por meio da ação de destinação. Tipo de evento explicit | |||
Guias de extração
Etapas
- Pré-requisitos: registre um aplicativo no Azure Active Directory. Antes de se conectar à API do Dynamics 365, registre um aplicativo no seu ambiente do Azure AD. Conceda ao aplicativo permissões delegadas para acessar o Dynamics 365 Finance & Operations, como
Financials.ReadWrite.Allou uma permissão personalizada. - Configure o ID do aplicativo no Dynamics 365. No Dynamics 365, acesse System administration > Setup > Azure Active Directory applications. Adicione o ID do aplicativo (cliente) do registro do aplicativo no Azure AD e associe-o a uma conta de usuário com as funções de segurança necessárias para ler as entidades de dados desejadas.
- Obtenha um token de acesso OAuth 2.0. Crie um script, por exemplo, em PowerShell ou Python, para autenticar no endpoint da plataforma de identidade da Microsoft. Use as credenciais do aplicativo (ID e segredo do cliente) para solicitar um token de acesso à URL do recurso do Dynamics 365.
- Identifique a URL do seu ambiente do Dynamics 365. Localize a URL base do ambiente. O endpoint da Web API geralmente segue este formato:
https://[YourD365FinanceAndOpsURL].dynamics.com/data. - Monte e execute as solicitações à API OData. Para cada uma das 12 atividades necessárias, monte uma URL específica para uma solicitação OData GET. Use
$selectpara recuperar apenas as colunas necessárias e$filterpara definir o período e as condições de status. Inclua o token de autenticação obtido na etapa 3 como token Bearer no cabeçalho de autorização de cada solicitação. - Desenvolva um script de extração. Crie um script que percorra a lista de solicitações OData. Ele deve cuidar da autenticação, executar cada solicitação GET e armazenar os dados JSON resultantes. Fique atento aos limites da API e inclua pausas quando necessário.
- Trate a paginação da API. O Dynamics 365 divide resultados grandes em páginas. Seu script deve verificar se a resposta contém a propriedade
@odata.nextLink. Se ela existir, o script deverá fazer outra solicitação para essa URL e recuperar a página seguinte. Continue até que não haja maisnextLink. - Transforme e una os dados. Processe a resposta JSON de cada uma das 12 chamadas à API. Para cada atividade, crie um registro padronizado com
ReturnCaseId,ActivityName,EventTimee outros atributos. Por exemplo, para o evento 'Return Order Created', mapeieReturnOrderNumberparaReturnCaseId, definaActivityNamecomo 'Return Order Created' e mapeiecreatedDateTimeparaEventTime. Reúna os registros transformados de todas as chamadas em uma única lista ou tabela. - Limpe e padronize os registros de data e hora. Garanta que todos os valores de
EventTimeusem um formato consistente, de preferência UTC, comoYYYY-MM-DDTHH:MM:SSZ. Trate os registros com valores de data e hora ausentes ou inválidos conforme necessário. - Exporte o Event Log final. Depois de coletar e transformar todos os dados em um conjunto de dados unificado, exporte-o para um arquivo CSV. Confira se os cabeçalhos das colunas atendem aos requisitos do ProcessMind:
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodeetc. O arquivo estará pronto para ser carregado.
Configuração
- URL do endpoint da API: URL base da sua instância do Dynamics 365 Finance & Operations. O formato é
https://[YourEnvironmentName].dynamics.com/data. - Aplicativo do Azure AD: registre um aplicativo no Azure AD com um ID e um segredo do cliente. Ele precisa de permissões de API para acessar as entidades de dados do Dynamics 365.
- Filtro por período: é essencial aplicar um filtro de período em cada chamada à API usando o parâmetro OData
$filterem um campo de data relevante, comocreatedDateTimeoumodifiedDateTime. Para começar, use normalmente os dados dos últimos 3 a 6 meses, mantendo a extração em um volume gerenciável. - Filtro por empresa: para extrair dados de uma entidade legal específica, inclua o parâmetro de consulta
cross-company=truee use$filterno campodataAreaId. Por exemplo:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - Preferência de paginação: use o cabeçalho
Prefer: odata.maxpagesize=[value]nas solicitações para definir quantos registros serão retornados por página. É comum usar um valor entre1000e5000. Isso ajuda a evitar tempos limite da API em entidades grandes. - Limitação de chamadas à API: considere os limites de proteção do serviço da API do Dynamics 365. O script de extração deve tratar respostas
429 (Too Many Requests), normalmente com uma espera exponencial ou um mecanismo simples de pausa e nova tentativa.
Consulta de exemplo graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser Etapas
- Habilite o endpoint TDS: confirme se o endpoint Tabular Data Stream (TDS) está habilitado no seu ambiente do Dynamics 365 Dataverse. Um administrador do sistema pode habilitá-lo no centro de administração do Power Platform, em Environment > Settings > Features.
- Identifique a URL do ambiente: localize a URL do ambiente. Ela geralmente segue o formato
yourorg.crm.dynamics.com. O nome do servidor do endpoint TDS será essa URL com a porta 5558, por exemplo,yourorg.crm.dynamics.com,5558. - Conecte-se com um cliente SQL: use um cliente SQL compatível com TDS, como o SQL Server Management Studio (SSMS) ou o Azure Data Studio.
- Autenticação: conecte-se ao servidor usando sua conta do Azure Active Directory, que deve ter as permissões adequadas no ambiente do Dataverse, geralmente de System Administrator ou System Customizer.
- Prepare a consulta: copie a consulta SQL completa fornecida na seção
querydeste documento para uma nova janela de consulta no cliente SQL. - Defina os parâmetros: localize os espaços reservados na consulta. Substitua
'{StartDate}'e'{EndDate}'pelo período desejado para a extração, por exemplo,'2023-01-01'e'2023-12-31'. Atualize também os valores de espaços reservados para códigos de status ou de disposição de acordo com a configuração do seu Dynamics 365. - Execute a consulta: execute a consulta modificada no banco de dados do Dataverse. O tempo de execução varia conforme o volume de dados e o período selecionado.
- Revise os resultados: quando a consulta terminar, confira se o conjunto de dados retornado contém as colunas esperadas:
ReturnCaseId,ActivityName,EventTimee os atributos recomendados. - Exporte o Event Log: exporte os resultados da consulta para um arquivo CSV. A maioria dos clientes SQL tem uma função integrada para salvar os resultados diretamente em um arquivo. Salve o arquivo com codificação UTF-8.
- Carregue no ProcessMind: o arquivo CSV exportado está pronto para ser carregado no ProcessMind como um novo Event Log para análise de Process Mining.
Configuração
- Pré-requisitos: você precisa de uma conta de usuário com pelo menos acesso de leitura às tabelas relevantes do Dataverse (por exemplo, SalesTable, SalesLine, CustInvoiceJour). As permissões geralmente são gerenciadas por meio de funções de segurança, como System Administrator, ou de uma função personalizada com permissões suficientes para as tabelas.
- Endpoint TDS: o endpoint TDS do Dataverse precisa estar habilitado no ambiente. Esse recurso permite executar consultas SQL diretamente no banco de dados do Dataverse, somente para leitura.
- Período: a consulta inclui os espaços reservados
'{StartDate}'e'{EndDate}'. Para a análise inicial, recomendamos um período de 3 a 6 meses, que oferece um conjunto de dados representativo sem causar problemas de performance. - Filtro por empresa: da forma como está escrita, a consulta será executada em todas as entidades legais (empresas) às quais o usuário tem acesso. Para analisar uma única empresa, remova o comentário e adicione uma cláusula
WHEREque filtre pelo campoDATAAREAIDem cada parte da instruçãoUNION ALL. Por exemplo:AND st.DATAAREAID = '[YourCompanyID]'. - Espaços reservados para lógica personalizada: a consulta contém espaços reservados como
[YourReplaceCode1]para códigos de disposição, além de observações sobre a vinculação de pedidos de substituição. Configure-os de acordo com seu processo de negócio e sua instalação do Dynamics 365. - Performance: consultas diretas ao endpoint TDS podem ser lentas quando o conjunto de dados é grande. A conexão é otimizada para consultas analíticas, mas junções complexas que abrangem milhões de linhas podem atingir o tempo limite. Recomendamos aplicar filtros de período rigorosos.
Consulta de exemplo sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; Pronto para começar?
Use este Template para simplificar a coleta de dados e começar a encontrar insights que ajudem a melhorar o processo de devoluções e reembolsos. Comece hoje a jornada para agilizar o processamento e aumentar a satisfação dos clientes.
Acabe com os atrasos em devoluções e reembolsos: otimize seu processo hoje
Reduza o tempo de ciclo em 30% e aumente a satisfação dos clientes.
Não é necessário informar o cartão de crédito. A configuração leva poucos minutos.