Seu Template de dados de Record to Report - Journal Entry
Seu Template de dados de Record to Report - Journal Entry
- Atributos recomendados para uma análise completa
- Principais atividades de lançamentos contábeis a acompanhar
- Orientações práticas para extração de dados do SAP ECC
Record to Report - Atributos dos lançamentos contábeis
| Nome | Descrição | ||
|---|---|---|---|
| Horário do evento EventTime | O timestamp que indica quando uma atividade ou evento específico ocorreu para o lançamento contábil. | ||
| Descrição O Horário do evento fornece a data e a hora exatas de cada atividade no processo de lançamento contábil. Esses dados são essenciais para calcular todas as métricas baseadas em tempo, como tempos de ciclo, durações de processamento e atrasos entre etapas. A origem desse timestamp varia conforme a atividade: pode ser a data e hora de criação do documento (CPUDT/CPUTM) ou timestamps de alteração dos logs (CDHDR-UDATE/UTIME). Na análise, o Horário do evento é usado para ordenar os eventos cronologicamente, formando a base do mapa de processo. Ele é essencial para calcular todos os KPIs relacionados a tempo, como Tempo médio de ciclo do lançamento contábil, Tempo médio de aprovação e Tempo entre aprovação e lançamento. Por que isso importa Este timestamp é a base de todas as análises relacionadas a tempo, permitindo calcular tempos de ciclo, durações e gargalos. Onde obter Obtido de vários campos, conforme a atividade, principalmente do timestamp de criação (CPUDT, CPUTM) da BKPF ou dos timestamps de alteração do documento (UDATE, UTIME) da CDHDR. Exemplos 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| ID do lançamento contábil JournalEntryId | O identificador exclusivo de um documento de contabilidade financeira, combinando o código da empresa, o número do documento e o exercício fiscal. | ||
| Descrição O ID do lançamento contábil é o principal identificador do caso para acompanhar o ciclo de vida de um lançamento contábil. É uma chave composta, normalmente formada pela concatenação do código da empresa (BUKRS), do número do documento (BELNR) e do exercício fiscal (GJAHR), garantindo exclusividade em todo o sistema SAP. Na análise de processos, esse ID vincula todas as atividades relacionadas, como criação, estacionamento, submissão, aprovação, rejeição e lançamento. Ao rastrear esse identificador, podemos construir a jornada de ponta a ponta de cada lançamento contábil, medir tempos de ciclo e identificar desvios ou gargalos do processo em lançamentos específicos. Por que isso importa Esta é a chave essencial para acompanhar um lançamento contábil desde sua criação até o lançamento final, permitindo a análise do processo de ponta a ponta e a comparação de variantes. Onde obter Este é um atributo derivado, normalmente uma concatenação de campos da tabela BKPF: código da empresa (BUKRS), número do documento (BELNR) e exercício fiscal (GJAHR). Exemplos 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nome da atividade ActivityName | O nome da atividade de negócio ou do evento ocorrido em um ponto específico do processo de lançamento contábil. | ||
| Descrição O Nome da atividade descreve uma etapa específica do ciclo de vida do lançamento contábil, como 'Lançamento contábil criado', 'Lançamento contábil aprovado' ou 'Lançamento contábil efetuado'. Esse atributo normalmente é derivado de várias fontes no SAP, incluindo códigos de transação (TCODE), logs de documentos de alteração (tabelas CDHDR e CDPOS) e campos de status do documento. Analisar atividades é o núcleo do Process Mining. Isso permite visualizar mapas de processo, calcular tempos de transição entre etapas e identificar ciclos de retrabalho, como 'Lançamento contábil rejeitado' seguido de 'Lançamento contábil corrigido'. Esses dados são fundamentais para Dashboards relacionados a tempos de ciclo, taxas de retrabalho e variantes do processo. Por que isso importa Ele define as etapas do mapa de processo, permitindo visualizar, analisar e otimizar o Workflow de lançamento contábil. Onde obter Derivado de várias fontes, incluindo códigos de transação na BKPF (TCODE), status do documento e logs de Workflow em tabelas como SWW_WI2OBJ, ou documentos de alteração em CDHDR e CDPOS. Exemplos Lançamento contábil criadoLançamento contábil aprovadoLançamento contábil rejeitadoLançamento contábil efetuado | |||
| Sistema de origem SourceSystem | O sistema do qual os dados do processo foram extraídos. | ||
| Descrição Este atributo identifica a origem dos dados, que neste caso é a instância específica do SAP ECC. Normalmente, é um valor estático adicionado durante o processo de extração dos dados. Embora seja simples, esse atributo é importante em ambientes com vários ERPs ou fontes de dados. Ele garante uma linhagem de dados clara e permite filtrar ou segmentar a análise pelo sistema de origem. Por que isso importa Fornece uma linhagem de dados clara e é essencial para acompanhar a qualidade dos dados, especialmente em ambientes com vários sistemas de origem. Onde obter Normalmente, é um valor estático adicionado durante o processo de transformação dos dados, identificando a instância específica do SAP ECC, como 'ECC_PROD_100'. Exemplos SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Última atualização dos dados LastDataUpdate | O timestamp que indica quando os dados foram extraídos ou atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração mais recente de dados do SAP ECC. É um campo de metadados essencial para entender a atualidade dos dados analisados. Em qualquer Dashboard ou análise de Process Mining, saber quando ocorreu a última atualização é fundamental para que os usuários confiem nos dados e tomem decisões informadas. Isso ajuda a responder à pergunta: 'Até que ponto estas informações estão atualizadas?'. Por que isso importa Informa os usuários sobre a atualidade dos dados, garantindo que entendam o período da análise e possam confiar nos resultados. Onde obter Este é um campo de metadados gerado e armazenado pela ferramenta de extração de dados ou pelo processo de ETL no momento da atualização dos dados. Exemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Código da empresa CompanyCode | A unidade organizacional que representa uma entidade legal independente para a qual são preparadas demonstrações financeiras. | ||
| Descrição O código da empresa é uma unidade organizacional fundamental no SAP Financials. Ele representa uma empresa legalmente independente e é um campo essencial no cabeçalho do documento de lançamento contábil. Esse atributo é essencial para segmentar a análise do processo por entidade legal. Ele permite comparar a performance do processo, as taxas de Conformidade e os resultados dos KPIs entre diferentes partes da empresa. Por exemplo, pode ajudar a identificar se atrasos na aprovação ou altas taxas de estorno são específicos de determinados códigos de empresa. Por que isso importa Permite filtrar e comparar a performance do processo entre diferentes entidades legais ou unidades de negócio da organização. Onde obter Localizado na tabela de cabeçalho de documentos BKPF, campo BUKRS. Exemplos 10002000US01DE01 | |||
| Código de transação TransactionCode | O código de transação SAP usado para criar ou processar o lançamento contábil. | ||
| Descrição O código de transação (T-Code) é um identificador exclusivo de uma função ou programa específico no SAP. Para lançamentos contábeis, ele indica como o lançamento foi criado, por exemplo, manualmente (FB01, F-02), por estacionamento (FV50) ou por uma interface automatizada. Esse atributo é muito importante para o Dashboard 'Otimização de atividades manuais'. Ao analisar o T-Code, podemos diferenciar atividades manuais e automatizadas, identificar quais processos manuais consomem mais tempo e encontrar oportunidades de automação para reduzir o esforço manual e melhorar a eficiência. Por que isso importa Ajuda a diferenciar processos manuais e automatizados, identificando oportunidades de automação e padronização do processo. Onde obter Localizado na tabela de cabeçalho de documentos BKPF, campo TCODE. Exemplos FB01F-02FV50FBD1 | |||
| Data de lançamento PostingDate | A data em que a transação é registrada no razão geral, afetando o período financeiro. | ||
| Descrição A data de lançamento determina o período fiscal em que o lançamento contábil é contabilizado. É um campo de data crítico do ponto de vista financeiro e de Conformidade, pois deve estar alinhado aos cronogramas e às regulamentações de fechamento do período contábil. No Process Mining, essa data é usada para monitorar a Conformidade. O Dashboard 'Monitoramento da adesão à Conformidade' e o KPI 'Taxa de conformidade' usam esse atributo para verificar se os lançamentos são efetuados no período correto. Ele também pode ser usado para analisar tendências no volume de lançamentos contábeis ao longo do tempo. Por que isso importa Essencial para o reporte financeiro e a análise de Conformidade, garantindo que os lançamentos sejam efetuados no período contábil correto. Onde obter Localizado na tabela de cabeçalho de documentos BKPF, campo BUDAT. Exemplos 2023-10-312023-11-302024-01-15 | |||
| Está estornado IsReversed | Um indicador booleano que informa se o lançamento contábil foi estornado. | ||
| Descrição Este indicador identifica lançamentos contábeis que foram posteriormente estornados por outro documento contábil. No SAP, um documento estornado é vinculado ao documento de estorno, fornecendo uma trilha de auditoria clara. Este atributo é fundamental para o Dashboard 'Análise de estornos de lançamentos contábeis' e o KPI 'Taxa de estorno de lançamentos contábeis'. Ele permite isolar lançamentos estornados para investigar as causas raiz, como erros de entrada de dados ou tratamentos contábeis incorretos, com o objetivo de reduzir a frequência dos estornos. Por que isso importa Dá suporte direto à análise de estornos ao sinalizar lançamentos que foram posteriormente desfeitos, ajudando a identificar as causas raiz dos erros e melhorar a integridade dos dados. Onde obter Derivado do campo de número do documento de estorno, STBLG, na tabela BKPF. Se STBLG não estiver vazio, o indicador será verdadeiro. Exemplos truefalse | |||
| Tipo de documento DocumentType | Uma classificação para documentos contábeis que controla como eles são processados e armazenados. | ||
| Descrição O tipo de documento diferencia os vários tipos de transações de negócio, como um lançamento no razão geral (SA), uma fatura de fornecedor (KR) ou um lançamento de ativo (AA). Ele é definido durante a configuração do sistema e atribuído a cada lançamento contábil. Este é um atributo crítico para a análise, pois permite segmentar o processo pela natureza da transação. O Dashboard 'Volume de lançamentos contábeis por tipo' e o KPI 'Tempo médio de ciclo por tipo de lançamento contábil' dependem diretamente desse campo. Ele ajuda a descobrir se determinados tipos de lançamento são mais propensos a atrasos, retrabalho ou estornos. Por que isso importa Permite segmentar a análise por tipo de transação, ajudando a identificar se os problemas do processo são específicos de determinados tipos de lançamento contábil. Onde obter Localizado na tabela de cabeçalho de documentos BKPF, campo BLART. Exemplos SAKRREAA | |||
| Usuário User | O ID do usuário SAP que criou ou alterou o lançamento contábil. | ||
| Descrição Este atributo registra o nome de usuário SAP responsável por uma determinada atividade, como criar, estacionar ou lançar um documento. Ele é obtido diretamente do cabeçalho do documento ou das tabelas de log de alterações. Analisar o atributo Usuário é essencial para entender a performance da equipe e dos indivíduos. Ele dá suporte ao Dashboard de produtividade do usuário, acompanhando volumes de atividade e tempos de processamento por usuário. Também ajuda a identificar quem participa de ciclos de retrabalho, estornos ou desvios de Conformidade, permitindo treinamentos ou melhorias de processo direcionados. Por que isso importa Identifica o usuário responsável por cada atividade, permitindo analisar a performance dos usuários, a distribuição da carga de trabalho e os padrões de retrabalho. Onde obter Normalmente, vem da tabela BKPF, campo USNAM, para o criador, ou da tabela CDHDR, campo USERNAME, para quem fez a alteração. Exemplos ABROWNCJONESDSMITH | |||
| Centro de custo CostCenter | Unidade organizacional dentro de uma área de controlling que representa um local onde os custos são incorridos. | ||
| Descrição O centro de custo é um elemento essencial dos dados mestres do módulo de Controlling (CO), geralmente atribuído no nível do item de linha do lançamento contábil. Ele é usado para acompanhar os custos de um departamento, função ou local específico. Incluir o centro de custo permite uma análise mais detalhada do processo de lançamento contábil. Isso pode ajudar a determinar se determinados departamentos geram mais retrabalho, têm tempos de ciclo mais longos ou são responsáveis por um volume maior de lançamentos manuais. Assim, você consegue analisar a eficiência do processo por departamento. Por que isso importa Permite analisar a performance do processo por departamento ou área funcional, ajudando a localizar ineficiências específicas. Onde obter Localizado na tabela de itens de linha do documento BSEG, campo KOSTL. Exemplos 4100CC_FINANCE_US10010101 | |||
| Código da moeda CurrencyKey | O código da moeda dos valores registrados no lançamento contábil. | ||
| Descrição Este atributo especifica a moeda do lançamento contábil, como USD, EUR ou JPY. Ele fornece contexto para todos os valores financeiros associados ao documento. Embora nem sempre seja uma dimensão primária da análise, é essencial para interpretar corretamente os valores monetários. Também pode ser usado para segmentar a análise em organizações globais e verificar se os processos diferem para lançamentos em moedas estrangeiras e locais. Por que isso importa Fornece o contexto necessário para todos os valores monetários, garantindo uma análise e interpretação financeiras precisas. Onde obter Localizado na tabela de cabeçalho de documentos BKPF, campo WAERS. Exemplos USDEURGBPJPY | |||
| É retrabalho IsRework | Indicador booleano que informa se um lançamento contábil passou por um ciclo de retrabalho, como ser rejeitado e depois corrigido. | ||
| Descrição Esse indicador identifica os casos que se desviaram do 'caminho ideal' e exigiram uma ação corretiva. Normalmente, ele recebe o valor true quando uma sequência de atividades como 'Journal Entry Rejected' seguida de 'Journal Entry Corrected' é observada para um determinado lançamento contábil. Esse atributo é essencial para calcular o KPI 'Journal Entry Rework Rate' e analisar o Dashboard 'Rework and Rejection Rate'. Ele ajuda a quantificar o nível de ineficiência do processo e fornece uma base para investigar as causas-raiz do retrabalho, como requisitos pouco claros ou documentação insuficiente. Por que isso importa Sinaliza os lançamentos que exigiram correção, permitindo quantificar o retrabalho e analisar suas causas-raiz para melhorar as taxas de acerto na primeira execução. Onde obter É um atributo calculado, derivado da análise da sequência de atividades de um caso. Um ciclo de retrabalho é identificado quando ocorre uma atividade de rejeição ou correção. Exemplos truefalse | |||
| Está estacionado IsParked | Indicador booleano que informa se o lançamento contábil foi salvo como documento estacionado antes de ser lançado. | ||
| Descrição Estacionar um documento permite que o usuário salve um lançamento contábil incompleto sem afetar os saldos financeiros. Depois, outro usuário pode concluí-lo ou revisá-lo antes do lançamento. Esse indicador identifica os lançamentos que passaram por uma etapa de estacionamento. Analisar esse atributo ajuda a entender o uso do recurso de estacionamento. Ele pode revelar se o estacionamento está sendo usado como uma etapa informal de revisão, causando possíveis atrasos. Também apoia a análise do tempo de ciclo de ponta a ponta, diferenciando os lançamentos feitos diretamente daqueles estacionados primeiro. Por que isso importa Identifica os lançamentos que usam o recurso de estacionamento, que pode ser uma fonte de atraso ou um indicador de um processo informal de revisão. Onde obter Derivado do campo de status do documento (BSTAT) na tabela BKPF. O valor 'V' indica um documento estacionado. Exemplos truefalse | |||
| Motivo do estorno ReversalReason | Um código que indica o motivo pelo qual um lançamento contábil foi estornado. | ||
| Descrição Quando um documento é estornado, o SAP permite que o usuário especifique um código de motivo. Esse código fornece informações estruturadas sobre por que o estorno foi necessário, por exemplo, data de lançamento incorreta ou erro de entrada de dados. Esse atributo é uma entrada essencial para o Dashboard "Journal Entry Reversal Analysis". Ao analisar os motivos de estorno mais comuns, as organizações podem identificar problemas sistêmicos nos processos ou lacunas de treinamento, além de tomar ações direcionadas para evitar erros futuros e reduzir a taxa de estorno. Por que isso importa Fornece um insight direto sobre os motivos dos estornos, permitindo uma análise direcionada das causas-raiz para reduzir erros futuros. Onde obter Localizado na tabela de cabeçalho do documento BKPF, campo STGRD. Exemplos 010205 | |||
| Tempo de aprovação ApprovalTime | Tempo decorrido desde o envio de um lançamento contábil para aprovação até sua aprovação ou rejeição. | ||
| Descrição Essa métrica mede a duração do subprocesso de aprovação, que costuma contribuir significativamente para o tempo de ciclo total. Ela é calculada como a diferença de tempo entre a atividade 'Journal Entry Submitted' e a atividade correspondente 'Journal Entry Approved' ou 'Journal Entry Rejected'. O tempo de aprovação é a métrica principal do Dashboard 'Journal Entry Approval Performance' e do KPI 'Average Journal Entry Approval Time'. Analisar essa duração ajuda a identificar gargalos no Workflow de aprovação, medir a performance dos aprovadores e justificar mudanças no processo, como o ajuste dos limites de aprovação. Por que isso importa Quantifica a duração da etapa de aprovação, ajudando a localizar e resolver atrasos no Workflow de revisão e aprovação. Onde obter Calculado subtraindo o timestamp do evento 'Journal Entry Submitted' do timestamp do evento 'Journal Entry Approved' ou 'Journal Entry Rejected'. Exemplos P1DT2HPT4H15MP3D | |||
| Valor total do documento TotalDocumentAmount | O valor total do lançamento contábil na moeda do documento. | ||
| Descrição Este atributo representa o valor financeiro total do lançamento contábil. Normalmente, ele é calculado somando os valores absolutos de todos os itens de débito ou crédito associados ao documento. Analisar o processo por valor financeiro pode revelar padrões importantes. Por exemplo, lançamentos de alto valor podem seguir um caminho de aprovação diferente e mais rigoroso. Este atributo pode ser usado para filtrar ou segmentar a análise e verificar se tempos de ciclo, taxas de rejeição ou atrasos na aprovação estão relacionados ao valor do lançamento. Por que isso importa Permite analisar o impacto financeiro, como correlacionar tempos de processamento ou taxas de rejeição ao valor monetário dos lançamentos contábeis. Onde obter Este é um campo calculado, derivado da agregação do campo de valor, WRBTR ou DMBTR, de todos os itens de linha da tabela BSEG para um determinado lançamento contábil. Exemplos 1500.0025000.75125.50 | |||
Record to Report - Atividades dos lançamentos contábeis
| Atividade | Descrição | ||
|---|---|---|---|
| Lançamento contábil aprovado | Esta atividade marca a aprovação final de um lançamento contábil dentro de um Workflow, tornando-o elegível para lançamento. O evento é capturado no log do Workflow quando a etapa final de 'liberação' ou 'aprovação' é concluída. | ||
| Por que isso importa Este é um marco importante que encerra o processo de aprovação. A duração até esta atividade é um KPI crítico da eficiência da aprovação, e o tempo entre este evento e o lançamento mede o atraso pós-aprovação. Onde obter Inferido a partir do timestamp de conclusão da etapa final de aprovação no log do SAP Business Workflow. Esta é a última ação de aprovação antes de o documento ser lançado ou ficar pronto para lançamento. Captura Identifique a conclusão da etapa final de 'liberação' ou 'aprovação' nos logs do Workflow. Tipo de evento inferred | |||
| Lançamento contábil efetuado | Esta é a atividade central em que o lançamento contábil é oficialmente registrado no razão geral, afetando as demonstrações financeiras. O evento é capturado explicitamente quando o status do documento é definido como 'lançado' e uma data de lançamento é atribuída. | ||
| Por que isso importa Este é o marco mais importante, pois indica o processamento bem-sucedido de um lançamento contábil. O tempo de ciclo de ponta a ponta costuma ser medido até este ponto, que também é um evento essencial para a análise do fechamento financeiro. Onde obter Identificado quando um documento na tabela BKPF tem uma data de lançamento, BKPF-BUDAT. Para documentos estacionados, isso corresponde ao momento em que o status BKPF-BSTAT muda de 'V' para em branco. O timestamp do lançamento é a data de entrada BKPF-CPUDT. Captura Identifique quando BKPF-BSTAT muda de 'V' para em branco ou, em lançamentos diretos, o evento de criação. Tipo de evento explicit | |||
| Lançamento contábil estacionado | Esta atividade marca a criação inicial de um lançamento contábil em estado preliminar, antes de seu lançamento oficial no razão geral. Isso é registrado explicitamente no SAP quando um usuário salva um documento usando uma transação de estacionamento, definindo o status do documento como 'estacionado'. | ||
| Por que isso importa Este é um evento inicial crítico para processos que envolvem revisão e aprovação. Analisar o tempo entre o estacionamento e o lançamento ajuda a identificar atrasos nas etapas de pré-lançamento e aprovação. Onde obter Este evento é identificado na tabela de cabeçalho de documentos BKPF. Um documento é considerado estacionado quando é criado com o status BKPF-BSTAT = 'V'. O timestamp do evento corresponde à data e hora de criação, BKPF-CPUDT e BKPF-CPUTM. Captura Identifique a criação do documento na BKPF quando BKPF-BSTAT for 'V'. Tipo de evento explicit | |||
| Lançamento contábil submetido | Esta atividade indica que um lançamento contábil estacionado foi finalizado por seu criador e agora está pronto para revisão e aprovação. Normalmente, ela é registrada pelo início de uma tarefa do SAP Business Workflow associada ao documento estacionado. | ||
| Por que isso importa Isso marca a transferência do criador para o aprovador e inicia a contagem do tempo de ciclo de aprovação dos KPIs. É um marco importante para medir a eficiência do Workflow de aprovação. Onde obter Inferido a partir do horário de início da instância do Workflow de aprovação vinculada ao objeto do documento financeiro. Isso exige analisar tabelas de log do Workflow, como SWW_WI2OBJ, para localizar o Workflow iniciado para o código da empresa, o número do documento e o exercício fiscal específicos. Captura Identifique o evento de início do Workflow para o objeto do documento estacionado. Tipo de evento inferred | |||
| Processo de estorno do lançamento contábil concluído | Esta atividade marca o estorno de um lançamento contábil efetuado anteriormente. Um estorno é um novo documento contábil que anula o lançamento original. | ||
| Por que isso importa Este é um evento crítico para medir a qualidade dos dados e a precisão do processo. Uma alta taxa de estornos aponta para problemas sistêmicos nas etapas iniciais de entrada ou aprovação dos dados, e cada estorno representa retrabalho. Onde obter Este evento é identificado no cabeçalho do documento original, na tabela BKPF. Quando um documento é estornado, o SAP preenche o número do documento de estorno, BKPF-STBLG, e o motivo do estorno, BKPF-STGRD. O timestamp do evento é a data de lançamento do novo documento de estorno. Captura Identifique quando BKPF-STBLG é preenchido no documento original; o timestamp é a data de lançamento do documento de estorno. Tipo de evento explicit | |||
| Alterações solicitadas no lançamento contábil | Representa um ponto do Workflow em que um aprovador revisou o lançamento contábil e o devolveu ao criador para correção. Este evento é capturado nos logs do Workflow, que indicam uma decisão do usuário de 'rejeitar' ou 'devolver'. | ||
| Por que isso importa Esta atividade é essencial para identificar ciclos de retrabalho, uma das principais fontes de ineficiência e desvios do processo. A alta frequência desse evento indica problemas na qualidade do lançamento ou requisitos pouco claros. Onde obter Este evento é inferido a partir do timestamp de uma etapa específica de decisão do usuário no log do SAP Business Workflow, correspondente a uma ação de 'rejeitar' ou 'enviar para correção'. Captura Identifique o timestamp da decisão de 'rejeição' ou 'retrabalho' nos logs do Workflow. Tipo de evento inferred | |||
| Documentação anexada | Esta atividade representa o anexo, por um usuário, de documentos de suporte, como notas fiscais ou planilhas, ao lançamento contábil. Esse evento não é registrado explicitamente como um evento contábil padrão e normalmente é inferido verificando a criação de anexos vinculados ao objeto do documento contábil. | ||
| Por que isso importa Acompanhar esta atividade ajuda a verificar a Conformidade com políticas que exigem documentação. Atrasos no anexo de documentos podem ser uma causa raiz de ciclos de aprovação prolongados. Onde obter É difícil capturar este evento de forma confiável com um timestamp. Ele pode ser inferido analisando as tabelas de anexos do Generic Object Services (GOS), como SOOD, e vinculando o timestamp de criação do anexo à chave do objeto do lançamento contábil. Captura Inferir a partir do timestamp de criação dos objetos vinculados nas tabelas do GOS, como SOOD. Tipo de evento inferred | |||
| Entrada manual identificada | Esta atividade identifica se um lançamento contábil foi criado por uma transação manual online, em vez de uma interface automatizada ou um processo em lote. Não é uma ação do usuário, mas um atributo calculado do lançamento, derivado dos dados do sistema. | ||
| Por que isso importa Diferenciar lançamentos manuais e automatizados é essencial para direcionar melhorias no processo. Os processos manuais costumam ser o foco de iniciativas de padronização e automação. Onde obter Isso é calculado pela análise dos campos da tabela de cabeçalho de documentos BKPF. Códigos de transação, como 'FB01', 'FB50' ou 'FV50', em BKPF-TCODE indicam uma entrada manual, enquanto outros T-codes ou nomes específicos de entrada em lote, em BKPF-AWKEY, sugerem automação. Captura Derive de BKPF-TCODE ou de outros indicadores do sistema de origem no cabeçalho do documento. Tipo de evento calculated | |||
| Item de linha do lançamento contábil compensado | Esta atividade representa a conciliação de um item de linha de uma conta do razão geral gerenciada por itens em aberto, como uma conta de compensação bancária. Ela ocorre quando um item é associado a outro, encerrando-o. | ||
| Por que isso importa Em processos como a conciliação bancária, o tempo para compensar itens é um KPI essencial. Esta atividade ajuda a analisar a eficiência da conciliação e dos procedimentos de fechamento mensal. Onde obter Este evento é capturado na tabela de itens de linha BSEG. Quando um item de linha é compensado, os campos de data de compensação, BSEG-AUGDT, e documento de compensação, BSEG-AUGBL, são preenchidos. O timestamp do evento é a data de compensação. Captura Identifique quando a data de compensação, BSEG-AUGDT, é preenchida para um item de linha. Tipo de evento explicit | |||
| Lançamento contábil corrigido | Esta atividade indica que o criador original modificou um lançamento contábil estacionado depois que ele foi devolvido para alterações. Ela é inferida pela detecção de alterações no documento após um evento de 'Alterações solicitadas'. | ||
| Por que isso importa Acompanhar as correções ajuda a quantificar o esforço gasto com retrabalho. O tempo entre a solicitação de alteração e a correção evidencia atrasos na resolução de problemas dos lançamentos submetidos. Onde obter Inferido pela análise dos logs de documentos de alteração, nas tabelas CDHDR e CDPOS, para o documento estacionado. Uma alteração registrada após um evento de rejeição no Workflow indica que uma correção foi feita. O timestamp vem da tabela CDHDR. Captura Identifique a entrada do log de alterações em CDHDR/CDPOS após um evento de rejeição. Tipo de evento inferred | |||
| Lançamento contábil criado | Representa a criação de um lançamento contábil que é lançado diretamente, sem uma etapa anterior de estacionamento. Isso é registrado quando um documento é criado no SAP usando uma transação de lançamento direto. | ||
| Por que isso importa Esta atividade funciona como um ponto de início alternativo para processos mais simples de lançamento contábil que não exigem um Workflow de aprovação. Ela ajuda a diferenciar lançamentos simples e diretos de lançamentos estacionados mais complexos. Onde obter Este evento corresponde à criação do documento na tabela BKPF quando o status do documento BKPF-BSTAT está em branco, indicando que foi lançado. O timestamp do evento é a data de criação, BKPF-CPUDT. Para esses documentos, os eventos 'Criado' e 'Lançado' ocorrem simultaneamente. Captura Identifique a criação do documento na BKPF quando BKPF-BSTAT estiver em branco. Tipo de evento explicit | |||
| Lançamento contábil estacionado excluído | Representa a exclusão de um lançamento contábil estacionado que nunca foi lançado. Isso pode ocorrer após uma rejeição ou quando o lançamento foi criado por engano. | ||
| Por que isso importa Esta atividade marca um encerramento malsucedido do processo. Analisar por que documentos estacionados são excluídos pode revelar problemas como lançamentos duplicados ou falhas de entendimento do processo. Onde obter Este evento é capturado quando o status de um documento estacionado na tabela BKPF é alterado. O campo de status BKPF-BSTAT é atualizado para 'Z', indicando documento estacionado excluído. O timestamp da alteração pode ser encontrado nos logs de alterações do documento, CDHDR. Captura Identifique quando BKPF-BSTAT é atualizado para 'Z'. Tipo de evento explicit | |||
| Lançamento contábil rejeitado | Esta atividade indica a rejeição final de um lançamento contábil, que não será lançado depois disso. Normalmente, esse é um status terminal em um Workflow de aprovação, levando à eventual exclusão do documento estacionado. | ||
| Por que isso importa Acompanhar rejeições é essencial para a gestão da qualidade. Analisar os motivos e a frequência das rejeições ajuda a melhorar a taxa de acerto na primeira tentativa dos lançamentos contábeis. Onde obter Este é um resultado capturado no log do SAP Business Workflow, representando uma decisão final do usuário de 'rejeitar' que encerra o processo. O documento estacionado pode ser excluído posteriormente. Captura Identifique o status terminal de 'rejeitado' no log do Workflow do documento. Tipo de evento inferred | |||
| Lançamento entre empresas identificado | Uma atividade calculada que sinaliza um lançamento contábil que afeta mais de um código de empresa. Isso é determinado pela análise dos itens de linha de um único documento financeiro. | ||
| Por que isso importa Transações entre empresas podem ter requisitos de processamento e aprovação mais complexos. Identificá-las permite analisar separadamente seus tempos de ciclo e caminhos do processo para encontrar gargalos específicos. Onde obter Calculado examinando a tabela de itens de linha BSEG para um determinado número de documento, BELNR. Se os itens de linha contiverem mais de um código de empresa distinto, BSEG-BUKRS, o lançamento será entre empresas. Captura Verifique se existem vários valores exclusivos de BSEG-BUKRS para um único BKPF-BELNR. Tipo de evento calculated | |||
Guias de extração
Etapas
- Crie o programa ABAP: No sistema SAP, acesse o código de transação SE38 (Editor ABAP). Informe um nome para o novo programa, por exemplo, Z_PM_JE_EXTRACTION, e clique em Criar. Forneça um título adequado e defina o tipo do programa como 'Programa executável'.
- Defina a tela de seleção: No código-fonte do programa, defina a tela de seleção. Ela permite que os usuários especifiquem parâmetros como um intervalo de datas para a criação de documentos, códigos de empresa e tipos de documento, limitando o volume de dados da extração.
- Declare as estruturas de dados: Defina uma estrutura de tabela interna que armazenará os dados finais do Event Log. Essa estrutura deve incluir todos os campos obrigatórios: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate e atributos recomendados, como User, CompanyCode e PostingDate.
- Implemente a lógica de seleção de dados: Escreva as consultas SQL ABAP principais para extrair dados de cada uma das 14 atividades obrigatórias. Isso envolve selecionar dados de tabelas principais, como BKPF (cabeçalho) e BSEG (item de linha), tabelas de logs de alterações, como CDHDR e CDPOS, tabelas de Workflow, como SWWLOGHIST, e tabelas de compensação, como BSAS e BSAK.
- Extraia documentos estacionados e lançados: Para eventos 'Journal Entry Parked', selecione na BKPF os registros cujo status do documento (BSTAT) seja 'V'. Para os eventos 'Journal Entry Created' e 'Journal Entry Posted', selecione na BKPF os registros cujo status esteja em branco, indicando um documento normal e lançado.
- Extraia eventos de alteração e exclusão: Consulte as tabelas de documentos de alteração CDHDR e CDPOS para a classe de objeto 'BELEG'. Filtre pela chave do documento para encontrar alterações correspondentes às atividades 'Journal Entry Corrected' ou 'Parked Journal Entry Deleted'.
- Extraia eventos de Workflow: Para capturar atividades como 'Journal Entry Submitted', 'Approved', 'Rejected' e 'Changes Requested', consulte as tabelas de Workflow. Use a tabela SWW_WI2OBJ para vincular o documento contábil a uma instância de Workflow e, em seguida, leia a SWWLOGHIST para identificar decisões específicas dos usuários ou alterações de status.
- Identifique eventos calculados: Para 'Manual Entry Identified', verifique o código de transação (BKPF-TCODE) em relação a uma lista de códigos de transação manuais conhecidos. Para 'Cross-Company Posting Identified', analise os itens de linha da BSEG de um determinado documento para verificar se há vários códigos de empresa envolvidos.
- Consolide e transforme os dados: Conforme os dados de cada atividade forem selecionados, transforme-os na estrutura final do Event Log. Concatene Company Code, Document Number e Fiscal Year para criar o JournalEntryId. Converta as datas e horas do SAP em um único timestamp EventTime. Anexe os resultados de cada consulta à tabela interna final.
- Implemente a exportação do arquivo: Use instruções de manipulação de arquivos ABAP, como OPEN DATASET, LOOP AT, TRANSFER e CLOSE DATASET, para gravar a tabela interna consolidada em um arquivo CSV ou arquivo simples no diretório do servidor de aplicação SAP, que pode ser visualizado pela transação AL11.
- Agende como job em segundo plano: Acesse a transação SM36 (Definir job em segundo plano). Crie um novo job, defina uma etapa que execute seu programa ABAP e configure uma agenda, por exemplo, noturna ou semanal em horários de menor demanda, para automatizar o processo de extração.
- Recupere e formate o arquivo: Use a transação CG3Y ou trabalhe com o administrador do sistema para baixar o arquivo gerado do servidor de aplicação para sua máquina local. Garanta que a codificação e o formato do arquivo sejam adequados para o upload na sua ferramenta de Process Mining.
Configuração
- Intervalo de datas: É fundamental definir um intervalo de datas para gerenciar a performance. Use a data de criação do documento (BKPF-CPUDT) como filtro principal. Para uma análise inicial, recomenda-se um período de 3 a 6 meses. Para testes, use um intervalo de alguns dias que você saiba que contém dados.
- Filtro por código de empresa: Sempre filtre pelo código de empresa (BKPF-BUKRS). Extrair dados de todos os códigos de empresa de uma só vez pode consumir muitos recursos. Comece com um ou com um pequeno grupo de códigos de empresa relevantes.
- Filtro por tipo de documento: Use o filtro de tipo de documento (BKPF-BLART) para restringir o escopo a tipos específicos de lançamentos contábeis, como 'SA' para documentos do razão geral, caso você não precise analisar todos os tipos de documento.
- IDs de Task do Workflow: A lógica para extrair eventos de Workflow depende dos IDs de Task específicos usados no seu sistema para aprovação, rejeição e envio. Esses IDs devem ser configurados no código-fonte do programa com base nas definições de Workflow da sua empresa.
- Considerações de performance: O programa faz junções entre várias tabelas grandes, especialmente CDPOS e as tabelas de histórico do Workflow. Executá-lo durante o horário comercial de maior demanda pode afetar a performance do sistema. Sempre agende-o como um job em segundo plano para execução em horários de menor demanda. Considere criar índices secundários no banco de dados se a performance for um problema recorrente.
- Pré-requisitos: Este método exige um usuário com autorizações de desenvolvimento ABAP (para a SE38) e permissões para criar e gerenciar jobs em segundo plano (para a SM36). O usuário ou job também precisa de acesso de leitura a todas as tabelas financeiras, de Workflow e do sistema relevantes (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST etc.).
a Consulta de exemplo abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Etapas
- Estabeleça a conexão com o banco de dados: Obtenha credenciais somente leitura para o banco de dados do SAP ECC. Use um cliente SQL padrão, como DBeaver, SAP HANA Studio ou SQL Server Management Studio, para conectar-se ao banco de dados.
- Prepare a consulta SQL: Copie a consulta SQL completa fornecida na seção 'query' deste documento para o seu cliente SQL.
- Defina os parâmetros de extração: Antes de executar, configure os placeholders na consulta. Substitua '[START_DATE]' e '[END_DATE]' pelo intervalo de datas desejado no formato 'YYYYMMDD'. Substitua '[COMPANY_CODE_1]' e '[COMPANY_CODE_2]' pelos códigos de empresa SAP específicos que você deseja analisar.
- Defina o sistema de origem: Na instrução
SELECTprincipal, substitua o placeholder '[Your SAP System ID]' pelo SID real do sistema SAP para identificar corretamente a origem dos dados. - Execute a consulta: Execute a consulta SQL configurada no banco de dados SAP. O tempo de execução varia conforme o intervalo de datas e o tamanho das tabelas do banco de dados.
- Revise os resultados iniciais: Quando a consulta for concluída, faça uma verificação rápida das linhas retornadas para garantir que os dados foram preenchidos conforme esperado. Confira se há diferentes atividades e se campos essenciais, como
JournalEntryIdeEventTime, não estão vazios. - Trate os timestamps: A consulta concatena os campos de data e hora em uma string
YYYYMMDDHHMMSS. Garanta que o pós-processamento ou o sistema de destino consiga interpretar esse formato ou ajuste a função SQLCONCATpara um formato ISO 8601, comoYYYY-MM-DDTHH:MI:SS, se o banco de dados for compatível. - Exporte os dados: Exporte o conjunto completo de resultados do seu cliente SQL para um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres especiais.
- Prepare o upload: Antes de fazer o upload para uma ferramenta de Process Mining, confirme se os cabeçalhos das colunas correspondem ao esquema de dados exigido.
JournalEntryId,ActivityNameeEventTimesão essenciais. Adicione a colunaLastDataUpdate, preenchendo-a com o timestamp de quando a extração foi realizada. - Validação final: Execute as etapas descritas na seção 'validationSteps' para garantir que os dados extraídos estejam completos e precisos antes de iniciar a análise.
Configuração
- Autorizações do banco de dados: O usuário do banco de dados precisa de acesso de leitura às seguintes tabelas SAP: BKPF, BSEG, CDHDR, CDPOS, T001 e V_USERNAME. Para atividades relacionadas ao Workflow, também é necessário acesso a SWW_WI2OBJ e SWWLOGHIST. Esse nível de acesso normalmente é concedido apenas a equipes técnicas especializadas.
- Filtragem por intervalo de datas: É fundamental filtrar os dados por um intervalo de datas específico para garantir a performance da consulta. A consulta fornecida usa placeholders para as datas inicial e final, aplicadas à data de criação do documento (
BKPF.CPUDT). Para uma análise inicial, recomenda-se um intervalo de 3 a 6 meses. - Filtragem por entidade: Para gerenciar o volume de dados e concentrar a análise, sempre filtre pelo código de empresa (
BKPF.BUKRS). Você também pode considerar a filtragem por tipo de documento (BKPF.BLART) para incluir apenas os tipos de lançamento contábil relevantes, como 'SA' para documentos do razão geral, e excluir documentos operacionais, como faturas ou pagamentos, caso estejam fora do escopo. - Considerações de performance: Consultas diretas em tabelas principais, como BSEG e CDPOS, podem consumir muitos recursos. É altamente recomendável executar essa extração fora do horário de pico para evitar impactos na performance do sistema para os usuários finais. Evite extrair dados de mais de um ano em uma única execução.
- IDs de Task do Workflow: A consulta contém placeholders como '[WF_TASK_ID_SUBMIT]' e '[WF_TASK_ID_APPROVE]'. Eles devem ser substituídos pelos IDs de Task reais da configuração específica de Workflow de lançamentos contábeis do seu sistema. Você pode identificá-los com o apoio de um especialista em SAP Workflow ou analisando a definição técnica do Workflow na transação PFTC.
a Consulta de exemplo sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Etapas
- Estabeleça a conexão com o SAP: na sua ferramenta ETL de terceiros, configure uma nova conexão de origem com o seu sistema SAP ECC. Normalmente, isso exige os dados do servidor de aplicação, o cliente, o número do sistema e um usuário SAP dedicado com as autorizações RFC necessárias.
- Defina as fontes de dados: no projeto de extração, adicione as tabelas SAP necessárias como fontes de dados. As principais tabelas incluem BKPF (cabeçalho do documento contábil), BSEG (segmento do documento contábil), VBSEGK (cabeçalho do documento estacionado), CDHDR (cabeçalho do documento de alteração), CDPOS (itens do documento de alteração), SWW_WI2OBJ (links entre Workflow e objeto), SWWLOGHIST (log do Workflow) e SRGBTBREL (relações para anexos do GOS).
- Extraia os eventos básicos (criado e estacionado): crie o primeiro fluxo de dados para extrair os eventos iniciais. Para 'Lançamento contábil estacionado', use VBSEGK como origem. Para 'Lançamento contábil criado', use BKPF, filtrando os documentos que não são estornos e que não foram inicialmente estacionados. Isso pode ser feito com uma antijunção com VBSEGK.
- Extraia os eventos do Workflow: crie um fluxo de dados que una BKPF a SWW_WI2OBJ usando a chave do objeto, composta pelo código da empresa, número do documento e exercício fiscal, para encontrar o ID da instância do Workflow. Una esse resultado a SWWLOGHIST para extrair eventos como 'Enviado', 'Aprovado', 'Rejeitado' e 'Alterações solicitadas', com base nos resultados das tarefas do Workflow e nas decisões dos usuários registradas no log.
- Extraia os eventos de alteração e exclusão: use as tabelas CDHDR e CDPOS para identificar alterações. Para 'Lançamento contábil corrigido', filtre as alterações feitas em documentos estacionados, com a classe de objeto 'FIPP'. Para 'Lançamento contábil estacionado excluído', procure marcadores de exclusão nos logs de alteração dos documentos estacionados.
- Extraia os eventos de anexos: para capturar 'Documentação anexada', una BKPF a SRGBTBREL quando o tipo de objeto for 'BKPF' e a relação for '[Your attachment relationship type]'. A data de criação do link será o horário do evento.
- Extraia os eventos de compensação e estorno: para 'Item do lançamento contábil compensado', consulte a tabela BSEG quando o campo do documento de compensação, AUGBL, estiver preenchido. O horário do evento será a data de lançamento do documento de compensação, AUGDT. Para 'Processo de estorno do lançamento contábil concluído', consulte a BKPF em busca de documentos de estorno, identificados por um valor no campo do documento estornado, STBLG.
- Derive os eventos calculados: crie blocos de lógica separados para os eventos calculados. Para 'Lançamento manual identificado', filtre a BKPF com base em uma lista de códigos de transação manuais, como FB01, FB50 e F-02. Para 'Lançamento entre empresas identificado', agrupe a tabela BSEG por ID do documento e identifique os documentos com mais de um código de empresa distinto.
- Combine todos os fluxos de eventos: use uma transformação UNION na ferramenta ETL para mesclar as saídas de todos os fluxos de eventos individuais, como criado, estacionado e aprovado, em uma única tabela de Event Log. Garanta que os nomes e os tipos de dados das colunas sejam consistentes em todos os fluxos.
- Mapeie para o esquema final: mapeie os dados combinados para a estrutura necessária do Event Log, criando
JournalEntryId,ActivityName,EventTime,Usuárioe os demais atributos necessários e recomendados. Adicione colunas estáticas, comoSourceSystem, e use o horário de execução do job ETL paraLastDataUpdate. - Configure o carregamento incremental: para extrações contínuas, configure uma estratégia de carregamento incremental. Use a última data de criação ou alteração, como BKPF.CPUDT ou CDHDR.UDATE, como marcador para buscar apenas os registros novos ou atualizados desde a última execução.
- Exporte para o ProcessMind: agende o job de extração e configure a etapa final para salvar o Event Log como arquivo CSV ou Parquet em um local acessível ao ProcessMind para carregamento.
Configuração
- Pré-requisitos: uma ferramenta ETL de terceiros licenciada, como Theobald Xtract Universal, Informatica ou Talend, com um conector SAP dedicado. Uma conta de usuário SAP com acesso RFC e autorizações para ler tabelas financeiras, como S_TABU_DIS para os grupos de tabelas F_00 e F_WF, além de dados do Workflow e logs de alteração.
- Parâmetros de conexão: você precisará do IP ou nome do host do servidor de aplicação SAP, do número do sistema e do ID do cliente. Use um gerenciamento seguro de credenciais para o nome de usuário e a senha do SAP.
- Filtros principais: sempre aplique filtros para Código da empresa (BKPF.BUKRS) e Exercício fiscal (BKPF.GJAHR) na origem, limitando o volume de dados. É altamente recomendável filtrar também pela Data de criação do documento (BKPF.CPUDT) para definir um período específico de extração, como os últimos 6 meses.
- Seleção do período: para o carregamento inicial, selecione um período representativo, como 3 a 6 meses. Para os carregamentos delta seguintes, use um watermark em um campo de timestamp, como
CPUDT, para buscar somente registros novos. - Considerações de performance: os joins em BSEG, CDPOS e nas tabelas do Workflow podem ser muito lentos. Garanta que sua ferramenta ETL envie os filtros para a origem SAP sempre que possível. Extraia os dados em blocos ou pacotes menores se a ferramenta permitir, especialmente em carregamentos históricos grandes.
- Personalização do Workflow: a lógica para identificar atividades do Workflow, como “Aprovado” ou “Rejeitado”, depende muito dos seus Templates de Workflow específicos. Você precisará identificar no seu sistema os IDs corretos das tarefas do Workflow e as chaves de decisão dos usuários para usá-los nos filtros.
a Consulta de exemplo sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Pronto para começar?
Use este Template de dados para iniciar sua jornada de Process Mining em Record to Report - Journal Entry. Obtenha insights mais profundos e aumente a eficiência das suas operações financeiras.
Otimize seu Record to Report - Journal Entry agora
Reduza em 30% o tempo de ciclo de Journal Entry e garanta relatórios impecáveis.
Não é necessário cartão de crédito. Comece a melhorar hoje.