> Melhoria Contínua de Processos > Record to Report Lançamento Contábil > Oracle Fusion Financials > Modelo de Dados

Seu Template de Dados Record to Report - Lançamento Contábil

Oracle Fusion Financials

Record to Report - Atributos de Lançamento Contábil (22) Record to Report - Atividades de Lançamento Contábil (12) Guias de Extração (4)

Seu Template de Dados Record to Report - Lançamento Contábil

Este template de dados fornece um guia abrangente para extrair e estruturar seus dados de Lançamento Contábil do Oracle Fusion Financials. Ele descreve os atributos essenciais a serem coletados e as principais atividades a serem rastreadas, garantindo que você capture todas as informações necessárias para uma análise robusta do processo. Você também encontrará orientações práticas sobre como extrair esses dados diretamente do seu sistema.

Atributos recomendados para coletar
Atividades-chave a monitorizar
Orientação para extração para Oracle Fusion Financials

É novo em event logs? Saiba como criar um event log para Process Mining.

Baixar Modelo

Record to Report - Atributos de Lançamento Contábil

Estes são os campos de dados recomendados para incluir em seu Event Log para uma análise abrangente do seu processo Record to Report - Lançamento Contábil.

5 Obrigatório 6 Recomendado 11 Opcional

	Nome	Descrição
	Atividade ActivityName	O nome do evento de negócio ou tarefa específica que ocorreu em um determinado momento no processo de lançamento contábil.
Descrição O Nome da Atividade descreve uma etapa única dentro do ciclo de vida do lançamento contábil, como 'Lançamento Contábil Criado' ou 'Lançamento Contábil Aprovado'. Esses dados são fundamentais para construir o mapa do processo e entender a sequência de eventos.\n\nA análise das atividades permite a identificação do fluxo do processo, incluindo caminhos padrão, desvios e loops de retrabalho. Ao rastrear diferentes atividades, podemos medir o tempo gasto em estágios específicos, como a aprovação, e identificar quais etapas consomem mais tempo ou são mais propensas a erros. Por que é importante Define as etapas do processo, formando a espinha dorsal do mapa e permitindo analisar fluxos, gargalos e variações. Onde obter Este atributo é normalmente derivado de mudanças de status, logs de eventos ou tabelas de trilha de auditoria associadas aos objetos de lançamento contábil no módulo do Razão Geral. Exemplos Lançamento Contábil CriadoLançamento Submetido para AprovaçãoLançamento Contábil AprovadoLançamento Contábil Efetivado
	Hora de Início EventTime	O timestamp que indica quando uma atividade ou evento específico ocorreu.
Descrição Este timestamp marca a data e a hora exatas em que uma atividade foi executada. É o principal elemento temporal usado no Process Mining para determinar a sequência de eventos e calcular as durações entre eles.\n\nA precisão do Horário do Evento é crítica para todas as análises baseadas em tempo, incluindo o cálculo de tempos de ciclo, a identificação de gargalos e o monitoramento do desempenho em relação aos acordos de nível de serviço. Ele fornece a ordem cronológica necessária para reconstruir o fluxo do processo conforme ele ocorreu. Por que é importante Este timestamp é essencial para ordenar os eventos, calcular todas as durações dos processos e realizar qualquer análise baseada em tempo. Onde obter Essas informações costumam ser armazenadas em tabelas de trilha de auditoria ou como uma 'Data da Última Atualização' ou 'Data de Criação' em tabelas de transação como GL_JE_HEADERS e GL_JE_LINES para eventos específicos. Exemplos 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	ID do Lançamento Contábil JournalEntryId	O identificador exclusivo para um único lançamento contábil, vinculando todas as atividades de transação financeira relacionadas.
Descrição O ID do Lançamento Contábil serve como o identificador principal do caso, vinculando de forma única todas as atividades relacionadas a um conjunto específico de transações financeiras. Isso permite o rastreamento do ciclo de vida completo de um único lançamento, do início à contabilização final, garantindo que todos os débitos e créditos sejam contabilizados.\n\nNo Process Mining, esse ID é essencial para reconstruir a jornada de ponta a ponta de cada lançamento. Ele conecta eventos distintos, como 'Lançamento Contábil Criado', 'Lançamento Enviado para Aprovação' e 'Lançamento Contábil Contabilizado' em um fluxo de processo coerente, permitindo a análise de tempos de ciclo, gargalos e variações de processo. Por que é importante Esta é a chave fundamental para rastrear um lançamento contábil do início ao fim, possibilitando analisar todo o fluxo do processo para cada caso exclusivo. Onde obter Esta é uma chave primária encontrada nas tabelas principais do Razão Geral, como GL_JE_HEADERS e GL_JE_LINES. Exemplos JE100523JE202311001882019
	Sistema de Origem SourceSystem	O sistema ou módulo onde os dados foram originados.
Descrição Este atributo identifica o sistema de origem de onde os dados do processo foram extraídos. Em um cenário de TI complexo, os dados podem vir de múltiplos sistemas integrados, e este campo ajuda a diferenciá-los.\n\nNa análise de processos, saber o sistema de origem é crucial para entender as variações de processo que podem ser causadas por diferentes comportamentos do sistema. Também ajuda na validação de dados e na resolução de problemas, rastreando os dados até sua origem. Por que é importante Identifica a origem dos dados, o que é fundamental para governança, validação e para entender variações de processos entre sistemas. Onde obter Muitas vezes, este é um valor estático configurado durante a extração de dados, ou pode ser um campo nas tabelas de origem que identifica o sistema de entrada. Exemplos Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Última Atualização de Dados LastDataUpdate	O timestamp da atualização ou extração de dados mais recentes do sistema de origem.
Descrição Este atributo registra quando o conjunto de dados foi atualizado pela última vez. Ele fornece contexto sobre o frescor dos dados analisados, o que é importante para entender a relevância dos insights obtidos.\n\nEm qualquer análise, especialmente em Dashboards operacionais, saber o horário da 'Última Atualização de Dados' é crítico para que os usuários confiem nos dados e tomem decisões informadas. Ele comunica claramente o ponto de corte para os dados incluídos no modelo de Process Mining. Por que é importante Indica a atualização dos dados, garantindo que os usuários saibam quão recente é a análise e possam confiar nos insights. Onde obter Este valor é gerado e armazenado durante o processo de extração e transformação de dados. Geralmente é o timestamp de quando a tarefa de ETL/ELT foi concluída. Exemplos 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoria do Lançamento JournalCategory	A categoria do lançamento contábil, como 'Provisão', 'Ajuste' ou 'Reclassificação'.
Descrição A Categoria classifica os lançamentos por finalidade de negócio, permitindo uma análise granular. Categorias diferentes podem ter fluxos, regras de aprovação e tempos de ciclo distintos. Por exemplo, lançamentos de ajuste de fechamento mensal podem ser mais complexos e urgentes que apropriações rotineiras. Analisar por categoria ajuda a identificar essas variações e adaptar melhorias a tipos específicos de lançamentos. Por que é importante Permite segmentar o processo pela finalidade do lançamento, revelando comportamentos e desempenhos distintos para cada tipo de entrada. Onde obter Disponível na tabela GL_JE_HEADERS, no campo JE_CATEGORY. Exemplos ApropriaçãoManualAjusteReavaliação
	Departamento do usuário UserDepartment	O departamento ou equipe ao qual pertence o usuário que realizou a atividade.
Descrição Este atributo fornece contexto organizacional vinculando uma atividade a um departamento específico, como 'Finanças', 'Operações Contábeis' ou 'Auditoria Interna'. Ele é geralmente derivado dos dados mestres do usuário.\n\nAnalisar pelo Departamento do Usuário ajuda a identificar gargalos entre departamentos, comparar o desempenho das equipes e entender como a execução do processo difere em toda a organização. É valioso para a alocação de recursos e iniciativas direcionadas de melhoria de processos. Por que é importante Fornece contexto organizacional, permitindo a análise de desempenho por equipe ou departamento e destacando ineficiências multifuncionais. Onde obter Normalmente, isso não está nas tabelas de transação. Deve ser obtido cruzando o UserName com uma tabela de dados mestres de usuários ou dados do sistema de RH. Exemplos Contabilidade GeralRelatórios FinanceirosContas a Pagar
	Motivo da Rejeição RejectionReason	Uma descrição em texto ou código explicando o motivo da rejeição do lançamento contábil.
Descrição Quando um lançamento contábil é rejeitado durante o processo de aprovação, este atributo captura o motivo da rejeição. Pode ser um código predefinido ou um comentário em texto livre do aprovador.\n\nEste é um dos atributos mais importantes para a análise de causa raiz de ineficiências nos processos. Ao analisar os motivos de rejeição mais comuns, as organizações podem identificar áreas de melhoria, como melhor treinamento para quem prepara os lançamentos, diretrizes mais claras ou melhorias nos controles do sistema. Ele apoia diretamente o Dashboard 'Análise da Taxa de Rejeição de Lançamentos Contábeis'. Por que é importante Oferece insights diretos sobre as causas raiz de retrabalhos e atrasos no processo, permitindo melhorias direcionadas para reduzir as taxas de rejeição. Onde obter Estas informações podem estar armazenadas em tabelas de workflow ou de trilha de auditoria associadas ao processo de aprovação, ou em um campo de observações no cabeçalho do lançamento. Exemplos Combinação de Contas IncorretaDocumentação de Suporte InsuficienteExcede o orçamento
	Origem do Lançamento JournalSource	O livro auxiliar ou fonte que gerou o lançamento contábil, como 'Contas a Pagar', 'Contas a Receber' ou 'Manual'.
Descrição Este atributo indica a origem do lançamento contábil dentro do sistema ERP. Os lançamentos podem ser criados manualmente no Razão Geral ou gerados automaticamente a partir de livros auxiliares, como Contas a Pagar, Contas a Receber ou Ativo Imobilizado.\n\nA Fonte do Lançamento é um atributo fundamental para a análise de automação. Ajuda a diferenciar entre lançamentos manuais e gerados pelo sistema, apoiando o KPI 'Taxa de Lançamento Contábil Automatizado'. Os processos para lançamentos de diferentes fontes costumam variar significativamente em termos de complexidade e eficiência. Por que é importante Distingue entre lançamentos manuais e automáticos, fundamental para medir taxas de automação e analisar diferenças de processo. Onde obter Disponível na tabela GL_JE_HEADERS, no campo JE_SOURCE. Exemplos ManualContas a PagarAtivosContas a Receber
	Utilizador UserName	O usuário que realizou a atividade, como criar, aprovar ou contabilizar o lançamento contábil.
Descrição Este atributo identifica o funcionário ou usuário do sistema específico responsável pela execução de uma atividade. Ele é crucial para entender a distribuição da carga de trabalho, o desempenho e para identificar gargalos individuais.\n\nNa análise, o UserName permite filtrar processos por usuário, comparar a eficiência entre eles e investigar motivos de atrasos ou erros. Ele dá suporte direto a Dashboards como 'Carga de Trabalho e Eficiência do Usuário entre Equipes' e KPIs como o 'Índice de Gargalo de Lançamento por Usuário'. Por que é importante Atribui responsabilidade pelas etapas, permitindo analisar carga de trabalho, desempenho individual e necessidades de treinamento. Onde obter Encontrado em tabelas transacionais como GL_JE_HEADERS (ex: CREATED_BY, LAST_UPDATED_BY) e tabelas de auditoria. Exemplos john.doesusan.smithautoprocess_user
	Valor do Lançamento JournalAmount	O valor monetário total do lançamento contábil, normalmente a soma dos débitos.
Descrição Este atributo representa o valor financeiro total transacionado no lançamento contábil. O valor pode ser um fator significativo que influencia o processo. Por exemplo, lançamentos de alto valor podem exigir etapas de aprovação adicionais ou revisões mais minuciosas.\n\nAnalisar o Valor do Lançamento permite a segmentação de casos por impacto financeiro. Ajuda a responder perguntas como 'Lançamentos de alto valor demoram mais para serem aprovados?' ou 'As rejeições são mais comuns para lançamentos acima de um certo limite?'. Isso fornece um contexto de negócios crucial para o fluxo do processo. Por que é importante Fornece um contexto de negócios crítico, permitindo análises baseadas no impacto financeiro e ajudando a identificar se lançamentos de alto valor seguem um processo diferente. Onde obter Este valor é normalmente calculado como a soma dos débitos ou créditos da tabela GL_JE_LINES para um determinado lançamento contábil. Exemplos 5000.00125000.75750.50
	Data Alvo de Contabilização TargetPostingDate	A data predeterminada até a qual se espera que o lançamento contábil seja postado.
Descrição A Data Alvo de Contabilização representa o prazo para postar um lançamento contábil no razão geral, geralmente determinado por acordos de nível de serviço (SLAs) ou calendários de fechamento mensal. Ela serve como referência para medir o desempenho.\n\nEste atributo é essencial para calcular o KPI 'Taxa de Contabilização de Lançamentos no Prazo'. Ao comparar a data real de contabilização com este alvo, o sistema pode sinalizar automaticamente os lançamentos como dentro do prazo ou atrasados, fornecendo uma medida clara da adesão do processo aos cronogramas. Por que é importante Define o acordo de nível de serviço (SLA) ou prazo para o lançamento, permitindo o cálculo de KPIs de desempenho pontual. Onde obter Este pode não ser um campo padrão. Pode ser derivado de regras de negócio com base na data de criação, período contábil ou categoria do lançamento. Exemplos 2023-10-312023-11-302024-01-05
	É Retrabalho IsRework	Um sinalizador calculado que é verdadeiro se o lançamento contábil passou por um ciclo de rejeição e correção.
Descrição Este atributo booleano é calculado para identificar casos que passaram por retrabalho. Geralmente é marcado como 'verdadeiro' para qualquer atividade que siga um evento 'Lançamento Contábil Rejeitado', como 'Lançamento Corrigido e Reenviado'.\n\nO campo 'É Retrabalho' é um atributo poderoso para análise, pois permite quantificar facilmente o volume e o impacto dos loops de retrabalho. Ele apoia diretamente o KPI 'Taxa Média de Retrabalho de Lançamentos' e ajuda a comparar o fluxo e a duração dos casos com retrabalho em relação aos que são processados corretamente na primeira vez. Por que é importante Sinaliza diretamente casos que passaram por loops de retrabalho ineficientes, facilitando a quantificação da frequência e do impacto de falhas no processo. Onde obter Isso não está disponível no sistema de origem. É calculado dentro da ferramenta de Process Mining analisando a sequência de atividades para cada caso. Exemplos verdadeirofalse
	End Time EndTime	O carimbo de data/hora (timestamp) que indica quando uma atividade específica foi concluída.
Descrição O Horário de Término marca a conclusão de uma atividade. Enquanto o Horário de Início registra o começo, o Horário de Término fornece o ponto final, permitindo o cálculo preciso do tempo de processamento dessa etapa específica.\n\nIsso é essencial para calcular os tempos de processamento das atividades, uma métrica central para identificar gargalos e medir a eficiência dos recursos. Por exemplo, a diferença entre o Horário de Término e o Horário de Início da atividade 'Lançamento Contábil Revisado' fornece o tempo real que um revisor dedicou à tarefa. Por que é importante Permite calcular a duração real ou tempo de processamento de cada atividade, fundamental para identificar problemas de eficiência. Onde obter Assim como o Horário de Início, este costuma ser encontrado em tabelas de trilha de auditoria ou pode ser inferido a partir do Horário de Início da atividade subsequente no processo. Exemplos 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Está no Prazo IsOnTimePosting	Um sinalizador calculado que é verdadeiro se o lançamento foi efetivado na data prevista ou antes dela.
Descrição Este atributo booleano é desenvolvido comparando o timestamp da atividade 'Lançamento Contábil Contabilizado' com a 'Data Alvo de Contabilização'. Se a contabilização ocorrer na data alvo ou antes, o valor é 'verdadeiro'; caso contrário, é 'falso'.\n\nEste atributo apoia diretamente o KPI 'Taxa de Contabilização de Lançamentos no Prazo', simplificando o cálculo. Ele permite filtrar e analisar facilmente os lançamentos atrasados para identificar as causas comuns dos atrasos, como categorias específicas de lançamentos ou aprovadores. Por que é importante Oferece um resultado binário claro para o desempenho da contabilização, simplificando a análise das taxas de pontualidade e das causas raiz dos atrasos. Onde obter Este atributo é calculado pela ferramenta de Process Mining. Requer o atributo 'TargetPostingDate' e o timestamp da atividade 'Lançamento Contábil Contabilizado'. Exemplos verdadeirofalse
	Indicador de Estorno ReversalIndicator	Um sinalizador que indica se o lançamento contábil é um estorno de outro lançamento.
Descrição Este atributo booleano identifica lançamentos contábeis criados para estornar um lançamento postado anteriormente. Os estornos são um tipo específico de lançamento que muitas vezes seguem um processo distinto e, às vezes, problemático.\n\nAnalisar este indicador é fundamental para apoiar o Dashboard 'Desempenho do Processo de Estorno de Lançamento'. Ele permite isolar os processos de estorno para medir sua frequência, causas e tempos de ciclo, ajudando a identificar problemas subjacentes nos lançamentos originais que exigem o estorno. Por que é importante Ajuda a isolar e analisar o processo de estorno, que costuma indicar erros ou problemas na transação original. Onde obter Isso pode ser uma flag específica na tabela GL_JE_HEADERS, como ACCRUAL_REV_FLAG, ou identificado através de links para o lançamento original que está sendo estornado. Exemplos verdadeirofalse
	Moeda CurrencyCode	O código da moeda para o valor do lançamento contábil, como BRL, USD ou EUR.
Descrição O Código da Moeda especifica a moeda dos valores financeiros no lançamento contábil. Isso é essencial para organizações multinacionais que operam com diversas moedas.\n\nEste atributo garante que os valores financeiros sejam interpretados corretamente. Ele permite filtrar por moeda e é um campo necessário ao realizar qualquer análise que envolva a comparação ou agregação de valores monetários em diferentes regiões. Por que é importante Fornece o contexto necessário para quaisquer valores financeiros, garantindo a interpretação correta e permitindo análises específicas para diferentes moedas. Onde obter Disponível na tabela GL_JE_HEADERS, no campo CURRENCY_CODE. Exemplos USDEURGBPJPY
	Nome do Razão LedgerName	O nome do livro razão onde o lançamento contábil é registrado.
Descrição O Nome do Livro Razão identifica o livro específico ao qual o lançamento contábil pertence. Em organizações com múltiplas entidades legais ou requisitos de relatórios, pode haver vários livros, como um livro principal para a contabilidade corporativa e livros secundários para relatórios estatutários locais.\n\nEste atributo é essencial para filtrar e comparar processos entre diferentes entidades legais ou unidades de negócio. Ele garante que as análises sejam conduzidas dentro do contexto organizacional correto, o que é particularmente importante para a conformidade financeira e relatórios. Por que é importante Permite filtrar e comparar a análise de processos entre diferentes entidades legais ou estruturas contábeis, o que é vital para grandes empresas. Onde obter Encontrado na tabela GL_JE_HEADERS, geralmente via LEDGER_ID, que pode ser unido à GL_LEDGERS para obter o nome. Exemplos Livro Razão Principal dos EUALivro Razão Estatutário do Reino UnidoLivro de Consolidação Global
	Período Contábil AccountingPeriod	O período fiscal no qual o lançamento contábil é postado, como 'Jan-24'.
Descrição O Período Contábil especifica o período financeiro em que a transação é reconhecida. Isso é fundamental para todos os relatórios e análises financeiras.\n\nNo Process Mining, este atributo é crucial para a análise de tendências. Ele permite comparar o desempenho do processo, como tempos de ciclo ou taxas de rejeição, entre diferentes meses ou trimestres. Isso ajuda a identificar efeitos de sazonalidade, como o aumento da carga de trabalho durante o fechamento mensal, e a medir o impacto das melhorias no processo ao longo do tempo. Por que é importante Permite a análise de tendências de KPIs ao longo do tempo, ajudando a medir melhorias e identificar padrões sazonais, como a pressão do fechamento mensal. Onde obter Disponível na tabela GL_JE_HEADERS, no campo PERIOD_NAME. Exemplos Jan-24Fev-24Mar-24
	Status da Efetivação PostingStatus	O status atual de contabilização do lançamento contábil, por exemplo, 'Não Contabilizado' ou 'Contabilizado'.
Descrição Este atributo reflete o estado atual do lançamento contábil em relação à sua contabilização no razão geral. É um indicador chave de onde um lançamento se encontra em seu ciclo de vida, especialmente para casos em andamento.\n\nO Status da Contabilização é crucial para o Dashboard 'Rastreador de Status de Lançamento Contábil em Tempo Real', fornecendo uma visão instantânea de todos os lançamentos ativos. Ajuda a monitorar o acúmulo de lançamentos não contabilizados e a identificar atrasos nos estágios finais do processo. Por que é importante Indica o estado atual de um lançamento, essencial para monitorar pendências e o status de entradas em andamento. Onde obter Disponível na tabela GL_JE_HEADERS, geralmente na coluna STATUS ou POSTING_STATUS. Exemplos LançadoNão ContabilizadoErro
	Tempo de Aprovação JournalApprovalTime	A duração calculada entre o envio do lançamento e a decisão final de aprovação ou rejeição.
Descrição Esta métrica mede o tempo decorrido desde o envio de um lançamento para aprovação até que ele seja aprovado ou rejeitado. É uma medida crítica da eficiência do workflow de aprovação.\n\nO Tempo de Aprovação de Lançamento é um insumo direto para o KPI 'Tempo Médio de Aprovação de Lançamentos' e para o Dashboard 'Gargalos na Aprovação de Lançamentos Contábeis'. Analisar essa duração ajuda a identificar atrasos na cadeia de aprovação, sejam eles causados por aprovadores específicos, departamentos ou tipos de lançamento. Por que é importante Mede diretamente a eficiência do workflow de aprovação, que costuma ser a maior fonte de atrasos no processo. Onde obter Esta é uma métrica calculada dentro da ferramenta de Process Mining. É a diferença de tempo entre os eventos 'Lançamento Enviado para Aprovação' e 'Lançamento Contábil Aprovado' ou 'Lançamento Contábil Rejeitado'. Exemplos P2DT4H30MPT8HP5D
	Tempo de Ciclo Ponta a Ponta EndToEndCycleTime	A duração total calculada desde a criação de um lançamento contábil até sua conciliação final.
Descrição Esta métrica representa o tempo total que um lançamento contábil leva em todo o processo, desde o primeiríssimo evento 'Lançamento Contábil Criado' até o evento final 'Lançamento Contábil Conciliado'. Ela fornece uma visão holística do desempenho do processo.\n\nEste é um KPI principal para medir a eficiência geral do processo. É usado em Dashboards de tendência para acompanhar o impacto das iniciativas de melhoria ao longo do tempo e fornece uma linha de base contra a qual todas as mudanças no processo podem ser medidas. Por que é importante Fornece uma medida de alto nível da saúde e eficiência de todo o processo, sendo uma métrica fundamental para relatórios executivos. Onde obter Esta métrica é calculada pela plataforma de Process Mining como a diferença de tempo entre os timestamps do primeiro e do último evento de cada caso. Exemplos P10DT5HP4DT12HP22D

Obrigatório Recomendado Opcional

Record to Report - Atividades de Lançamento Contábil

Estas são as etapas principais do processo e os marcos a serem capturados em seu Event Log para uma descoberta de processo precisa no Lançamento Contábil.

5 Recomendado 7 Opcional

	Atividade	Descrição
	Lançamento Contábil Aprovado	O aprovador designado aprovou formalmente o lançamento contábil, confirmando sua precisão e validade. Esta é a etapa final no workflow de aprovação, liberando o caminho para a contabilização.
Por que é importante Este marco sinaliza o fim do processo de aprovação. O tempo entre o envio e a aprovação é um KPI fundamental para medir a eficiência do workflow e identificar gargalos na aprovação. Onde obter Este evento é inferido de uma mudança de status na tabela GL_JE_HEADERS, onde o APPROVAL_STATUS_CODE é atualizado para 'APPROVED'. As tabelas de workflow contêm a identidade do aprovador e o timestamp. Captura Rastreie o timestamp de quando o APPROVAL_STATUS_CODE em GL_JE_HEADERS muda para 'APPROVED'. Tipo de evento inferred
	Lançamento Contábil Conciliado	O lançamento contábil foi conciliado e compensado durante um processo de conciliação de contas de final de período. Isso confirma que a transação está alinhada com outros dados financeiros, como extratos bancários.
Por que é importante Esta atividade serve como um ponto final real para o ciclo de vida do lançamento. Medir o tempo desde a contabilização até a conciliação é um KPI fundamental para avaliar a eficiência do processo de fechamento financeiro. Onde obter Este evento é normalmente capturado no Oracle Financial Consolidation and Close Cloud Service (FCCS) ou no Account Reconciliation Cloud Service (ARCS), e não no próprio Razão Geral. É inferido de uma mudança de status no registro de conciliação vinculado ao lançamento. Captura Correlacione dados de lançamentos com atualizações de status de conciliação das tabelas ARCS ou FCCS. Tipo de evento inferred
	Lançamento Contábil Criado	Esta atividade marca o início do processo de lançamento contábil. Ela representa o momento em que um usuário cria um novo cabeçalho de lançamento e começa a inserir os dados, mas antes de ser enviado para qualquer revisão ou aprovação.
Por que é importante Este é o principal evento de início do processo. Analisar o tempo desta atividade até as etapas subsequentes ajuda a medir a eficiência inicial da entrada de dados e o tempo de ciclo geral do processo. Onde obter Este evento é normalmente inferido a partir do timestamp da data de criação na tabela GL_JE_HEADERS para um ID de Lançamento Contábil específico. O usuário que criou o registro também está disponível nesta tabela. Captura Use o CREATION_DATE da tabela GL_JE_HEADERS. Tipo de evento inferred
	Lançamento Contábil Efetivado	Os dados financeiros do lançamento contábil foram registrados com sucesso no Razão Geral (General Ledger). Os débitos e créditos agora estão refletidos nos saldos das contas.
Por que é importante Este é um marco crítico que representa a entrada do lançamento no registro financeiro oficial. É essencial para medir a taxa de contabilização no prazo e o tempo total da criação até a contabilização. Onde obter Isso é inferido de uma mudança de status na tabela GL_JE_HEADERS, onde o campo STATUS muda para 'P' (Posted). A tabela GL_JE_BATCHES também possui um status de contabilização. Captura Rastreie o timestamp de quando o STATUS em GL_JE_HEADERS muda para 'P'. Tipo de evento inferred
	Lançamento Submetido para Aprovação	Esta atividade ocorre quando o usuário envia formalmente o lançamento contábil concluído para o workflow de aprovação. Ela altera o estado do lançamento de rascunho ou incompleto para pendente de aprovação.
Por que é importante Este é um marco crítico que inicia o cronômetro para medir os tempos do ciclo de aprovação e identificar gargalos. Ele separa a fase de entrada de dados da fase de revisão e aprovação. Onde obter Este evento é inferido de uma mudança de status na tabela GL_JE_HEADERS, especificamente quando o APPROVAL_STATUS_CODE muda para um valor como 'REQUIRED' ou 'INITIATED'. O timestamp da data de envio também pode ser registrado. Captura Rastreie o timestamp de quando o APPROVAL_STATUS_CODE em GL_JE_HEADERS muda para indicar o envio. Tipo de evento inferred
	Documentação de Suporte Anexada	Representa a ação de anexar documentos de suporte, como faturas ou planilhas, ao lançamento contábil. Isso costuma ser feito para fornecer contexto e evidências para auditores e aprovadores.
Por que é importante Rastrear esta atividade ajuda a entender se os atrasos são causados por falta de documentação. Também fornece insights sobre a conformidade e a integridade dos lançamentos contábeis antes que eles entrem no workflow de aprovação. Onde obter Isso pode ser difícil de rastrear como um evento discreto. Pode ser inferido a partir de timestamps em tabelas de anexos, como FND_ATTACHED_DOCUMENTS, vinculadas ao registro do lançamento contábil em GL_JE_HEADERS. Captura Inferido a partir da data de criação dos registros em FND_ATTACHED_DOCUMENTS vinculados ao lançamento. Tipo de evento inferred
	Efetivação do Lançamento Iniciada	O processo de contabilização do lançamento aprovado no Razão Geral foi iniciado. Isso pode ser uma etapa automatizada ou manual que coloca o lançamento em uma fila para ser processado pelo programa de contabilização.
Por que é importante Esta atividade separa a aprovação do processo técnico de contabilização. Atrasos entre a aprovação e o início da contabilização podem indicar problemas de agendamento ou restrições de recursos no motor de contabilização. Onde obter Isso pode ser inferido de mudanças de status na tabela GL_JE_BATCHES, ou pelo horário de envio da solicitação simultânea de contabilização associada ao lote de lançamentos. Captura Identifica o horário de submissão do programa de Efetivação do Razão Geral para o lote específico. Tipo de evento inferred
	Efetivação Verificada	Uma etapa de verificação pós-lançamento em que um usuário ou sistema confirma se os saldos estão corretos. Geralmente é um controle manual.
Por que é importante Analisar esta atividade ajuda a entender o tempo gasto em controles manuais pós-efetivação, revelando oportunidades para automação de verificações. Onde obter É improvável que este seja um evento explícito no Oracle Fusion. Ele precisaria ser inferido de outras ações, como um usuário executando um relatório específico ou a atualização de um campo de status personalizado, o que não é padrão. Captura Requer lógica personalizada, como o rastreamento do tempo de execução de relatórios de verificação ou atualizações em um campo flexível descritivo (flexfield). Tipo de evento inferred
	Estorno de Lançamento Processado	Um lançamento de estorno foi criado e efetivado para anular o impacto financeiro do original em um período subsequente. Comum em apropriações (accruals).
Por que é importante Rastrear os estornos ajuda a identificar os tipos de lançamentos que são estornados com frequência e a analisar a eficiência do próprio processo de estorno. Isso pode indicar problemas na gestão de provisões. Onde obter Isso é inferido ao identificar um novo lançamento contábil que está explicitamente vinculado ao original como seu estorno. A tabela GL_JE_HEADERS possui campos como REVERSAL_PERIOD e REVERSAL_FLAG para identificar e vincular esses lançamentos. Captura Identifica a data de criação e efetivação do novo lançamento contábil que referencia o original como estornado. Tipo de evento inferred
	Lançamento Contábil Rejeitado	O aprovador revisou o lançamento e o rejeitou por erros ou falta de documentos. Isso devolve o processo ao criador para correção.
Por que é importante Esta atividade é crucial para analisar loops de retrabalho, taxas de rejeição e métricas de acerto na primeira tentativa (First-Time-Right). Uma alta frequência de rejeições aponta para problemas na qualidade dos dados ou no treinamento. Onde obter Isso é inferido de uma mudança de status na tabela GL_JE_HEADERS quando o APPROVAL_STATUS_CODE é atualizado para 'REJECTED'. O histórico do workflow registrará o usuário e o timestamp desta ação. Captura Rastreie o timestamp de quando o APPROVAL_STATUS_CODE em GL_JE_HEADERS é definido como 'REJECTED'. Tipo de evento inferred
	Lançamento Contábil Revisado	Etapa de revisão que ocorre antes ou durante a aprovação formal. Representa a conferência por um colega ou gestor para garantir conformidade antes do aprovador final.
Por que é importante Isolar esta atividade ajuda a diferenciar tempos de revisão preliminar e aprovação final. Pode revelar gargalos ocultos em etapas informais, mas demoradas. Onde obter Esta pode ser uma etapa explícita em um workflow de aprovação de vários estágios, capturada em tabelas de histórico de workflow. Se for informal, não será capturada. Pode ser inferida se uma ação específica do usuário for registrada antes da decisão final de aprovação. Captura Analise as tabelas de histórico de workflow para encontrar etapas de revisão ou aprovação intermediária antes do status final 'Aprovado'. Tipo de evento inferred
	Lançamento Corrigido e Reenviado	Após a rejeição, o criador faz as correções e reenvia para aprovação. Esta atividade inicia um novo ciclo de aprovação para o mesmo lançamento.
Por que é importante Rastrear o retrabalho é essencial para entender a ineficiência do processo. Esta atividade, combinada com 'Lançamento Contábil Rejeitado', permite medir o tempo e a frequência do retrabalho. Onde obter Este é um evento subsequente de 'Lançamento Enviado para Aprovação' para um lançamento que estava anteriormente em estado 'REJEITADO'. É identificado pela análise da sequência de mudanças de status para um único ID de Lançamento Contábil. Captura Identifica o timestamp de um evento de submissão que ocorre após um evento de rejeição para o mesmo ID de caso. Tipo de evento inferred

Recomendado Opcional

Guias de Extração

Como obter os seus dados do Oracle Fusion Financials

Etapas

Acesse Relatórios e Análises: Entre no Oracle Fusion Financials. No menu Navigator, vá em Ferramentas e selecione Relatórios e Análises. Este é o centro de gestão de todos os relatórios.
Crie um Modelo de Dados no BI Publisher: Para extrair o event log, criar o Modelo de Dados diretamente é mais eficiente que o OTBI, permitindo o uso de SQL personalizado com UNION ALL. Clique em 'Procurar Catálogo', escolha uma pasta e vá em Criar > Modelo de Dados.
Defina o Dataset: No editor, clique no '+' para adicionar um novo Dataset e escolha 'Consulta SQL'. Nomeie como 'JournalEventLog'.
Insira o SQL: Escolha 'Oracle BI EE' como Fonte de Dados. Copie o script SQL da seção abaixo e cole na área de texto. A consulta unifica todas as atividades e atributos necessários.
Defina Parâmetros: A interface detectará automaticamente parâmetros como :start_date, :end_date e :ledger_name. Configure os tipos de dados (Data ou Texto) para permitir execuções flexíveis.
Crie o Relatório: Após salvar o modelo, volte ao catálogo e clique em Criar > Relatório. No assistente, selecione 'Usar Modelo de Dados Existente' e aponte para o que você criou.
Configure o Layout: Escolha o layout 'Tabela'. É fundamental arrastar todas as colunas para garantir que constem na exportação. Não é preciso formatação visual complexa.
Defina CSV como Saída Padrão: No editor do relatório, acesse 'Exibir uma Lista'. Em 'Formatos de Saída', marque apenas 'CSV' para simplificar o agendamento. Salve.
Agende a Extração: No catálogo, clique em 'Mais' no relatório e depois em 'Agendar'. Configure a frequência (ex: diária ou semanal).
Configure Entrega: Na guia 'Saída' do agendamento, selecione seu relatório e o formato 'CSV'. Na guia 'Destino', você pode configurar o envio para um servidor UCM ou SFTP externo para automação.
Prepare os Dados: Após a execução, obtenha o CSV no destino. Verifique se os cabeçalhos coincidem com o padrão ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. O arquivo está pronto para upload.

Configuração

Fonte de Dados: A consulta deve ser executada na fonte de dados 'Oracle BI EE' dentro do BI Publisher, que se conecta às visões do banco de dados transacional subjacente do OTBI.
Áreas de Assunto (referência): A lógica da consulta baseia-se em dados da área 'General Ledger - Journals Real Time'. Também integra dados de 'HCM - Workforce Management - Worker Assignment Real Time' para detalhes de usuários e áreas de workflow para histórico de aprovações.
Filtro de Período: É fundamental filtrar os dados para um período gerenciável. A consulta inclui os parâmetros :start_date e :end_date. Recomendamos extrair de 3 a 6 meses para a análise inicial. O filtro é aplicado à data de criação do lançamento.
Filtro de Ledger: Use o parâmetro :ledger_name para limitar a extração a um livro-razão (ledger) primário específico. Extrair todos simultaneamente pode gerar arquivos excessivamente grandes e problemas de performance.
Pré-requisitos: O usuário que criar o relatório deve ter funções de BI adequadas, como 'BI Administrator' ou 'BI Author'. Além disso, o perfil de segurança de dados deve permitir acesso aos ledgers e unidades de negócio consultados.
Agendamento: Para melhor desempenho e evitar impactos no sistema, agende a extração para horários de baixo uso, como durante a madrugada.

a Consulta de Exemplo config

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Etapas

Acesse o BI Publisher: Entre no Oracle Fusion Financials. No menu Navigator, vá em Ferramentas e selecione Relatórios e Análises. Isso abrirá o catálogo de Business Intelligence.
Crie um Novo Modelo de Dados: No catálogo de BI, clique em Criar e selecione Modelo de Dados para abrir o editor.
Defina o Conjunto de Dados da Consulta SQL: No editor, clique no ícone de mais (+) na guia Diagrama e escolha Consulta SQL. Dê um nome ao conjunto (ex: ProcessMind_JE_EventLog). Selecione a Fonte de Dados adequada (geralmente FUSIONDB). Cole a consulta SQL completa fornecida na área de texto.
Defina os Parâmetros: A consulta usa parâmetros de data (p_start_date e p_end_date), que o BI Publisher detectará automaticamente. Configure-os como tipo Texto e use rótulos claros como 'Data Inicial (AAAA-MM-DD)' e 'Data Final (AAAA-MM-DD)'.
Salve o Modelo de Dados: Clique em OK e salve o modelo em uma pasta apropriada, como Shared Folders/Custom/ProcessMining.
Crie o Relatório: Clique no botão Criar Relatório no canto superior direito do editor de modelo de dados.
Configure o Layout: No assistente, escolha usar o modelo de dados atual e selecione o layout 'Tabela'. Arraste todas as colunas para a área de layout e desmarque a opção 'Mostrar Linha de Totais Gerais'.
Salve o Relatório: Salve-o na mesma pasta do modelo de dados com um nome descritivo como 'Relatório de Event Log de Lançamentos Contábeis'.
Defina o Formato de Saída Padrão: Edite o relatório e, na guia 'Visualização', em 'Formatos de Saída', garanta que o CSV esteja selecionado e definido como padrão para facilitar o uso direto.
Executar e Exportar: Abra o relatório, insira as datas solicitadas e clique em Aplicar. Após a execução, use o botão Exportar e escolha o formato CSV para baixar o arquivo do event log.
Prepare para o Upload: Abra o CSV baixado e verifique se os cabeçalhos das colunas coincidem com os atributos esperados (JournalEntryId, ActivityName, EventTime, etc.) antes de fazer o upload para a plataforma ProcessMind.

Configuração

Pré-requisitos: O usuário deve ter privilégios de segurança de dados para acessar o General Ledger, como a função de Contador Geral ou função de BI personalizada. O acesso ao BI Publisher também é obrigatório.
Fonte de Dados: O Modelo de Dados do BI Publisher deve ser configurado para usar a conexão de banco de dados FUSIONDB.
Parâmetros de Período: A consulta utiliza p_start_date e p_end_date para controlar a janela de extração. Recomendamos iniciar com um período de 3 a 6 meses para garantir a performance.
Filtros de Relatório: Em grandes organizações, é altamente recomendável adicionar filtros diretamente na cláusula WHERE da expressão de tabela comum JournalHeaders. Filtrar por LEDGER_ID ou LEGAL_ENTITY_ID é essencial para gerenciar o volume de dados.
Considerações de Performance: Executar esta consulta em bases de produção volumosas pode consumir recursos significativos. Agende o relatório para horários de folga para minimizar o impacto no sistema.
Formato de Saída: O relatório deve ser configurado para o formato CSV. Isso garante uma estrutura limpa para a ingestão em ferramentas de Process Mining.

a Consulta de Exemplo sql

WITH JournalHeaders AS (
    SELECT
        gjh.JE_HEADER_ID,
        gjh.NAME AS JOURNAL_NAME,
        gjh.LEDGER_ID,
        gjh.JE_CATEGORY,
        gjh.JE_SOURCE,
        gjh.STATUS,
        gjh.APPROVAL_STATUS_CODE,
        gjh.CREATED_BY,
        gjh.CREATION_DATE,
        gjh.LAST_UPDATED_BY,
        gjh.LAST_UPDATE_DATE,
        gjh.POSTED_DATE,
        gjh.ACCRUAL_REV_JE_HEADER_ID,
        gjh.ACCRUAL_REV_PERIOD_NAME,
        gjs.USER_JE_SOURCE_NAME,
        gjc.USER_JE_CATEGORY_NAME,
        (SELECT SUM(NVL(gjl.ACCOUNTED_DR, 0)) FROM GL_JE_LINES gjl WHERE gjl.JE_HEADER_ID = gjh.JE_HEADER_ID) AS JOURNAL_AMOUNT
    FROM
        GL_JE_HEADERS gjh
    JOIN
        GL_JE_SOURCES_TL gjs ON gjh.JE_SOURCE = gjs.JE_SOURCE_NAME AND gjs.LANGUAGE = USERENV('LANG')
    JOIN
        GL_JE_CATEGORIES_TL gjc ON gjh.JE_CATEGORY = gjc.JE_CATEGORY_NAME AND gjc.LANGUAGE = USERENV('LANG')
    WHERE
        gjh.CREATION_DATE BETWEEN TO_TIMESTAMP(:p_start_date || ' 00:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF') AND TO_TIMESTAMP(:p_end_date || ' 23:59:59.999', 'YYYY-MM-DD HH24:MI:SS.FF')
        AND gjh.ACTUAL_FLAG = 'A'
        -- Recommended: Add a filter for your specific ledger(s) to improve performance
        -- AND gjh.LEDGER_ID IN ([Your Ledger ID])
),
UserDepartment AS (
    -- This subquery is an example. The join logic to find a user's department may need to be adjusted
    -- based on your specific Oracle HCM configuration (e.g., using different assignment types or tables).
    SELECT 
        pu.USERNAME, 
        org.NAME as Department
    FROM PER_USERS pu
    LEFT JOIN PER_ALL_ASSIGNMENTS_F asg ON pu.PERSON_ID = asg.PERSON_ID 
        AND asg.ASSIGNMENT_TYPE IN ('E', 'C') 
        AND asg.PRIMARY_FLAG = 'Y'
        AND SYSDATE BETWEEN asg.EFFECTIVE_START_DATE AND asg.EFFECTIVE_END_DATE
    LEFT JOIN HR_ALL_ORGANIZATION_UNITS_F_VL org ON asg.ORGANIZATION_ID = org.ORGANIZATION_ID
        AND SYSDATE BETWEEN org.EFFECTIVE_START_DATE AND org.EFFECTIVE_END_DATE
    WHERE pu.USERNAME IS NOT NULL
)
-- 1. Journal Entry Created
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.CREATED_BY = ud.USERNAME

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    TO_NUMBER(fad.PK1_VALUE) AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    fad.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    FND_ATTACHED_DOCUMENTS fad
JOIN
    JournalHeaders jh ON fad.PK1_VALUE = TO_CHAR(jh.JE_HEADER_ID)
LEFT JOIN UserDepartment ud ON fad.CREATED_BY = ud.USERNAME
WHERE
    fad.ENTITY_NAME = 'GL_JE_HEADERS'

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')

UNION ALL

-- 4. Journal Entry Reviewed (Placeholder)
-- This activity requires custom logic based on your approval workflow configuration.
-- The query below is a placeholder and may not return any data without customization.
-- It assumes a review happens if the approval status is updated but not yet approved or rejected.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    -- Rejection Reason is not a standard field. This might be found in workflow tables.
    '[Configure based on your system]' AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'REJECTED'

UNION ALL

-- 6. Journal Corrected and Resubmitted
-- This logic assumes a resubmission is an update that occurs after a rejection.
-- A more precise method would involve analyzing workflow history, which is complex.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')
    AND jh.JE_HEADER_ID IN (SELECT h.JE_HEADER_ID FROM GL_JE_HEADERS h WHERE h.APPROVAL_STATUS_CODE = 'REJECTED')

UNION ALL

-- 7. Journal Entry Approved
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'APPROVED'

UNION ALL

-- 8. Journal Posting Initiated
-- The exact initiation time is not stored. We infer it as 5 minutes before the final posted date.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    (jh.POSTED_DATE - INTERVAL '5' MINUTE) AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    -- Posting is often a system process, so user might not be available.
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 10. Posting Verified (Placeholder)
-- This is a manual control activity not tracked by default. This query must be customized.
-- It assumes a descriptive flexfield named 'POSTING_VERIFIED_DATE' on GL_JE_HEADERS exists.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 11. Journal Entry Reconciled (Placeholder)
-- Reconciliation is typically done in other modules. This query must be customized.
-- It assumes a custom table or field indicates when a journal is reconciled.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    rev_jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
JOIN
    GL_JE_HEADERS rev_jh ON jh.ACCRUAL_REV_JE_HEADER_ID = rev_jh.JE_HEADER_ID
LEFT JOIN UserDepartment ud ON rev_jh.CREATED_BY = ud.USERNAME
WHERE
    jh.ACCRUAL_REV_JE_HEADER_ID IS NOT NULL
    AND rev_jh.STATUS = 'P'
ORDER BY
    "JournalEntryId", "EventTime"

Etapas

Pré-requisitos: Tenha o Python 3 instalado com as bibliotecas requests e pandas. Você precisará de acesso ao Oracle Fusion Financials com permissão para a API REST de General Ledger Journals, além da URL da instância, usuário e senha.
Configuração do Script: Crie um arquivo Python e importe: requests, json, pandas e datetime.
Variáveis: Defina no script as credenciais, URL base e os parâmetros de extração (datas de início e fim).
Autenticação: O script utiliza Autenticação Básica. A biblioteca requests codifica o usuário e a senha no cabeçalho da requisição.
Função de Chamada de API: Crie uma função para as requisições que gerencie a paginação via parâmetros offset e limit, fazendo chamadas sucessivas até coletar todos os registros do período.
Construção da Consulta: Use o parâmetro q na API para filtrar por LastUpdateDate. Isso permite extrações específicas, ex: LastUpdateDate entre '2023-01-01' e '2023-03-31'.
Início da Coleta: Chame a função apontando para o endpoint .../fscmRestApi/resources/11.13.18.05/journals para obter a lista de lançamentos.
Transformação de Dados: Itere sobre os lançamentos. Para cada um, gere linhas de eventos para as atividades (Journal Entry Created, Journal Entry Approved, etc.), usando os campos de data e status da API (CreationDate, PostedDate, ApprovalStatus, etc.).
Estrutura do Event Log: Armazene cada linha de evento como um dicionário em uma lista, formando os dados brutos.
Criação do DataFrame: Converta essa lista em um DataFrame do Pandas para facilitar a manipulação.
Ajuste de Colunas: Selecione e renomeie as colunas conforme o esquema do ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, etc.
Exportação: Salve o DataFrame final em um arquivo CSV para upload e análise no ProcessMind.

Configuração

Credenciais: É necessário um usuário e senha válidos do Oracle Fusion para a Autenticação Básica.
URL da Instância: A URL base da sua instância do Oracle Fusion Financials é necessária para construir o endpoint da API (ex: https://[sua-instancia].fa.us2.oraclecloud.com).
Endpoint da API: O script utiliza o endpoint fscmRestApi/resources/11.13.18.05/journals para buscar dados do Razão Geral (General Ledger).
Filtro de Período: O script deve ser configurado com start_date e end_date para limitar o escopo da extração. Para uma análise inicial, recomendamos um período de 3 a 6 meses. Para uso contínuo, configure cargas incrementais diárias ou semanais.
Limite de Paginação: O parâmetro limit controla quantos registros são buscados por chamada de API. Um valor entre 200 e 500 costuma ser eficiente, equilibrando o número de chamadas com o tamanho de cada resposta.
Funções Necessárias no Oracle: A conta de usuário deve ter uma função com as permissões necessárias para ler dados de lançamentos via API REST, como General Accountant ou uma função personalizada equivalente.

a Consulta de Exemplo python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance details
FUSION_URL = class="hl-string">"https://[your-instance].fa.us2.oraclecloud.com"
USERNAME = class="hl-string">"[your-username]"
PASSWORD = class="hl-string">"[your-password]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
PAGE_LIMIT = 500 class=class="hl-string">"hl-comment"># Number of records per API call

def get_all_journals(base_url, user, password, start_date, end_date):
    class="hl-string">"""Fetches all journals from the Oracle Fusion REST API within a date range, handling pagination."""
    all_journals = []
    offset = 0
    has_more = True
    
    api_url = fclass="hl-string">"{base_url}/fscmRestApi/resources/11.13.18.05/journals"
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourcecollection+json'
    }
    
    query_filter = fclass="hl-string">"LastUpdateDate between '{start_date}' and '{end_date}'"
    
    while has_more:
        params = {
            class="hl-string">'q': query_filter,
            class="hl-string">'onlyData': class="hl-string">'true',
            class="hl-string">'limit': PAGE_LIMIT,
            class="hl-string">'offset': offset,
            class="hl-string">'fields': class="hl-string">'JeHeaderId,CreatedBy,CreationDate,LastUpdatedBy,LastUpdateDate,PostedDate,ApprovalStatus,ActualFlag,DefaultEffectiveDate,Description,JeCategory,JeSource,PeriodName,TotalDebit,ReversalDate,ReversalPeriodName,ExternalReference,attachments'
        }
        
        print(fclass="hl-string">"Fetching records from offset {offset}...")
        try:
            response = requests.get(api_url, auth=(user, password), headers=headers, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            
            journals = data.get(class="hl-string">'items', [])
            all_journals.extend(journals)
            
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += PAGE_LIMIT

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            has_more = False

    return all_journals

def transform_to_event_log(journals):
    class="hl-string">"""Transforms the raw journal data into a structured event log."""
    event_log = []
    extraction_timestamp = datetime.now(timezone.utc).isoformat()

    for jrnl in journals:
        journal_id = jrnl.get(class="hl-string">'JeHeaderId')
        created_by = jrnl.get(class="hl-string">'CreatedBy')
        last_updated_by = jrnl.get(class="hl-string">'LastUpdatedBy')
        approval_status = jrnl.get(class="hl-string">'ApprovalStatus')
        rejection_reason_text = class="hl-string">"Rejected per workflow comments" if approval_status == class="hl-string">'REJECTED' else None

        class=class="hl-string">"hl-comment"># 1. Journal Entry Created
        if jrnl.get(class="hl-string">'CreationDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'CreationDate'),
                class="hl-string">'UserName': created_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached (Approximation)
        if jrnl.get(class="hl-string">'attachments') and len(jrnl[class="hl-string">'attachments']) > 0:
             event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class=class="hl-string">"hl-comment"># Approximation: uses last update date
                class="hl-string">'UserName': last_updated_by, 
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 3, 4, 5, 6, 7: Approval Workflow Events (Inferred from final status)
        class=class="hl-string">"hl-comment"># Note: This block infers events. For a more detailed history, workflow-specific APIs would be needed.
        if approval_status in [class="hl-string">'IN_PROCESS', class="hl-string">'REQUIRED']:
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Submitted For Approval',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'REJECTED':
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Rejected',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by, class=class="hl-string">"hl-comment"># Approver is often the last updater
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': rejection_reason_text,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            class=class="hl-string">"hl-comment"># A resubmission is assumed if a rejected journal is updated again
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Corrected and Resubmitted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': created_by, class=class="hl-string">"hl-comment"># Typically the creator corrects it
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'APPROVED':
            class=class="hl-string">"hl-comment"># class="hl-string">'Journal Entry Reviewed' is often an implicit part of approval
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reviewed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Approved',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 8, 9: Posting Events
        if jrnl.get(class="hl-string">'PostedDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Posting Initiated',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'), class=class="hl-string">"hl-comment"># Assuming initiation is same as posted time
                class="hl-string">'UserName': class="hl-string">'System', class=class="hl-string">"hl-comment"># Posting is often a system process
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Posted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'),
                class="hl-string">'UserName': class="hl-string">'System',
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        
        class=class="hl-string">"hl-comment"># 12. Journal Reversal Processed
        if jrnl.get(class="hl-string">'ReversalDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Reversal Processed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'ReversalDate'),
                class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># Activities not directly available from this API, added as placeholders for potential enrichment
        class=class="hl-string">"hl-comment"># Posting Verified, Journal Entry Reconciled

    return pd.DataFrame(event_log)

class=class="hl-string">"hl-comment"># --- Main Execution ---
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Oracle Fusion Journal Entry extraction...")
    raw_journals = get_all_journals(FUSION_URL, USERNAME, PASSWORD, START_DATE, END_DATE)
    
    if raw_journals:
        print(fclass="hl-string">"Successfully extracted {len(raw_journals)} journal records.")
        event_log_df = transform_to_event_log(raw_journals)
        
        if not event_log_df.empty:
            class=class="hl-string">"hl-comment"># Save to CSV
            output_filename = fclass="hl-string">"oracle_fusion_journal_events_{START_DATE}_to_{END_DATE}.csv"
            event_log_df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"Event log saved to {output_filename}")
        else:
            print(class="hl-string">"No events were generated from the extracted data.")
    else:
        print(class="hl-string">"No data extracted. Please check configuration and API availability.")

Etapas

Acesse Relatórios e Análises: Entre no Oracle Fusion Financials. No menu Navigator, vá em Ferramentas e selecione Relatórios e Análises. Este é o centro de gestão de todos os relatórios.
Crie um Modelo de Dados no BI Publisher: Para extrair o event log, criar o Modelo de Dados diretamente é mais eficiente que o OTBI, permitindo o uso de SQL personalizado com UNION ALL. Clique em 'Procurar Catálogo', escolha uma pasta e vá em Criar > Modelo de Dados.
Defina o Dataset: No editor, clique no '+' para adicionar um novo Dataset e escolha 'Consulta SQL'. Nomeie como 'JournalEventLog'.
Insira o SQL: Escolha 'Oracle BI EE' como Fonte de Dados. Copie o script SQL da seção abaixo e cole na área de texto. A consulta unifica todas as atividades e atributos necessários.
Defina Parâmetros: A interface detectará automaticamente parâmetros como :start_date, :end_date e :ledger_name. Configure os tipos de dados (Data ou Texto) para permitir execuções flexíveis.
Crie o Relatório: Após salvar o modelo, volte ao catálogo e clique em Criar > Relatório. No assistente, selecione 'Usar Modelo de Dados Existente' e aponte para o que você criou.
Configure o Layout: Escolha o layout 'Tabela'. É fundamental arrastar todas as colunas para garantir que constem na exportação. Não é preciso formatação visual complexa.
Defina CSV como Saída Padrão: No editor do relatório, acesse 'Exibir uma Lista'. Em 'Formatos de Saída', marque apenas 'CSV' para simplificar o agendamento. Salve.
Agende a Extração: No catálogo, clique em 'Mais' no relatório e depois em 'Agendar'. Configure a frequência (ex: diária ou semanal).
Configure Entrega: Na guia 'Saída' do agendamento, selecione seu relatório e o formato 'CSV'. Na guia 'Destino', você pode configurar o envio para um servidor UCM ou SFTP externo para automação.
Prepare os Dados: Após a execução, obtenha o CSV no destino. Verifique se os cabeçalhos coincidem com o padrão ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. O arquivo está pronto para upload.

Configuração

Fonte de Dados: A consulta deve ser executada na fonte de dados 'Oracle BI EE' dentro do BI Publisher, que se conecta às visões do banco de dados transacional subjacente do OTBI.
Áreas de Assunto (referência): A lógica da consulta baseia-se em dados da área 'General Ledger - Journals Real Time'. Também integra dados de 'HCM - Workforce Management - Worker Assignment Real Time' para detalhes de usuários e áreas de workflow para histórico de aprovações.
Filtro de Período: É fundamental filtrar os dados para um período gerenciável. A consulta inclui os parâmetros :start_date e :end_date. Recomendamos extrair de 3 a 6 meses para a análise inicial. O filtro é aplicado à data de criação do lançamento.
Filtro de Ledger: Use o parâmetro :ledger_name para limitar a extração a um livro-razão (ledger) primário específico. Extrair todos simultaneamente pode gerar arquivos excessivamente grandes e problemas de performance.
Pré-requisitos: O usuário que criar o relatório deve ter funções de BI adequadas, como 'BI Administrator' ou 'BI Author'. Além disso, o perfil de segurança de dados deve permitir acesso aos ledgers e unidades de negócio consultados.
Agendamento: Para melhor desempenho e evitar impactos no sistema, agende a extração para horários de baixo uso, como durante a madrugada.

a Consulta de Exemplo config

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Seu Template de Dados Record to Report - Lançamento Contábil

Seu Template de Dados Record to Report - Lançamento Contábil

Record to Report - Atributos de Lançamento Contábil

Record to Report - Atividades de Lançamento Contábil

Guias de Extração

Exportação de relatórios Oracle OTBI e BI Publisher

Etapas

Configuração

a Consulta de Exemplo config

Relatório do BI Publisher com consulta via SQL Data Model

Etapas

Configuração

a Consulta de Exemplo sql

Script Python utilizando a API REST do Oracle Fusion Financials

Etapas

Configuração

a Consulta de Exemplo python

Extração em massa de dados via BI Cloud Connector (BICC)

Etapas

Configuração

a Consulta de Exemplo config

Pronto para Começar?

Acelere seu Record to Report - Lançamentos Contábeis agora

Seu Template de Dados Record to Report - Lançamento Contábil

Seu Template de Dados Record to Report - Lançamento Contábil

Record to Report - Atributos de Lançamento Contábil

Record to Report - Atividades de Lançamento Contábil

Guias de Extração

Exportação de relatórios Oracle OTBI e BI Publisher

Etapas

Configuração

a Consulta de Exemplo config

Relatório do BI Publisher com consulta via SQL Data Model

Etapas

Configuração

a Consulta de Exemplo sql

Script Python utilizando a API REST do Oracle Fusion Financials

Etapas

Configuração

a Consulta de Exemplo python

Extração em massa de dados via BI Cloud Connector (BICC)

Etapas

Configuração

a Consulta de Exemplo config

Valorizamos sua privacidade

Pronto para Começar?

Acelere seu Record to Report - Lançamentos Contábeis agora