> Melhoria contínua de processos > Pedido ao recebimento: faturamento e emissão de faturas > Oracle Fusion Financials > Template de dados

Seu Template de dados de pedido ao recebimento: faturamento e emissão de faturas

Oracle Fusion Financials

← Voltar ao guia de melhoria

Atributos de pedido ao recebimento: faturamento e emissão de faturas(22) Atividades de pedido ao recebimento: faturamento e emissão de faturas(13) Guias de extração(2)

Seu Template de dados de pedido ao recebimento: faturamento e emissão de faturas

Este Template orienta você na extração dos dados necessários para analisar o processo de pedido ao recebimento, faturamento e emissão de faturas. Ele apresenta os atributos essenciais a coletar, as atividades importantes a acompanhar e orientações práticas para extrair os dados. Com ele, você pode preparar um conjunto de dados consistente para fazer Process Mining e otimizar o processo.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extrair dados do Oracle Fusion Financials

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos de pedido ao recebimento: faturamento e emissão de faturas

Estes são os campos de dados recomendados para incluir no Event Log e analisar o processo de pedido ao recebimento, faturamento e emissão de faturas de forma abrangente.

3 Obrigatório 5 Recomendado 14 Opcional

	Nome	Descrição
	Hora de início EventTimestamp	Data e hora exatas em que uma atividade ou evento específico ocorreu.
Descrição O registro de data e hora do evento indica o momento exato em que uma atividade ocorreu. Ele estabelece a ordem cronológica dos eventos de cada fatura, algo essencial para montar o fluxo do processo e fazer análises baseadas em tempo. Este atributo é a base de todos os cálculos de duração e performance. Ele permite medir o tempo entre atividades, calcular tempos de ciclo de ponta a ponta, verificar se os pagamentos foram feitos no prazo 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 com esses registros de data e hora. Por que isso importa Os registros de data e hora são essenciais para calcular todas as métricas de performance, incluindo tempos de ciclo, atrasos e cumprimento de prazos. Eles formam a base da análise quantitativa do processo. Onde encontrar Esses dados vêm de vários campos de data nas tabelas do Oracle Fusion Financials, como CREATION_DATE na RA_CUSTOMER_TRX_ALL ou registros de data e hora de atualização de status nas tabelas do fluxo de trabalho. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	Número da fatura InvoiceNumber	Identificador exclusivo de cada fatura, usado como ID do caso 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 ID do caso e agrupa todos os eventos, desde a criação da fatura até o pagamento final e o encerramento. Assim, você tem uma visão completa, de ponta a ponta, do ciclo de vida de cada documento de faturamento. Em Process Mining, analisar os dados pelo número da fatura permite visualizar as variantes do processo, calcular o tempo de ciclo de cada fatura e identificar gargalos ou ciclos 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 o prazo médio de recebimento de vendas (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 encontrar Geralmente, corresponde ao número da transação (TRX_NUMBER) da tabela RA_CUSTOMER_TRX_ALL no Oracle Fusion Financials. Exemplos INV-1002345983451CM-55432
	Nome da atividade ActivityName	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õem o fluxo do processo de cada fatura. Este atributo é fundamental para descobrir o processo, pois permite 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 ciclos 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 e permite visualizar e analisar o fluxo, além de identificar ineficiências no processo de faturamento. Onde encontrar Essas informações são obtidas de várias tabelas e alterações de status no Oracle Fusion Financials, como tabelas de histórico do fluxo de trabalho (por exemplo, relacionadas a aprovações) e campos de status da transação. Exemplos Fatura criadaFatura aprovadaPagamento do cliente recebidoFatura encerrada
	Data de vencimento DueDate	Data limite para o pagamento da fatura.
Descrição A data de vencimento é um atributo essencial que define o prazo de pagamento da fatura conforme as condições de pagamento. Este atributo é fundamental para acompanhar as cobranças e a saúde financeira. Ele serve de referência para calcular o KPI de pagamentos em dia e criar relatórios de vencimento 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 envelhecimento das contas a receber. Onde encontrar Está na tabela AR_PAYMENT_SCHEDULES_ALL, geralmente no campo DUE_DATE. Exemplos 2023-05-302023-06-152023-07-01
	Nome do cliente CustomerName	Nome do cliente ou da entidade que está recebendo a cobrança.
Descrição Este atributo identifica o cliente associado à fatura. É uma dimensão principal para segmentar e filtrar os dados do processo. Analisar o processo pelo nome do cliente ajuda a identificar quais clientes têm os ciclos de pagamento mais longos, contestam faturas com mais frequência e pagam em dia de forma consistente. Isso é essencial para o dashboard de tendência do 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 e revelar diferenças de comportamento, padrões de pagamento e possíveis problemas de relacionamento que afetam o fluxo de caixa. Onde encontrar Obtido pela junção da tabela de transações (RA_CUSTOMER_TRX_ALL) com tabelas de dados cadastrais de clientes, como HZ_PARTIES. Exemplos Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	Status da fatura InvoiceStatus	Status atual da fatura no ciclo de vida, como 'Em aberto', 'Fechada' ou 'Contestada'.
Descrição O status da fatura mostra em que etapa do processo ela está. Os status mais comuns incluem em aberto (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 valores em aberto. Ele ajuda a identificar rapidamente as faturas vencidas, contestadas ou totalmente liquidadas. Por que isso importa Oferece uma visão rápida e geral do estado atual da fatura, permitindo filtrar e categorizar dados com eficiência para relatórios financeiros e gestão operacional. Onde encontrar Obtido de campos de status em tabelas como RA_CUSTOMER_TRX_ALL ou AR_PAYMENT_SCHEDULES_ALL (por exemplo, o campo STATUS). Exemplos Em abertoFechadaContestadaAguardando aprovação
	Unidade de negócio BusinessUnit	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 dado importante para segmentação e relatórios financeiros em grandes empresas. Este atributo permite comparar a performance do processo entre diferentes áreas da empresa. Por exemplo, você pode analisar se o DSO varia significativamente entre unidades de negócio ou se uma delas tem uma taxa de retrabalho no faturamento muito maior. Isso ajuda a direcionar iniciativas de melhoria para onde 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 melhorias em detalhe. Onde encontrar Disponível em tabelas de transações como RA_CUSTOMER_TRX_ALL, muitas vezes no campo ORG_ID, que se relaciona às definições das unidades de negócio. Exemplos Consultoria dos USManufatura da EMEAServiços da APAC
	Valor da fatura InvoiceAmount	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 passa pelo processo de faturamento. Na análise, o valor da fatura ajuda a priorizar transações de alto valor, calcular o total de contas a receber em aberto e ponderar KPIs como o prazo médio de recebimento de vendas (DSO). Também permite segmentar o processo pelo impacto financeiro, por exemplo, para analisar se faturas de alto valor seguem um fluxo 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, a priorização de faturas de alto valor e o cálculo de KPIs financeiros importantes. Onde encontrar Está na tabela RA_CUSTOMER_TRX_ALL, provavelmente em um campo como INVOICE_AMOUNT ou em outro campo relacionado que represente o total da transação. Exemplos 5000.001250.75250000.00
	Condições de pagamento PaymentTerms	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 sobre quando e como uma fatura deve ser paga, incluindo possíveis descontos para pagamentos antecipados. Essas informações são essenciais para gerenciar contas a receber e o fluxo de caixa. Este atributo é fundamental para calcular corretamente a data de vencimento e identificar oportunidades de desconto 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 ao desconto. Por que isso importa Define as regras de pagamento da fatura, afeta diretamente o cálculo da data de vencimento e permite acompanhar e otimizar o aproveitamento de descontos por pagamento antecipado. Onde encontrar Está na tabela RA_TERMS e é associado à transação por meio de term_id na RA_CUSTOMER_TRX_ALL. Exemplos Net 30Net 602% 10, Net 30
	Data da fatura InvoiceDate	Data oficial de emissão da fatura.
Descrição A data da fatura, também chamada de data da transação, é a data registrada no documento. Ela serve como ponto de partida para calcular as condições de pagamento. Essa data é essencial para calcular o prazo médio de recebimento de vendas (DSO), que 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 É a data oficial de início do ciclo de vida da fatura e serve de referência para calcular o KPI de prazo médio de recebimento de vendas (DSO). Onde encontrar Está na tabela RA_CUSTOMER_TRX_ALL, no campo TRX_DATE. Exemplos 2023-04-142023-05-182023-06-25
	Departamento de faturamento BillingDepartment	Departamento ou equipe interna responsável por criar e gerenciar a fatura.
Descrição Este atributo identifica a equipe ou o departamento da organização responsável pelo processo de faturamento. Ele acrescenta outra dimensão organizacional à 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 mais retrabalho, ciclos de aprovação mais longos ou contribuem mais para um DSO elevado, apontando oportunidades de treinamento direcionado ou padronização do processo. Por que isso importa Permite comparar a performance entre equipes internas e ajuda a identificar boas práticas, necessidades de recursos e áreas que precisam de melhorias no processo. Onde encontrar Essas informações podem ser obtidas a partir do usuário que criou a fatura, associando-o ao departamento ao qual está vinculado 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
	É retrabalho IsRework	Indicador booleano que mostra 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. Por exemplo, quando uma fatura é rejeitada e depois reenviada para aprovação, ou quando é corrigida após a criação inicial. Ao sinalizar o retrabalho, fica fácil quantificar seu impacto no processo. O KPI de taxa de retrabalho no faturamento é calculado diretamente com este atributo. Os dashboards podem mostrar a frequência do retrabalho e medir o tempo de ciclo adicional que ele gera, ajudando a identificar 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 custos e tempo. Onde encontrar É calculado durante a transformação dos dados, com base na sequência de atividades. Por exemplo, se a atividade 'Fatura aprovada' for precedida por 'Fatura rejeitada' no mesmo caso, ela será sinalizada como retrabalho. Exemplos truefalse
	Foi pago em dia IsPaidOnTime	Indicador booleano que mostra se a fatura foi paga até a data de vencimento.
Descrição Este atributo calculado indica de forma simples se o pagamento foi feito em dia. Ele é obtido comparando a data da atividade 'Pagamento do cliente recebido' com o atributo 'Data de vencimento' da fatura. Este indicador simplifica a análise e os relatórios do KPI de taxa de pagamentos em dia. Ele permite filtrar e segmentar os dados facilmente para entender quais fatores, como cliente, região ou valor da fatura, estão relacionados a pagamentos atrasados. É uma métrica importante para avaliar a eficácia das cobranças. Por que isso importa Simplifica a medição da performance das cobranças e facilita a análise dos fatores que contribuem para pagamentos em dia ou atrasados. Onde encontrar Calculado comparando o registro de data e hora da atividade de pagamento final com o atributo DueDate. A lógica é: `PaymentTimestamp <= DueDate`. Exemplos truefalse
	Hora de término EventEndTime	Data e 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 duração: começam quando são enviadas e terminam quando uma decisão é tomada. Ter uma hora de término permite calcular com precisão o tempo de processamento da atividade. Isso ajuda a analisar quanto tempo os usuários dedicam a tarefas específicas. Também melhora a precisão da análise de gargalos ao diferenciar o tempo de espera do tempo efetivo de processamento. Por que isso importa Permite calcular com precisão o tempo de processamento das atividades e diferenciar o tempo de trabalho ativo do tempo de espera, algo essencial para uma análise detalhada de gargalos. Onde encontrar Muitas vezes, é obtido usando a hora de início da atividade seguinte no processo. Para algumas atividades, os registros do fluxo de trabalho podem ter um campo específico de hora de término. Exemplos 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	Método de pagamento PaymentMethod	Método usado pelo cliente para fazer 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. Os métodos de pagamento podem ter prazos de processamento e custos de transação diferentes. Analisar os dados por método de pagamento ajuda a entender se alguns métodos estão mais sujeitos a erros de conciliação ou atrasos. 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 das transações e as taxas de erro de conciliação associadas a diferentes canais de pagamento. Onde encontrar Está nas tabelas de recebimentos em dinheiro, como AR_CASH_RECEIPTS_ALL, que contém um campo para indicar o método de pagamento. Exemplos ACHTransferência bancáriaCartão de créditoCheque
	Motivo da contestação DisputeReason	Motivo informado pelo cliente para contestar uma fatura.
Descrição Quando um cliente contesta uma fatura, o motivo da contestação é registrado. Ele pode estar relacionado a preços, quantidade, qualidade do serviço ou outros problemas. Analisar os motivos das contestações é uma forma eficaz de fazer uma análise de causa raiz. Ao entender os motivos mais comuns, a empresa pode resolver problemas subjacentes relacionados a preços, atendimento de pedidos ou qualidade dos dados. Isso ajuda a reduzir o tempo médio de resolução de contestações de faturas e a melhorar a satisfação dos clientes. Por que isso importa Oferece insight direto sobre as causas raiz dos atrasos nos pagamentos e da insatisfação dos clientes, permitindo que a empresa resolva problemas sistêmicos. Onde encontrar Essas informações podem estar armazenadas no Oracle Collections ou em um módulo relacionado à gestão de contestações. Talvez estejam em uma tabela específica de contestações ou como um código de motivo na própria transação. Exemplos Preço incorretoDivergência na quantidadeMercadoria danificadaFatura duplicada
	Prazo médio de recebimento de vendas DaysSalesOutstanding	Número de dias entre a data da fatura e a data em que o pagamento foi recebido.
Descrição O prazo médio de recebimento de vendas (DSO) é uma métrica financeira essencial que mede o tempo médio para receber o pagamento após a emissão de uma fatura. Este atributo calcula esse prazo para cada fatura. Embora o DSO geral seja um KPI importante, calculá-lo para cada fatura permite uma análise muito mais detalhada. Ele pode ser usado para criar dashboards de tendências, identificar características de faturas com DSO elevado e medir o impacto financeiro dos atrasos no 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 para cada fatura, permitindo analisar em detalhe os fatores que influenciam os prazos de recebimento e a performance financeira. Onde encontrar Calculado pela diferença entre o registro de data e hora da atividade 'Pagamento do cliente recebido' e o atributo 'Data da fatura'. Exemplos 356228
	Região Region	Região geográfica associada ao cliente ou à transação.
Descrição A região fornece o contexto geográfico da fatura, geralmente com base na localização do cliente. Isso permite analisar a performance do processo por área geográfica. A análise 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 do DSO e Tempo de ciclo de ponta a ponta da fatura podem ser segmentados por região para identificar áreas com desafios específicos para receber pagamentos. Por que isso importa Permite segmentar o processo por região geográfica e destacar diferenças regionais de performance, comportamento dos clientes ou Conformidade. Onde encontrar Geralmente, é obtido dos dados de endereço do cliente armazenados no TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Não é um campo direto da própria fatura. Exemplos América do NorteEuropaÁsia-Pacífico
	Sistema de origem SourceSystem	Sistema oficial de registro de onde os dados do evento foram extraídos.
Descrição Este atributo identifica o aplicativo de origem dos dados. Neste processo, geralmente será o Oracle Fusion Financials, mas também pode indicar um módulo específico, como o Oracle Receivables (AR). Em ambientes com vários sistemas integrados, este campo ajuda a diferenciar as fontes de dados e é fundamental para a validação e a governança dos dados. Ele garante que a análise use o conjunto de dados correto e previsto. Por que isso importa Identifica a origem dos dados, algo essencial para a governança, a solução de problemas e a garantia de que a análise se baseia no sistema oficial de registro correto. Onde encontrar Geralmente, é um valor estático ('Oracle Fusion Financials') adicionado durante a extração e a transformação dos dados. Exemplos Oracle Fusion FinancialsOracle AR CloudFusion Apps
	Tempo de ciclo da fatura InvoiceCycleTime	Tempo total entre a criação inicial da fatura e seu fechamento.
Descrição Este atributo mede a duração de ponta a ponta de todo o ciclo de vida de uma fatura em um único caso. Ele é calculado pela diferença entre a primeira atividade, geralmente 'Fatura criada', e a atividade final, 'Fatura fechada'. Esta métrica oferece 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 este atributo por dimensões como cliente ou unidade de negócio, as organizações podem identificar quais tipos de fatura levam mais tempo para ser processados e investigar as causas raiz. Por que isso importa Oferece uma medida única e essencial da velocidade geral do processo, ajudando a identificar rapidamente quais faturas levam mais tempo para ser concluídas do início ao fim. Onde encontrar Esta métrica calculada é obtida pela diferença entre o maior e o menor EventTimestamp de cada InvoiceNumber exclusivo. Exemplos 45 dias e 8 horas32 dias e 2 horas90 dias e 12 horas
	Última atualização dos dados LastDataUpdate	Registro de data e hora que indica quando os dados deste evento foram atualizados ou extraídos pela última vez do sistema de origem.
Descrição Este atributo informa a data e a hora 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 essa informação para confirmar se estão trabalhando com dados atualizados e saber quando eles foram obtidos. Ela é especialmente importante em dashboards que se apresentam como 'em tempo real' ou quase em tempo real, pois mostra com transparência possíveis atrasos na atualização dos dados. Por que isso importa Informa aos usuários se os dados estão atualizados, garantindo que as análises e conclusões se baseiem em informações com um nível de atualização conhecido e aceitável. Onde encontrar Este campo de metadados é gerado durante o processo de extração, transformação e carregamento de dados (ETL). Em geral, corresponde ao horário de execução do pipeline de dados. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Usuário User	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 quem criou a fatura, o gerente que a aprovou ou o agente de cobrança que enviou um lembrete. Analisar os dados por usuário ajuda a identificar oportunidades de treinamento, distribuir a carga de trabalho e comparar a performance entre pessoas ou equipes. Também pode revelar se determinados usuários estão associados a altas taxas de erro ou se alguns aprovadores se tornam gargalos recorrentes. Por que isso importa Atribui responsabilidade pelas etapas do processo e permite analisar a performance dos usuários, equilibrar a carga de trabalho e identificar necessidades de treinamento. Onde encontrar Obtido de campos de ID de usuário, como CREATED_BY ou LAST_UPDATED_BY, em várias tabelas de transações e do fluxo de trabalho. Em seguida, esse ID é associado a tabelas de diretório de usuários (por exemplo, PER_ALL_PEOPLE_F) para obter o nome do usuário. Exemplos john.smithjane.doeCollectionsBot

Obrigatório Recomendado Opcional

Atividades de pedido ao recebimento: faturamento e emissão de faturas

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir o processo com precisão.

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. O evento é registrado quando o fluxo de trabalho de aprovação é concluído com sucesso e o status da fatura é atualizado.
Por que isso importa Este é um marco crítico que condiciona o envio da fatura ao cliente. Atrasos nessa etapa afetam diretamente o início do prazo de pagamento e o Prazo médio de recebimento de vendas (DSO). Onde encontrar 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 da tarefa de fluxo de trabalho BPM associada. Coleta Registre a data e a hora em que o status de aprovação da fatura muda para 'Approved'. Tipo de evento inferred
	Fatura criada	Criação inicial de uma transação de fatura no sistema, geralmente com status de rascunho ou incompleto. O evento é registrado explicitamente quando alguém salva pela primeira vez um novo registro de fatura no módulo de Contas a Receber.
Por que isso importa Este é o início efetivo do processo de faturamento. Analisar o tempo entre a criação e a conclusão ajuda a identificar atrasos na entrada inicial de dados ou problemas de performance do sistema. Onde encontrar Este evento é capturado a partir da data de criação do registro da transação na tabela RA_CUSTOMER_TRX_ALL. O status inicial costuma ser 'Incomplete'. Coleta Use creation_date da tabela RA_CUSTOMER_TRX_ALL para o número da fatura correspondente. Tipo de evento explicit
	Fatura encerrada	A fatura foi totalmente paga e conciliada, e seu ciclo de vida foi concluído. Esse evento costuma ser inferido quando o saldo em aberto da fatura chega a zero e o 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 dos principais KPIs do processo de faturamento. Onde encontrar Inferido da tabela AR_PAYMENT_SCHEDULES_ALL quando o status é atualizado para 'CLOSED' e amount_due_remaining chega a zero. O campo 'gl_date_closed' indica a data de fechamento. Coleta Use o campo gl_date_closed da tabela AR_PAYMENT_SCHEDULES_ALL para a fatura específica. Tipo de evento inferred
	Fatura enviada ao cliente	A fatura foi enviada ao cliente pelo canal de sua preferência, como e-mail ou impressão. Em geral, o sistema registra a data e a hora em que a ação de envio é executada.
Por que isso importa Esta atividade inicia oficialmente o prazo de pagamento. Medir o tempo entre a aprovação e o envio é essencial para entender a eficiência do processo de distribuição de faturas. Onde encontrar Isso pode ser inferido pelo campo 'last_printed_date' da tabela RA_CUSTOMER_TRX_ALL ou pelos registros do Oracle Business Intelligence Publisher, quando o envio eletrônico é usado. Coleta Use a data e a hora do registro de envio ou impressão correspondente à fatura. Tipo de evento inferred
	Pagamento aplicado à fatura	O pagamento recebido do cliente foi conciliado e aplicado com sucesso à fatura correspondente, reduzindo o saldo em aberto. Isso é registrado como uma transação específica.
Por que isso importa Esta atividade confirma que o valor recebido foi alocado corretamente, o que é essencial para a precisão dos relatórios de envelhecimento e das demonstrações financeiras. É a etapa final para reconhecer o recebimento em relação ao valor a receber. Onde encontrar Registrado explicitamente na tabela AR_RECEIVABLE_APPLICATIONS_ALL. Os campos apply_date e gl_date indicam quando a aplicação ocorreu. Coleta Use apply_date da tabela AR_RECEIVABLE_APPLICATIONS_ALL, que vincula o recebimento em dinheiro à fatura. Tipo de evento explicit
	Pagamento do cliente recebido	Um pagamento do cliente foi registrado no sistema como recebimento de caixa. Nesse momento, o pagamento ainda pode não estar vinculado a uma fatura específica.
Por que isso importa Este é um marco essencial que representa uma entrada de caixa. 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 encontrar Registrado explicitamente quando um registro é criado na tabela AR_CASH_RECEIPTS_ALL. O campo receipt_date indica quando o pagamento foi processado. Coleta Use 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 conforme o contrato já passou. Este não é um evento transacional, mas um cálculo baseado nas condições da fatura e na data atual.
Por que isso importa Este evento calculado é fundamental para a análise de envelhecimento e o cálculo do DSO. Ele diferencia as faturas pagas no prazo das vencidas e permite direcionar as atividades de cobrança. Onde encontrar 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. Coleta Calculado comparando a data atual com o campo due_date da tabela 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 pela alteração de um indicador de status na programação de pagamentos da fatura.
Por que isso importa As disputas interrompem o processo de pagamento e exigem trabalho manual para serem resolvidas. Analisar a frequência e o tempo de resolução ajuda a identificar causas raiz, como erros de preço ou de envio. Onde encontrar Isso pode ser inferido quando o campo de status da tabela AR_PAYMENT_SCHEDULES_ALL recebe um status de disputa ou pelos registros de criação na tabela AR_DISPUTE_HISTORY. Coleta Identifique quando o indicador ou status de disputa é ativado na programação 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. Essa transação explícita modifica o saldo em aberto da fatura.
Por que isso importa Os ajustes muitas vezes 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 encontrar Registrado explicitamente na tabela AR_ADJUSTMENTS_ALL. A creation_date do registro do ajuste marca o evento. Coleta Use creation_date da tabela AR_ADJUSTMENTS_ALL para a fatura correspondente. Tipo de evento explicit
	Fatura concluída	Indica que a entrada dos dados da fatura foi finalizada e que a transação está pronta para validação e contabilização. Normalmente, isso é identificado pela mudança do status da fatura de 'Incomplete' para 'Complete'.
Por que isso importa Este marco encerra a etapa de entrada de dados. O tempo entre a criação e a conclusão pode indicar a eficiência da entrada e da revisão de dados pela equipe de faturamento. Onde encontrar 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'. Coleta Acompanhe o histórico de status da transação na tabela RA_CUSTOMER_TRX_ALL ou em tabelas relacionadas ao fluxo de trabalho. Tipo de evento inferred
	Fatura enviada para aprovação	A fatura é formalmente encaminhada para um fluxo de trabalho de aprovação, se houver um configurado. Isso é registrado quando o status da fatura muda para um estado de aprovação pendente, acionando notificações para os responsáveis 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 encontrar Inferido a partir de uma mudança de status na transação da fatura ou capturado nas tabelas do fluxo de trabalho do Oracle Business Process Management (BPM), que registram o início da tarefa de aprovação. Coleta Identifique o registro de data e hora em que o status de aprovação da fatura muda para 'Pending' ou um estado semelhante. Tipo de evento inferred
	Fatura rejeitada	Um responsável pela aprovação rejeitou a fatura, geralmente por erros em dados como preços ou quantidades. Esse evento devolve a fatura para correção e cria um ciclo de retrabalho.
Por que isso importa Acompanhar as rejeições ajuda a identificar problemas na precisão do faturamento e nos controles internos. Analisar a frequência e os motivos das rejeições pode revelar oportunidades de melhoria do processo e treinamento. Onde encontrar Inferido a partir de uma atualização de status no registro da transação da fatura ou do resultado 'Rejected' na tarefa de fluxo de trabalho BPM. Coleta Registre a data e a hora em que o status de aprovação da fatura muda para 'Rejected'. Tipo de evento inferred
	Lembrete de pagamento enviado	Uma carta de cobrança ou um aviso de lembrete foi enviado ao cliente por causa de uma fatura vencida. Essa 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 e permite analisar quais estratégias levam a pagamentos mais rápidos. Onde encontrar Registrado explicitamente no módulo Oracle Advanced Collections. Tabelas de histórico de cobrança, como IEX_DUNNINGS, registram a data e o nível do lembrete enviado. Coleta Capture os dados nas tabelas de histórico de cobrança e vincule a transação de cobrança à fatura. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como extrair seus dados do Oracle Fusion Financials

Etapas

Acesse o BI Publisher: Entre 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 catálogo do Business Intelligence.
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 mais ao lado de Data Sets e selecione SQL Query. Na nova janela, dê um nome ao conjunto de dados, por exemplo, AR_INVOICE_LIFECYCLE. Selecione a fonte de dados adequada, geralmente 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 guia Parameters para definir valores padrão ou configurar opções de exibição para o usuário. Depois, acesse a guia Data, informe os valores dos parâmetros (por exemplo, um intervalo curto de datas) e clique em View para testar a consulta e ver 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 salve o modelo de dados 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 de relatórios, 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, não crie um layout complexo. Selecione a opção 'Create Table' e arraste todas as colunas do conjunto de dados para a tabela. O objetivo é exportar dados brutos, não criar um relatório formatado.
Defina CSV como formato de saída padrão: Nas propriedades do relatório, configure CSV como formato de saída padrão. Assim, ao executar o relatório, será gerado 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 (intervalo de datas e unidade de negócio) e defina o destino. Uma opção 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 UCM) e baixe o arquivo CSV gerado. Esse arquivo é seu Event Log.
Prepare o arquivo para carregamento: Confirme se o arquivo CSV tem 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 (formato YYYY-MM-DD). A consulta filtra os eventos com base no timestamp.
- :P_END_DATE: Data final do período de extração (formato YYYY-MM-DD).
- :P_BUSINESS_UNIT: Nome da unidade de negócio usada para filtrar as faturas. Use esse parâmetro para reduzir o volume de dados e direcionar 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, conforme as necessidades do negócio.
Configuração dos códigos de status: A consulta contém marcadores como '[Your Pending Approval Status]'. Substitua-os pelos códigos de status usados na sua implementação do Oracle Fusion para os fluxos de trabalho 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 horários de menor movimento, evitando impactos na performance do sistema para outros 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 precisa de perfis de segurança de dados que permitam acessar os dados necessários de contas a receber, clientes e unidades de negócio.

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: Instale o Python 3.6 ou superior e as bibliotecas requests e pandas. Você pode instalá-las com pip: pip install requests pandas.
Credenciais do Oracle Fusion: Obtenha as credenciais necessárias para acessar as APIs REST do Oracle Fusion. Você precisará da URL base da sua instância do Fusion, de um nome de usuário e de uma senha com privilégios suficientes para ler os 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 exemplo de FUSION_URL, USERNAME, PASSWORD e de parâmetros de filtro, como start_date.
Entenda os endpoints da API: O script usa principalmente o endpoint receivablesInvoices para buscar os dados principais das faturas. Em seguida, faz chamadas a outros endpoints, como receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments e collectionsDelinquentTransactions, para reunir eventos relacionados.
Paginação: O script inclui a função auxiliar get_paginated_data, que percorre automaticamente as páginas da API seguindo o link next na resposta até recuperar todos os registros da consulta.
Busca de dados: Primeiro, o script busca uma lista de faturas dentro do intervalo de datas especificado. Depois, percorre cada fatura para reunir os detalhes específicos e os eventos relacionados.
Geração de eventos: Para cada fatura, o script cria linhas para diferentes atividades. Algumas, como 'Invoice Created', são obtidas 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 corresponde a uma transação direta. O script o calcula verificando se a data de vencimento (DueDate) da fatura já passou e se ela continua sem pagamento.
Execute o script: Execute o script no terminal com python your_script_name.py. Ele exibirá atualizações de andamento enquanto busca os dados de cada fatura.
Confira o resultado: Quando a execução terminar, será criado no mesmo diretório um arquivo chamado oracle_fusion_ar_event_log.csv. Esse arquivo contém o Event Log extraído.
Prepare o arquivo para carregamento: Abra o arquivo CSV gerado. Confira se os cabeçalhos das colunas são CaseId, ActivityName e EventTimestamp para um mapa de processo básico, ou mapeie as colunas geradas (InvoiceNumber, ActivityName, EventTimestamp, InvoiceAmount etc.) na ferramenta de Process Mining durante o carregamento.

Configuração

URL base da API: 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. Confira 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 período 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. Em geral, um valor entre 100 e 500 é eficiente. O script já 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 quando o volume é grande. O script faz várias chamadas à API para cada fatura. Para conjuntos de dados com mais de 100.000 faturas, considere executar o script em lotes ou fora dos horários de pico para evitar queda de performance ou limitação de chamadas à API.

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, otimizar o processo de pedido ao recebimento, faturamento e emissão de faturas e acelerar a conversão em caixa. Descubra insights e aumente a eficiência das operações no Oracle Fusion Financials.

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 ciclo de faturamento e melhore o fluxo de caixa com nossa solução.

Começar o teste grátis

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

Seu Template de dados de pedido ao recebimento: faturamento e emissão de faturas

Seu Template de dados de pedido ao recebimento: faturamento e emissão de faturas

Atributos de pedido ao recebimento: faturamento e emissão de faturas

Atividades de pedido ao recebimento: faturamento e emissão de faturas

Guias de extração

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

Etapas

Configuração

Consulta de exemplo sql

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

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

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