Seu Template de dados de gestão de crédito e cobrança
Seu Template de dados de gestão de crédito e cobrança
- Atributos recomendados para uma análise completa
- Principais atividades a acompanhar para descobrir o processo
- Orientações passo a passo para extração de dados
Atributos de gestão de crédito e cobrança
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTime | A data e a hora exatas em que a atividade ocorreu, registradas como data e hora do evento. | ||
| Descrição A data e hora do evento registram o momento exato em que uma atividade ocorreu. Elas são essenciais para ordenar os eventos cronologicamente e montar um fluxo de processo preciso. Sem datas e horas corretas, não é possível determinar a sequência dos eventos com precisão. Na análise, este atributo é usado para calcular durações e tempos de ciclo entre atividades, algo fundamental para medir a performance. Por exemplo, ele permite calcular KPIs como o tempo do ciclo de resolução de disputas ou o tempo do ciclo de pagamento da fatura. Também possibilita analisar tendências de performance do processo em diferentes períodos. Por que isso importa Esta data e hora são essenciais para ordenar eventos, calcular tempos de ciclo e durações e analisar a performance do processo ao longo do tempo. Onde encontrar Derivado de vários campos de data nas tabelas do Oracle Fusion Financials, como TRX_DATE em RA_CUSTOMER_TRX_ALL para a criação da fatura ou a data de criação de uma ação de cobrança. Exemplos 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Nome da atividade ActivityName | Nome do evento de negócio ou da tarefa específica que ocorreu em determinado momento do processo de gestão de crédito. | ||
| Descrição Este atributo descreve uma etapa do ciclo de vida da fatura, como "Fatura gerada", "Procedimento de cobrança iniciado" ou "Pagamento recebido". Cada atividade representa um evento distinto que faz o caso avançar. Analisar a sequência e a frequência das atividades é a base do Process Mining. Isso ajuda a revelar o fluxo real do processo, identificar gargalos onde os casos ficam parados, detectar ciclos de retrabalho em que as atividades se repetem e comparar o processo real com o processo planejado ou ideal. O nome da atividade é fundamental para criar mapas de processo e calcular o tempo entre as etapas. Por que isso importa Este atributo define as etapas do mapa do processo e permite visualizar e analisar o ciclo de vida da fatura do início ao fim. Onde encontrar Este é um campo conceitual derivado de vários eventos de negócio no Oracle Fusion Financials. Em geral, ele é construído mapeando status de transações, datas de eventos ou ações específicas de módulos como Receivables (AR) e Advanced Collections. Exemplos Fatura geradaProcedimento de cobrança iniciadoPagamento recebidoDisputa registrada | |||
| Número da fatura InvoiceNumber | Identificador exclusivo de cada fatura de cliente, usado como identificador principal do caso no processo de gestão de crédito. | ||
| Descrição O número da fatura é a chave central que vincula todos os eventos e atividades relacionados a um único valor a receber, desde a criação até a liquidação final ou a baixa. Ele permite acompanhar o ciclo de vida completo da fatura, de ponta a ponta. Na análise de Process Mining, este atributo é usado para reconstruir a jornada de cada fatura. Ao agrupar todas as atividades relacionadas sob um único número de fatura, os analistas podem visualizar os fluxos do processo, identificar caminhos comuns e desvios e medir os tempos de ciclo do processo inteiro ou de etapas específicas, como a resolução de disputas ou a contabilização de pagamentos. Por que isso importa Este é o ID do caso essencial que conecta todas as etapas relacionadas do processo, permitindo reconstruir e analisar a jornada de cada fatura, da emissão ao encerramento. Onde encontrar Em geral, este identificador aparece como TRX_NUMBER na tabela RA_CUSTOMER_TRX_ALL do Oracle Fusion Financials. Exemplos INV-1005679884321AR-2023-04-112 | |||
| Sistema de origem SourceSystem | Sistema de onde vêm os dados. | ||
| Descrição Este atributo identifica o aplicativo de origem em que os dados do evento foram registrados. Em ambientes de TI complexos, vários sistemas podem participar de um único processo de ponta a ponta. Especificar o sistema de origem é importante para a governança de dados, a solução de problemas e a compreensão do contexto dos dados. Quando eventos de vários sistemas são reunidos em uma única visão do processo, essa informação ajuda a diferenciá-los e a manter clara a linhagem dos dados. Por que isso importa Esclarece a origem dos dados, algo essencial para validá-los, garantir a governança e entender o contexto tecnológico do processo. Onde encontrar Em geral, este é um valor estático adicionado durante a extração dos dados para identificar a origem dos registros. Exemplos Oracle Fusion FinancialsOracle AROracle Collections | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados deste evento foram atualizados ou extraídos pela última vez do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração de dados mais recente. É um campo de metadados que não faz parte do processo de negócio, mas é essencial para entender o quanto os dados analisados estão atualizados. Os analistas usam esta data e hora para confirmar que estão trabalhando com informações atualizadas e entender até que momento os dados estão disponíveis. Ela é essencial para a governança de dados e para alinhar as expectativas dos usuários sobre a atualidade dos dados em dashboards e relatórios. Por que isso importa Indica o quanto os dados estão atualizados e ajuda analistas e partes interessadas a entender sua atualidade e relevância. Onde encontrar Este valor é gerado e registrado em cada linha durante o processo de extração e carregamento de dados (ETL). Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Cobrador Collector | Nome ou ID do agente de cobrança responsável pela fatura. | ||
| Descrição O cobrador é a pessoa ou equipe responsável pelas atividades de cobrança de uma fatura em atraso. Essa atribuição é uma etapa importante do fluxo de trabalho de cobrança. Este atributo é essencial para gerenciar a performance e alocar recursos na equipe de cobrança. Ao analisar os resultados por cobrador, os gestores podem avaliar a eficácia, identificar necessidades de treinamento e equilibrar as cargas de trabalho. O dashboard de eficácia da atribuição de cobradores usa este atributo para comparar taxas de sucesso e tempos de ciclo entre diferentes cobradores. Por que isso importa Permite analisar a performance de cobradores individuais ou de equipes, ajudando a otimizar a alocação de recursos e melhorar a eficiência geral da cobrança. Onde encontrar Essas informações geralmente ficam armazenadas no módulo Oracle Advanced Collections, muitas vezes em tabelas como IEX_CASES_ALL_B ou em tabelas relacionadas à atribuição. Exemplos John SmithJane DoeEquipe de cobrança A | |||
| Data de vencimento DueDate | A data limite para o pagamento da fatura. | ||
| Descrição A data de vencimento é uma data importante, acordada em contrato, que serve de referência para avaliar se o pagamento foi feito no prazo. Esse atributo é fundamental para identificar faturas vencidas e calcular há quantos dias estão em atraso. Ele é a principal referência para determinar quando iniciar os procedimentos de cobrança e calcular KPIs como o prazo médio de recebimento de vendas (DSO). Também é essencial para criar relatórios de envelhecimento que classificam os valores em aberto. Por que isso importa Serve de referência para identificar faturas vencidas, iniciar ações de cobrança e analisar o envelhecimento dos valores em aberto. Onde encontrar Disponível na tabela AR_PAYMENT_SCHEDULES_ALL como DUE_DATE. Exemplos 2023-05-302023-06-152023-07-01 | |||
| Nível de cobrança DunningLevel | A etapa ou o nível do procedimento de cobrança aplicado à fatura. | ||
| Descrição O nível de cobrança indica a intensidade do lembrete de pagamento, que geralmente aumenta com o tempo. Por exemplo, o nível 1 pode ser um lembrete cordial por e-mail, enquanto o nível 3 pode ser uma carta formal ou uma ligação. Analisar o processo por nível de cobrança ajuda a avaliar a eficácia da estratégia de cobrança. O Dashboard de eficácia da cobrança usa esse atributo para mostrar as taxas de conversão de cada etapa de cobrança em pagamento. Assim, a empresa pode identificar quais ações de cobrança funcionam melhor e ajustar o momento e o conteúdo dos lembretes para maximizar os recebimentos. Por que isso importa Acompanha a etapa de escalonamento das ações de cobrança, essencial para avaliar a eficácia da estratégia de cobrança. Onde encontrar Esses dados são gerenciados no módulo Oracle Advanced Collections. Eles podem ser encontrados em tabelas relacionadas ao histórico de cobranças, como IEX_DUNNINGS. Exemplos Nível 1: LembreteNível 2: AvisoNível 3: Notificação final | |||
| Número do cliente CustomerNumber | Identificador exclusivo do cliente associado à fatura. | ||
| Descrição O número do cliente vincula uma fatura a uma conta específica. Isso permite segmentar e analisar o processo de crédito e cobrança com base nos atributos dos clientes. Com o número do cliente, os analistas podem investigar se determinados clientes costumam pagar com atraso, contestar mais faturas ou exigir mais ações de cobrança. Essas informações são essenciais para criar estratégias de cobrança específicas para cada cliente, ajustar prazos de crédito e identificar segmentos de clientes de alto risco. Elas também ajudam diretamente em análises como a análise da taxa de baixa de faturas por segmento de cliente. Por que isso importa Permite segmentar o processo por cliente e ajuda a identificar padrões, riscos e oportunidades para criar estratégias de cobrança sob medida. Onde encontrar Em geral, aparece como BILL_TO_CUSTOMER_ID na tabela RA_CUSTOMER_TRX_ALL, vinculada a HZ_CUST_ACCOUNTS. Exemplos CUST-0012389455ACME-CORP-US | |||
| Segmento do cliente CustomerSegment | Classificação do cliente em um grupo definido, por exemplo, por porte, setor ou importância estratégica. | ||
| Descrição O segmento do cliente é um atributo categórico que agrupa clientes com características em comum. Os segmentos podem ser definidos por fatores como "Estratégico", "Pequenas e médias empresas" ou "Enterprise", ou por setor, como "Manufatura" ou "Varejo". Este atributo é útil para análises comparativas. Ele permite comparar a performance do processo entre diferentes segmentos e verificar, por exemplo, se um deles tem mais disputas ou um ciclo de pagamento mais longo. Esse insight ajuda a adaptar as políticas de crédito e as estratégias de cobrança às necessidades e aos riscos de cada segmento, além de apoiar dashboards como o de análise da taxa de baixa de faturas. Por que isso importa Permite fazer análises comparativas e entender como a performance e os riscos do processo variam entre diferentes grupos de clientes. Onde encontrar Em geral, é gerenciado nos dados mestres de clientes (HZ_CUST_ACCOUNTS ou tabelas relacionadas) ou derivado de atributos como receita ou setor. Exemplos Grande empresaPequena e média empresaGovernoParceiro estratégico | |||
| Usuário User | O usuário ou ID do sistema que realizou a atividade. | ||
| Descrição Esse atributo identifica o funcionário ou usuário de sistema responsável por realizar uma atividade, como aprovar um limite de crédito, registrar um pagamento ou resolver uma contestação. Analisar as atividades por usuário é essencial para entender a distribuição da carga de trabalho, o desempenho individual e a conformidade. No caso de atividades automatizadas, ajuda a acompanhar a participação dos processos do sistema. Também pode ajudar a identificar necessidades de treinamento ou possíveis fraudes por meio do monitoramento do comportamento dos usuários. Por que isso importa Associa as atividades do processo a pessoas específicas ou sistemas automatizados, permitindo acompanhar o desempenho, analisar a carga de trabalho e realizar auditorias. Onde encontrar Obtido nas colunas 'CREATED_BY' ou 'LAST_UPDATED_BY' de várias tabelas de transações e histórico do Oracle Fusion Financials. Exemplos jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Valor da fatura InvoiceAmount | Valor monetário total da fatura. | ||
| Descrição O valor da fatura corresponde ao valor total dos produtos ou serviços cobrados do cliente. Este é um atributo financeiro essencial para entender o impacto monetário do processo. Na análise, o valor da fatura ajuda a priorizar as ações de cobrança, com foco nas faturas em atraso de maior valor. Também permite analisar o comportamento de pagamento conforme o valor da transação e calcular o impacto financeiro das baixas. Dashboards como o de análise da taxa de baixa de faturas usam este valor para avaliar a dimensão das perdas financeiras. Por que isso importa Dá contexto financeiro ao processo, permitindo priorizar faturas de alto valor e analisar o impacto monetário das ineficiências. Onde encontrar Estas informações podem ser obtidas da tabela AR_PAYMENT_SCHEDULES_ALL, que armazena o valor devido de cada fatura. Exemplos 5000.001250.75250000.00 | |||
| Condições de pagamento PaymentTerms | As condições acordadas que definem quando o pagamento deve ser feito. | ||
| Descrição As condições de pagamento definem os prazos que o cliente deve cumprir, como '30 dias' ou '60 dias'. Elas são usadas para calcular a data de vencimento da fatura. Analisar o desempenho dos pagamentos por condição pode revelar padrões importantes. Por exemplo, clientes com prazos menores podem ter maior probabilidade de pagar com atraso. Essas informações ajudam a revisar e otimizar as políticas de crédito e a segmentar clientes para adotar diferentes estratégias de cobrança. Também ajudam a entender por que determinadas faturas vencem sem pagamento. Por que isso importa Apresenta o contexto do prazo de pagamento acordado e permite analisar o comportamento de pagamento em diferentes condições de crédito. Onde encontrar Essas informações ficam armazenadas na tabela RA_TERMS, vinculadas à transação da fatura. Exemplos 30 dias60 diasVencimento no recebimento | |||
| Data prometida para pagamento PromiseToPayDate | A data em que o cliente prometeu fazer o pagamento. | ||
| Descrição Durante as ações de cobrança, o cliente pode se comprometer a pagar em uma data futura. A data prometida para pagamento é registrada para acompanhar esse compromisso. Esse atributo é importante para gerenciar os fluxos de trabalho de cobrança e avaliar a confiabilidade dos compromissos assumidos pelos clientes. Ao comparar a data prometida para pagamento com a data em que o pagamento foi recebido, a equipe de cobrança pode avaliar quantas promessas foram cumpridas. Isso ajuda a prever o fluxo de caixa com mais precisão e a decidir quando intensificar a cobrança caso uma promessa não seja cumprida. Por que isso importa Acompanha os compromissos de pagamento dos clientes, ajudando a prever entradas de caixa e avaliar a eficácia das negociações de cobrança. Onde encontrar Armazenada no módulo Oracle Advanced Collections, provavelmente em tabelas como IEX_PROMISES_T. Exemplos 2023-06-102023-06-252023-07-05 | |||
| Dias em atraso DaysOverdue | O número de dias desde o vencimento da fatura. | ||
| Descrição Essa métrica calculada quantifica o atraso de uma fatura não paga. O cálculo considera a diferença entre a data atual (para faturas em aberto) ou a data de pagamento (para faturas fechadas) e a data de vencimento. Os dias em atraso são uma medida essencial para a análise de envelhecimento e a priorização das ações de cobrança. Essa é a principal métrica do Dashboard de envelhecimento e status de faturas vencidas, que agrupa as faturas por faixa de atraso (por exemplo, de 1 a 30 dias, de 31 a 60 dias). Assim, a equipe de cobrança pode priorizar as dívidas mais antigas e de maior risco. Por que isso importa Quantifica o atraso nos pagamentos e serve como métrica central para priorizar cobranças e analisar o envelhecimento dos valores em aberto. Onde encontrar Este é um campo calculado. A lógica é: CurrentDate - DueDate para faturas em aberto ou PaymentDate - DueDate para faturas fechadas. Exemplos 1545920 | |||
| Está em atraso IsOverdue | Um indicador booleano que informa se a fatura passou da data de vencimento. | ||
| Descrição Esse atributo derivado indica de forma simples se uma fatura está ou não vencida. Geralmente, ele é calculado comparando a data atual (ou a data de pagamento) com a data de vencimento da fatura. Esse indicador é muito útil para filtrar e segmentar dados na análise. Ele permite que analistas identifiquem rapidamente as faturas vencidas e estudem seus caminhos no processo, a eficácia das ações de cobrança e outras características. Também simplifica a criação de Dashboards e KPIs voltados à gestão de valores vencidos, como o Dashboard de envelhecimento e status de faturas vencidas. Por que isso importa Oferece um indicador simples e claro para identificar e analisar todas as faturas vencidas, foco principal do processo de cobrança. Onde encontrar Este é um campo calculado. A lógica é: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Exemplos truefalse | |||
| Foi baixada como perda IsWrittenOff | Um indicador booleano que informa se a fatura foi baixada como perda por inadimplência. | ||
| Descrição Esse indicador derivado identifica as faturas que a empresa considerou incobráveis e retirou dos valores a receber ativos. Geralmente, esse é o resultado final e indesejado de uma fatura. Esse atributo é essencial para calcular o KPI de taxa de baixa de faturas como perda e para a análise correspondente no Dashboard. Ele permite que analistas isolem os casos de cobrança malsucedida e identifiquem características comuns, como o segmento do cliente ou o valor da fatura, que podem estar associadas a um risco maior de baixa como perda. Esse insight ajuda a aprimorar as políticas de crédito e as estratégias de cobrança. Por que isso importa Identifica com clareza os casos de cobrança malsucedida, essenciais para analisar as causas raiz da inadimplência e calcular as taxas de baixa como perda. Onde encontrar Este é um campo calculado, derivado da verificação da existência da atividade 'Fatura baixada como perda' no caso ou da presença do status 'Baixada como perda' na fatura. Exemplos truefalse | |||
| Hora de término EndTime | A data e hora que indicam quando uma atividade com duração foi concluída. | ||
| Descrição Para atividades com início e fim definidos, esse atributo registra o horário de conclusão. Embora muitos eventos em Process Mining sejam instantâneos, alguns, como 'Investigação de contestação', podem durar um período de tempo. Ter uma hora de término separada permite calcular com precisão o tempo de processamento das atividades. Esse cálculo é mais preciso do que estimar a duração com base no início da atividade seguinte, principalmente quando há períodos de inatividade. Esse dado é essencial para analisar a utilização de recursos e identificar quais etapas específicas estão consumindo mais tempo no processo. Por que isso importa Permite calcular com precisão a duração de atividades específicas e oferece mais insight sobre gargalos e utilização de recursos. Onde encontrar Esse é, muitas vezes, um atributo conceitual. Ele pode vir de uma data e hora da última atualização ou de um campo específico de data de fechamento nas tabelas de origem correspondentes à atividade. Exemplos 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Moeda da fatura InvoiceCurrency | Moeda em que o valor da fatura é expresso. | ||
| Descrição Este atributo especifica a moeda da fatura, como USD, EUR ou GBP. Em organizações multinacionais, as faturas costumam ser emitidas em diferentes moedas. Analisar dados com várias moedas exige atenção. Este atributo permite filtrar a visão do processo por moeda ou aplicar as taxas de câmbio corretas em relatórios financeiros consolidados. Assim, os valores monetários são interpretados corretamente e as comparações são feitas em bases equivalentes. Por que isso importa É essencial para interpretar corretamente os dados financeiros em ambientes com várias moedas e garantir análises financeiras precisas. Onde encontrar Em geral, aparece como INVOICE_CURRENCY_CODE na tabela RA_CUSTOMER_TRX_ALL. Exemplos USDEURGBPJPY | |||
| Motivo da contestação DisputeReason | O motivo informado pelo cliente para contestar uma fatura. | ||
| Descrição Quando contesta uma fatura, o cliente geralmente informa um motivo, como 'Preço incorreto', 'Mercadoria danificada' ou 'Fatura duplicada'. Esse atributo registra o motivo apresentado. Analisar os motivos das contestações é fundamental para a análise de causa raiz. Isso ajuda a identificar problemas recorrentes em processos anteriores, como gestão de pedidos ou faturamento, que provocam atrasos nos pagamentos. Ao categorizar e acompanhar a frequência de cada motivo, a empresa pode agir diretamente sobre as causas e reduzir o tempo de resolução de contestações. Por que isso importa Ajuda a identificar as causas raiz das contestações de faturas e a melhorar proativamente os processos anteriores para evitar novas ocorrências. Onde encontrar Essas informações geralmente são registradas nos módulos Oracle Advanced Collections ou Oracle Channel Revenue Management, quando a gestão de contestações é formalizada. Elas podem estar em tabelas como AR_DISPUTE_HISTORY. Exemplos Quantidade incorretaDivergência de preçoMercadoria danificadaServiço não prestado | |||
| Status da fatura InvoiceStatus | O status atual da fatura ao longo do seu ciclo de vida. | ||
| Descrição O status da fatura mostra em que ponto do processo ela se encontra. Entre os status mais comuns estão 'Em aberto', 'Paga', 'Contestada', 'Em atraso' e 'Baixada como perda'. Esse atributo oferece uma visão geral da situação das contas a receber. Em Process Mining, esse atributo ajuda a filtrar casos e analisar grupos específicos, como todas as faturas em aberto e vencidas. Ele é uma dimensão importante do Dashboard de envelhecimento e status de faturas vencidas, pois mostra de imediato a situação atual da carteira de faturas e ajuda a priorizar as ações de cobrança. Por que isso importa Oferece uma visão rápida da situação atual de uma fatura, facilitando a filtragem e a priorização das ações de cobrança. Onde encontrar Geralmente disponível na tabela AR_PAYMENT_SCHEDULES_ALL, em um campo chamado STATUS. Exemplos Em abertoFechadaContestadaEm cobrança | |||
| Unidade de negócio BusinessUnit | A unidade de negócio ou entidade organizacional específica que emitiu a fatura. | ||
| Descrição Em grandes organizações, as operações costumam ser divididas em várias unidades de negócio. Esse atributo identifica a unidade associada à fatura. Analisar o processo por unidade de negócio permite comparar o desempenho entre diferentes áreas da organização. A análise pode revelar diferenças na aplicação das políticas de crédito e cobrança e mostrar quais unidades gerenciam melhor os valores a receber. Isso ajuda a compartilhar boas práticas e padronizar os processos quando necessário. Por que isso importa Permite comparar o desempenho entre diferentes unidades organizacionais e identificar boas práticas e oportunidades de melhoria. Onde encontrar Disponível na tabela RA_CUSTOMER_TRX_ALL pelo campo ORG_ID, que faz a ligação com a estrutura organizacional. Exemplos Unidade de negócio da América do NorteUnidade de negócio da EMEADivisão de serviços globais | |||
| Valor do limite de crédito CreditLimitAmount | O valor máximo de crédito aprovado para o cliente. | ||
| Descrição O valor do limite de crédito representa a exposição total ao crédito que a empresa aceita ter com determinado cliente. Esse limite é definido durante a análise de crédito. Esse atributo é essencial para o Dashboard de impacto das decisões sobre limites de crédito. Ao relacionar o limite aprovado com o comportamento de pagamento e as baixas como perda posteriores, a empresa pode avaliar a eficácia das políticas de risco de crédito. A análise pode revelar se limites de crédito excessivamente altos contribuem para o aumento da inadimplência, ajudando a aprimorar o processo de aprovação de crédito. Por que isso importa É fundamental para avaliar a eficácia das políticas de risco de crédito, relacionando o limite aprovado aos resultados de pagamento e às baixas como perda. Onde encontrar Esse dado é gerenciado no Oracle Credit Management e geralmente fica armazenado em tabelas relacionadas aos perfis de crédito dos clientes, como HZ_CUST_PROFILE_AMTS. Exemplos 10000.0050000.00250000.00 | |||
Atividades de gestão de crédito e cobrança
| Atividade | Descrição | ||
|---|---|---|---|
| Fatura baixada | Representa a decisão formal de encerrar as tentativas de cobrança e reconhecer o valor da fatura como perda por inadimplência. É uma transação financeira explícita que ajusta o saldo da fatura para zero. | ||
| Por que isso importa Este é um ponto crítico de insucesso no processo de cobrança. Analisar as baixas por segmento de cliente, região ou limite de crédito ajuda a aprimorar as políticas de crédito e as estratégias de cobrança para reduzir perdas. Onde encontrar Registrado explicitamente a partir da criação de um ajuste na tabela AR_ADJUSTMENTS_ALL com um RECEIVABLES_TRX_ID associado a uma atividade de dívida incobrável ou baixa. Coleta Data de criação de um registro na tabela AR_ADJUSTMENTS_ALL com um tipo de atividade de baixa. Tipo de evento explicit | |||
| Fatura gerada | Marca a criação do registro da transação da fatura no Oracle Fusion Financials. Este é o início oficial do ciclo de vida da fatura no módulo de contas a receber e serve como principal ponto de partida para a análise. | ||
| Por que isso importa Este é o evento de início essencial da jornada da fatura. Todos os cálculos de tempo de ciclo subsequentes, como o prazo médio de recebimento de vendas (DSO) e o tempo do ciclo de pagamento da fatura, dependem desta data e hora inicial. Onde encontrar Este é um evento explícito, registrado na coluna CREATION_DATE ou TRX_DATE da tabela RA_CUSTOMER_TRX_ALL para um TRX_NUMBER (número da fatura) específico. Coleta A data e hora do evento correspondem a CREATION_DATE na tabela RA_CUSTOMER_TRX_ALL. Tipo de evento explicit | |||
| Pagamento aplicado | Representa a aplicação de um pagamento recebido a uma fatura específica, reduzindo o saldo em aberto. Esta etapa vincula formalmente o pagamento à fatura. | ||
| Por que isso importa Esta atividade é essencial para confirmar que uma fatura foi paga. Ela marca o verdadeiro ponto final do cálculo do prazo médio de recebimento de vendas (DSO) e do ciclo de contabilização do pagamento. Onde encontrar Este é um evento explícito, registrado a partir de APPLY_DATE na tabela AR_RECEIVABLE_APPLICATIONS_ALL, que vincula um recebimento em dinheiro a uma transação do cliente (fatura). Coleta APPLY_DATE de AR_RECEIVABLE_APPLICATIONS_ALL para a fatura correspondente. Tipo de evento explicit | |||
| Pagamento recebido | Marca o recebimento de valores de um cliente, que talvez ainda não tenham sido aplicados a uma fatura específica. O evento é registrado quando uma transação de recebimento em dinheiro é criada no sistema. | ||
| Por que isso importa Este é um marco importante no processo de cobrança, pois indica que o pagamento foi recebido. O tempo entre este evento e a aplicação do pagamento mede a eficiência do processamento interno. Onde encontrar Registrado explicitamente a partir de RECEIPT_DATE na tabela AR_CASH_RECEIPTS_ALL. Em seguida, o recebimento pode ser vinculado à fatura em que foi aplicado por meio de AR_RECEIVABLE_APPLICATIONS_ALL. Coleta RECEIPT_DATE de AR_CASH_RECEIPTS_ALL, vinculado por meio das tabelas de aplicação. Tipo de evento explicit | |||
| Prazo de pagamento vencido | Evento calculado que ocorre quando a data atual ultrapassa a data de vencimento da fatura e ela ainda não foi paga integralmente. Esse evento marca a mudança do status da fatura de "em dia" para "em atraso". | ||
| Por que isso importa Este é um marco importante que dá início aos processos de cobrança. Analisar o volume e o valor das faturas que vencem é essencial para gerenciar o capital de giro e avaliar o risco de crédito. Onde encontrar Este evento é calculado comparando a data atual do sistema com DUE_DATE na tabela AR_PAYMENT_SCHEDULES_ALL, para faturas com STATUS igual a 'OP' (em aberto). Coleta Evento calculado: ocorre quando SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Tipo de evento calculated | |||
| Procedimento de cobrança iniciado | Marca o início formal do processo de cobrança de uma fatura em atraso, que muitas vezes inclui o envio da primeira notificação oficial. Em geral, o evento é registrado quando um processo em lote de cobrança é executado e inclui a fatura. | ||
| Por que isso importa Acompanhar esta atividade é essencial para medir a eficácia da cobrança e o cumprimento das políticas. Ela serve como referência para medir quanto tempo a cobrança leva para resultar em pagamento. Onde encontrar Registrado no módulo Oracle Advanced Collections. A data de criação de um registro de cobrança em tabelas como IEX_DUNNINGS, vinculado ao ID da transação, marca este evento. Coleta Data de criação do registro na tabela IEX_DUNNINGS associado à fatura. Tipo de evento explicit | |||
| Ação do cobrador concluída | Representa uma ação manual realizada por um cobrador, como fazer uma ligação, enviar um e-mail ou registrar uma nota sobre uma interação. Essas ações são registradas como atividades ou interações no módulo de cobrança. | ||
| Por que isso importa Monitorar as ações dos cobradores ajuda a medir a eficiência e a eficácia do fluxo de trabalho manual de cobrança. Também permite analisar a frequência das atividades e sua relação com o sucesso dos pagamentos. Onde encontrar Registrado nas tabelas de histórico de interações ou atividades do Oracle Advanced Collections, como JTF_IH_ACTIVITIES, vinculado ao cliente e, possivelmente, à fatura específica. Coleta Data e hora de criação dos registros em JTF_IH_ACTIVITIES com um resultado ou código de motivo relevante. Tipo de evento explicit | |||
| Análise de crédito concluída | Indica a conclusão da avaliação de crédito do cliente associado à fatura. Em geral, esse evento é inferido ao relacionar a data de criação da fatura à data de conclusão mais recente da análise de crédito da conta do cliente, servindo como referência para análises de crédito. | ||
| Por que isso importa Analisar o tempo entre a análise de crédito e a realização do pedido ajuda a identificar atrasos nas etapas iniciais do ciclo do pedido ao recebimento. Essa análise é a base para medir o KPI de tempo do ciclo de aprovação de crédito e entender o impacto das decisões de crédito. Onde encontrar Inferido por meio de uma consulta a HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE para o cliente da fatura (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). A data e hora do evento correspondem a LAST_CREDIT_REVIEW_DATE, anterior a CREATION_DATE da fatura. Coleta Vincule a fatura à data mais recente de análise de crédito do cliente anterior à criação da fatura. Tipo de evento inferred | |||
| Disputa registrada | Indica que o cliente contestou formalmente a fatura, total ou parcialmente. Em geral, isso é registrado por uma mudança de status no cronograma de pagamentos da fatura. | ||
| Por que isso importa Esta atividade marca o início do processo de resolução de disputas. Analisar o tempo entre o registro e a resolução é essencial para identificar gargalos que atrasam o recebimento. Onde encontrar Inferido a partir de uma mudança de status na tabela AR_PAYMENT_SCHEDULES_ALL, quando o campo STATUS muda para 'DS' (em disputa). A data e hora podem ser obtidas de tabelas de auditoria ou da data da última atualização. Coleta Detecte quando AR_PAYMENT_SCHEDULES_ALL.STATUS mudar para 'DS' para a fatura. Tipo de evento inferred | |||
| Disputa resolvida | Indica que uma disputa registrada foi investigada e resolvida. O evento é registrado quando o status de disputa da fatura é removido. | ||
| Por que isso importa Este evento marca o fim do ciclo de resolução da disputa. O tempo entre "Disputa registrada" e este evento é um KPI importante para medir a eficiência operacional e o impacto no fluxo de caixa. Onde encontrar Inferido quando STATUS em AR_PAYMENT_SCHEDULES_ALL muda de 'DS' (em disputa) para 'OP' (em aberto) ou para 'CL' (fechado), após uma nota de crédito ou um ajuste. Coleta Detecte quando AR_PAYMENT_SCHEDULES_ALL.STATUS mudar de 'DS' para outro status. Tipo de evento inferred | |||
| Estratégia de cobrança atribuída | Ocorre quando uma estratégia automatizada de cobrança é atribuída à fatura ou ao cliente em atraso. Ela define a sequência de etapas e atividades que o sistema ou o cobrador vai seguir. | ||
| Por que isso importa Este evento oferece um insight sobre a automação do processo de cobrança. Analisar quais estratégias são atribuídas e seus resultados ajuda a otimizar as abordagens de cobrança para diferentes segmentos de clientes. Onde encontrar Registrado no módulo Oracle Advanced Collections. Em geral, o evento é identificado pela data de criação de uma atribuição de estratégia em tabelas como IEX_STRATEGIES ou em objetos relacionados. Coleta Data de criação do item de trabalho da estratégia nas tabelas de cobrança, vinculado ao cliente ou à transação. Tipo de evento explicit | |||
| Fatura encerrada | Ocorre quando o saldo em aberto da fatura chega a zero, seja por pagamento, aplicação de nota de crédito ou ajuste. Isso marca a conclusão bem-sucedida do ciclo de vida da fatura. | ||
| Por que isso importa Este evento é um dos principais pontos de conclusão bem-sucedida do processo. Monitorar o encerramento das faturas é fundamental para entender a saúde geral da carteira de contas a receber. Onde encontrar Inferido a partir de uma mudança de status na tabela AR_PAYMENT_SCHEDULES_ALL, quando STATUS muda para 'CL' (fechado). A data e hora correspondem a LAST_UPDATE_DATE dessa alteração. Coleta Detecte quando AR_PAYMENT_SCHEDULES_ALL.STATUS passar a 'CL' para a fatura. Tipo de evento inferred | |||
| Fatura enviada ao cliente | Indica que a fatura foi entregue formalmente ao cliente, por meio eletrônico ou impressa. O evento pode ser registrado explicitamente por um módulo de entrega ou inferido a partir da data de impressão da fatura. | ||
| Por que isso importa Esta atividade marca o início da contagem do prazo de pagamento do cliente. Acompanhar esse momento ajuda a calcular os dias de atraso com precisão e a analisar eventuais demoras entre a geração da fatura e a notificação do cliente. Onde encontrar Pode ser registrado a partir de LAST_PRINTED_DATE em RA_CUSTOMER_TRX_ALL. Outra opção é inferir o evento a partir dos registros de integração com sistemas de entrega de e-mails ou outras plataformas de comunicação. Coleta Use LAST_PRINTED_DATE de RA_CUSTOMER_TRX_ALL ou o status de um registro de entrega. Tipo de evento inferred | |||
| Promessa de pagamento registrada | Representa um acordo formal registrado no sistema, no qual o cliente promete fazer um pagamento em uma data específica. É um resultado importante das atividades de cobrança. | ||
| Por que isso importa Acompanhar as promessas de pagamento e a taxa de cumprimento é um indicador de performance importante para os cobradores. Isso ajuda a prever o fluxo de caixa de contas a receber em atraso e a avaliar a eficácia dos cobradores. Onde encontrar Criado explicitamente no Oracle Advanced Collections. A data de criação é obtida da tabela IEX_PROMISE_DETAILS. Coleta Data de criação na tabela IEX_PROMISE_DETAILS para a fatura correspondente. Tipo de evento explicit | |||
Guias de extração
Etapas
- Acesse o Oracle BI Publisher: Faça login no seu ambiente Oracle Fusion Financials. Acesse a área Reports and Analytics clicando no ícone Navigator e, em seguida, selecione Tools > Reports and Analytics.
- Crie um novo modelo de dados: No painel Reports and Analytics, clique no botão 'Browse Catalog'. No catálogo, clique no menu suspenso 'New' e selecione 'Data Model'.
- Defina o conjunto de dados da consulta SQL: No editor do Data Model, clique no ícone '+' para adicionar um conjunto de dados e selecione 'SQL Query'.
- Configure a fonte de dados: Na janela do novo conjunto de dados, dê um nome descritivo, por exemplo, 'CreditCollectionsEventLog'. Selecione 'FSCM' ou o banco de dados do aplicativo Oracle Fusion adequado como fonte de dados. Defina o tipo de SQL como 'Standard SQL'.
- Insira a consulta SQL: Copie a consulta SQL completa fornecida na seção 'query' deste documento e cole-a na área de texto SQL Query.
- Defina os parâmetros da consulta: A consulta usa parâmetros como
:P_START_DATEe:P_END_DATEpara filtrar o período. O BI Publisher os detecta automaticamente. Você pode configurá-los como solicitações ao usuário e definir o tipo de dados como 'Date'. - Salve e teste o modelo de dados: Salve o modelo de dados em uma pasta compartilhada ou personalizada. Para verificar se a consulta funciona, acesse a guia 'Data', informe valores de exemplo para os parâmetros, como um período recente, e clique em 'View' para conferir uma amostra dos dados de saída. Verifique se todas as colunas aparecem corretamente.
- Crie um novo relatório: Volte ao catálogo, clique no menu suspenso 'New' e selecione 'Report'. Na caixa de diálogo 'Create Report', selecione a opção 'Use Data Model' e localize o modelo de dados que você acabou de salvar.
- Configure as propriedades do relatório: No editor de relatórios, um layout simples de tabela é suficiente para extrair os dados. Defina o formato de saída padrão. Para Process Mining, o formato recomendado é CSV. Para isso, clique em 'View a List', localize 'CSV' na lista 'Output Formats' e marque a caixa correspondente. Se quiser simplificar a experiência de uso, desmarque os outros formatos.
- Salve o relatório: Salve o relatório na mesma pasta do modelo de dados.
- Agende a extração: Para automatizar a extração, você pode agendar o relatório. Abra-o, clique em 'Actions' e selecione 'Schedule'. Configure a frequência, por exemplo, diária, especifique CSV como formato de saída e defina o destino, como um diretório do servidor de conteúdo ou um servidor externo via FTP.
Configuração
- Pré-requisitos: A pessoa que criar e executar o relatório precisa ter as funções adequadas do BI, como 'BI Administrator' ou 'BI Author', e as permissões de segurança de dados para acessar as tabelas financeiras subjacentes (AR, IEX, HZ, JTF).
- Fonte de dados: A consulta deve ser executada no banco de dados principal do aplicativo, geralmente chamado 'FSCM'.
- Parâmetros de período: É essencial usar os parâmetros
:P_START_DATEe:P_END_DATEpara limitar o volume de dados. Nos testes iniciais, use um período curto, como um mês. Em produção, é comum usar um período móvel de 3 a 6 meses. - Filtros: Em organizações grandes, considere adicionar um parâmetro
BU_NAME(nome da unidade de negócio) à cláusulaWHEREda expressão de tabela comuminvoices_basepara processar os dados de uma unidade de negócio por vez. - Considerações de performance: A consulta combina várias tabelas transacionais grandes. Executá-la para um período extenso sem filtros pode levar muito tempo ou causar timeouts no BI Publisher. Agende o relatório para horários de menor movimento.
- Formato de saída: Verifique se o formato de saída padrão ou agendado é CSV. Assim, você terá um arquivo delimitado, fácil de usar em ferramentas de Process Mining. Confira as propriedades de saída do CSV para garantir que o delimitador e a codificação de caracteres estejam configurados corretamente.
Consulta de exemplo sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Pronto para começar?
Use este Template para preparar seus dados para análise e descobrir insights valiosos sobre o processo de gestão de crédito e cobrança. Comece hoje a otimizar o processo.
Comece hoje a otimizar a gestão de crédito e a cobrança
Reduza o tempo de ciclo em 30% e fortaleça a saúde financeira no Oracle Fusion.
Não é necessário informar cartão de crédito. Comece em poucos minutos.