Seu Template de dados para Order to Cash, processamento de pedidos de venda
Seu Template de dados para 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 Order to Cash, processamento de pedidos de venda
| Nome | Descrição | ||
|---|---|---|---|
| Pedido de venda SalesOrder | Identificador exclusivo de um pedido de venda, usado como caso principal do processo de pedido ao recebimento. | ||
| Descrição O número do pedido de venda identifica cada pedido de cliente de forma exclusiva durante todo o seu ciclo de vida. Ele conecta todas as atividades relacionadas, desde a criação e confirmação até o atendimento, o faturamento e o pagamento final. Em 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 o tempo total do ciclo, identificar variantes do processo em cada pedido e acompanhar seu percurso por diferentes departamentos e sistemas. Por que isso importa Este é o ID do caso. Ele conecta todos os eventos do processo e permite acompanhar a jornada completa de um único pedido de cliente. Onde encontrar Esse identificador costuma estar 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 | |||
| Horário do evento EventTime | O timestamp que indica quando uma atividade ou evento específico ocorreu para um pedido de venda. | ||
| Descrição Este atributo informa a data e a hora de cada atividade do processo e estabelece a sequência cronológica dos eventos. Ele é a base temporal da análise do processo, registrando exatamente quando cada etapa ocorreu. Em Process Mining, o EventTime é essencial para calcular tempos de ciclo, intervalos entre atividades e o tempo total de atravessamento de cada caso. Ele permite analisar a performance, detectar gargalos com base nos tempos de espera e monitorar a Conformidade com os 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 Este timestamp é essencial para ordenar os eventos cronologicamente e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações. Onde encontrar Este é um atributo derivado de vários campos de timestamp em diferentes tabelas do Oracle Fusion, como data de criação do pedido, data de expedição, 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 | Nome do evento de negócio ou da tarefa específica que ocorreu no processo do pedido de venda. | ||
| Descrição Este atributo descreve a etapa executada em um determinado momento para um pedido de venda, como 'Pedido de venda criado', 'Mercadorias expedidas' ou 'Pagamento recebido'. A sequência dessas atividades forma o fluxo do processo de cada caso. Analisar o ActivityName é fundamental para fazer a mineração do processo. Isso permite visualizar o mapa do processo, descobrir diferentes variantes e identificar gargalos onde os casos se acumulam. Também serve de base para calcular os tempos de transição entre etapas e entender a sequência operacional do processo de pedido ao recebimento. Por que isso importa Este atributo define as etapas do mapa do processo e permite visualizar e analisar o fluxo do processo. Onde encontrar Este é um atributo derivado, criado ao mapear status de transações ou tipos de evento de várias tabelas do Oracle Fusion, como status do pedido, da expedição e da fatura, para uma lista padronizada de nomes de atividades. Exemplos Pedido de vendas criadoMercadorias enviadasFatura criadaPagamento recebido | |||
| Canal de vendas SalesChannel | O canal pelo qual o pedido de venda foi recebido. | ||
| Descrição Este atributo classifica a origem do pedido de venda, como 'Web', 'Vendas diretas', 'Parceiro' ou 'EDI'. Ele mostra como o pedido entrou na organização. Segmentar o processo por canal de vendas é essencial para o Dashboard de 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 de cada canal, identificar os mais eficazes e apontar aqueles que podem precisar de melhorias no processo ou de mais automação. Por que isso importa Permite analisar a performance por canal e identificar os mais e menos eficientes no processamento de pedidos. Onde encontrar Essa informação pode estar armazenada em um campo específico no cabeçalho do pedido de venda. Consulte a documentação do Oracle Fusion Financials. Exemplos Vendas diretasPortal da 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 as mercadorias. Ele serve como uma meta de performance importante para a etapa de atendimento do processo de pedido ao recebimento. Essa data é essencial para calcular o KPI de taxa de entregas no prazo e dar suporte ao Dashboard de 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 na entrega. Por que isso importa Serve como referência para medir a performance de entrega no prazo e a Conformidade com o acordo de nível de serviço (SLA) com o cliente. Onde encontrar Geralmente, está nas tabelas de itens das linhas do pedido 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 pagar a 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 receber o pagamento em dia. Este atributo é essencial para o KPI de taxa de recebimentos no prazo. Ao comparar a PaymentDueDate com a data real de recebimento do pagamento, o sistema determina se o pagamento foi feito no prazo ou com atraso. Isso ajuda a monitorar a performance de Contas a Receber e a gerenciar o fluxo de caixa. Por que isso importa Serve como prazo de referência para calcular as taxas de pagamentos no prazo, uma medida importante da eficiência do fluxo de caixa. Onde encontrar Encontrado 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 as mercadorias foram efetivamente entregues ao cliente. | ||
| Descrição Este atributo registra a data final da 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 de entrega no prazo. Ela é um dado essencial para o KPI de taxa de entregas no prazo e o Dashboard de SLA de entrega, pois oferece uma medida clara da eficácia da logística e da cadeia de suprimentos. Por que isso importa Esta é a data do resultado real, usada para calcular as taxas de entrega no prazo e avaliar a performance do atendimento em relação às solicitações dos clientes. Onde encontrar Obtido de tabelas de transações de expedição e entrega no Oracle Fusion. Consulte a documentação do Oracle Fusion Financials. Exemplos 2023-05-202023-06-032023-05-25 | |||
| É automatizada IsAutomated | Um indicador que mostra se uma atividade foi realizada automaticamente pelo sistema ou manualmente por um usuário. | ||
| Descrição Este atributo booleano diferencia eventos conduzidos pelo sistema, como uma análise de crédito automatizada ou uma fatura gerada pelo sistema, de ações manuais de usuários. Geralmente, ele é derivado do nome de usuário associado à atividade: um ID de sistema genérico indica automação. A análise desse atributo ajuda a medir o nível de automação do processo e alimenta diretamente o KPI de percentual de pedidos retrabalhados manualmente. Ela pode revelar oportunidades de ampliar a 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 que geram custos. Onde encontrar Este é um campo derivado, geralmente baseado em uma regra aplicada ao atributo UserName. Por exemplo, se o usuário for 'SYSTEM' ou 'BATCH', o indicador será definido como verdadeiro. Exemplos truefalse | |||
| Nome de usuário UserName | O nome ou ID do usuário que realizou 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. A análise por usuário ajuda a identificar necessidades de treinamento, reconhecer pessoas ou equipes com alta performance e investigar desvios causados por usuários específicos. Também é útil para Conformidade e auditoria, pois permite rastrear quem realizou cada ação. Por que isso importa Permite analisar a performance por usuário e a distribuição da carga de trabalho, além de identificar padrões de retrabalho manual associados a pessoas específicas. Onde encontrar Geralmente, é obtido de campos como CREATED_BY ou LAST_UPDATED_BY nas tabelas de transações do Oracle Fusion e costuma estar vinculado a uma tabela mestre de usuários, como FND_USER. Exemplos john.smithjane.doesystem_batch_user | |||
| Nome do cliente CustomerName | O nome do cliente que fez o pedido de venda. | ||
| Descrição Este atributo identifica a razão social da conta de cliente associada ao pedido de venda. É uma dimensão importante para segmentar e analisar o processo sob a perspectiva do cliente. A análise 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, adaptar processos para contas estratégicas e investigar problemas que afetam a satisfação do cliente. Por que isso importa Permite analisar o processo sob a perspectiva do cliente, identificar problemas que afetam clientes específicos e melhorar a satisfação. Onde encontrar Obtido de tabelas mestre de dados 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 | |||
| 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 fazer a mineração com base no 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 melhorias nos casos com maior impacto financeiro. Por que isso importa Permite analisar o impacto financeiro, priorizar melhorias em pedidos de alto valor e entender os fatores que geram custos. Onde encontrar Geralmente, está 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 de pagamento acordadas com o cliente. | ||
| Descrição Este atributo especifica as condições em que se espera que o cliente pague a fatura, como '30 dias líquidos' ou '60 dias líquidos'. Essas condições servem de base para calcular a PaymentDueDate. Na análise, segmentar os dados por condições de pagamento ajuda a explicar diferenças nos tempos de ciclo de pagamento. Isso dá contexto ao KPI de taxa de pagamentos no prazo, já que condições diferentes naturalmente levam a comportamentos de pagamento distintos. Essas informações podem orientar a política de crédito e a previsão do fluxo de caixa. Por que isso importa Fornece contexto essencial para analisar o comportamento de pagamento e ajuda a explicar diferenças no tempo entre a emissão da fatura e o pagamento. Onde encontrar 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 30 dias líquidos60 dias líquidosVencimento no recebimento | |||
| Entrega no prazo IsOnTimeDelivery | Um indicador calculado que é verdadeiro quando a entrega real ocorreu na data solicitada ou antes dela. | ||
| Descrição Este atributo booleano é derivado da comparação entre ActualDeliveryDate e RequestedDeliveryDate. Ele oferece um indicador simples da performance de entrega em cada caso. Este indicador é a base para calcular o KPI agregado de taxa de entregas no prazo. 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 contribuíram para os atrasos. Por que isso importa Mede diretamente a performance do atendimento em relação às expectativas dos clientes e simplifica a análise de pedidos atrasados. Onde encontrar Este é um campo calculado. A lógica é: ActualDeliveryDate <= RequestedDeliveryDate. Exemplos truefalse | |||
| Fatura corrigida IsInvoiceCorrected | Indica se uma fatura foi corrigida ou revisada após sua criação inicial. | ||
| Descrição Este atributo booleano é verdadeiro quando uma fatura passa por um ciclo de correção, indicado pela presença da atividade 'Fatura corrigida'. Ele sinaliza os casos que tiveram retrabalho na etapa de faturamento. Este é um dado essencial para o Dashboard 'Análise de precisão e retrabalho de faturas' e para o KPI 'Taxa de retrabalho de faturas'. Ele ajuda a quantificar a frequência de erros no 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 em faturas, um indicador importante de ineficiência do processo, problemas na qualidade dos dados e possíveis atrasos nos pagamentos. Onde encontrar Este é um campo calculado, normalmente definido como verdadeiro para um caso quando existe uma atividade 'Fatura corrigida' no Event Log. Exemplos falsetrue | |||
| Método de envio ShippingMethod | O método ou a transportadora usada para enviar as mercadorias ao cliente. | ||
| Descrição Este atributo detalha a transportadora ou o nível de serviço logístico usado na entrega, como 'Frete terrestre', 'Entrega expressa aérea' ou 'Entrega local'. Essa informação é essencial para o Dashboard de Conformidade de entrega por método de envio. Ela permite comparar a performance de entrega 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 Dá suporte direto à análise logística, permitindo comparar a performance de diferentes transportadoras e métodos de envio. Onde encontrar Disponível nas tabelas de expedição e atendimento 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 da linha do pedido de venda. Se um pedido tiver várias linhas, o caso poderá ser analisado no nível do item ou esse atributo poderá ser agregado no nível do cabeçalho. A análise 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 as 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 e destacar itens que podem ter etapas complexas de atendimento ou faturamento. Onde encontrar Obtido das tabelas de itens das linhas do pedido de venda e combinado com uma tabela mestre de produtos. Consulte a documentação do Oracle Fusion Financials. Exemplos Standard Widget X1Pacote de serviços premiumComponente 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 à etapa de liquidação financeira do processo. Embora o pedido de venda seja o ID do caso principal, o número da fatura é essencial para analisar os subprocessos de faturamento e pagamento. Ele permite acompanhar correções de faturas, contestações e status de pagamento, além de dar suporte a Dashboards como Análise de precisão e retrabalho de faturas. Por que isso importa Faz 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 encontrar 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 a PaymentDueDate. Ele indica claramente se uma fatura foi paga no prazo. Este atributo é usado para calcular o KPI de taxa de pagamentos no prazo. Ele facilita a segmentação entre pagamentos no prazo e atrasados para analisar as características dos clientes que pagam com atraso, os motivos mais comuns e o impacto financeiro no capital de giro. Por que isso importa Mede diretamente a eficácia da cobrança e simplifica a análise de pagamentos em atraso. Onde encontrar 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 indicado no endereço de entrega ou de faturamento 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 ajuda a entender o impacto das regulamentações locais, dos desafios logísticos e das condições de mercado no processo de pedido ao recebimento. Por que isso importa Permite fazer análises geográficas para identificar diferenças regionais na eficiência do processo, na Conformidade e no comportamento dos clientes. Onde encontrar Obtido de tabelas mestre de dados de clientes, como HZ_LOCATIONS e HZ_PARTY_SITES, vinculadas ao pedido de venda. Exemplos USAAlemanhaJapão | |||
| Sistema de origem SourceSystemIdentifier | Identifica o sistema de origem de onde os dados do evento foram extraídos. | ||
| Descrição Este atributo especifica a origem dos dados, o que é especialmente útil quando vários sistemas participam do processo de pedido ao recebimento. Por exemplo, os dados do pedido podem vir do Oracle Fusion, enquanto os dados de expedição podem vir de um sistema de logística de terceiros. Na análise, ele ajuda a entender a linhagem dos dados e permite filtrar a visualização do processo para mostrar eventos de sistemas específicos. Também é essencial para validar os dados e identificar a fragmentação do processo entre diferentes ambientes de TI. Por que isso importa Fornece contexto sobre a origem dos dados, essencial para a governança de dados e a solução de problemas em ambientes com vários sistemas. Onde encontrar Geralmente, é 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 'Pedido padrão' ou 'Pedido de devolução'. | ||
| Descrição O tipo de pedido é usado para classificar 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 materiais (RMAs) e pedidos internos. Analisar o processo por tipo de pedido é importante porque cada tipo costuma ter fluxos de processo e metas de performance próprios. Essa segmentação ajuda a entender quais variações são intencionais e esperadas, evitando que sejam interpretadas como desvios. Por que isso importa Permite segmentar fluxos de processo diferentes e legítimos, como pedidos padrão e devoluções, para garantir uma análise justa e precisa. Onde encontrar Geralmente, está disponível como 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 timestamp 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. Assim, você sabe o quanto os dados analisados estão atualizados. Essa informação é essencial para entender a atualidade da análise do processo. Ela ajuda a alinhar as expectativas sobre a atualização dos dados e é importante para definir e monitorar os cronogramas de atualização. Por que isso importa Indica o quanto os dados estão atualizados, para que você saiba até que ponto a análise do processo reflete a situação atual. Onde encontrar Este valor é gerado e registrado no conjunto de dados a 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 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 diferenças de eficiência, custo e Conformidade entre as áreas da empresa. A análise pode revelar boas práticas em unidades com alta performance que podem ser compartilhadas ou destacar unidades com resultados abaixo do esperado que precisam de melhorias direcionadas. Por que isso importa Permite comparar a performance e analisar a consistência dos processos entre diferentes unidades organizacionais. Onde encontrar Geralmente, está disponível no cabeçalho do pedido de venda e vinculado à estrutura organizacional definida no Oracle Fusion. Exemplos Unidade de negócio - América do NorteUnidade de negócio - EMEAServiços globais | |||
Atividades do Order to Cash, processamento de pedidos de venda
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura criada | Esta atividade representa a criação da fatura do cliente no módulo Accounts Receivable, geralmente iniciada pelo evento de confirmação de envio. É gerado um registro de fatura com número exclusivo e data de criação. | ||
| Por que isso importa Marca o início oficial do ciclo de recebimento de pagamentos. É a base para medir o "Tempo entre emissão da fatura e pagamento" e a eficiência geral do fluxo de caixa. Onde encontrar 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. Coleta Obtido da data de criação da transação da fatura no módulo AR. Tipo de evento explicit | |||
| Mercadorias enviadas | Esta atividade marca o momento em que as mercadorias saem do armazém e seguem para o cliente. Ela é registrada quando uma transação de confirmação de envio é processada no Oracle Shipping. | ||
| Por que isso importa Este é um marco essencial: indica a conclusão da etapa de atendimento do processo e dá início ao faturamento. Também é fundamental para medir a pontualidade dos envios e os prazos de entrega. Onde encontrar Este é um evento explícito registrado no Oracle Shipping Execution. A transação de confirmação de envio cria um registro em tabelas de envio, como WSH_DELIVERY_DETAILS, com a data de envio. Coleta Obtido 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 | |||
| Pagamento recebido | Esta atividade indica que o pagamento do cliente foi recebido e aplicado à fatura em Contas a Receber. O registro é feito quando a aplicação do recebimento em dinheiro é lançada. | ||
| Por que isso importa Este é um marco essencial para medir o tempo total do ciclo de pedido ao recebimento e a taxa de pagamentos no prazo. Ele representa a conversão da venda em dinheiro. Onde encontrar Este é um evento explícito no Oracle Accounts Receivable. Ele é registrado em tabelas de recebimentos em dinheiro, como AR_RECEIVABLE_APPLICATIONS_ALL, quando um recebimento é aplicado a uma fatura. Coleta Capturado a partir do timestamp da data de aplicação do registro de recebimento em dinheiro no AR. Tipo de evento explicit | |||
| Pedido confirmado | Este marco importante indica que o pedido de vendas passou por todas as verificações iniciais, incluindo a aprovação de crédito, e está liberado para atendimento. Em geral, ele é inferido quando o status do pedido muda para algo como "Aguardando envio" ou "Programado". | ||
| Por que isso importa Esta atividade é um marco essencial para calcular o "Tempo médio de confirmação de pedidos" e marca a passagem da entrada do pedido para o processo de atendimento. Onde encontrar Inferido quando o status do cabeçalho ou da linha do pedido de vendas muda para indicar que está pronto para atendimento, por exemplo, "Aguardando envio". Verifique as colunas de status em DOO_HEADERS_ALL ou DOO_FULFILL_LINES_ALL. Coleta Obtido do registro de data e hora em que o status do pedido muda para confirmado ou programado. Tipo de evento inferred | |||
| Pedido de vendas criado | Esta atividade marca o início do processo de pedidos de vendas: o momento em que um novo pedido é registrado no Oracle Fusion. Em geral, o evento é registrado explicitamente quando um usuário salva um novo pedido no módulo Order Management. | ||
| Por que isso importa Como marca o início do processo, esta atividade é essencial para medir o tempo total de ciclo de Order to Cash e analisar o volume de pedidos recebidos. Onde encontrar Registrado explicitamente quando um pedido de vendas é criado no Order Management Cloud. Procure os registros de data e hora de criação na tabela DOO_HEADERS_ALL. Coleta Obtido do registro de data e hora de criação do cabeçalho do pedido de vendas. Tipo de evento explicit | |||
| Pedido encerrado | A atividade final do processo indica que todas as linhas do pedido de venda foram atendidas, faturadas e encerradas. O status do cabeçalho do pedido é atualizado para 'Closed'. | ||
| Por que isso importa Esta atividade marca o fim bem-sucedido do ciclo de vida do pedido de venda. Ela é essencial para calcular a duração do processo de ponta a ponta e identificar pedidos que nunca são encerrados. Onde encontrar Inferido pela mudança do status do cabeçalho do pedido de venda para 'Closed' na tabela DOO_HEADERS_ALL. O timestamp dessa mudança final de status é usado como horário do evento. Coleta Derivado do timestamp da mudança de status do cabeçalho do pedido de venda para 'Closed'. Tipo de evento inferred | |||
| Bloqueio por crédito aplicado | Esta atividade ocorre quando um pedido de vendas é bloqueado automática ou manualmente devido a uma verificação de crédito reprovada ou a outro problema relacionado ao crédito. Em geral, isso é registrado como uma mudança no status de bloqueio do pedido no sistema. | ||
| Por que isso importa Acompanhar os bloqueios por crédito é essencial para identificar os motivos dos atrasos no processamento dos pedidos e medir a eficiência do processo de liberação. Onde encontrar Inferido pela aplicação de um bloqueio ao pedido de vendas. Em geral, isso é registrado em tabelas relacionadas a bloqueios, como DOO_HOLDS_ALL, vinculadas ao pedido. Coleta Inferido pela criação de um registro na tabela de bloqueios de pedidos com o tipo de bloqueio "Crédito". Tipo de evento inferred | |||
| Estoque reservado | Esta atividade representa a alocação ou reserva de estoque físico para atender a linha do pedido de vendas. O sistema compromete unidades específicas do estoque para garantir que estejam disponíveis quando o pedido for separado. | ||
| Por que isso importa Acompanhar esta atividade ajuda a analisar o KPI "Prazo de alocação de estoque" e identificar atrasos entre a confirmação do pedido e a reserva das mercadorias. Onde encontrar Este evento costuma ser registrado nos módulos de estoque ou de execução da cadeia de suprimentos. Ele pode ser inferido pelas atualizações de status da linha de atendimento que indicam que o estoque foi detalhado ou reservado. Coleta Inferido pelas mudanças de status da linha de atendimento relacionadas à reserva ou à programação do estoque. Tipo de evento inferred | |||
| Fatura corrigida | Ocorre quando uma fatura criada anteriormente é alterada, emitida novamente ou creditada devido a erros ou contestações do cliente. Isso geralmente é registrado com a 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 de taxa de retrabalho de faturas, que evidencia problemas no processo de faturamento capazes de atrasar pagamentos e aumentar os custos administrativos. Onde encontrar Inferido pela 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. Coleta 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 encerrada | Representa o encerramento definitivo de uma linha individual do pedido de venda, indicando que ela foi totalmente expedida e faturada e que não são esperadas novas transações. O sistema atualiza o status da linha para 'Closed'. | ||
| Por que isso importa O encerramento das linhas do pedido indica que todas as obrigações contratuais daquele item foram cumpridas. A análise ajuda a identificar pedidos que continuam abertos muito tempo depois do atendimento e do pagamento. Onde encontrar Inferido pela mudança do status da linha de atendimento para 'Closed' na tabela DOO_FULFILL_LINES_ALL. O timestamp dessa mudança de status marca o evento. Coleta Derivado do timestamp da mudança de status da linha de atendimento para 'Closed'. Tipo de evento inferred | |||
| Mercadorias entregues | Indica que o cliente recebeu a remessa. Em geral, essa informação vem da transportadora e é atualizada no Oracle Fusion, ou pode ser inferida com base no tempo padrão de trânsito a partir da data de envio. | ||
| Por que isso importa Esta atividade é essencial para calcular o KPI "Taxa de entregas no prazo" e medir com precisão os níveis de atendimento ao cliente. Onde encontrar Em geral, este não é um evento nativo do Oracle. Ele pode ser registrado quando há integração com a transportadora ou calculado somando-se um tempo padrão de trânsito à data de "Mercadorias enviadas". É necessário analisar o sistema. Coleta Inferido a partir dos dados fornecidos pela transportadora ou calculado com base na data de envio mais o tempo médio de trânsito. Tipo de evento inferred | |||
| Mercadorias separadas | Representa a separação física das mercadorias no armazém para atender ao pedido. Esta é uma etapa importante do processo logístico e costuma ser registrada no módulo de gestão de armazém ou de envio. | ||
| Por que isso importa Esta atividade dá visibilidade às 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 encontrar Registrado nos módulos Oracle Fusion Cloud SCM (Supply Chain Management). O evento pode ser inferido pela mudança de status de uma onda de separação ou de uma lista de separação associada à linha do pedido de vendas. Coleta Inferido pelo registro de data e hora de conclusão da transação de separação nos módulos SCM. Tipo de evento inferred | |||
| Pedido cancelado | Representa o cancelamento de um pedido de venda antes da expedição completa. Isso pode ocorrer por vários motivos e resulta no status final 'Cancelled'. | ||
| Por que isso importa Este é um caminho de exceção importante. A análise dos pedidos cancelados ajuda a identificar causas raiz, como falta de estoque, problemas de preço ou mudança de ideia do cliente, e pode orientar melhorias no processo. Onde encontrar Inferido pela mudança do status do cabeçalho ou da linha do pedido de venda para 'Cancelled'. O timestamp dessa mudança de status é usado para registrar o evento. Coleta Derivado do timestamp da mudança de status do cabeçalho ou da linha do pedido para 'Cancelled'. Tipo de evento inferred | |||
| Verificação de crédito realizada | Indica que foi feita uma verificação de crédito na conta do cliente para avaliar sua capacidade de crédito. Essa etapa do fluxo de trabalho de processamento do pedido pode ser automatizada ou manual, e sua conclusão costuma ser 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 dos pedidos. Essa análise é essencial para o KPI "Tempo entre verificação de crédito e confirmação". Onde encontrar Pode ser inferido pelas mudanças de status do pedido de vendas, como a passagem para o status "Aguardando aprovação de crédito", ou por um registro de evento explícito na funcionalidade de gestão de crédito. Coleta Inferido pelas mudanças de status do pedido ou pelos 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: Entre no seu ambiente Oracle Fusion com um usuário que tenha privilégios de BI Administrator ou BI Author. No menu Navigator, acesse 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, por exemplo, Shared Folders > Custom. Clique no menu suspenso 'New' e selecione 'Data Model'.
- Defina o conjunto de dados da consulta SQL: No editor de Data Model, clique no ícone '+' para criar um conjunto de dados e selecione 'SQL Query'. Uma caixa de diálogo será exibida. Dê um nome ao conjunto de dados, por exemplo, '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 o BI Publisher reconhecerá automaticamente.
- 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 de modelo de dados. Verifique se a opção 'Include Parameter Tags' está marcada. 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 testar. Clique em 'View' para ver uma amostra dos dados. Se os dados estiverem corretos, salve o modelo de dados clicando no ícone de salvar e atribuindo um nome descritivo, por exemplo, 'OrderToCash_EventLog_DM'.
- Crie um relatório a partir do modelo de dados: Com o modelo de dados 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ê na configuração do layout. Para uma exportação simples em CSV, escolha o layout 'Table'. Arraste todas as colunas para a 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. Você precisará informar as datas inicial e final da extração. Insira o período desejado.
- Exporte os dados: Quando 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. O arquivo do Event Log será baixado.
- Prepare o arquivo para carregamento: Abra o arquivo CSV baixado. Confira se os cabeçalhos das colunas correspondem aos atributos necessários: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. O arquivo está pronto para ser carregado na ferramenta de Process Mining.
Configuração
- Privilégios de 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 desenvolvida para a fonte de dados padrão 'Oracle BI EE', que se conecta ao banco de dados transacional (Fusion Apps). Em geral, não é necessária nenhuma configuração especial.
- Parâmetros de intervalo de datas: A consulta usa dois parâmetros, :p_start_date e :p_end_date, para filtrar os dados. Recomendamos extrair os dados em lotes gerenciáveis, por exemplo, de 3 a 6 meses por vez, para evitar que o relatório exceda o tempo limite e tenha problemas de performance.
- Filtro por unidade de negócio: Para limitar o escopo da extração, você pode adicionar uma cláusula WHERE à CTE BaseOrders da consulta e filtrar por um ID específico de unidade de negócio, por exemplo, AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtro 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 conjuntos de dados 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 mensais menores. Verifique se a propriedade 'Enable SQL Pruning' está desmarcada no Data Model, pois ela pode interferir em consultas UNION complexas.
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: Entre 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.
- Configure um novo destino: No console do BICC, clique em Configure External Storage para definir o destino, que pode ser o Oracle Universal Content Management (UCM) ou um bucket do OCI Object Storage. Confira se os dados de conexão e as credenciais estão corretos.
- Inicie um novo trabalho de extração: Acesse a seção Manage Extract Jobs. Clique no ícone + para criar um trabalho. Dê a ele um nome descritivo, por exemplo, ProcessMind_O2C_SalesOrder_Extract.
- Selecione os Data Stores (PVOs): Na configuração do trabalho, pesquise e adicione os Public View Objects (PVOs) necessários para registrar o ciclo de vida dos pedidos 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 com atenção as colunas necessárias para gerar o Event Log, como HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e os 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 controlar o volume de dados, aplique um filtro a cada PVO com base na coluna LastUpdateDate. Na primeira execução, você pode selecionar um intervalo amplo. Nas execuções agendadas seguintes, configure o filtro para extrair apenas os registros atualizados desde a última execução do trabalho.
- Agende o trabalho de extração: Acesse a seção Manage Schedule. Crie um novo agendamento para o trabalho. Recomendamos executá-lo fora dos horários de pico, por exemplo, durante a madrugada, para minimizar o impacto na performance do sistema.
- Envie e monitore o trabalho: Depois de configurar, envie o trabalho. Você pode acompanhar o andamento na tela Manage Extract Jobs. Quando a execução for concluída com sucesso, 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 das 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 envolve:
- Combinar dados de arquivos diferentes, por exemplo, vinculando os dados das faturas ao cabeçalho do pedido de venda.
- Transformar colunas de data em linhas distintas de atividade. Por exemplo, no arquivo FscmTopModelAM.DooTopAM.Header, crie uma linha para Pedido de venda criado usando CreationDate e outra para Pedido encerrado usando ClosedDate.
- Mapear códigos de status ou sinalizadores para atividades específicas, como Pedido confirmado ou Pedido cancelado.
- Combinar todos os dados transformados em um único arquivo com as colunas necessárias: SalesOrder, ActivityName e EventTime.
- Formate o arquivo para carregamento: Confira se o arquivo transformado final está em formato CSV e contém as colunas correspondentes aos atributos necessários e recomendados. 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. Entre os principais estão 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: Use sempre o filtro LastUpdateDate nas extrações recorrentes. Isso é essencial para a performance e evita extrair repetidamente o mesmo conjunto de dados de vários gigabytes. A carga completa inicial estabelece uma referência; as execuções seguintes capturam apenas as alterações.
- Intervalo de datas: Na primeira carga histórica, extraia um período representativo, como os últimos 3 a 6 meses de dados, para equilibrar a abrangência e um volume gerenciável. As execuções seguintes serão incrementais.
- Configuração do armazenamento: O BICC pode exportar dados para o UCM da Oracle ou para o OCI Object Storage. Em geral, o OCI Object Storage é recomendado para cenários com grandes volumes de dados e integração mais simples com ferramentas de ETL posteriores.
- Agendamento dos trabalhos: Agende as extrações fora do horário comercial para evitar possíveis quedas de performance no sistema transacional do Oracle Fusion Financials.
- Pré-requisitos: Quem configurar o trabalho precisa ter a função BICC_ADMINISTRATOR. Também é necessário configurar previamente as credenciais do armazenamento em nuvem e entender claramente a lógica de transformação dos dados após a extração.
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 a otimizar o processamento de pedidos de venda no 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 informar cartão de crédito. Teste grátis por 14 dias.