Seu Template de dados de Order to Cash - Processamento de pedidos de venda
Seu Template de dados de Order to Cash - Processamento de pedidos de venda
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações práticas para extração de dados
Atributos do processamento de pedidos de venda de Order to Cash
| Nome | Descrição | ||
|---|---|---|---|
| Pedido de venda SalesOrder | O identificador exclusivo de um pedido de venda, que funciona como o caso principal do processo Order to Cash. | ||
| Descrição O número do pedido de venda identifica exclusivamente cada pedido do cliente durante todo o seu ciclo de vida. Ele funciona como o fio condutor central que conecta todas as atividades relacionadas, desde a criação e confirmação iniciais até o atendimento, faturamento e pagamento final. No Process Mining, esse atributo é essencial para agrupar todos os eventos relacionados em um único caso. Analisar o processo por pedido de venda permite ter uma visão completa de ponta a ponta, calcular os tempos totais de ciclo, identificar variantes do processo para pedidos individuais e acompanhar a jornada de um pedido por diferentes departamentos e sistemas. Por que isso importa Este é o Case ID. Ele conecta todos os eventos do processo, permitindo rastrear a jornada completa de um único pedido do cliente. Onde obter Esse identificador normalmente é encontrado na tabela de cabeçalho dos pedidos de venda no Oracle Fusion, como DOO_HEADERS_ALL. Consulte a documentação do Oracle Fusion Financials. Exemplos SO-100567SO-100568SO-100569 | |||
| Hora do evento EventTime | O registro de data e hora que indica quando uma atividade ou evento específico ocorreu para um pedido de venda. | ||
| Descrição Este atributo fornece a data e a hora de cada atividade do processo, estabelecendo a sequência cronológica dos eventos. Ele é a base temporal da análise do processo, registrando exatamente quando cada etapa aconteceu. No Process Mining, o EventTime é essencial para calcular tempos de ciclo, durações entre atividades e lead times gerais dos casos. Ele permite analisar a performance, detectar gargalos com base nos tempos de espera e monitorar a conformidade com acordos de nível de serviço (SLAs) relacionados a prazos. Todos os KPIs e Dashboards baseados em tempo dependem da precisão desse atributo. Por que isso importa Esse registro de data e hora é essencial para ordenar cronologicamente os eventos e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações. Onde obter Este é um atributo derivado, obtido de vários campos de data e hora em diferentes tabelas do Oracle Fusion, como data de criação do pedido, data de envio, data da fatura e data do pagamento. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Nome da atividade ActivityName | O nome do evento de negócio ou da tarefa específica que ocorreu no processo de pedido de venda. | ||
| Descrição Este atributo descreve a etapa executada em um momento específico para um pedido de venda, como 'Pedido de venda criado', 'Produtos enviados' ou 'Pagamento recebido'. A sequência dessas atividades forma o fluxo do processo de cada caso. Analisar o ActivityName é fundamental para o Process Mining. Isso permite visualizar o mapa do processo, descobrir diferentes variantes e identificar gargalos onde os casos se acumulam. Também é a base para calcular os tempos de transição entre as etapas e entender a sequência operacional do processo Order to Cash. Por que isso importa Este atributo define as etapas no mapa do processo, permitindo visualizar e analisar o fluxo do processo. Onde obter Este é um atributo derivado, construído pelo mapeamento de status de transações ou tipos de eventos de várias tabelas do Oracle Fusion, como status do pedido, status da remessa e status da fatura, para uma lista padronizada de nomes de atividades. Exemplos Pedido de venda criadoProdutos enviadosFatura criadaPagamento recebido | |||
| Canal de vendas SalesChannel | O canal pelo qual o pedido de venda foi recebido. | ||
| Descrição Este atributo categoriza a origem do pedido de venda, como 'Web', 'Vendas diretas', 'Parceiro' ou 'EDI'. Ele fornece contexto sobre como o pedido entrou na organização. Segmentar o processo por canal de vendas é essencial para o Dashboard 'Visão geral da performance dos canais de vendas'. Isso ajuda a comparar a eficiência, os tempos de ciclo e as taxas de erro dos diferentes canais, identificando quais são mais eficazes e quais podem exigir melhorias no processo ou mais automação. Por que isso importa Apoia a análise da performance por canal, ajudando a identificar os canais mais e menos eficientes no processamento de pedidos. Onde obter Essas informações podem ser armazenadas em um campo dedicado no cabeçalho do pedido de venda. Consulte a documentação do Oracle Fusion Financials. Exemplos Vendas diretasPortal webEDIRevendedor | |||
| Data de entrega solicitada RequestedDeliveryDate | A data de entrega do pedido solicitada pelo cliente. | ||
| Descrição Este atributo registra a data em que o cliente deseja receber os produtos. Ele funciona como uma meta de performance importante para a etapa de atendimento do processo Order to Cash. Essa data é essencial para calcular o KPI 'Taxa de entrega no prazo' e apoiar o Dashboard 'Acordo de nível de serviço de entrega (SLA)'. Ao comparar essa data com a ActualDeliveryDate, a organização pode medir sua capacidade de atender às expectativas dos clientes e identificar as causas-raiz dos atrasos nas entregas. Por que isso importa Funciona como referência para medir a performance das entregas no prazo e a conformidade com o acordo de nível de serviço (SLA) ao cliente. Onde obter Normalmente, está localizada nas tabelas de itens das linhas de pedidos de venda no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos 2023-05-202023-06-012023-05-25 | |||
| Data de vencimento do pagamento PaymentDueDate | A data até a qual o cliente deve efetuar o pagamento da fatura. | ||
| Descrição A data de vencimento do pagamento é calculada com base na data da fatura e nas condições de pagamento acordadas com o cliente. Ela define o prazo para o recebimento no prazo. Esse atributo é essencial para o KPI 'Taxa de recebimento de pagamentos no prazo'. Ao comparar a PaymentDueDate com a data real de recebimento do pagamento, o sistema pode determinar se o pagamento foi feito no prazo ou com atraso, ajudando a monitorar a performance de contas a receber e gerenciar o fluxo de caixa. Por que isso importa Funciona como prazo para calcular as taxas de pagamentos no prazo, uma medida importante da eficiência do fluxo de caixa. Onde obter Encontrada nas tabelas de contas a receber ou de faturas do Oracle Fusion, como AR_PAYMENT_SCHEDULES_ALL. Exemplos 2023-06-192023-07-012023-06-25 | |||
| Data real de entrega ActualDeliveryDate | A data em que os produtos foram efetivamente entregues ao cliente. | ||
| Descrição Este atributo registra a data final de entrega, que marca a conclusão da etapa de atendimento do processo. É o resultado real usado para comparar as datas planejadas ou solicitadas. Essa data é comparada com a RequestedDeliveryDate para calcular a performance das entregas no prazo. É uma entrada essencial para o KPI 'Taxa de entrega no prazo' e o Dashboard 'SLA de entrega', oferecendo uma medida clara da eficácia da logística e da cadeia de suprimentos. Por que isso importa É a data real do resultado usada para calcular as taxas de entrega no prazo e avaliar a performance do atendimento em relação às solicitações dos clientes. Onde obter Obtida de tabelas de transações de envio e entrega no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos 2023-05-202023-06-032023-05-25 | |||
| É automatizado IsAutomated | Um indicador que informa se uma atividade foi executada automaticamente pelo sistema ou manualmente por um usuário. | ||
| Descrição Este atributo booleano diferencia eventos conduzidos pelo sistema, como uma verificação de crédito automatizada ou uma fatura gerada pelo sistema, de ações manuais do usuário. Normalmente, ele é derivado com base no nome de usuário associado a uma atividade, em que um ID de sistema genérico indica automação. Analisar esse atributo ajuda a medir o nível de automação do processo e é uma entrada direta para o KPI 'Percentual de pedidos retrabalhados manualmente'. Ele pode destacar oportunidades de automação ao mostrar quais etapas manuais consomem mais tempo ou estão mais sujeitas a erros. Por que isso importa Ajuda a quantificar o nível de automação do processo e identificar oportunidades para reduzir intervenções manuais dispendiosas. Onde obter Este é um campo derivado, geralmente baseado em uma regra aplicada ao atributo UserName. Por exemplo, se o usuário for 'SYSTEM' ou 'BATCH', esse indicador será definido como true. Exemplos truefalse | |||
| Nome do cliente CustomerName | O nome do cliente que fez o pedido de venda. | ||
| Descrição Este atributo identifica o nome legal da conta do cliente associada ao pedido de venda. É uma dimensão importante para segmentar e analisar o processo sob a perspectiva do cliente. Analisar por cliente ajuda a identificar se determinados clientes enfrentam tempos de ciclo mais longos, mais retrabalho ou desvios específicos no processo. Esse insight pode ser usado para melhorar o atendimento ao cliente, adaptar processos para contas estratégicas e investigar problemas que afetam a satisfação do cliente. Por que isso importa Permite uma análise centrada no cliente para identificar problemas do processo que afetam clientes específicos e melhorar a satisfação do cliente. Onde obter Obtido de tabelas de dados mestres de clientes, como HZ_PARTIES, e vinculado ao pedido de venda por meio de um ID de cliente. Exemplos Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Nome do usuário UserName | O nome ou ID do usuário que executou a atividade. | ||
| Descrição Este atributo identifica o funcionário ou usuário do sistema responsável por executar uma etapa específica do processo. Ele pode ser usado para analisar a performance por usuário, a distribuição da carga de trabalho e a adesão aos procedimentos padrão. Analisar por usuário ajuda a identificar necessidades de treinamento, reconhecer pessoas ou times de alta performance e investigar desvios causados por usuários específicos. Também é útil para fins de conformidade e auditoria, permitindo rastrear quem executou cada ação. Por que isso importa Permite analisar a performance por usuário, a distribuição da carga de trabalho e a identificação de padrões de retrabalho manual associados a pessoas específicas. Onde obter Normalmente, é obtido de campos como CREATED_BY ou LAST_UPDATED_BY nas tabelas de transações do Oracle Fusion, geralmente vinculados a uma tabela mestre de usuários, como FND_USER. Exemplos john.smithjane.doesystem_batch_user | |||
| Valor total do pedido de venda SalesOrderTotalAmount | O valor monetário total do pedido de venda. | ||
| Descrição Este atributo representa o valor total cobrado do cliente pelo pedido de venda completo. Ele inclui a soma de todos os itens, impostos e outras cobranças, antes da aplicação de descontos. Na análise do processo, esse atributo é essencial para o Process Mining baseado em valor. Ele permite segmentar os pedidos por valor, como pedidos de alto e baixo valor, para verificar se seguem caminhos diferentes ou têm tempos de ciclo distintos. Também ajuda a priorizar iniciativas de melhoria nos casos com maior impacto financeiro. Por que isso importa Permite analisar o impacto financeiro, ajudando a priorizar melhorias nos pedidos de alto valor e entender os fatores que geram custos. Onde obter Normalmente, é encontrado nas tabelas de cabeçalho dos pedidos de venda no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos 5250.00125000.75980.50 | |||
| Condições de pagamento PaymentTerms | As condições acordadas para o pagamento do cliente. | ||
| Descrição Este atributo especifica as condições em que o cliente deve pagar a fatura, por exemplo, 'Net 30' ou 'Net 60'. Essas condições são a base para calcular o PaymentDueDate. Na análise, segmentar os dados por condições de pagamento pode ajudar a explicar variações nos tempos de ciclo de pagamento. Isso dá contexto ao KPI 'On-Time Payment Rate', já que condições diferentes naturalmente levam a comportamentos de pagamento diferentes. Essas informações podem orientar a política de crédito e a previsão de fluxo de caixa. Por que isso importa Oferece um contexto essencial para analisar o comportamento de pagamento e ajuda a explicar variações nos tempos de ciclo entre faturamento e pagamento. Onde obter Disponível no nível do pedido de venda ou da conta do cliente no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos Líquido em 30 diasLíquido em 60 diasVencimento na entrega | |||
| Entrega no prazo IsOnTimeDelivery | Um indicador calculado que é verdadeiro quando a entrega real ocorre na data de entrega solicitada ou antes dela. | ||
| Descrição Este atributo booleano é derivado da comparação entre ActualDeliveryDate e RequestedDeliveryDate. Ele fornece um indicador simples da performance de entrega no nível do caso. Esse indicador é a base para calcular o KPI agregado 'On-Time Delivery Rate'. Ele simplifica a filtragem e a análise, permitindo que você identifique rapidamente todos os pedidos atrasados e faça uma análise de causa raiz dos fatores que contribuem para os atrasos. Por que isso importa Mede diretamente a performance do atendimento em relação às expectativas do cliente e simplifica a análise de pedidos atrasados. Onde obter Este é um campo calculado. A lógica é: ActualDeliveryDate <= RequestedDeliveryDate. Exemplos truefalse | |||
| Fatura corrigida IsInvoiceCorrected | Um indicador que informa se uma fatura foi corrigida ou revisada após sua criação inicial. | ||
| Descrição Este atributo booleano é verdadeiro quando uma fatura passou por um ciclo de correção, indicado pela presença da atividade 'Invoice Corrected'. Ele identifica casos que envolveram retrabalho na etapa de faturamento. Esse é um dado essencial para o Dashboard 'Invoice Accuracy & Rework Analysis' e para o KPI 'Invoice Rework Rate'. Ele ajuda a quantificar a extensão dos erros de faturamento e permite fazer uma análise de causa raiz para identificar por que as correções são necessárias, com o objetivo de reduzir o trabalho manual e os atrasos nos pagamentos. Por que isso importa Identifica o retrabalho de faturas, um indicador importante de ineficiência do processo, problemas de qualidade dos dados e possíveis atrasos nos pagamentos. Onde obter Este é um campo calculado, normalmente definido como verdadeiro para um caso quando existe uma atividade 'Invoice Corrected' no Event Log. Exemplos falsetrue | |||
| Método de envio ShippingMethod | O método ou a transportadora usada para enviar os produtos ao cliente. | ||
| Descrição Este atributo detalha a transportadora ou o nível de serviço logístico usado na entrega, como 'Transporte terrestre', 'Expresso aéreo' ou 'Transportadora local'. Essas informações são essenciais para o Dashboard 'Conformidade das entregas por método de envio'. Elas permitem comparar a performance das entregas no prazo e os custos de envio entre diferentes métodos e transportadoras, ajudando a otimizar a estratégia logística e a seleção de fornecedores. Por que isso importa Apoia diretamente a análise logística ao permitir comparar a performance de diferentes transportadoras e métodos de envio. Onde obter Disponível nas tabelas de expedição e atendimento de pedidos do Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos FedEx GroundUPS Next Day AirDHL International | |||
| Nome do produto ProductName | O nome do produto ou serviço vendido. | ||
| Descrição Este atributo especifica o item na linha do pedido de venda. Se um pedido tiver várias linhas, o caso poderá ser analisado no nível do item da linha, ou esse atributo poderá ser agregado no nível do cabeçalho. Analisar por produto ajuda a entender se determinados produtos estão associados a fluxos de processo mais complexos ou problemáticos, como atrasos frequentes na entrega ou problemas de pagamento. Isso pode orientar estratégias de gestão de produtos e da cadeia de suprimentos. Por que isso importa Permite analisar a performance do processo para diferentes produtos, destacando itens que podem ter caminhos complexos de atendimento ou faturamento. Onde obter Obtido das tabelas de itens das linhas de pedidos de venda e associado a uma tabela mestre de produtos. Consulte a documentação do Oracle Fusion Financials. Exemplos Standard Widget X1Premium Service PackageComponent Y2-B | |||
| Número da fatura InvoiceNumber | O identificador exclusivo da fatura do cliente. | ||
| Descrição Este atributo é o número exclusivo atribuído à fatura gerada a partir do pedido de venda. Ele conecta as atividades de vendas e atendimento de pedidos à etapa de liquidação financeira do processo. Embora o Sales Order seja o ID de caso principal, o Invoice Number é essencial para analisar os subprocessos de faturamento e pagamento. Ele é indispensável para acompanhar correções de faturas, disputas e o status de pagamento, dando suporte a Dashboards como 'Invoice Accuracy & Rework Analysis'. Por que isso importa Oferece uma conexão essencial com o processo de contas a receber e é necessário para analisar o retrabalho de faturas e os ciclos de pagamento. Onde obter Disponível nas tabelas de transações de contas a receber do Oracle Fusion, como RA_CUSTOMER_TRX_ALL. Exemplos INV-93485INV-93486INV-93487 | |||
| Pagamento atrasado IsLatePayment | Um indicador calculado que é verdadeiro quando o pagamento é recebido após a data de vencimento. | ||
| Descrição Este atributo booleano é derivado da comparação entre a data real de recebimento do pagamento e o PaymentDueDate. Ele fornece uma indicação clara de que a fatura foi paga ou não no prazo. Este atributo é usado para calcular o KPI 'On-Time Payment Rate'. Ele permite segmentar facilmente pagamentos feitos no prazo e atrasados, analisando as características dos clientes que pagam em atraso, os motivos mais comuns dos atrasos e o impacto financeiro no capital de giro. Por que isso importa Mede diretamente a eficácia da cobrança de pagamentos e simplifica a análise de pagamentos em atraso. Onde obter Este é um campo calculado. A lógica é: PaymentReceivedDate > PaymentDueDate. Exemplos falsetrue | |||
| País do cliente CustomerCountry | O país onde o cliente está localizado. | ||
| Descrição Este atributo informa o país do endereço de entrega ou cobrança do cliente. É uma dimensão importante para a análise geográfica. Segmentar o processo por país pode revelar diferenças regionais na performance do processo, nos tempos de ciclo ou no comportamento de pagamento. Isso é útil para entender o impacto das regulamentações locais, dos desafios logísticos e das condições de mercado no processo Order to Cash. Por que isso importa Permite analisar a distribuição geográfica para identificar variações regionais na eficiência do processo, na conformidade e no comportamento do cliente. Onde obter Obtido nas tabelas de dados mestres de clientes (HZ_LOCATIONS, HZ_PARTY_SITES) vinculadas ao pedido de venda. Exemplos USAAlemanhaJapão | |||
| Sistema de origem SourceSystemIdentifier | Identifica o sistema de origem do qual os dados do evento foram extraídos. | ||
| Descrição Este atributo especifica a origem dos dados, o que é especialmente útil em ambientes que envolvem vários sistemas no processo Order to Cash. Por exemplo, os dados do pedido podem vir do Oracle Fusion, enquanto os dados de envio podem ter origem em um sistema de logística de terceiros. Na análise, isso ajuda a entender a linhagem dos dados e pode ser usado para filtrar a visão do processo por eventos de sistemas específicos. É essencial para validar os dados e identificar a fragmentação do processo em diferentes ambientes de TI. Por que isso importa Fornece contexto sobre a origem dos dados, algo essencial para a governança de dados e a solução de problemas em ambientes com vários sistemas. Onde obter Normalmente, é um valor estático adicionado durante a extração e transformação dos dados para identificar a origem do conjunto de dados. Exemplos Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo de pedido OrderType | Uma classificação do pedido de venda, como 'Standard Order' ou 'Return Order'. | ||
| Descrição Order Type é usado para categorizar pedidos de venda de acordo com sua finalidade comercial. Os tipos mais comuns incluem vendas padrão, pedidos de serviço, autorizações de devolução de material (RMAs) e pedidos internos. Analisar o processo por tipo de pedido é importante porque diferentes tipos geralmente têm fluxos de processo e metas de performance próprios. Essa segmentação ajuda a entender variações de processo intencionais e esperadas, evitando que sejam interpretadas incorretamente como desvios. Por que isso importa Permite segmentar diferentes fluxos de processo legítimos, como pedidos padrão e devoluções, garantindo uma análise justa e precisa. Onde obter Normalmente disponível como um campo na tabela de cabeçalho do pedido de venda no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos Pedido de venda padrãoAutorização de devoluçãoPedido de serviço | |||
| Última atualização dos dados LastUpdateDate | O registro de data e hora que indica a última vez em que os dados desse evento foram atualizados a partir do sistema de origem. | ||
| Descrição Este atributo registra quando os dados foram extraídos ou atualizados pela última vez no conjunto de dados de Process Mining. Ele oferece transparência sobre a atualidade dos dados analisados. Essa informação é essencial para que você entenda o quanto a análise do processo está atualizada. Ela ajuda a alinhar as expectativas sobre a atualidade dos dados e é importante para configurar e monitorar os cronogramas de atualização. Por que isso importa Indica a atualidade dos dados, garantindo que você saiba o quanto a análise do processo está atualizada. Onde obter Esse valor é gerado e gravado no conjunto de dados durante cada ciclo de extração e transformação dos dados. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Unidade de negócio BusinessUnitName | O nome da unidade de negócio interna responsável pelo pedido de venda. | ||
| Descrição Este atributo representa a divisão ou unidade operacional específica da empresa que é responsável pela transação. Ele permite comparar a performance entre diferentes áreas da organização. Segmentar o processo por unidade de negócio ajuda a identificar variações de eficiência, custo e conformidade na empresa. Essa análise pode revelar boas práticas em unidades de alta performance para compartilhá-las ou destacar unidades com baixa performance que precisam de melhorias direcionadas no processo. Por que isso importa Permite comparar a performance e analisar a consistência do processo entre diferentes unidades organizacionais. Onde obter Normalmente, está disponível no cabeçalho do pedido de venda e vinculado à estrutura organizacional definida no Oracle Fusion. Exemplos BU-North AmericaBU-EMEAGlobal Services | |||
Atividades do processamento de pedidos de venda de Order to Cash
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura criada | Esta atividade representa a criação da fatura do cliente no módulo Accounts Receivable, normalmente acionada pelo evento de confirmação de envio. Um registro de fatura é gerado com um número exclusivo e uma data de criação. | ||
| Por que isso importa Marca o início oficial do ciclo de cobrança do pagamento. É a base para medir o 'Tempo da fatura até o pagamento' e a eficiência geral do fluxo de caixa. Onde obter Este é um evento explícito no Oracle Accounts Receivable (AR). Um registro de fatura é criado na tabela RA_CUSTOMER_TRX_ALL com uma data de transação. Captura Capturado a partir da data de criação da transação da fatura no módulo AR. Tipo de evento explicit | |||
| Pagamento recebido | Esta atividade indica que o pagamento do cliente foi recebido e aplicado à fatura no Accounts Receivable. Ela é capturada quando a aplicação de um recebimento em dinheiro é lançada. | ||
| Por que isso importa Este é um marco essencial para medir o 'Tempo total do ciclo Order to Cash' e a 'Taxa de pagamentos no prazo'. Ele representa a conversão da venda em dinheiro. Onde obter Este é um evento explícito no Oracle Accounts Receivable. Ele é registrado em tabelas de recebimentos, como AR_RECEIVABLE_APPLICATIONS_ALL, quando um recebimento é aplicado a uma fatura. Captura Capturado a partir do registro de data e hora da 'data de aplicação' do registro de aplicação do recebimento em dinheiro no AR. Tipo de evento explicit | |||
| Pedido confirmado | Este marco importante indica que o pedido de venda passou por todas as verificações iniciais, incluindo a aprovação de crédito, e agora está comprometido com o atendimento. Normalmente, ele é inferido quando o status do pedido avança para um estado como 'Aguardando envio' ou 'Agendado'. | ||
| Por que isso importa Esta atividade é um marco essencial para calcular o 'Tempo médio de confirmação do pedido' e marca a transição da entrada do pedido para o processo de atendimento. Onde obter Inferido a partir da alteração do status do cabeçalho ou da linha do pedido de venda para um valor que indique que ele está pronto para atendimento, como 'Aguardando envio'. Verifique as colunas de status em DOO_HEADERS_ALL ou DOO_FULFILL_LINES_ALL. Captura Derivado do registro de data e hora em que o status do pedido muda para um estado confirmado ou agendado. Tipo de evento inferred | |||
| Pedido de venda criado | Esta atividade marca o início do processo de pedido de venda, representando o momento em que um novo pedido é inserido no Oracle Fusion. Normalmente, esse evento é capturado de forma explícita quando um usuário salva um novo registro de pedido no módulo Order Management. | ||
| Por que isso importa Como início do processo, esta atividade é essencial para medir o tempo total do ciclo Order to Cash e analisar os volumes de entrada de pedidos. Onde obter Registrado explicitamente no momento da criação de um registro de pedido de venda no Order Management Cloud. Procure os registros de data e hora de criação na tabela DOO_HEADERS_ALL. Captura Capturado a partir do registro de data e hora de criação do cabeçalho do pedido de venda. Tipo de evento explicit | |||
| Pedido fechado | A atividade final do processo indica que todas as linhas do pedido de venda foram atendidas, faturadas e fechadas. O status do cabeçalho do pedido é atualizado para 'Fechado'. | ||
| Por que isso importa Esta atividade marca o encerramento bem-sucedido do ciclo de vida do pedido de venda. Ela é essencial para calcular as durações do processo de ponta a ponta e identificar pedidos zumbis que nunca são fechados. Onde obter Inferido a partir da alteração do status do cabeçalho do pedido de venda para 'Fechado' na tabela DOO_HEADERS_ALL. O registro de data e hora dessa alteração final representa o momento do evento. Captura Derivado do registro de data e hora da alteração do status do cabeçalho do pedido de venda para 'Fechado'. Tipo de evento inferred | |||
| Produtos enviados | Esta atividade marca o momento em que os produtos são despachados do armazém e entram em trânsito até o cliente. Ela é capturada quando uma transação de confirmação de envio é processada no Oracle Shipping. | ||
| Por que isso importa Este é um marco essencial que indica a conclusão da etapa de atendimento do processo e aciona o faturamento. Ele é fundamental para medir os prazos de envio e entrega no prazo. Onde obter Este é um evento explícito registrado no Oracle Shipping Execution. A transação de confirmação de envio cria um registro em tabelas de expedição, como WSH_DELIVERY_DETAILS, com uma data de envio. Captura Capturado a partir do registro de data e hora da 'data real de envio' no registro de detalhes da entrega associado à linha do pedido. Tipo de evento explicit | |||
| Estoque reservado | Esta atividade representa a alocação ou reserva do estoque físico para atender a linha do pedido de venda. O sistema compromete um estoque específico, garantindo sua disponibilidade quando o pedido estiver pronto para separação. | ||
| Por que isso importa Acompanhar esse dado ajuda a analisar o KPI 'Lead time de alocação de estoque' e identificar atrasos entre a confirmação do pedido e a reserva dos produtos. Onde obter Esse evento costuma ser capturado nos módulos de estoque ou de execução da cadeia de suprimentos. Ele pode ser inferido a partir de atualizações no status da linha de atendimento que indiquem que o estoque foi detalhado ou reservado. Captura Inferido a partir de alterações no status da linha de atendimento relacionadas à reserva ou ao agendamento do estoque. Tipo de evento inferred | |||
| Fatura corrigida | Ocorre quando uma fatura criada anteriormente é modificada, reemitida ou creditada devido a erros ou contestações do cliente. Normalmente, isso é capturado pela criação de uma nota de crédito ou de uma nova versão da fatura. | ||
| Por que isso importa Acompanhar as correções de faturas é essencial para o KPI 'Taxa de retrabalho de faturas', destacando problemas no processo de faturamento que podem atrasar os pagamentos e aumentar os custos administrativos. Onde obter Inferido a partir da criação de uma nota de crédito vinculada à fatura original ou de uma versão posterior da mesma fatura na tabela RA_CUSTOMER_TRX_ALL. Captura Derivado da identificação de notas de crédito ou faturas que fazem referência a uma transação de fatura anterior. Tipo de evento inferred | |||
| Linha do pedido fechada | Representa o fechamento final de uma linha individual do pedido de venda, indicando que ela foi totalmente enviada e faturada e que não são esperadas novas transações. O sistema atualiza o status da linha para 'Fechado'. | ||
| Por que isso importa Fechar as linhas do pedido indica a conclusão de todas as obrigações contratuais daquele item. Analisar esse dado ajuda a identificar pedidos que continuam abertos muito tempo depois do atendimento e do pagamento. Onde obter Inferido a partir da alteração do status da linha de atendimento para 'Fechado' na tabela DOO_FULFILL_LINES_ALL. O registro de data e hora dessa alteração marca o evento. Captura Derivado do registro de data e hora da alteração do status da linha de atendimento para 'Fechado'. Tipo de evento inferred | |||
| Pedido cancelado | Representa o cancelamento de um pedido de venda antes que ele seja totalmente enviado. Isso pode ocorrer por vários motivos e resulta no status terminal 'Cancelado'. | ||
| Por que isso importa Este é um caminho de exceção importante. Analisar os pedidos cancelados ajuda a identificar causas-raiz, como falta de estoque, problemas de preço ou mudança de decisão do cliente, orientando melhorias no processo. Onde obter Inferido a partir da alteração do status do cabeçalho ou da linha do pedido de venda para o estado 'Cancelado'. O registro de data e hora dessa alteração é usado para registrar o evento. Captura Derivado do registro de data e hora da alteração do status do cabeçalho ou da linha do pedido para 'Cancelado'. Tipo de evento inferred | |||
| Produtos entregues | Indica que o cliente recebeu a remessa. Essas informações geralmente vêm de uma transportadora externa e são atualizadas no Oracle Fusion, ou podem ser inferidas com base em um tempo de trânsito padrão a partir da data de envio. | ||
| Por que isso importa Esta atividade é essencial para calcular o KPI 'Taxa de entrega no prazo' e medir com precisão os níveis de serviço ao cliente. Onde obter Esse geralmente não é um evento nativo do Oracle. Ele pode ser capturado quando há integração com a transportadora ou calculado adicionando um tempo de trânsito padrão à data de 'Produtos enviados'. Requer análise do sistema. Captura Inferido a partir dos dados da transportadora ou calculado com base na data de envio mais um tempo médio de trânsito. Tipo de evento inferred | |||
| Produtos separados | Representa a separação física dos produtos no armazém para atender o pedido. Essa é uma etapa importante do processo logístico e geralmente é registrada no módulo de gestão de armazém ou de expedição. | ||
| Por que isso importa Esta atividade oferece visibilidade sobre as operações do armazém. Atrasos entre a reserva do estoque e a separação podem indicar gargalos de recursos ou do processo no armazém. Onde obter Capturado nos módulos Oracle Fusion Cloud SCM (Supply Chain Management). Pode ser inferido a partir da alteração do status de uma onda de separação ou de uma lista de separação associada à linha do pedido de venda. Captura Inferido a partir do registro de data e hora de conclusão da transação de separação nos módulos SCM. Tipo de evento inferred | |||
| Retenção por crédito aplicada | Esta atividade ocorre quando um pedido de venda é colocado em retenção, automática ou manualmente, devido a uma verificação de crédito reprovada ou a outro problema relacionado ao crédito. Normalmente, isso é capturado por uma alteração no status de retenção do pedido no sistema. | ||
| Por que isso importa Acompanhar as retenções por crédito é essencial para identificar as causas dos atrasos no processamento dos pedidos e medir a eficiência do processo de liberação dessas retenções. Onde obter Inferido a partir da aplicação de uma retenção ao pedido de venda. Normalmente, isso é registrado em tabelas relacionadas a retenções, como DOO_HOLDS_ALL, vinculadas ao pedido de venda. Captura Inferido a partir da criação de um registro na tabela de retenções do pedido com o tipo de retenção 'Credit'. Tipo de evento inferred | |||
| Verificação de crédito realizada | Representa a execução de uma verificação de crédito na conta do cliente para avaliar sua capacidade de pagamento. Essa etapa pode ser automática ou manual no Workflow de processamento do pedido, e sua conclusão normalmente é registrada como uma atualização de status ou uma tarefa concluída. | ||
| Por que isso importa Analisar o tempo gasto nas verificações de crédito ajuda a identificar gargalos na aprovação de pedidos. Esse dado é essencial para o KPI 'Tempo da verificação de crédito até a confirmação'. Onde obter Pode ser inferido a partir de alterações no status do pedido de venda, como a mudança para o status 'Aguardando aprovação de crédito', ou de um Event Log explícito na funcionalidade de gestão de crédito. Captura Inferido a partir de alterações no status do pedido ou dos registros de data e hora associados às tarefas de análise de crédito. Tipo de evento inferred | |||
Guias de extração
Etapas
- Acesse o Oracle BI Publisher: Faça login no seu ambiente Oracle Fusion com um usuário que tenha privilégios de BI Administrator ou BI Author. Use o menu Navigator para acessar Tools > Reports and Analytics. Clique no botão 'Browse Catalog' para abrir o Business Intelligence Catalog.
- Crie um novo modelo de dados: No BI Catalog, acesse uma pasta adequada, como Shared Folders > Custom. Clique no menu suspenso 'New' e selecione 'Data Model'.
- Defina o dataset da consulta SQL: No editor do Data Model, clique no ícone '+' para criar um novo dataset e selecione 'SQL Query'. Uma caixa de diálogo será exibida. Dê um nome ao dataset, como 'OrderToCash_EventLog', selecione 'Oracle BI EE' como Data Source e escolha 'Standard SQL' como tipo de SQL.
- Insira a consulta SQL: Copie a consulta SQL completa fornecida na seção 'query' deste documento e cole-a na área de texto SQL Query. A consulta inclui os parâmetros de data inicial e final (:p_start_date e :p_end_date), que serão reconhecidos automaticamente pelo BI Publisher.
- Configure as propriedades do modelo de dados: Depois de colar a consulta, clique em 'OK'. Acesse a seção 'Properties' no painel esquerdo do editor do modelo de dados. Verifique se 'Include Parameter Tags' está selecionado. Se quiser, você também pode definir valores padrão para os parâmetros de data.
- Visualize e salve o modelo de dados: Clique na aba 'Data'. Talvez seja necessário informar valores para os parâmetros de data. Insira um intervalo curto para fazer um teste. Clique em 'View' para visualizar uma amostra dos dados. Se os dados forem exibidos corretamente, salve o modelo clicando no ícone de salvar e atribuindo um nome descritivo, como 'OrderToCash_EventLog_DM'.
- Crie um relatório a partir do modelo de dados: Com o modelo salvo, clique no botão 'Create Report' no canto superior direito. O assistente de criação de relatórios será aberto.
- Configure o relatório: No assistente, selecione a opção 'Use Data Model'. O assistente orientará você pelas configurações de layout. Para uma exportação CSV simples, escolha o layout 'Table'. Arraste e solte todas as colunas na tabela. Clique em 'Next' e desmarque 'Show Grand Totals Row'. Clique em 'Finish' para salvar o relatório. Dê a ele um nome como 'OrderToCash_EventLog_Report'.
- Execute o relatório: Abra o relatório recém-criado. Será necessário informar as datas inicial e final da extração. Insira o intervalo desejado.
- Exporte os dados: Depois que o relatório for executado, clique no menu suspenso 'View' e selecione outra opção de visualização, como 'View Report'. Em seguida, localize o link ou ícone 'Export' e escolha 'CSV' como formato de exportação. Isso fará o download do arquivo de Event Log.
- Prepare o upload: Abra o arquivo CSV baixado. Verifique se os cabeçalhos das colunas correspondem aos atributos necessários: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. Agora o arquivo está pronto para ser carregado na ferramenta de Process Mining.
Configuração
- Privilégios do usuário: Você precisa ter uma função com privilégios para criar modelos de dados e relatórios no BI Publisher, como 'BI Administrator' ou 'BI Author'.
- Fonte de dados: A consulta foi criada para a fonte de dados padrão da aplicação 'Oracle BI EE', que se conecta ao banco de dados transacional, o Fusion Apps. Normalmente, nenhuma configuração especial é necessária.
- Parâmetros de intervalo de datas: A consulta usa dois parâmetros, :p_start_date e :p_end_date, para filtrar os dados. É altamente recomendável extrair os dados em lotes gerenciáveis, como períodos de 3 a 6 meses por vez, para evitar timeouts do relatório e problemas de performance.
- Filtragem por unidade de negócios: Para limitar o escopo da extração, você pode adicionar uma cláusula WHERE à CTE BaseOrders na consulta e filtrar por um ID específico de unidade de negócios, por exemplo, AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtragem por tipo de pedido: Você também pode filtrar tipos específicos de pedidos de venda adicionando uma condição para dhead.SOURCE_ORDER_TYPE_CODE na CTE BaseOrders.
- Performance: Para datasets muito grandes, que abrangem vários anos, essa abordagem com uma única consulta pode ser lenta. Considere executá-la fora dos horários de pico ou dividir a extração em lotes menores, organizados por mês. Verifique se a propriedade 'Enable SQL Pruning' não está selecionada no Data Model, pois ela pode interferir em consultas UNION complexas.
a Consulta de exemplo sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'Etapas
- Acesse o console do BICC: Faça login na sua instância do Oracle Fusion Applications com um usuário que tenha a função BICC_ADMINISTRATOR. Acesse Tools e selecione Business Intelligence Cloud Connector no menu.
- Crie uma nova oferta: No console do BICC, clique em Configure External Storage para configurar o destino. Ele pode ser o Oracle Universal Content Management (UCM) ou um bucket do OCI Object Storage. Verifique se os dados de conexão e as credenciais estão corretos.
- Inicie um novo job de extração: Acesse a seção Manage Extract Jobs. Clique no ícone + para criar um novo job. Dê um nome descritivo, como ProcessMind_O2C_SalesOrder_Extract.
- Selecione os Data Stores (PVOs): Na configuração do job, pesquise e adicione os Public View Objects (PVOs) necessários para capturar o ciclo de vida do pedido de venda. Você precisará adicionar vários PVOs, incluindo FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice e FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configure as colunas de cada PVO: Para cada PVO selecionado, clique no menu Actions e escolha Select Columns. Selecione cuidadosamente as colunas necessárias para gerar o Event Log, como HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e identificadores de usuário. Consulte o manifesto da consulta para ver a lista detalhada das colunas necessárias de cada PVO.
- Aplique filtros para cargas incrementais: Para gerenciar o volume de dados, aplique um filtro a cada PVO com base na coluna LastUpdateDate. Na execução inicial, você pode selecionar um intervalo de datas amplo. Nas execuções agendadas seguintes, configure esse filtro para extrair somente os registros atualizados desde a última execução do job.
- Agende o job de extração: Acesse a seção Manage Schedule. Crie um novo agendamento para o job. É recomendável executá-lo fora dos horários de pico, por exemplo, diariamente durante a madrugada, para minimizar o impacto na performance do sistema.
- Envie e monitore o job: Depois de configurar tudo, envie o job. Você pode acompanhar o progresso na tela Manage Extract Jobs. Após a conclusão bem-sucedida, os arquivos de dados estarão disponíveis no local de armazenamento em nuvem configurado, em formato CSV compactado.
- Transforme os dados brutos em um Event Log: Baixe os arquivos CSV extraídos. O BICC fornece dados brutos de tabelas, não um Event Log formatado. Você precisará usar uma ferramenta externa, como Python, um script de banco de dados ou uma plataforma de ETL, para processar esses arquivos. Isso inclui:
- Fazer joins entre dados de arquivos diferentes, como vincular os dados da fatura ao cabeçalho do pedido de venda.
- Transformar colunas de data em linhas distintas de atividades. Por exemplo, a partir do arquivo FscmTopModelAM.DooTopAM.Header, crie uma linha para Sales Order Created usando CreationDate e outra para Order Closed usando ClosedDate.
- Mapear códigos ou indicadores de status para atividades específicas, como Order Confirmed ou Order Cancelled.
- Combinar todos os dados transformados em um único arquivo com as colunas necessárias: SalesOrder, ActivityName e EventTime.
- Formate para o upload: Verifique se o arquivo transformado final é um único CSV, com colunas correspondentes aos atributos necessários e recomendados. Agora o arquivo está pronto para ser carregado no ProcessMind.
Configuração
- Seleção de PVOs: A precisão do Event Log depende totalmente da seleção dos PVOs corretos. Os principais PVOs incluem FscmTopModelAM.DooTopAM.Header, para criação e encerramento de pedidos, FscmTopModelAM.ScmTopAM.ShipmentLine, para eventos de envio, e FscmTopModelAM.ArTopAM.ReceivableInvoice, para faturamento.
- Extração incremental: Sempre use o filtro LastUpdateDate para extrações recorrentes. Isso é essencial para a performance e evita extrair repetidamente o mesmo dataset de vários gigabytes. A carga completa inicial deve estabelecer uma base, enquanto as execuções seguintes capturam apenas as alterações.
- Intervalo de datas: Para a primeira carga histórica, extraia um período representativo, como os últimos 3 a 6 meses de dados, equilibrando a abrangência com um volume gerenciável. As execuções seguintes serão incrementais.
- Configuração de armazenamento: O BICC pode exportar para o UCM da Oracle ou para o OCI Object Storage. O OCI Object Storage geralmente é recomendado para cenários de dados em massa e para facilitar a integração com ferramentas de ETL posteriores.
- Agendamento de jobs: Agende os jobs de extração fora do horário comercial para evitar qualquer possível queda de performance no sistema transacional do Oracle Fusion Financials.
- Pré-requisitos: Os usuários que configurarem o job precisam da função BICC_ADMINISTRATOR. Você também precisa ter credenciais de armazenamento em nuvem previamente configuradas e entender claramente a lógica de transformação de dados necessária após a extração.
a Consulta de exemplo config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filteringPronto para começar?
Use este Template para simplificar a coleta de dados e dar início à sua jornada de Process Mining. Comece hoje mesmo a otimizar o processamento de pedidos de venda no processo Order to Cash.
Otimize hoje o processamento de pedidos de venda no Order to Cash
Identifique gargalos e reduza com facilidade em 30% o tempo de ciclo do Order to Cash.
Não é necessário cartão de crédito. Teste grátis por 14 dias.