> Melhoria contínua de processos > Do pedido ao recebimento: faturamento e emissão de notas fiscais > Oracle Fusion Financials > Template de dados

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Oracle Fusion Financials

← Voltar ao guia de melhoria

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento (22) Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento (13) Guias de extração (2)

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Este Template oferece um guia completo para extrair os dados necessários à análise do processo de Order to Cash - Faturamento e emissão de faturas. Ele apresenta os atributos essenciais a coletar, as atividades críticas a acompanhar e orientações práticas para a extração dos dados. Seguindo este Template, você garante um conjunto de dados robusto para realizar Process Mining e otimizar o processo com eficiência.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações de extração para o Oracle Fusion Financials

Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Baixar Template

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise abrangente do faturamento e da emissão de notas fiscais, do pedido ao recebimento.

3 Obrigatório 5 Recomendado 14 Opcional

	Nome	Descrição
	Hora de início EventTimestamp	A data e a hora exatas em que uma atividade ou evento específico ocorreu.
Descrição O timestamp do evento registra o momento exato em que uma atividade ocorreu. Ele fornece a ordem cronológica dos eventos de cada fatura, o que é essencial para construir o fluxo do processo e realizar qualquer análise baseada em tempo. Este atributo é a base de todos os cálculos de duração e performance. Ele é usado para medir o tempo entre atividades, calcular tempos de ciclo de ponta a ponta, determinar se os pagamentos estão em dia e analisar tendências ao longo do tempo. KPIs como 'Tempo médio de aprovação da fatura' e 'Tempo de ciclo de ponta a ponta da fatura' são calculados diretamente a partir desses timestamps. Por que isso importa Os timestamps são essenciais para calcular todas as métricas de performance, incluindo tempos de ciclo, atrasos e cumprimento de prazos, formando a base da análise quantitativa do processo. Onde obter É obtido de vários campos de data nas tabelas do Oracle Fusion Financials, como CREATION_DATE em RA_CUSTOMER_TRX_ALL ou timestamps de atualização de status em tabelas de Workflow. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	Número da fatura InvoiceNumber	O identificador exclusivo de cada fatura de cobrança, usado como o Case ID principal para acompanhar todas as atividades relacionadas.
Descrição O número da fatura é a base da análise do processo de faturamento. Ele funciona como o Case ID, agrupando todos os eventos desde a criação da fatura até o pagamento e o fechamento final. Isso permite ter uma visão completa, de ponta a ponta, do ciclo de vida de um único documento de cobrança. No Process Mining, analisar pelo número da fatura permite visualizar variantes do processo, calcular tempos de ciclo de faturas individuais e identificar gargalos ou loops de retrabalho que afetam transações específicas. Esse atributo é essencial para Dashboards como 'Tempo de ciclo de ponta a ponta da fatura' e para calcular KPIs fundamentais, como Days Sales Outstanding (DSO), por fatura. Por que isso importa Este atributo é essencial porque conecta todas as atividades relacionadas ao faturamento e ao pagamento em um único caso, permitindo uma análise completa e precisa do ciclo de vida da fatura. Onde obter Normalmente, é o Transaction Number (TRX_NUMBER) da tabela RA_CUSTOMER_TRX_ALL no Oracle Fusion Financials. Exemplos INV-1002345983451CM-55432
	Nome da atividade ActivityName	O nome do evento de negócio ou da tarefa específica que ocorreu em determinado momento do ciclo de vida da fatura.
Descrição O nome da atividade descreve uma etapa do processo de faturamento, como 'Fatura criada', 'Fatura aprovada' ou 'Pagamento do cliente recebido'. Esses eventos formam a sequência de ações que compõe o fluxo do processo de cada fatura. Este atributo é fundamental para a descoberta de processos, permitindo que a ferramenta de mineração construa um mapa visual de como as faturas são realmente processadas. Ele é usado para analisar variantes do processo, identificar loops de retrabalho, como várias etapas de aprovação, e medir a frequência e a duração de cada etapa. Todos os Dashboards e KPIs dependem desse atributo para entender o fluxo do processo. Por que isso importa Este atributo define as etapas do mapa do processo, permitindo visualizar, analisar e identificar ineficiências no Workflow de faturamento. Onde obter Essas informações são obtidas de várias tabelas e alterações de status no Oracle Fusion Financials, como tabelas de histórico de Workflow, por exemplo, relacionadas a aprovações, e campos de status de transações. Exemplos Fatura criadaFatura aprovadaPagamento do cliente recebidoFatura fechada
	Data de vencimento DueDate	A data até a qual o pagamento da fatura deve ser realizado.
Descrição A data de vencimento é um atributo de data essencial que define o prazo de pagamento de uma fatura, conforme determinado pelas condições de pagamento. Este atributo é essencial para monitorar a cobrança e a saúde financeira. Ele é a base para calcular o KPI de taxa de pagamentos em dia e criar relatórios de aging de pagamentos. Nos Dashboards, é usado para prever o fluxo de caixa, mostrando quando os pagamentos são esperados, e identificar faturas vencidas que exigem ações de cobrança. Por que isso importa É a principal referência para medir a pontualidade dos pagamentos, calcular o DSO e gerenciar o aging de contas a receber. Onde obter Localizado na tabela AR_PAYMENT_SCHEDULES_ALL, normalmente no campo DUE_DATE. Exemplos 2023-05-302023-06-152023-07-01
	Nome do cliente CustomerName	O nome do cliente ou da entidade que está sendo faturada.
Descrição Este atributo identifica o cliente associado à fatura. É uma dimensão principal para segmentar e filtrar os dados do processo. Analisar o processo por nome do cliente ajuda a identificar quais clientes têm os ciclos de pagamento mais longos, quais têm maior probabilidade de contestar faturas e quais pagam pontualmente de forma consistente. Isso é essencial para o Dashboard de tendência de DSO e para adaptar as estratégias de cobrança ao comportamento de cada cliente. Por que isso importa Permite segmentar o processo por cliente, revelando diferentes comportamentos, padrões de pagamento e possíveis problemas de relacionamento que afetam o fluxo de caixa. Onde obter Obtido pela junção da tabela de transações (RA_CUSTOMER_TRX_ALL) com tabelas de dados mestres de clientes, como HZ_PARTIES. Exemplos Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	Status da fatura InvoiceStatus	O status atual da fatura em seu ciclo de vida, como 'Aberta', 'Fechada' ou 'Contestada'.
Descrição O status da fatura fornece uma visão do ponto em que ela está no processo. Os status comuns incluem aberta (não paga), fechada (paga), contestada ou anulada. Este atributo é útil para monitoramento e filtragem em alto nível. Por exemplo, o Dashboard de previsão do fluxo de caixa em tempo real usa esse status para categorizar os valores em aberto. Ele ajuda a identificar rapidamente o conjunto de faturas vencidas, em disputa ou totalmente liquidadas. Por que isso importa Fornece uma visão rápida e geral do estado atual da fatura, permitindo filtragem e categorização eficientes para relatórios financeiros e gestão operacional. Onde obter Obtido de campos de status em tabelas como RA_CUSTOMER_TRX_ALL ou AR_PAYMENT_SCHEDULES_ALL, por exemplo, o campo STATUS. Exemplos Em abertoFechadoContestadoAguardando aprovação
	Unidade de negócio BusinessUnit	A unidade de negócio específica da organização que emitiu a fatura.
Descrição A unidade de negócio representa a entidade organizacional responsável pela transação. É um elemento de dados importante para segmentação e relatórios financeiros em grandes empresas. Este atributo permite comparar a performance do processo entre diferentes partes da empresa. Por exemplo, você pode analisar se o DSO varia significativamente entre unidades de negócio ou se uma unidade tem uma taxa de retrabalho de faturamento muito maior. Isso ajuda a direcionar iniciativas de melhoria para onde elas são mais necessárias. Por que isso importa Permite comparar a performance entre diferentes unidades organizacionais, ajudando a identificar boas práticas e áreas que precisam de melhoria em um nível detalhado. Onde obter Disponível em tabelas de transações como RA_CUSTOMER_TRX_ALL, geralmente como ORG_ID, que se vincula às definições de unidades de negócio. Exemplos Consultoria nos EUAManufatura na EMEAServiços na APAC
	Valor da fatura InvoiceAmount	O valor monetário total da fatura.
Descrição Este atributo representa o valor total devido na fatura. É uma métrica financeira essencial para entender o valor monetário que circula pelo processo de faturamento. Na análise, o valor da fatura é usado para priorizar transações de alto valor, calcular o valor total dos recebíveis em aberto e ponderar KPIs como Days Sales Outstanding (DSO). Ele permite segmentar o processo com base no impacto financeiro, por exemplo, analisando se faturas de alto valor seguem um caminho de aprovação diferente ou demoram mais para ser pagas. Por que isso importa Fornece o contexto financeiro de cada caso, permitindo análises baseadas em valor, priorização de faturas de alto valor e cálculo de KPIs financeiros importantes. Onde obter Encontrado na tabela RA_CUSTOMER_TRX_ALL, provavelmente em um campo como INVOICE_AMOUNT ou em um campo relacionado que represente o total da transação. Exemplos 5000.001250.75250000.00
	Condições de pagamento PaymentTerms	As condições acordadas para o pagamento da fatura, como 'Net 30' ou '2% 10, Net 30'.
Descrição As condições de pagamento definem as regras que determinam quando e como uma fatura deve ser paga, incluindo possíveis descontos para pagamento antecipado. Essas informações são essenciais para gerenciar recebíveis e fluxo de caixa. Este atributo é essencial para calcular a data de vencimento correta e identificar oportunidades de descontos por pagamento antecipado. O KPI de taxa de aproveitamento de descontos por pagamento antecipado depende diretamente desses dados para determinar quais faturas eram elegíveis para desconto. Por que isso importa Define as regras de pagamento de uma fatura, impactando diretamente o cálculo da data de vencimento e a capacidade de acompanhar e otimizar o aproveitamento de descontos por pagamento antecipado. Onde obter Localizado na tabela RA_TERMS e vinculado à transação por meio de um term_id em RA_CUSTOMER_TRX_ALL. Exemplos Líquido em 30 diasLíquido em 60 dias2% em 10 dias, líquido em 30 dias
	Data da fatura InvoiceDate	A data oficial de emissão da fatura.
Descrição A data da fatura, também conhecida como data da transação, é a data registrada no documento da fatura. Ela serve como ponto de partida para os cálculos das condições de pagamento. Essa data é um componente essencial para calcular o Days Sales Outstanding (DSO), pois o DSO mede o tempo entre a data da fatura e a data do pagamento. Ela é diferente da data de criação no sistema e representa o início oficial do ciclo de pagamento do ponto de vista do cliente. Por que isso importa Serve como a data oficial de início do ciclo de vida da fatura e como base para calcular o KPI de Days Sales Outstanding (DSO). Onde obter Localizada na tabela RA_CUSTOMER_TRX_ALL, no campo TRX_DATE. Exemplos 2023-04-142023-05-182023-06-25
	Departamento de faturamento BillingDepartment	O departamento interno ou a equipe responsável por criar e gerenciar a fatura.
Descrição Este atributo identifica a equipe ou o departamento específico da organização que conduziu o processo de faturamento. Ele fornece outra camada de contexto organizacional para a análise. Ao segmentar o processo por departamento de faturamento, a empresa pode comparar a eficiência e a precisão de diferentes equipes. Isso ajuda a identificar quais departamentos têm taxas de retrabalho mais altas, ciclos de aprovação mais longos ou contribuem mais para um DSO elevado, destacando oportunidades de treinamento direcionado ou padronização do processo. Por que isso importa Permite comparar a performance entre equipes internas, ajudando a identificar boas práticas, necessidades de recursos ou áreas que exigem melhoria do processo. Onde obter Essas informações podem ser obtidas a partir do usuário que criou a fatura, associando o usuário ao departamento designado a ele no sistema de RH, por exemplo, por meio de PER_ALL_ASSIGNMENTS_F. Exemplos Faturamento corporativoEquipe de faturamento de serviçosFaturamento de vendas de produtos
	É pago em dia IsPaidOnTime	Um indicador booleano que informa se a fatura foi paga na data de vencimento ou antes dela.
Descrição Este atributo calculado fornece um indicador simples, verdadeiro ou falso, da pontualidade do pagamento. Ele é obtido comparando a data da atividade 'Pagamento do cliente recebido' com o atributo 'Data de vencimento' da fatura. Esse indicador simplifica a análise e os relatórios do KPI de taxa de pagamentos em dia. Ele permite filtrar e segmentar facilmente os dados para entender quais fatores, como cliente, região ou valor da fatura, estão relacionados a pagamentos atrasados. É uma métrica essencial para avaliar a eficácia da cobrança. Por que isso importa Simplifica a medição da performance da cobrança e permite analisar facilmente os fatores que contribuem para pagamentos em dia ou atrasados. Onde obter Calculado comparando o timestamp da atividade de pagamento final com o atributo DueDate. A lógica é: `PaymentTimestamp <= DueDate`. Exemplos truefalse
	É retrabalho IsRework	Um indicador booleano que informa se uma atividade é considerada retrabalho, como uma aprovação repetida ou uma correção.
Descrição Este atributo calculado sinaliza atividades que representam trabalho desnecessário ou redundante. Exemplos incluem uma fatura rejeitada e depois reenviada para aprovação ou uma correção feita após a criação inicial. Ao sinalizar o retrabalho, fica fácil quantificar seu impacto no processo. O KPI de taxa de retrabalho do faturamento é calculado diretamente a partir deste atributo. Os Dashboards podem visualizar a frequência do retrabalho e medir o tempo de ciclo adicional que ele gera, ajudando a localizar as fontes de ineficiência e erros. Por que isso importa Quantifica diretamente a ineficiência do processo ao sinalizar trabalho desnecessário ou repetido, facilitando a medição do impacto de problemas de qualidade em custo e tempo. Onde obter É calculado durante a transformação dos dados com base na sequência de atividades. Por exemplo, se uma atividade 'Fatura aprovada' for precedida por uma atividade 'Fatura rejeitada' no mesmo caso, ela será sinalizada como retrabalho. Exemplos truefalse
	Hora de término EventEndTime	A data e a hora exatas em que uma atividade ou evento específico foi concluído.
Descrição A hora de término do evento registra o momento em que uma atividade foi concluída. Embora muitos eventos sejam instantâneos, algumas atividades, como 'Aprovação da fatura', podem ter uma duração, começando quando são enviadas e terminando quando uma decisão é tomada. Ter uma hora de término permite calcular com precisão o tempo de processamento da atividade. Isso é útil para analisar quanto tempo os usuários gastam em tarefas específicas. Também melhora a precisão da análise de gargalos ao distinguir o tempo de espera do tempo efetivo de processamento. Por que isso importa Permite calcular com precisão os tempos de processamento das atividades, distinguindo o tempo de trabalho ativo do tempo de espera ocioso, o que é essencial para uma análise detalhada de gargalos. Onde obter Frequentemente, é obtido usando a hora de início da atividade seguinte no processo. Para algumas atividades, pode existir um campo dedicado de hora de término nos logs de Workflow. Exemplos 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	Método de pagamento PaymentMethod	O método usado pelo cliente para realizar o pagamento, como transferência bancária ou cartão de crédito.
Descrição Este atributo especifica como o cliente pagou a fatura. Essas informações podem ser úteis para analisar tendências e custos de pagamento. Diferentes métodos de pagamento podem ter tempos de processamento e custos de transação distintos. Analisar por método de pagamento ajuda a entender se determinados métodos estão mais sujeitos a erros ou atrasos de reconciliação. Também pode orientar estratégias para incentivar os clientes a usar canais de pagamento mais eficientes. Por que isso importa Ajuda a analisar a eficiência do processamento de pagamentos, os custos de transação e as taxas de erro de reconciliação associadas a diferentes canais de pagamento. Onde obter Encontrado em tabelas de recebimentos em dinheiro, como AR_CASH_RECEIPTS_ALL, que conteriam um campo indicando o método de pagamento. Exemplos ACHTransferência bancáriaCartão de créditoCheque
	Motivo da disputa DisputeReason	O motivo informado para o cliente contestar uma fatura.
Descrição Quando um cliente contesta uma fatura, o motivo da disputa é registrado. Ele pode estar relacionado a preço, quantidade, qualidade do serviço ou outros problemas. Analisar os motivos das disputas é uma forma eficaz de realizar uma análise de causa-raiz. Ao entender os motivos mais comuns das contestações, a empresa pode resolver problemas subjacentes de preço, atendimento do pedido ou qualidade dos dados. Isso ajuda a reduzir o tempo médio de resolução de disputas de faturas e melhora a satisfação do cliente. Por que isso importa Fornece um insight direto sobre as causas-raiz dos atrasos de pagamento e da insatisfação dos clientes, permitindo que a empresa resolva problemas sistêmicos. Onde obter Essas informações podem ser armazenadas no Oracle Collections ou em um módulo relacionado de gestão de disputas. Elas podem estar em uma tabela dedicada de disputas ou como um código de motivo na própria transação. Exemplos Preço incorretoDivergência de quantidadeMercadorias danificadasFatura duplicada
	Prazo médio de recebimento de vendas DaysSalesOutstanding	O número de dias entre a data da fatura e a data em que o pagamento foi recebido.
Descrição Days Sales Outstanding (DSO) é uma métrica financeira essencial que mede o tempo médio necessário para receber o pagamento após a emissão de uma fatura. Este atributo calcula esse valor para cada fatura individual. Embora o DSO geral seja um KPI importante, calculá-lo no nível de cada fatura permite uma análise muito mais aprofundada. Ele pode ser usado para criar Dashboards de tendência, identificar as características das faturas com DSO elevado e medir o impacto financeiro dos atrasos do processo. Esse cálculo detalhado fornece os dados necessários para entender os fatores que influenciam o KPI agregado de DSO. Por que isso importa Calcula uma métrica essencial de fluxo de caixa no nível de cada fatura, permitindo analisar em detalhes o que influencia os tempos de recebimento e a performance financeira. Onde obter É calculado encontrando a diferença entre o timestamp da atividade 'Pagamento do cliente recebido' e o atributo 'Data da fatura'. Exemplos 356228
	Região Region	A região geográfica associada ao cliente ou à transação.
Descrição A região fornece o contexto geográfico da fatura, normalmente com base na localização do cliente. Isso permite analisar a performance do processo por área geográfica. Analisar por região pode revelar variações causadas por regulamentações locais, condições de mercado ou performance das equipes regionais. Dashboards como Tendência de DSO e Tempo de ciclo de ponta a ponta da fatura podem ser segmentados por região para verificar se determinadas áreas enfrentam desafios específicos para receber os pagamentos. Por que isso importa Permite segmentar o processo geograficamente, destacando diferenças regionais de performance, comportamento dos clientes ou conformidade. Onde obter Normalmente, é obtido das informações de endereço do cliente armazenadas no TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Não é um campo direto da fatura. Exemplos América do NorteEuropaÁsia-Pacífico
	Sistema de origem SourceSystem	O sistema de registro do qual os dados do evento foram extraídos.
Descrição Este atributo identifica o aplicativo de origem onde os dados foram gerados. Para este processo, normalmente será o Oracle Fusion Financials, mas também pode especificar um módulo específico, como Oracle Receivables (AR). Em ambientes com vários sistemas integrados, esse campo ajuda a diferenciar as fontes de dados e é essencial para a validação e a governança dos dados. Ele garante que a análise seja baseada no conjunto de dados correto e pretendido. Por que isso importa Identifica a origem dos dados, o que é essencial para a governança dos dados, a solução de problemas e a garantia de que a análise seja baseada no sistema de registro correto. Onde obter Normalmente, é um valor estático ('Oracle Fusion Financials') adicionado durante o processo de extração e transformação dos dados. Exemplos Oracle Fusion FinancialsOracle AR CloudFusion Apps
	Tempo de ciclo da fatura InvoiceCycleTime	O tempo total desde a criação inicial da fatura até seu fechamento.
Descrição Este atributo mede a duração de ponta a ponta de todo o ciclo de vida da fatura para um único caso. Ele é calculado como a diferença entre a primeira atividade, normalmente 'Fatura criada', e a atividade final, 'Fatura fechada'. Essa métrica fornece uma visão geral da eficiência do processo. É a principal medida do Dashboard 'Tempo de ciclo de ponta a ponta da fatura'. Ao analisar esse atributo por diferentes dimensões, como cliente ou unidade de negócio, as organizações podem identificar quais tipos de fatura demoram mais para ser processados e investigar as causas-raiz. Por que isso importa Fornece uma medida única e essencial da velocidade geral do processo, ajudando a identificar rapidamente quais faturas demoram mais para ser concluídas do início ao fim. Onde obter É uma métrica calculada, obtida pela diferença entre o EventTimestamp máximo e o mínimo para cada InvoiceNumber exclusivo. Exemplos 45 dias e 8 horas32 dias e 2 horas90 dias e 12 horas
	Última atualização dos dados LastDataUpdate	O timestamp que indica a última vez em que os dados deste evento foram atualizados ou extraídos do sistema de origem.
Descrição Este atributo fornece o timestamp da extração de dados mais recente. É um campo de metadados essencial para entender o nível de atualização dos dados analisados. Os analistas usam essas informações para confirmar que estão trabalhando com dados atualizados e entender a recência dos dados. Isso é especialmente importante para Dashboards que afirmam ser 'em tempo real' ou quase em tempo real, pois oferece transparência sobre possíveis atrasos nos dados. Por que isso importa Informa aos usuários o nível de atualização dos dados, garantindo que as análises e conclusões sejam baseadas em informações com um nível de recência conhecido e aceitável. Onde obter É um campo de metadados gerado durante o processo de extração, transformação e carregamento (ETL) dos dados. Normalmente, corresponde ao horário de execução do pipeline de dados. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Usuário User	O funcionário ou usuário do sistema que realizou determinada atividade.
Descrição O atributo usuário identifica a pessoa ou o agente automatizado responsável por executar uma etapa do processo. Pode ser o usuário que criou a fatura, o gerente que a aprovou ou o agente de cobrança que emitiu um lembrete. Analisar por usuário ajuda a identificar oportunidades de treinamento, distribuição de carga de trabalho e diferenças de performance entre pessoas ou equipes. Isso pode revelar se determinados usuários estão associados a altas taxas de erro ou se aprovadores específicos são gargalos recorrentes. Por que isso importa Atribui responsabilidade pelas etapas do processo, permitindo analisar a performance dos usuários, equilibrar a carga de trabalho e identificar necessidades de treinamento. Onde obter Obtido de campos de ID de usuário, como CREATED_BY ou LAST_UPDATED_BY, em várias tabelas de transações e Workflow. Esse ID é então associado a tabelas de diretório de usuários, como PER_ALL_PEOPLE_F, para obter o nome do usuário. Exemplos john.smithjane.doeCollectionsBot

Obrigatório Recomendado Opcional

Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento

Estas são as principais etapas e os marcos do processo que devem ser registrados no seu Event Log para uma descoberta precisa do processo.

6 Recomendado 7 Opcional

	Atividade	Descrição
	Fatura aprovada	A fatura recebeu todas as aprovações necessárias e está pronta para ser enviada ao cliente. Esse evento é capturado quando o Workflow de aprovação é concluído com sucesso, atualizando o status da fatura.
Por que isso importa Este é um marco crítico que condiciona a entrega da fatura ao cliente. Atrasos nessa etapa afetam diretamente o início da contagem do prazo de pagamento e o Days Sales Outstanding (DSO). Onde obter É inferido a partir da atualização final do status de aprovação no registro da transação da fatura ou do registro de data e hora de conclusão na tarefa de Workflow BPM associada. Captura Capture o registro de data e hora em que o status de aprovação da fatura é definido como 'Approved'. Tipo de evento inferred
	Fatura criada	Representa a criação inicial de uma transação de fatura no sistema, geralmente com status de rascunho ou incompleto. Esse evento é registrado explicitamente quando um usuário salva um novo registro de fatura pela primeira vez no módulo Accounts Receivable.
Por que isso importa Este é o início definitivo do processo de faturamento. Analisar o tempo entre a criação e a conclusão ajuda a identificar atrasos na entrada de dados na etapa inicial ou problemas de performance do sistema. Onde obter Esse evento é capturado a partir da data de criação do registro da transação na tabela RA_CUSTOMER_TRX_ALL. O status inicial geralmente é 'Incomplete'. Captura Use o creation_date da tabela RA_CUSTOMER_TRX_ALL para o número específico da fatura. Tipo de evento explicit
	Fatura enviada ao cliente	A fatura foi entregue ao cliente pelo método de sua preferência, como e-mail ou impressão. O sistema geralmente registra o momento em que a ação de entrega é executada.
Por que isso importa Essa atividade inicia oficialmente o período da condição de pagamento. Medir o tempo entre a aprovação e a entrega é essencial para entender a eficiência do processo de distribuição de faturas. Onde obter Isso pode ser inferido a partir do campo 'last_printed_date' na RA_CUSTOMER_TRX_ALL ou dos logs do Oracle Business Intelligence Publisher, caso a entrega eletrônica seja utilizada. Captura Use o registro de data e hora do log de entrega ou impressão relevante associado à fatura. Tipo de evento inferred
	Fatura fechada	A fatura foi totalmente paga e reconciliada, e seu ciclo de vida foi concluído. Normalmente, esse evento é inferido quando o saldo em aberto da fatura chega a zero e seu status é atualizado.
Por que isso importa Esta é a resolução final da fatura e marca o fim do processo. O tempo total até chegar a esse estado é o tempo de ciclo de ponta a ponta, um KPI principal do processo de faturamento. Onde obter Inferido a partir da tabela AR_PAYMENT_SCHEDULES_ALL quando o status é atualizado para 'CLOSED' e amount_due_remaining é zero. O campo 'gl_date_closed' indica a data de fechamento. Captura Usar gl_date_closed de AR_PAYMENT_SCHEDULES_ALL para a fatura específica. Tipo de evento inferred
	Pagamento aplicado à fatura	O pagamento recebido do cliente foi correspondido e aplicado com sucesso à fatura específica, reduzindo seu saldo em aberto. Este é um registro transacional distinto.
Por que isso importa Esta atividade confirma que o dinheiro foi alocado corretamente, o que é essencial para relatórios de aging e demonstrações financeiras precisos. É a etapa final do reconhecimento do dinheiro contra o contas a receber. Onde obter Registrado explicitamente na tabela AR_RECEIVABLE_APPLICATIONS_ALL. Os campos apply_date e gl_date indicam quando a aplicação ocorreu. Captura Usar apply_date da tabela AR_RECEIVABLE_APPLICATIONS_ALL, vinculando o recebimento em dinheiro à fatura. Tipo de evento explicit
	Pagamento do cliente recebido	Um pagamento do cliente foi inserido no sistema como um recebimento em dinheiro. Nesta etapa, o pagamento ainda pode não ter sido aplicado a uma fatura específica.
Por que isso importa Este é um marco essencial que representa a entrada de dinheiro. O intervalo entre o recebimento do pagamento e sua aplicação a uma fatura é um indicador importante da eficiência da gestão de caixa. Onde obter Registrado explicitamente quando um registro é criado na tabela AR_CASH_RECEIPTS_ALL. O campo receipt_date indica quando o pagamento foi processado. Captura Usar creation_date ou receipt_date da tabela AR_CASH_RECEIPTS_ALL. Tipo de evento explicit
	Data de vencimento do pagamento atingida	A data em que o pagamento da fatura vence contratualmente já passou. Este não é um evento transacional, mas um evento calculado com base nas condições da fatura e na data atual.
Por que isso importa Esse evento calculado é fundamental para a análise de aging e o cálculo do DSO. Ele separa as faturas pagas no prazo das faturas vencidas, permitindo direcionar as atividades de cobrança. Onde obter Este é um evento calculado. Ele ocorre quando a data atual é posterior ao campo due_date da tabela AR_PAYMENT_SCHEDULES_ALL para uma determinada fatura. Captura Calculado comparando a data atual com o campo due_date de AR_PAYMENT_SCHEDULES_ALL. Tipo de evento calculated
	Disputa iniciada	O cliente contestou formalmente a fatura, e um caso de disputa foi criado no sistema. Normalmente, isso é registrado alterando um indicador de status no cronograma de pagamentos da fatura.
Por que isso importa As disputas congelam o processo de pagamento e exigem esforço manual para serem resolvidas. Analisar a frequência das disputas e o tempo de resolução ajuda a identificar causas-raiz, como erros de preço ou de envio. Onde obter Isso pode ser inferido a partir do campo de status da tabela AR_PAYMENT_SCHEDULES_ALL, quando definido como um status de disputa, ou dos registros de criação em AR_DISPUTE_HISTORY. Captura Identificar quando o indicador ou status de disputa é ativado no cronograma de pagamentos da fatura. Tipo de evento inferred
	Fatura ajustada	Foi feita uma alteração no valor da fatura, como uma baixa contábil ou um crédito. Esta é uma transação explícita para alterar o saldo em aberto da fatura.
Por que isso importa Os ajustes geralmente indicam disputas, concessões ou correções. Analisar a frequência e o valor dos ajustes pode revelar problemas subjacentes no processo order-to-cash. Onde obter Registrado explicitamente na tabela AR_ADJUSTMENTS_ALL. O creation_date do registro de ajuste marca o evento. Captura Usar creation_date da tabela AR_ADJUSTMENTS_ALL para a fatura relevante. Tipo de evento explicit
	Fatura concluída	Representa o momento em que a entrada de dados da fatura é finalizada e a transação está pronta para validação e contabilização. Normalmente, isso é capturado observando a mudança do status da fatura de 'Incomplete' para 'Complete'.
Por que isso importa Esse marco indica o fim da etapa de entrada de dados. O tempo entre a criação e a conclusão pode indicar a eficiência do processo de entrada e revisão de dados do departamento de faturamento. Onde obter É inferido a partir de uma mudança de status no registro da transação da fatura na tabela RA_CUSTOMER_TRX_ALL. Procure o registro de data e hora associado à atualização do status para 'Complete'. Captura Acompanhe o histórico de status da transação na RA_CUSTOMER_TRX_ALL ou em tabelas de Workflow relacionadas. Tipo de evento inferred
	Fatura enviada para aprovação	A fatura é formalmente enviada para um Workflow de aprovação, se houver um configurado. Isso é capturado quando o status da fatura é atualizado para um estado de aprovação pendente, acionando notificações aos aprovadores designados.
Por que isso importa Marca o início do ciclo de aprovação. Acompanhar essa atividade é essencial para medir e analisar o tempo de aprovação subsequente, um componente importante do tempo total do ciclo da fatura. Onde obter É inferido a partir de uma mudança de status na transação da fatura ou capturado nas tabelas do Workflow Oracle Business Process Management (BPM), que registram o início da tarefa de aprovação. Captura Identifique o registro de data e hora em que o status de aprovação da fatura muda para 'Pending' ou para um estado semelhante. Tipo de evento inferred
	Fatura rejeitada	Um aprovador rejeitou a fatura, geralmente devido a erros em dados como preços ou quantidades. Esse evento envia a fatura de volta para correção, criando um ciclo de retrabalho.
Por que isso importa Acompanhar as rejeições destaca problemas de precisão do faturamento e dos controles internos. Analisar a frequência e os motivos das rejeições pode apontar áreas para melhoria do processo e treinamento. Onde obter É inferido a partir de uma atualização de status no registro da transação da fatura ou do resultado 'Rejected' na tarefa de Workflow BPM. Captura Capture o registro de data e hora em que o status de aprovação da fatura é definido como 'Rejected'. Tipo de evento inferred
	Lembrete de pagamento emitido	Uma carta de cobrança ou notificação de lembrete foi enviada ao cliente sobre uma fatura vencida. Esta é uma ação explícita registrada pelo módulo de cobrança.
Por que isso importa Acompanhar os lembretes ajuda a medir a eficácia do processo de cobrança. Isso permite analisar quais estratégias de lembrete levam a pagamentos mais rápidos. Onde obter Registrado explicitamente no módulo Oracle Advanced Collections. Tabelas de histórico de cobrança, como IEX_DUNNINGS, registrariam a data e o nível do lembrete enviado. Captura Capturado nas tabelas de histórico de cobrança, vinculando a transação de cobrança à fatura. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Oracle Fusion Financials

Etapas

Acesse o BI Publisher: faça login no Oracle Fusion Applications e use o menu Navigator para acessar Tools e, em seguida, selecione Reports and Analytics. Clique no botão Browse Catalog para abrir o Business Intelligence Catalog.
Crie um modelo de dados: no catálogo, clique no menu suspenso New e selecione Data Model. O editor de modelos de dados será aberto.
Defina o conjunto de dados da consulta SQL: no painel Data Model, clique no ícone de adição ao lado de Data Sets e selecione SQL Query. Na nova caixa de diálogo, dê um nome ao conjunto de dados, por exemplo, AR_INVOICE_LIFECYCLE. Selecione a Data Source adequada, normalmente ApplicationDB_FSCM.
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 usa parâmetros como :P_START_DATE, :P_END_DATE e :P_BUSINESS_UNIT, que serão reconhecidos automaticamente.
Configure os parâmetros e visualize os dados: acesse a aba Parameters para definir valores padrão ou configurar as opções de exibição para o usuário. Depois, acesse a aba Data, informe os valores dos parâmetros, por exemplo, um intervalo curto de datas, e clique em View para testar a consulta e visualizar uma amostra dos dados de saída.
Salve o modelo de dados: depois de confirmar que os dados estão corretos, clique no ícone Save e armazene o modelo em uma pasta adequada, por exemplo, em Shared Folders/Custom/ProcessMining.
Crie um relatório: volte ao catálogo, clique no menu suspenso New e selecione Report. No assistente de criação do relatório, selecione a opção 'Use Data Model' e localize o modelo de dados que você acabou de salvar.
Configure o layout do relatório: no editor de layout do relatório, não crie um layout complexo. Selecione a opção 'Create Table' e arraste todas as colunas do conjunto de dados. O objetivo é exportar dados brutos, não criar um relatório formatado.
Defina CSV como saída padrão: nas propriedades do relatório, configure o formato de saída padrão como CSV. Assim, quando o relatório for executado, ele gerará um arquivo de texto simples adequado para Process Mining.
Agende o relatório: no catálogo, localize o relatório, clique em More e selecione Schedule. Crie um novo job, configure os parâmetros, como intervalo de datas e unidade de negócio, e defina o destino. Um destino comum é o Content Server (UCM) ou um servidor SFTP externo.
Recupere o Event Log: quando o job agendado for concluído, acesse o destino especificado, por exemplo, o repositório de conteúdo do UCM, para baixar o arquivo CSV gerado. Esse arquivo é o seu Event Log.
Prepare o upload: verifique se o arquivo CSV contém os cabeçalhos de coluna corretos, conforme definidos na consulta (InvoiceNumber, ActivityName, EventTimestamp etc.). Agora, o arquivo está pronto para ser carregado na sua plataforma de Process Mining.

Configuração

Parâmetros do BI Publisher: a consulta foi criada com parâmetros para controlar o escopo dos dados. Eles aparecerão automaticamente quando você criar um relatório a partir do modelo de dados.
- :P_START_DATE: data inicial do período de extração, no formato YYYY-MM-DD. A consulta filtra os eventos com base no carimbo de data e hora.
- :P_END_DATE: data final do período de extração, no formato YYYY-MM-DD.
- :P_BUSINESS_UNIT: nome específico da unidade de negócio usada para filtrar as faturas. Use esse parâmetro para reduzir o volume de dados e concentrar a análise.
Intervalo de datas: para os testes e a análise inicial, extraia um período limitado, como 3 a 6 meses de dados. Para uma análise completa, você pode extrair de 12 a 18 meses, dependendo das necessidades do negócio.
Configuração dos códigos de status: a consulta contém placeholders como '[Your Pending Approval Status]'. Você deve substituí-los pelos códigos de status usados na sua implementação do Oracle Fusion para os workflows de aprovação de faturas. Consulte um analista funcional para identificar esses valores na tabela RA_CUST_TRX_TYPES_ALL ou nas consultas do sistema.
Performance: extrair dados de um período longo ou de todas as unidades de negócio de uma só vez pode consumir muitos recursos. Recomendamos agendar o relatório do BI Publisher para execução fora do horário de pico, evitando impactos na performance do sistema para os demais usuários.
Pré-requisitos: você precisa de uma conta de usuário com funções que permitam criar modelos de dados e relatórios no BI Publisher, como BI Administrator, ou uma função personalizada com privilégios semelhantes. O usuário também deve ter perfis de segurança de dados que permitam acessar os dados necessários de contas a receber, clientes e unidades de negócio.

a Consulta de exemplo sql

WITH BaseInvoices AS (
    SELECT
        rct.trx_number,
        rct.customer_trx_id,
        hp.party_name AS customer_name,
        rct.trx_date,
        rct.creation_date,
        rct.last_update_date,
        rct.complete_flag,
        aps.status AS payment_schedule_status,
        aps.amount_due_original,
        aps.due_date,
        aps.dispute_flag,
        aps.gl_date_closed,
        rct.last_printed_date,
        rct.status_trx,
        bu.bu_name AS business_unit
    FROM
        ra_customer_trx_all rct
    JOIN
        hz_cust_accounts hca ON rct.bill_to_customer_id = hca.cust_account_id
    JOIN
        hz_parties hp ON hca.party_id = hp.party_id
    JOIN
        ar_payment_schedules_all aps ON rct.customer_trx_id = aps.customer_trx_id
    JOIN
        fun_all_business_units_v bu ON rct.org_id = bu.bu_id
    WHERE
        bu.bu_name = :P_BUSINESS_UNIT
        AND rct.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD') + 1
        AND aps.class = 'INV'
)
-- 1. Invoice Created
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    bi.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi

UNION ALL

-- 2. Invoice Completed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Completed' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.complete_flag = 'Y'

UNION ALL

-- 3. Invoice Submitted for Approval
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Submitted for Approval' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Pending Approval Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 4. Invoice Approved
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Approved Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 5. Invoice Rejected
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Rejected Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 6. Invoice Sent to Customer
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Sent to Customer' AS "ActivityName",
    bi.last_printed_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.last_printed_date IS NOT NULL

UNION ALL

-- 7. Payment Due Date Reached
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Due Date Reached' AS "ActivityName",
    bi.due_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.due_date <= CURRENT_TIMESTAMP

UNION ALL

-- 8. Payment Reminder Issued
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Reminder Issued' AS "ActivityName",
    dlt.trx_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_dunning_letters_trx dlt ON bi.customer_trx_id = dlt.customer_trx_id

UNION ALL

-- 9. Dispute Initiated
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Dispute Initiated' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp", -- Uses last update as a proxy for dispute date
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Disputed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.dispute_flag = 'Y'

UNION ALL

-- 10. Customer Payment Received
SELECT DISTINCT
    bi.trx_number AS "InvoiceNumber",
    'Customer Payment Received' AS "ActivityName",
    acr.receipt_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
JOIN
    ar_cash_receipts_all acr ON ara.cash_receipt_id = acr.cash_receipt_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 11. Payment Applied to Invoice
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Applied to Invoice' AS "ActivityName",
    ara.apply_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 12. Invoice Adjusted
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Adjusted' AS "ActivityName",
    adj.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_adjustments_all adj ON bi.customer_trx_id = adj.customer_trx_id

UNION ALL

-- 13. Invoice Closed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Closed' AS "ActivityName",
    bi.gl_date_closed AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Closed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.payment_schedule_status = 'CL' AND bi.gl_date_closed IS NOT NULL

Etapas

Pré-requisitos: verifique se o Python 3.6 ou superior está instalado, junto com as bibliotecas requests e pandas. Você pode instalá-las usando pip: pip install requests pandas.
Credenciais do Oracle Fusion: obtenha as credenciais necessárias para acessar as APIs REST do Oracle Fusion. Isso inclui a URL base da sua instância do Fusion, um nome de usuário e uma senha de um usuário com privilégios suficientes para ler dados de contas a receber.
Configure o script: abra o script Python fornecido em um editor. Localize a seção de configuração no início do script e substitua os valores de placeholder de FUSION_URL, USERNAME, PASSWORD e de parâmetros de filtragem, como start_date.
Entenda os endpoints da API: o script usa principalmente o endpoint receivablesInvoices para buscar os dados principais das faturas. Depois, ele faz chamadas a outros endpoints, como receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments e collectionsDelinquentTransactions, para coletar eventos relacionados.
Tratamento da paginação: o script inclui uma função auxiliar, get_paginated_data, que trata automaticamente a paginação da API seguindo o link next na resposta até recuperar todos os registros de uma determinada consulta.
Busca dos dados: a parte principal do script primeiro busca uma lista de faturas dentro do intervalo de datas especificado. Depois, percorre cada fatura para coletar seus detalhes específicos e os eventos relacionados.
Geração de eventos: para cada fatura, o script cria diferentes linhas de atividade. Algumas atividades, como 'Invoice Created', são derivadas diretamente dos campos da fatura (CreationDate). Outras, como 'Payment Applied to Invoice', exigem chamadas a APIs separadas e a associação dos dados ao número da fatura.
Tratamento de eventos calculados: o evento 'Payment Due Date Reached' não é uma transação direta. O script calcula esse evento verificando se a DueDate da fatura já passou e se a fatura continua sem pagamento.
Execute o script: execute o script no terminal usando python your_script_name.py. O script exibirá atualizações de progresso enquanto busca os dados de cada fatura.
Revise a saída: após a conclusão da execução, um arquivo chamado oracle_fusion_ar_event_log.csv será criado no mesmo diretório. Esse arquivo contém o Event Log extraído.
Prepare o upload: abra o arquivo CSV gerado. Verifique se os cabeçalhos das colunas são CaseId, ActivityName e EventTimestamp para um mapa de processo básico, ou mapeie as colunas geradas, como InvoiceNumber, ActivityName, EventTimestamp, InvoiceAmount etc., na sua ferramenta de Process Mining durante o upload.

Configuração

URL base da API: a URL raiz da sua instância do Oracle Fusion Financials, por exemplo, https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05.
Autenticação: o script usa autenticação básica. Verifique se a conta de usuário tem funções como 'Accounts Receivable Manager' ou uma função personalizada com privilégios para acessar os recursos REST receivablesInvoices, receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments e collectionsDelinquentTransactions.
Filtro por intervalo de datas: o script usa um parâmetro q com um filtro em CreationDate para limitar o conjunto inicial de faturas. Recomendamos começar com um intervalo menor, como 3 a 6 meses, para controlar o tempo de extração e a carga na API. Exemplo: CreationDate between 'YYYY-MM-DD' and 'YYYY-MM-DD'.
Limite de paginação: o parâmetro limit nas chamadas da API controla quantos registros são retornados por solicitação. Um valor entre 100 e 500 costuma ser eficiente. O script está configurado com um limite padrão.
Filtro por unidade de negócio: você pode adicionar um filtro de unidade de negócio ao parâmetro de consulta (q) para restringir o escopo da extração, por exemplo: BusinessUnitName = '[Your Business Unit Name]'.
Performance: extrair dados fatura por fatura pode ser lento em grandes volumes. O script faz várias chamadas à API para cada fatura. Para conjuntos com mais de 100.000 faturas, considere executar o script em lotes ou fora do horário de pico para evitar queda de performance ou limitação de requisições da API.

a Consulta de exemplo python

import requests
import pandas as pd
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password
FUSION_URL = class="hl-string">"https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05"
USERNAME = class="hl-string">"YOUR_USERNAME"
PASSWORD = class="hl-string">"YOUR_PASSWORD"

class=class="hl-string">"hl-comment"># --- Filter Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the initial invoice query
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
class=class="hl-string">"hl-comment"># Optional: Filter by a specific Business Unit
BUSINESS_UNIT_FILTER = class="hl-string">"" class=class="hl-string">"hl-comment"># e.g., class="hl-string">" and BusinessUnitName = 'US1 Business Unit'"

class=class="hl-string">"hl-comment"># API call settings
API_LIMIT = 100

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to handle pagination for Oracle Fusion REST API calls."""
    all_items = []
    url = fclass="hl-string">"{FUSION_URL}/{endpoint}"
    
    while url:
        try:
            response = requests.get(url, auth=(USERNAME, PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            all_items.extend(data.get(class="hl-string">'items', []))
            
            class=class="hl-string">"hl-comment"># Get the next page link
            links = data.get(class="hl-string">'links', [])
            next_link = next((link[class="hl-string">'href'] for link in links if link[class="hl-string">'rel'] == class="hl-string">'next'), None)
            url = next_link
            class=class="hl-string">"hl-comment"># Params are only needed for the first request
            params = {}

        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error fetching data from {url}: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            break
            
    return all_items


def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    event_log = []
    today = datetime.datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    class=class="hl-string">"hl-comment"># 1. Fetch main invoice data
    print(class="hl-string">"Fetching invoices...")
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'{BUSINESS_UNIT_FILTER}",
        class="hl-string">'fields': class="hl-string">'TransactionNumber,CreationDate,TransactionDate,CreatedBy,LastUpdateDate,LastUpdatedBy,Amount,AmountDueRemaining,Status,CompletedDate,CustomerName,DueDate,BusinessUnitName,ApprovalStatus,paymentSchedules,CustomerTransactionId',
        class="hl-string">'limit': API_LIMIT,
        class="hl-string">'expand': class="hl-string">'paymentSchedules'
    }
    invoices = get_paginated_data(class="hl-string">'receivablesInvoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices.")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to generate events
    for i, inv in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {inv.get('TransactionNumber')}")
        
        case_id = inv.get(class="hl-string">'TransactionNumber')
        cust_trx_id = inv.get(class="hl-string">'CustomerTransactionId')
        common_attrs = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'Amount'),
            class="hl-string">'CustomerName': inv.get(class="hl-string">'CustomerName'),
            class="hl-string">'DueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'Status'),
            class="hl-string">'BusinessUnit': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Event: Invoice Created
        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CreationDate')})

        class=class="hl-string">"hl-comment"># Event: Invoice Completed
        if inv.get(class="hl-string">'CompletedDate'):
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Completed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CompletedDate')})
        
        class=class="hl-string">"hl-comment"># Events: Approval Cycle (based on final status)
        if inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'APPROVED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'REJECTED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'PENDING':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Submitted for Approval', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># Placeholder for class="hl-string">'Invoice Sent to Customer' - requires specific configuration
        class=class="hl-string">"hl-comment"># This might come from BI Publisher or another module. Using LastUpdateDate if status is class="hl-string">'COMPLETE' as an example.
        if inv.get(class="hl-string">'Status') == class="hl-string">'COMPLETE': class=class="hl-string">"hl-comment"># This is a proxy event
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})

        class=class="hl-string">"hl-comment"># Event: Payment Due Date Reached (calculated)
        if inv.get(class="hl-string">'DueDate') and inv.get(class="hl-string">'DueDate') < today and inv.get(class="hl-string">'AmountDueRemaining', 0) > 0:
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'DueDate')})

        class=class="hl-string">"hl-comment"># Event: Dispute Initiated
        for ps in inv.get(class="hl-string">'paymentSchedules', []):
            if ps.get(class="hl-string">'DisputeDate'):
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Dispute Initiated', class="hl-string">'EventTimestamp': ps.get(class="hl-string">'DisputeDate')})
                break class=class="hl-string">"hl-comment"># Assuming one dispute event per invoice for simplicity

        class=class="hl-string">"hl-comment"># Event: Invoice Closed
        if inv.get(class="hl-string">'AmountDueRemaining') == 0 and inv.get(class="hl-string">'Status') == class="hl-string">'CLOSED':
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Closed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># 3. Fetch related events using other APIs
        if cust_trx_id:
            class=class="hl-string">"hl-comment"># Events: Payment Applied and Payment Received
            apps = get_paginated_data(class="hl-string">'receivablesReceipts', {class="hl-string">'q': fclass="hl-string">'AppliedCustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ReceiptNumber,ReceiptDate,ActivityApplication.ApplyDate,ActivityApplication.AppliedCustomerTransactionId'})
            for app in apps:
                for activity_app in app.get(class="hl-string">'ActivityApplication', []):
                    if activity_app.get(class="hl-string">'AppliedCustomerTransactionId') == cust_trx_id:
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received', class="hl-string">'EventTimestamp': app.get(class="hl-string">'ReceiptDate')})
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Applied to Invoice', class="hl-string">'EventTimestamp': activity_app.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Invoice Adjusted
            adjustments = get_paginated_data(class="hl-string">'receivablesAdjustments', {class="hl-string">'q': fclass="hl-string">'CustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ApplyDate'})
            for adj in adjustments:
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Adjusted', class="hl-string">'EventTimestamp': adj.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Payment Reminder Issued (from Delinquency data)
            reminders = get_paginated_data(class="hl-string">'collectionsDelinquentTransactions', {class="hl-string">'q': fclass="hl-string">'TransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'LastDunningLetterDate'})
            for rem in reminders:
                if rem.get(class="hl-string">'LastDunningLetterDate'):
                    event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued', class="hl-string">'EventTimestamp': rem.get(class="hl-string">'LastDunningLetterDate')})

    class=class="hl-string">"hl-comment"># 4. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTimestamp'])
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    df_final = df[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'DueDate', class="hl-string">'InvoiceStatus', class="hl-string">'BusinessUnit']]

    output_filename = class="hl-string">'oracle_fusion_ar_event_log.csv'
    df_final.to_csv(output_filename, index=False)
    print(fclass="hl-string">"\nEvent log successfully saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

Pronto para começar?

Use este Template para preparar seus dados, simplificar o processo de Order to Cash - Faturamento e emissão de faturas e acelerar a conversão de caixa. Descubra novos insights e aumente a eficiência das suas operações no Oracle Fusion Financials hoje mesmo.

Voltar ao guia de melhoria Baixar Template

Comece agora a otimizar o faturamento e a emissão de faturas no Oracle

Reduza em 30% o tempo do seu ciclo de faturamento e aumente o fluxo de caixa com nossa solução.

Começar o teste grátis

Não é necessário cartão de crédito. Configure tudo em poucos minutos.

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento

Guias de extração

Relatório do Oracle BI Publisher para dados de faturamento e emissão de faturas

Etapas

Configuração

a Consulta de exemplo sql

Extração por script Python pelas APIs REST do Oracle Fusion

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Comece agora a otimizar o faturamento e a emissão de faturas no Oracle

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento

Guias de extração

Relatório do Oracle BI Publisher para dados de faturamento e emissão de faturas

Etapas

Configuração

a Consulta de exemplo sql

Extração por script Python pelas APIs REST do Oracle Fusion

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Comece agora a otimizar o faturamento e a emissão de faturas no Oracle

Valorizamos sua privacidade