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 coletar
- Atividades-chave a monitorizar
- Orientação prática para extração de dados
Order to Cash (O2C) - Atributos de Processamento de Pedidos de Venda
| Nome | Descrição | ||
|---|---|---|---|
| Pedido de venda SalesOrder | O identificador exclusivo de um pedido de venda, servindo como o caso (case) principal para o processo de Order to Cash. | ||
| Descrição O número do Pedido de Venda identifica de forma exclusiva cada pedido do cliente ao longo do seu ciclo de vida. Ele atua como o fio condutor que conecta todas as atividades relacionadas, desde a criação inicial e confirmação até o atendimento, faturamento e pagamento final. No process mining, este atributo é essencial para agrupar todos os eventos relacionados em um único caso (case). Analisar o processo pelo Pedido de Venda permite uma visão completa de ponta a ponta, possibilitando o cálculo dos tempos totais de ciclo, a identificação de variantes de processo para pedidos individuais e o rastreamento da jornada de um pedido através de diferentes departamentos e sistemas. Por que é importante Este é o ID do Caso (Case ID). Ele vincula todos os eventos do processo, permitindo rastrear a jornada de ponta a ponta de um único pedido de cliente. Onde obter Este identificador é geralmente encontrado na tabela de cabeçalho de pedidos de venda no Oracle Fusion, como DOO_HEADERS_ALL. Consulte a documentação do Oracle Fusion Financials. Exemplos SO-100567SO-100568SO-100569 | |||
| Nome da Atividade ActivityName | O nome do evento ou tarefa de negócio específica que ocorreu no processo de pedido de venda. | ||
| Descrição Este atributo descreve a etapa que foi executada em um momento específico para um pedido de venda, como 'Pedido Criado', 'Mercadorias Enviadas' ou 'Pagamento Recebido'. A sequência dessas atividades forma o fluxo do processo para cada caso. Analisar o Nome da Atividade é fundamental para o process mining. Permite a visualização do mapa do processo, a descoberta de diferentes variantes e a identificação de gargalos. É a base para calcular os tempos de transição entre as etapas e entender a sequência operacional do processo de Order to Cash. Por que é importante Este atributo define as etapas no mapa do processo, permitindo a visualização e análise do fluxo de trabalho. Onde obter Este é um atributo derivado, construído pelo mapeamento de status de transação ou tipos de eventos de várias tabelas do Oracle Fusion para uma lista padronizada de nomes de atividades. Exemplos Pedido de venda criadoMercadorias expedidasFatura CriadaPagamento Recebido | |||
| Tempo do Evento EventTime | O registro de data e hora (timestamp) indicando quando uma atividade ou evento específico ocorreu para um pedido de venda. | ||
| Descrição Este atributo fornece a data e hora de cada atividade no processo, estabelecendo a sequência cronológica dos eventos. É a espinha dorsal temporal da análise do processo. No process mining, o Horário do Evento é crítico para calcular tempos de ciclo e lead times totais. Ele permite a detecção de gargalos com base em tempos de espera e o monitoramento da conformidade com SLAs de pontualidade. Todos os KPIs e dashboards baseados em tempo dependem da precisão deste atributo. Por que é importante Este registro de tempo é essencial para ordenar os eventos cronologicamente e calcular todas as métricas baseadas em tempo, como durações e tempos de ciclo. Onde obter Este é um atributo derivado, extraído de vários campos de timestamp em diferentes tabelas do Oracle Fusion, como data de criação do pedido, data de envio, data da fatura e data de pagamento. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| 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 é crítico para o dashboard de 'Visão Geral de Desempenho do Canal'. Ajuda a comparar a eficiência, tempos de ciclo e taxas de erro de diferentes canais para identificar quais são mais eficazes e quais podem exigir melhorias ou mais automação. Por que é importante Suporta a análise de desempenho por canal, ajudando a identificar os canais mais e menos eficientes para o processamento de pedidos. Onde obter Esta informação pode estar armazenada em um campo dedicado no cabeçalho do pedido de venda. Consulte a documentação do Oracle Fusion Financials. Exemplos Venda DiretaPortal WebEDIRevendedor | |||
| Data de entrega real ActualDeliveryDate | A data em que as mercadorias foram efetivamente entregues ao cliente. | ||
| Descrição Este atributo registra a data de entrega final, que marca a conclusão da etapa de atendimento do processo. É o resultado real pelo qual as datas planejadas ou solicitadas são medidas. Esta data é comparada com a data solicitada para calcular a performance de entrega pontual. É um dado crítico para o KPI 'Taxa de Entrega Pontual', fornecendo uma medida clara da eficácia da logística e da cadeia de suprimentos. Por que é importante Esta é a data do resultado real usada para calcular as taxas de entrega pontual e avaliar o desempenho do atendimento em relação às solicitações dos clientes. Onde obter Extraído das tabelas de transações de remessa e entrega no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos 2023-05-202023-06-032023-05-25 | |||
| Data de entrega solicitada RequestedDeliveryDate | A data de entrega do pedido solicitada pelo cliente. | ||
| Descrição Este atributo captura a data em que o cliente deseja receber as mercadorias. Ele serve como uma meta de desempenho fundamental para a parte de atendimento do processo de Order to Cash. Esta data é essencial para o cálculo do KPI 'Taxa de Entrega Pontual' e para o dashboard de 'SLA de Entrega'. Ao comparar esta data com a data real de entrega, a organização pode medir sua capacidade de atender às expectativas dos clientes e identificar as causas raiz dos atrasos. Por que é importante Serve como linha de base para medir a performance de entrega pontual e conformidade com os acordos de nível de serviço (SLAs). Onde obter Geralmente localizado nas tabelas de itens de linha 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-limite para o cliente efetuar o pagamento da fatura. | ||
| Descrição A Data de Vencimento do Pagamento é calculada com base na data da fatura e nos termos de pagamento acordados com o cliente. Ela define o prazo para a cobrança pontual. Este atributo é crucial para o KPI 'Taxa de Cobrança Pontual'. Ao comparar a data de vencimento com a data real de recebimento do pagamento, o sistema pode determinar se um pagamento foi pontual ou atrasado, ajudando a monitorar o desempenho do contas a receber e a gerir o fluxo de caixa. Por que é importante Serve como o prazo para calcular as taxas de pagamento pontual, que é uma medida fundamental da eficiência do fluxo de caixa. Onde obter Encontrado em tabelas de faturamento ou contas a receber no Oracle Fusion, como AR_PAYMENT_SCHEDULES_ALL. Exemplos 2023-06-192023-07-012023-06-25 | |||
| É Automatizado IsAutomated | Um indicador que mostra se a atividade foi executada automaticamente pelo sistema ou manualmente por um usuário. | ||
| Descrição Este atributo booleano distingue entre eventos acionados pelo sistema (ex: verificação automática de crédito) e ações manuais de usuários. Geralmente é derivado do nome do usuário associado à atividade. Analisar este atributo ajuda a medir o nível de automação e é uma entrada direta para o KPI de 'Porcentagem de Pedidos com Retrabalho Manual'. Ele destaca oportunidades de automação ao mostrar quais etapas manuais são mais demoradas ou propensas a erros. Por que é importante Ajuda a quantificar o nível de automação e identificar chances de reduzir intervenções manuais caras. Onde obter Este é um campo derivado, muitas vezes baseado em uma regra aplicada ao atributo UserName. Por exemplo, se o usuário for 'SISTEMA' ou 'LOTE', este sinalizador é definido como verdadeiro. Exemplos verdadeirofalse | |||
| Nome do Cliente CustomerName | O nome do cliente que realizou o pedido de venda. | ||
| Descrição Este atributo identifica o nome legal da conta do cliente associada ao pedido. É uma dimensão fundamental para segmentar e analisar o processo sob uma ótica centrada no cliente. Analisar por cliente ajuda a identificar se determinados perfis enfrentam tempos de ciclo mais longos ou mais retrabalho. Esse insight pode ser usado para melhorar o atendimento, personalizar processos para contas estratégicas e investigar problemas de satisfação. Por que é importante Permite análises focadas no cliente para identificar problemas que afetam contas específicas e elevar o nível de satisfação. Onde obter Extraído das tabelas de dados mestre de clientes (ex: HZ_PARTIES) e vinculado ao pedido de venda via ID do cliente. Exemplos Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Nome do Utilizador 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. Pode ser usado para analisar o desempenho individual, distribuição de carga de trabalho e adesão aos procedimentos padrão. A análise por usuário ajuda a identificar necessidades de treinamento, reconhecer equipes de alto desempenho e investigar desvios causados por usuários específicos. Também é valioso para fins de conformidade e auditoria. Por que é importante Permite analisar a performance por usuário, distribuir carga de trabalho e identificar padrões de retrabalho manual ligados a indivíduos. Onde obter Geralmente extraído de campos como CREATED_BY ou LAST_UPDATED_BY nas tabelas de transação do Oracle Fusion, frequentemente vinculado 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 por todo o pedido. Inclui a soma de todos os itens, impostos e outros encargos, antes de quaisquer descontos. Na análise de processos, este atributo é crucial para o process mining baseado em valor. Ele permite segmentar pedidos (ex: alto vs. baixo valor) para ver se seguem caminhos diferentes. Também ajuda a priorizar esforços de melhoria nos casos financeiramente mais significativos. Por que é importante Permite análise de impacto financeiro, ajudando a priorizar melhorias em pedidos de alto valor e entender os geradores de custo. Onde obter Geralmente encontrado nas tabelas de cabeçalho de 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 sob as quais o cliente deve pagar sua fatura, por exemplo, 'Net 30' ou 'Net 60'. Estes termos são a base para o cálculo da data de vencimento. Na análise, segmentar pelos termos de pagamento ajuda a explicar variações nos tempos de ciclo de pagamento. Fornece contexto para o KPI de 'Taxa de Pagamento Pontual', informando políticas de crédito e previsões de fluxo de caixa. Por que é importante Fornece um contexto crucial para a análise do comportamento de pagamento e ajuda a explicar variações nos tempos de ciclo da fatura ao pagamento. Onde obter Disponível no nível do pedido de venda ou conta do cliente no Oracle Fusion. Exemplos Líquido 30Líquido 60Vencimento no Recebimento | |||
| É Pagamento em Atraso IsLatePayment | Indicador que confirma se o pagamento foi recebido após a data de vencimento. | ||
| Descrição Este atributo booleano é derivado da comparação entre a data real de recebimento e a data de vencimento. Ele indica claramente se uma fatura foi paga no prazo. É usado para calcular o KPI 'Taxa de Pagamento Pontual'. Permite a segmentação entre pagamentos pontuais e atrasados para analisar características de clientes inadimplentes, razões comuns para atrasos e o impacto financeiro no capital de giro. Por que é importante Mede diretamente a eficácia da cobrança e simplifica a análise de pagamentos inadimplentes. Onde obter Este é um campo calculado. A lógica é: DataRecebimentoPagamento > DataVencimentoPagamento. Exemplos falseverdadeiro | |||
| Entrega no prazo IsOnTimeDelivery | Indicador que confirma se a entrega real ocorreu na data solicitada ou antes. | ||
| Descrição Este atributo booleano é derivado da comparação entre a data real de entrega e a data solicitada. Fornece um indicador simples de performance de entrega no nível do caso. Este sinalizador é a base para o cálculo do KPI 'Taxa de Entrega Pontual'. Simplifica a filtragem e análise, permitindo isolar rapidamente pedidos atrasados para realizar a análise de causa raiz dos fatores que contribuem para os atrasos. Por que é importante Mede diretamente o desempenho 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 é: DataRealEntrega <= DataSolicitadaEntrega. Exemplos verdadeirofalse | |||
| Fatura foi corrigida? IsInvoiceCorrected | Indicador que mostra se uma fatura foi corrigida ou revisada após sua criação inicial. | ||
| Descrição Este atributo booleano é verdadeiro se uma fatura passou por um loop de correção, indicado pela atividade 'Fatura Corrigida'. Ele sinaliza casos que envolveram retrabalho no faturamento. É uma entrada chave para o dashboard de 'Análise de Precisão e Retrabalho' e para o KPI de 'Taxa de Retrabalho de Faturas'. Ajuda a quantificar erros e permite a análise de causa raiz para reduzir o trabalho manual e atrasos nos pagamentos. Por que é importante Identifica retrabalho em faturas, um indicador chave de ineficiência, problemas de qualidade de dados e possíveis atrasos de pagamento. Onde obter Este é um campo calculado, geralmente definido como verdadeiro se uma atividade de 'Fatura Corrigida' existir em seu event log. Exemplos falseverdadeiro | |||
| Método de envio ShippingMethod | O método ou transportadora utilizada para o envio das mercadorias ao cliente. | ||
| Descrição Este atributo detalha a transportadora logística ou o nível de serviço utilizado para a entrega, como 'Frete Rodoviário', 'Aéreo Expresso' ou 'Mensageiro Local'. Esta informação é essencial para o dashboard de 'Conformidade de Entrega por Método de Envio'. Permite comparar o desempenho de entrega no prazo e os custos de frete entre diferentes métodos e transportadoras, ajudando a otimizar a estratégia logística. Por que é importante Suporta a análise logística ao comparar a performance de diferentes transportadoras e métodos de envio. Onde obter Disponível nas tabelas de envio e atendimento no 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 sendo vendido. | ||
| Descrição Este atributo especifica o item na linha do pedido. Se um pedido tiver várias linhas, o caso pode ser analisado por item, ou este atributo pode ser agregado no nível do cabeçalho. Analisar por produto ajuda a entender se certos itens estão associados a fluxos mais complexos ou problemáticos, como atrasos frequentes. Isso pode orientar as estratégias de gestão de produtos e da cadeia de suprimentos. Por que é importante Permite analisar a performance por produto, destacando itens com fluxos complexos de atendimento ou faturamento. Onde obter Extraído das tabelas de itens de linha do pedido de venda e cruzado com uma tabela mestre de produtos. Consulte a documentação do Oracle Fusion Financials. Exemplos Widget Padrão X1Pacote de Serviço PremiumComponente Y2-B | |||
| Número da fatura InvoiceNumber | O identificador único da fatura do cliente. | ||
| Descrição Este atributo é o número exclusivo atribuído à fatura gerada a partir do pedido de venda. Ele vincula as atividades de venda e atendimento à parte de liquidação financeira do processo. Embora o Pedido de Venda seja o ID do caso principal, o Número da Fatura é crítico para analisar os subprocessos de faturamento e pagamento. É essencial para rastrear correções de faturas, disputas e status de pagamento, alimentando dashboards como 'Análise de Precisão e Retrabalho de Faturas'. Por que é importante Fornece um link crucial para 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 no Oracle Fusion, como RA_CUSTOMER_TRX_ALL. Exemplos INV-93485INV-93486INV-93487 | |||
| País do Cliente CustomerCountry | O país onde o cliente está localizado. | ||
| Descrição Este atributo fornece o país do endereço de envio ou cobrança do cliente. É uma dimensão fundamental para análise geográfica. Segmentar o processo por país pode revelar diferenças regionais no desempenho, nos tempos de ciclo ou no comportamento de pagamento. Isso é valioso para entender o impacto das regulamentações locais e dos desafios logísticos no processo de Order to Cash. Por que é importante Permite análise geográfica para identificar variações regionais de eficiência, conformidade e comportamento do cliente. Onde obter Extraído das tabelas de dados mestre de clientes (HZ_LOCATIONS, HZ_PARTY_SITES) vinculadas ao pedido de venda. Exemplos EUAAlemanhaJapão | |||
| Sistema de Origem SourceSystemIdentifier | Identifica o sistema de origem de onde os dados de eventos foram extraídos. | ||
| Descrição Este atributo especifica a origem dos dados, o que é útil em ambientes onde vários sistemas estão envolvidos no Order to Cash. Por exemplo, dados do pedido podem vir do Oracle Fusion, enquanto dados de envio podem vir de um sistema logístico terceiro. Na análise, isso ajuda a entender a linhagem dos dados e pode ser usado para filtrar eventos de sistemas específicos. É crucial para a validação de dados e para identificar a fragmentação do processo. Por que é importante Fornece contexto sobre a origem dos dados, o que é crucial para a governança de dados e a resolução de problemas em ambientes de múltiplos sistemas. Onde obter Este é tipicamente um valor estático adicionado durante o processo de extração e transformação de dados para rotular a origem do dataset. Exemplos Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo de Pedido OrderType | Classificação do pedido de venda, como 'Pedido Padrão' ou 'Pedido de Retorno'. | ||
| Descrição O Tipo de Pedido é usado para categorizar pedidos de venda com base em seu propósito comercial. Tipos 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 possuem fluxos de processo e metas de desempenho distintos. Essa segmentação ajuda a entender variações de processo que são intencionais e esperadas, evitando que sejam interpretadas erroneamente como desvios. Por que é importante Permite segmentar fluxos distintos (ex: vendas vs. devoluções) para garantir uma análise justa e precisa. Onde obter Geralmente 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çãoOrdem de serviço | |||
| Última Atualização de Dados LastUpdateDate | O carimbo de data e hora que indica a última vez que os dados deste 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 fornece transparência sobre a atualidade dos dados analisados. Esta informação é vital para que os usuários entendam quão recente é a análise. Ajuda a gerenciar expectativas sobre os dados e é importante para configurar cronogramas de atualização. Por que é importante Indica a atualização dos dados, garantindo que os usuários saibam o quão atualizada está a sua análise de processo. Onde obter Este valor é gerado e marcado no conjunto de dados durante cada ciclo de extração e transformação de 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 dentro da empresa que detém a transação. Ele permite a comparação de desempenho entre diferentes partes da organização. Segmentar o processo por unidade de negócio ajuda a identificar variações de eficiência, custo e conformidade. Essa análise pode revelar as melhores práticas de unidades de alto desempenho ou destacar unidades que precisam de melhorias direcionadas. Por que é importante Permite benchmarks de performance e análise de consistência de processos entre diferentes unidades organizacionais. Onde obter Geralmente disponível no cabeçalho do pedido de venda e vinculado à estrutura organizacional definida no Oracle Fusion. Exemplos BU-North AmericaBU-EMEAServiços Globais | |||
Order to Cash (O2C) - Atividades de Processamento de Pedidos de Venda
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura Criada | Esta atividade representa a criação da fatura do cliente no módulo de Contas a Receber, geralmente acionada pelo evento de confirmação de envio. Um registro de fatura é gerado com um número único e data de criação. | ||
| Por que é importante Marca o início oficial do ciclo de cobrança. É a base para medir o tempo entre faturamento e pagamento, e a eficiência 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 de fatura no módulo de Contas a Receber (AR). Tipo de evento explicit | |||
| Mercadorias expedidas | Esta atividade marca o ponto em que as mercadorias foram despachadas do armazém e estão em trânsito para o cliente. É capturada quando uma transação de confirmação de envio é processada no Oracle Shipping. | ||
| Por que é importante Este é um marco crítico que sinaliza a conclusão da parte de atendimento do processo e aciona o faturamento. É essencial para medir o envio pontual e os lead times de entrega. Onde obter Este é um evento explícito registrado no Oracle Shipping Execution. A transação de confirmação de envio cria um registro nas tabelas de expedição como WSH_DELIVERY_DETAILS com uma data de envio. Captura Capturado a partir da data real de envio ('actual ship date') no registro detalhado da entrega vinculado à linha do pedido. Tipo de evento explicit | |||
| Pagamento Recebido | Esta atividade significa que o pagamento do cliente foi recebido e aplicado contra a fatura no Contas a Receber. Isso é capturado quando uma aplicação de recebimento de caixa é lançada. | ||
| Por que é importante Este é um marco crítico para medir o 'Tempo de Ciclo Total do Order to Cash' e a 'Taxa de Pagamento Pontual'. Representa a conversão da venda em dinheiro. Onde obter Este é um evento explícito no Oracle Accounts Receivable. É registrado nas tabelas de recebimento de caixa como AR_RECEIVABLE_APPLICATIONS_ALL quando um recebimento é aplicado a uma fatura. Captura Capturado a partir da data de aplicação ('apply date') do registro de recebimento de caixa no Contas a Receber (AR). Tipo de evento explicit | |||
| Pedido Confirmado | Este marco fundamental indica que o pedido de venda passou por todas as verificações iniciais, incluindo aprovação de crédito, e está agora comprometido para atendimento. É geralmente inferido quando o status do pedido avança para 'Aguardando Envio' ou 'Agendado'. | ||
| Por que é importante Esta atividade é um marco crítico para calcular o 'Tempo Médio de Confirmação do Pedido' e marca a transferência da entrada do pedido para o processo de atendimento. Onde obter Inferido pela mudança de status para valores como 'Aguardando Envio'. Verifique as colunas de status em DOO_HEADERS_ALL ou DOO_FULFILL_LINES_ALL. Captura Derivado do timestamp em que o status do pedido muda para 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. Este evento é geralmente capturado quando um usuário salva um novo registro de pedido no módulo de Order Management. | ||
| Por que é importante Como início do processo, esta atividade é essencial para medir o tempo de ciclo total do Order to Cash e analisar o volume de entrada de pedidos. Onde obter Registrado explicitamente na criação de um registro de pedido de venda no Order Management Cloud. Procure pelos timestamps de criação na tabela DOO_HEADERS_ALL. Captura Capturado a partir do timestamp de criação no cabeçalho do pedido de venda. Tipo de evento explicit | |||
| Pedido encerrado | A atividade final no processo, indicando 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 é importante Esta atividade marca o fim bem-sucedido do ciclo de vida do pedido de venda. É essencial para calcular as durações dos processos de ponta a ponta e identificar pedidos "zumbis" que nunca fecham. Onde obter Inferido pela mudança de status no cabeçalho para 'Fechado' na tabela DOO_HEADERS_ALL. O timestamp desta mudança serve como o tempo do evento. Captura Derivado do timestamp da mudança de status para 'Fechado' no cabeçalho do pedido. Tipo de evento inferred | |||
| Análise de crédito realizada | Representa a execução de uma verificação de crédito na conta do cliente para avaliar a solvência. Frequentemente é uma etapa automatizada ou manual no workflow de processamento de pedidos, e sua conclusão é geralmente registrada como uma atualização de status ou uma tarefa concluída. | ||
| Por que é importante Analisar o tempo de análise de crédito ajuda a identificar gargalos na aprovação. É vital para o KPI de tempo de confirmação. Onde obter Pode ser inferido pelas mudanças de status do pedido, como 'Pendente de Aprovação de Crédito', ou por logs de eventos na funcionalidade de gestão de crédito. Captura Inferido por mudanças de status do pedido ou timestamps de tarefas de revisão de crédito. Tipo de evento inferred | |||
| Bloqueio de Crédito Aplicado | Esta atividade ocorre quando um pedido de venda é retido automática ou manualmente devido a uma falha na verificação de crédito ou outro problema relacionado. Geralmente é capturada por uma mudança no status de retenção do pedido no sistema. | ||
| Por que é importante O acompanhamento das retenções de crédito é crucial para identificar os motivos dos atrasos no processamento de pedidos e para medir a eficiência do processo de liberação dessas retenções. Onde obter Inferido pela aplicação de uma retenção (hold). Geralmente registrado em tabelas como DOO_HOLDS_ALL, vinculadas ao pedido. Captura Inferido pela criação de um registro na tabela de retenção de pedidos com o tipo 'Crédito'. Tipo de evento inferred | |||
| Estoque Reservado | Esta atividade representa a alocação ou reserva de estoque físico para atender à linha do pedido de venda. O sistema compromete o estoque específico, garantindo que esteja disponível para a separação. | ||
| Por que é importante O acompanhamento disso ajuda a analisar o KPI 'Lead Time de Alocação de Estoque' e identifica atrasos entre a confirmação do pedido e a reserva das mercadorias. Onde obter Este evento é frequentemente capturado nos módulos de estoque ou execução da cadeia de suprimentos. Pode ser inferido a partir de atualizações de status que indicam que o estoque foi detalhado ou reservado. Captura Inferido por mudanças de status na linha de atendimento ligadas a reserva ou agendamento de estoque. Tipo de evento inferred | |||
| Fatura Corrigida | Ocorre quando uma fatura criada anteriormente é modificada, reemitida ou creditada devido a erros ou disputas de clientes. Isso geralmente é registrado pela criação de uma nota de crédito ou uma nova versão da fatura. | ||
| Por que é importante O rastreamento de correções de faturas é fundamental para o KPI 'Taxa de Retrabalho de Faturas', destacando problemas no faturamento que podem atrasar pagamentos e elevar custos administrativos. Onde obter Inferido pela criação de uma nota de crédito ou versão posterior da fatura na tabela RA_CUSTOMER_TRX_ALL. Captura Derivado da identificação de notas de crédito ou faturas que referenciam uma transação anterior. Tipo de evento inferred | |||
| Linha do pedido fechada | Representa o fechamento final de uma linha de pedido de venda individual, indicando que ela foi totalmente enviada, faturada e não são esperadas mais transações. O sistema atualiza o status da linha para 'Fechado'. | ||
| Por que é importante O fechamento das linhas significa que todas as obrigações foram cumpridas. Analisar isso ajuda a encontrar pedidos que continuam abertos muito após a entrega e o pagamento. Onde obter Inferido pela mudança de status para 'Fechado' na tabela DOO_FULFILL_LINES_ALL. O timestamp desta mudança marca o evento. Captura Derivado do timestamp da mudança de status para 'Fechado' na linha de atendimento. Tipo de evento inferred | |||
| Mercadorias entregues | Indica o recebimento pelo cliente. Pode vir de uma transportadora externa ou ser inferido por tempos de trânsito padrão a partir da data de envio. | ||
| Por que é importante Esta atividade é crucial para o cálculo do KPI de 'Taxa de Entrega Pontual' e para medir os níveis de serviço ao cliente com precisão. Onde obter Geralmente não é um evento nativo do Oracle. Pode ser capturado se houver integração com transportadoras, ou calculado somando um tempo de trânsito padrão à data de envio. Requer análise de sistema. Captura Inferido por feeds de dados da transportadora ou calculado pela data de envio somada ao tempo de trânsito médio. Tipo de evento inferred | |||
| Mercadorias separadas | Representa a separação física de mercadorias no armazém para atender ao pedido. Esta é uma etapa fundamental no processo logístico e geralmente é registrada no módulo de gestão de armazém ou expedição. | ||
| Por que é importante Esta atividade fornece visibilidade sobre as operações do armazém. Atrasos entre a reserva de estoque e a separação podem indicar gargalos de recursos ou de processos no armazém. Onde obter Capturado nos módulos de SCM do Oracle Fusion Cloud. Pode ser inferido pela mudança de status da separação (pick) vinculada à linha do pedido. Captura Inferido a partir do timestamp de conclusão da transação de separação (pick) nos módulos de SCM. Tipo de evento inferred | |||
| Pedido Cancelado | Representa o cancelamento de um pedido de venda antes de ser totalmente enviado. Isso pode ocorrer por vários motivos e resulta em um status final de 'Cancelado'. | ||
| Por que é importante Este é um caminho de exceção crítico. Analisar pedidos cancelados ajuda a identificar causas raiz, como falta de estoque ou problemas de preços, o que pode orientar melhorias no processo. Onde obter Inferido pela mudança de status para 'Cancelado' no cabeçalho ou linha do pedido. O timestamp é usado para registrar o evento. Captura Derivado do timestamp da mudança de status para 'Cancelado' no cabeçalho ou linha do pedido. Tipo de evento inferred | |||
Guias de Extração
Etapas
- Acesse o Oracle BI Publisher: Entre no Oracle Fusion com um usuário que tenha privilégios de BI Administrator ou BI Author. No menu Navigator, vá em Ferramentas > Relatórios e Análises. Clique em 'Procurar Catálogo' para abrir o Business Intelligence Catalog.
- Crie um Novo Data Model: No catálogo, escolha uma pasta apropriada (ex: Shared Folders > Custom). Clique no menu 'Novo' e selecione 'Modelo de Dados' (Data Model).
- Defina o Dataset de Query SQL: No editor, clique no ícone '+' para criar um novo dataset e escolha 'Consulta SQL'. Nomeie o dataset (ex: 'OrderToCash_EventLog'), selecione 'Oracle BI EE' como fonte de dados e escolha 'Standard SQL'.
- Insira a Query SQL: Copie a query SQL completa fornecida na seção 'query' deste documento e cole-a na área de texto. A query possui parâmetros de data (:p_start_date e :p_end_date) que o BI Publisher reconhecerá automaticamente.
- Configure as Propriedades: Clique em 'OK' após colar a query. Vá em 'Propriedades' no painel esquerdo e certifique-se de que 'Include Parameter Tags' esteja marcado. Você pode definir valores padrão para as datas aqui.
- Visualize e Salve: Clique na aba 'Dados'. Informe um intervalo de datas curto para teste e clique em 'Visualizar'. Se os dados estiverem corretos, salve o modelo com um nome descritivo (ex: 'OrderToCash_EventLog_DM').
- Crie um Relatório: Com o modelo salvo, clique em 'Criar Relatório' no canto superior direito para abrir o assistente.
- Configure o Relatório: Escolha 'Usar Modelo de Dados'. No layout, selecione 'Tabela'. Arraste todas as colunas para a tabela. Clique em 'Próximo' e desmarque 'Mostrar Linha de Totais Gerais'. Salve o relatório como 'OrderToCash_EventLog_Report'.
- Execute o Relatório: Abra o relatório criado e insira as datas de início e fim desejadas para a extração.
- Exporte os Dados: Após a execução, no menu 'Visualizar', procure a opção 'Exportar' e escolha o formato 'CSV'. O download do Event Log começará.
- Finalize para Upload: Abra o CSV e verifique se os cabeçalhos estão corretos: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. O arquivo está pronto para o Process Mining.
Configuração
- Privilégios de Usuário: Você deve ter uma função com privilégios de criação de relatórios e modelos de dados no BI Publisher, como 'BI Administrator' ou 'BI Author'.
- Fonte de Dados: A query foi projetada para a fonte de dados padrão 'Oracle BI EE', que se conecta ao banco de dados transacional (Fusion Apps). Geralmente, não é necessária nenhuma configuração especial.
- Parâmetros de Intervalo de Datas: A query utiliza dois parâmetros, :p_start_date e :p_end_date, para filtrar os dados. Recomendamos extrair os dados em lotes gerenciáveis, de 3 a 6 meses por vez, para evitar timeouts e problemas de performance no relatório.
- Filtro de Unidade de Negócio: Para limitar o escopo da extração, você pode adicionar uma cláusula WHERE ao CTE BaseOrders na query para filtrar por um ID de Unidade de Negócio específico (ex: AND dhead.SUBMITTING_BU_ID IN ([Seu ID de Business Unit])).
- Filtro de Tipo de Pedido: Você também pode filtrar tipos específicos de pedidos de venda adicionando uma condição em dhead.SOURCE_ORDER_TYPE_CODE no CTE BaseOrders.
- Performance: Para conjuntos de dados muito grandes abrangendo vários anos, esta abordagem de query única pode ser lenta. Considere executá-la em horários de baixo acesso ou dividir a extração em lotes mensais menores. Certifique-se de que a propriedade 'Enable SQL Pruning' não esteja selecionada no Data Model, pois ela pode interferir em queries 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 no Oracle Fusion com um usuário que possua a função BICC_ADMINISTRATOR. Vá em Ferramentas e selecione Business Intelligence Cloud Connector no menu.
- Configure o Armazenamento Externo: No console do BICC, clique em Configure External Storage para definir seu destino, que pode ser o Oracle UCM ou um bucket no OCI Object Storage. Verifique se as credenciais e detalhes de conexão estão corretos.
- Inicie um Novo Job de Extração: Vá para a seção Manage Extract Jobs. Clique no ícone + para criar um novo job. Use 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 o ciclo do pedido. Você precisará de vários, 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, clique no menu Actions e escolha Select Columns. Selecione cuidadosamente os campos necessários para o Event Log, como HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e identificadores de usuário.
- Filtros para Cargas Incrementais: Para gerenciar o volume, aplique um filtro em cada PVO baseado na coluna LastUpdateDate. Na primeira execução, use um intervalo amplo. Para os agendamentos seguintes, configure para extrair apenas registros atualizados desde a última execução.
- Agende o Job: Na seção Manage Schedule, crie um novo agendamento. Recomendamos executar o job em horários de baixo uso, como diariamente durante a madrugada, para minimizar o impacto no sistema.
- Monitore a Execução: Após configurar, envie o job. Você pode acompanhar o progresso na tela Manage Extract Jobs. Ao concluir, os arquivos estarão disponíveis no seu armazenamento em nuvem em formato CSV compactado.
- Transforme Dados Brutos em um Event Log: Baixe os arquivos CSV. O BICC entrega dados brutos de tabelas, não um Event Log formatado. Use uma ferramenta externa (Python, script de banco de dados ou ETL) para:
- Unir dados de diferentes arquivos (ex: vincular dados da fatura ao cabeçalho do pedido).
- Transformar colunas de data em linhas de atividades distintas. Por exemplo, do arquivo Header, crie uma linha para 'Pedido de Venda Criado' usando CreationDate e outra para 'Pedido Fechado' usando ClosedDate.
- Mapear códigos de status para atividades como 'Pedido Confirmado' ou 'Pedido Cancelado'.
- Combinar tudo em um único arquivo com as colunas: SalesOrder, ActivityName e EventTime.
- Prepare o Upload: Garanta que o arquivo final seja um CSV único, com as colunas correspondentes aos atributos necessários. Agora ele está pronto para o upload no ProcessMind.
Configuração
- Seleção de PVOs: A precisão do Event Log depende totalmente da seleção dos PVOs corretos. Os principais incluem FscmTopModelAM.DooTopAM.Header (para criação e fechamento de pedidos), FscmTopModelAM.ScmTopAM.ShipmentLine (para eventos de envio) e FscmTopModelAM.ArTopAM.ReceivableInvoice (para faturamento).
- Extração Incremental: Sempre utilize o filtro LastUpdateDate para extrações recorrentes. Isso é crucial para a performance e evita a extração repetida de conjuntos de dados de vários gigabytes. A carga inicial completa deve estabelecer uma linha de base, com as execuções seguintes capturando 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, para equilibrar a completude com um volume de dados gerenciável. As execuções posteriores serão incrementais.
- Configuração de Armazenamento: O BICC pode exportar para o Oracle UCM ou OCI Object Storage. O uso do OCI Object Storage é geralmente recomendado para cenários de dados em massa e facilita a integração com ferramentas de ETL.
- Agendamento de Jobs: Agende as extrações fora do horário comercial para evitar qualquer degradação de performance no sistema transacional do Oracle Fusion Financials.
- Pré-requisitos: Os usuários que configuram o job precisam da função BICC_ADMINISTRATOR. É necessário ter credenciais de armazenamento em nuvem pré-configuradas e uma compreensão clara da 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 filtering