Seu Template de dados de Record to Report - Lançamento contábil
Seu Template de dados de Record to Report - Lançamento contábil
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações práticas para extração
Record to Report - Atributos dos lançamentos contábeis
| Nome | Descrição | ||
|---|---|---|---|
| Atividade ActivityName | O nome da atividade de negócio que ocorreu em um ponto específico do processo de lançamentos contábeis. | ||
| Descrição A atividade representa uma etapa ou um evento específico do ciclo de vida de um lançamento contábil, como “Lançamento contábil criado”, “Lançamento contábil enviado para revisão” ou “Lançamento contábil efetuado”. Essas atividades normalmente são derivadas de registros de alteração, atualizações de status ou códigos de transação registrados no sistema. Analisar as atividades permite visualizar o fluxo do processo, identificar caminhos comuns e descobrir desvios do procedimento padrão. Esse é um elemento fundamental para calcular métricas como frequência das atividades, tempos de espera entre etapas e taxas de conformidade. Por que isso importa Ele define as etapas do processo, permitindo visualizar mapas de processo e analisar padrões de Workflow. Onde obter Derivada de várias fontes, incluindo campos de status em tabelas de cabeçalho e itens, como BKPF-BSTAT, registros de documentos de alteração (CDHDR/CDPOS) e registros de Workflow. Exemplos Lançamento contábil criadoLançamento contábil estacionadoLançamento contábil enviado para revisãoLançamento contábil aprovadoLançamento contábil efetuado | |||
| Hora do evento EventTime | O registro de data e hora que indica quando uma atividade específica ocorreu para o lançamento contábil. | ||
| Descrição A hora do evento é a data e a hora exatas em que uma atividade de negócio foi executada e registrada no sistema. Cada atividade de um caso tem seu próprio registro de data e hora, criando uma sequência cronológica de eventos. Esse Atributo é essencial para todas as análises de processo baseadas em tempo. Ele é usado para calcular tempos de ciclo, durações entre atividades, tempos de espera e a distribuição temporal do trabalho. Registros de data e hora precisos são essenciais para construir um modelo de processo confiável e calcular KPIs importantes, como o tempo do ciclo de aprovação. Por que isso importa Ele fornece a ordem cronológica dos eventos, essencial para calcular todas as métricas baseadas em duração e entender a linha do tempo do processo. Onde obter Obtida de registros de documentos de alteração (CDHDR-UDATE, CDHDR-UTIME), registros de Workflow ou registros de criação e entrada em tabelas como BKPF (CPUDT, CPUTM). Exemplos 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| ID do lançamento contábil JournalEntryId | O identificador exclusivo de um lançamento contábil financeiro, que funciona como o identificador principal do caso no processo. | ||
| Descrição O ID do lançamento contábil é um número exclusivo atribuído a cada documento contábil quando ele é criado no SAP S/4HANA. Esse identificador é essencial para acompanhar todo o ciclo de vida de um lançamento contábil, desde sua criação ou seu estacionamento inicial, passando pelos Workflows de aprovação, até seu lançamento final e possível estorno ou compensação. Na análise de Process Mining, esse ID é usado para vincular todas as atividades relacionadas em um único caso. Ao agrupar os eventos sob um ID de lançamento contábil comum, os analistas podem reconstruir o fluxo ponta a ponta do processo, medir os tempos de ciclo e identificar variações ou gargalos de cada transação financeira específica. Esse é o Atributo fundamental para construir toda a visão do processo. Por que isso importa Esse identificador conecta todas as etapas relacionadas do processo, permitindo analisar a jornada ponta a ponta de cada lançamento contábil. Onde obter Esta é uma chave composta, normalmente formada pela concatenação do código da empresa (BKPF-BUKRS), do número do documento (BKPF-BELNR) e do exercício fiscal (BKPF-GJAHR). Exemplos 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Código da empresa CompanyCode | O identificador exclusivo da empresa ou entidade legal para a qual o lançamento contábil é registrado. | ||
| Descrição O código da empresa é uma unidade organizacional fundamental no SAP Financials, representando uma entidade legal independente para a qual são geradas demonstrações financeiras. Todo lançamento contábil é atribuído a um código de empresa específico. Este atributo é essencial para segmentar e comparar a performance do processo entre diferentes partes da organização. Os analistas podem usá-lo para filtrar a visão do processo por uma entidade legal específica, comparar taxas de rejeição entre códigos de empresa ou identificar variações regionais no processo. Por que isso importa Permite filtrar e comparar o processo de lançamento contábil entre diferentes entidades legais ou unidades de negócio da organização. Onde obter Tabela BKPF do SAP S/4HANA, campo BUKRS (código da empresa). Exemplos 10001710US01 | |||
| Data de lançamento PostingDate | A data em que o lançamento contábil é registrado no razão geral, afetando o período financeiro. | ||
| Descrição A data de lançamento determina o período fiscal em que a transação aparecerá nas demonstrações financeiras. É uma data essencial para a contabilidade e pode ser diferente da data em que o documento foi criado ou inserido no sistema. No Process Mining, a data de lançamento é usada em análises de coorte baseadas em tempo, como a comparação dos processos de fechamento no fim do mês ou a análise de tendências de performance em diferentes períodos financeiros. Ela também é usada para medir os atrasos entre a criação do lançamento e seu registro financeiro efetivo. Por que isso importa É essencial para o contexto financeiro, permitindo analisar a performance do processo em períodos contábeis específicos, como o fechamento mensal ou anual. Onde obter Tabela BKPF do SAP S/4HANA, campo BUDAT (data de lançamento no documento). Exemplos 2023-10-312023-11-012024-02-29 | |||
| Tipo de lançamento contábil JournalEntryType | Classifica o lançamento contábil de acordo com sua finalidade de negócio, como lançamento de ativo, fatura de fornecedor ou lançamento no razão geral. | ||
| Descrição O tipo de lançamento contábil, chamado de tipo de documento na terminologia do SAP, é uma chave que categoriza documentos contábeis. Ele controla aspectos como a faixa de numeração atribuída ao documento e os tipos de conta permitidos para o lançamento. Analisar o processo por tipo de lançamento contábil é essencial para entender comportamentos específicos de cada contexto. Por exemplo, o processo de aprovação de uma apropriação simples, do tipo SA, pode ser muito mais simples do que o de uma aquisição complexa de ativo, do tipo AA. Essa dimensão é fundamental para o Dashboard "Conformidade por tipo de lançamento". Por que isso importa Categoriza os lançamentos por contexto de negócio, permitindo analisar as variações e a performance do processo para diferentes tipos de transações financeiras. Onde obter Tabela BKPF do SAP S/4HANA, campo BLART (tipo de documento). Exemplos SAKRAA | |||
| Usuário que criou CreatedByUser | O ID do usuário que criou o lançamento contábil. | ||
| Descrição Este atributo armazena o identificador exclusivo do usuário que iniciou o processo de lançamento contábil ao criar o documento inicial. Pode ser um contador, um usuário de negócio ou um ID de sistema usado em lançamentos automatizados. Analisar o processo por criador ajuda a identificar padrões relacionados a usuários ou equipes específicas. Isso pode revelar necessidades de treinamento quando determinados usuários apresentam taxas de rejeição mais altas ou destacar profissionais com alta performance. O atributo é essencial para o Dashboard "Atividade e produtividade dos usuários". Por que isso importa Atribui as atividades do processo a usuários específicos, permitindo analisar a performance, equilibrar a carga de trabalho e identificar oportunidades de treinamento. Onde obter Tabela BKPF do SAP S/4HANA, campo USNAM (nome do usuário). Exemplos ABROWNCJONESBATCH_USER | |||
| Valor na moeda local AmountInLocalCurrency | O valor total do lançamento contábil expresso na moeda local do código da empresa. | ||
| Descrição Este atributo representa a dimensão financeira do lançamento contábil. Normalmente, ele corresponde à soma dos valores absolutos de todos os itens de débito ou crédito do documento, convertidos para a moeda local do código da empresa. Analisar os dados por valor permite segmentar o processo de acordo com o impacto financeiro. Por exemplo, lançamentos de alto valor podem seguir um processo de aprovação mais rigoroso do que lançamentos de baixo valor. Isso ajuda a priorizar iniciativas de melhoria nos processos das transações que apresentam maior risco financeiro. Por que isso importa Fornece o valor financeiro do lançamento, permitindo analisar como o comportamento do processo muda de acordo com o valor monetário envolvido. Onde obter Calculado pela soma dos valores da tabela de itens BSEG, campo DMBTR, para um determinado lançamento contábil, BELNR, e pela conversão do resultado para um valor positivo. Exemplos 1500.75125000.0050.20 | |||
| Ano fiscal FiscalYear | O ano fiscal ao qual o lançamento contábil pertence. | ||
| Descrição O ano fiscal faz parte da chave exclusiva de um lançamento contábil, junto com o código da empresa e o número do documento. Ele representa o ano financeiro em que o documento é relevante. Na análise, o ano fiscal é usado para análises de tendências de longo prazo e para garantir a exclusividade do identificador do caso. Comparar as métricas do processo entre diferentes anos fiscais pode revelar melhorias ou quedas de performance ao longo do tempo. Por que isso importa Fornece um componente essencial para identificar documentos de forma exclusiva e permite analisar a performance do processo ano a ano. Onde obter Tabela BKPF do SAP S/4HANA, campo GJAHR (ano fiscal). Exemplos 202320242022 | |||
| Código da transação TransactionCode | O código de transação do SAP usado para criar ou alterar o lançamento contábil. | ||
| Descrição O código de transação, ou T-Code, é um atalho que identifica uma função ou um programa específico no SAP. Para lançamentos contábeis, diferentes T-Codes podem indicar como o lançamento foi criado, como FB01 para lançamento manual no razão geral, FV50 para estacionamento ou um código automatizado para lançamentos gerados pelo sistema. Este atributo é um forte indicador de que uma atividade foi executada manualmente por um usuário ou automaticamente pelo sistema. Ele é essencial para calcular o KPI de taxa de lançamentos manuais e identificar oportunidades de automação. Por que isso importa Indica como um lançamento foi processado, por exemplo, manualmente ou automaticamente, algo essencial para analisar a automação e entender as variações do processo. Onde obter Tabela BKPF do SAP S/4HANA, campo TCODE (código da transação). Exemplos FB01FV50F-02 | |||
| É lançamento manual IsManualPosting | Um indicador booleano que informa se o lançamento contábil foi realizado manualmente por um usuário. | ||
| Descrição Este atributo identifica lançamentos contábeis realizados com intervenção manual do usuário, em vez de serem registrados automaticamente por um job do sistema ou uma interface. Normalmente, ele é derivado do código de transação usado para registrar o documento. Esse indicador é usado para calcular o KPI de taxa de lançamentos manuais e ajuda as organizações a acompanhar o avanço da automação do processo Record to Report. Ao filtrar os lançamentos manuais, os analistas podem identificar os cenários específicos que ainda exigem intervenção humana e avaliar seu potencial de automação. Por que isso importa Diferencia lançamentos realizados por pessoas daqueles conduzidos pelo sistema, algo essencial para medir os níveis de automação e identificar oportunidades de automação. Onde obter Este é um atributo calculado, derivado do TransactionCode. Uma lista predefinida de códigos de transação manuais, como "FB01" e "F-02", é usada para definir o indicador como "true". Exemplos truefalse | |||
| É retrabalho IsRework | Um indicador booleano que informa se o lançamento contábil passou por retrabalho, como uma correção após uma rejeição. | ||
| Descrição Este atributo calculado identifica lançamentos contábeis que se desviaram do processo ideal, ou "caminho feliz". Normalmente, ele recebe o valor true quando uma atividade como "Lançamento contábil rejeitado" ou "Lançamento contábil corrigido" ocorre no caso. Esse indicador simplifica a análise da eficiência do processo. Ele permite calcular rapidamente o KPI de taxa de retrabalho e comparar diretamente os tempos de ciclo e os custos entre casos com e sem retrabalho. Identificar os fatores que geram retrabalho é um dos principais objetivos de muitas iniciativas de melhoria de processos. Por que isso importa Identifica casos que exigiram correções ou ciclos adicionais, permitindo quantificar facilmente e analisar a causa-raiz das ineficiências do processo. Onde obter Este é um atributo calculado, derivado da sequência de atividades de um caso. Ele recebe o valor "true" quando uma atividade como "Lançamento contábil rejeitado" está presente. Exemplos truefalse | |||
| Hora de término EndTime | O timestamp que indica quando a atividade foi concluída. | ||
| Descrição A hora de término marca a conclusão de uma atividade. Em muitos Event Logs, a hora de início e a hora de término de uma atividade são iguais, representando um evento instantâneo. No entanto, para atividades com duração mensurável, como a revisão ativa de um documento por um usuário, este atributo pode registrar essa duração. Ter uma hora de término distinta permite calcular com mais precisão o tempo de processamento da atividade em comparação com o tempo de espera. Isso ajuda a diferenciar o período em que uma tarefa estava sendo executada ativamente do período em que permaneceu parada em uma fila. Por que isso importa Permite calcular com precisão o tempo de processamento das atividades, separando o tempo de trabalho ativo do tempo de espera ocioso. Onde obter Normalmente, é igual a StartTime em eventos atômicos. Para atividades com duração, pode ser obtido a partir de logs do Workflow ou calculado com base em eventos subsequentes. Exemplos 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Motivo do estorno ReversalReason | Um código que indica o motivo pelo qual um lançamento contábil lançado foi estornado. | ||
| Descrição Quando um lançamento contábil lançado está incorreto, ele não pode ser excluído e precisa ser estornado por meio de um novo documento. O código do motivo do estorno explica por que essa ação foi realizada, por exemplo, devido a uma data ou valor de lançamento incorreto. Analisar os motivos de estorno ajuda a identificar as causas-raiz dos erros no processo Record to Report. Uma frequência alta de determinado motivo pode indicar problemas sistêmicos, como treinamento inadequado ou falhas de controle, que precisam ser tratados para melhorar a qualidade na primeira execução. Por que isso importa Ajuda a diagnosticar a causa-raiz dos erros que levam a estornos, fornecendo insights para reduzir o retrabalho e melhorar a qualidade do processo. Onde obter Tabela BKPF do SAP S/4HANA, campo STGRD (motivo do estorno). Exemplos 010205 | |||
| Sistema de origem SourceSystem | Identifica o sistema de origem do qual os dados dos lançamentos contábeis foram extraídos. | ||
| Descrição Este atributo especifica o sistema de registro de origem dos dados do lançamento contábil. Para empresas com várias instâncias de ERP ou uma combinação de sistemas legados e modernos, ele ajuda a diferenciar as fontes de dados. Na análise, ele pode ser usado para comparar a performance do processo entre diferentes sistemas ou filtrar os dados de uma fonte específica. É importante para a governança de dados e para garantir que o contexto dos dados seja compreendido. Por que isso importa Fornece contexto sobre a origem dos dados, algo essencial em ambientes com vários sistemas para realizar análises e comparações precisas do processo. Onde obter Normalmente, este é um valor estático adicionado durante a extração de dados, identificando a instância específica do SAP S/4HANA, como o SID ou o nome do sistema lógico. Exemplos S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Status do documento DocumentStatus | O status atual de processamento do lançamento contábil, como estacionado, lançado ou compensado. | ||
| Descrição O status do documento indica em que etapa do ciclo de vida o lançamento contábil se encontra. Por exemplo, um documento "estacionado" foi salvo, mas ainda não foi lançado no razão geral, enquanto um documento "lançado" foi finalizado. Analisar o status ajuda a entender o fluxo de trabalho e identificar gargalos. Um volume alto de documentos que permanecem por longos períodos como "estacionados" ou "aguardando aprovação" pode indicar ineficiências no processo. O status também é uma fonte importante para derivar atividades do processo. Por que isso importa Oferece uma visão do ponto do ciclo de vida em que o lançamento contábil se encontra, ajudando a identificar filas e gargalos. Onde obter Tabela BKPF do SAP S/4HANA, campo BSTAT (status do documento). Exemplos VAB | |||
| Tempo do ciclo de aprovação ApprovalCycleTime | O tempo decorrido desde o envio de um lançamento contábil para aprovação até sua aprovação ou rejeição. | ||
| Descrição Esta métrica calculada se concentra especificamente na duração da etapa de aprovação. Ela mede o tempo entre a atividade "Lançamento contábil enviado para revisão" e a atividade subsequente "Lançamento contábil aprovado" ou "Lançamento contábil rejeitado". Este KPI é essencial para identificar gargalos no Workflow de aprovação. Tempos de ciclo de aprovação altos podem atrasar significativamente o processo como um todo. Analisar essa métrica por aprovador, código da empresa ou tipo de lançamento contábil pode revelar áreas específicas para melhoria. Por que isso importa Isola a duração da etapa de aprovação, ajudando a localizar e resolver gargalos no Workflow de revisão e aprovação. Onde obter Calculado pela diferença de tempo entre o evento "Lançamento contábil enviado para revisão" e o evento "Lançamento contábil aprovado" ou "Lançamento contábil rejeitado". Exemplos 1 dia e 2 horas4 horas e 25 minutos5 dias e 0 horas | |||
| Última atualização dos dados LastDataUpdate | Timestamp que indica a última vez que os dados deste registro foram atualizados a partir do sistema de origem. | ||
| Descrição Este atributo registra a data e a hora da extração ou atualização mais recente dos dados no sistema de origem. Ele oferece transparência sobre o nível de atualização dos dados analisados. Saber quando ocorreu a última atualização é importante para entender o quanto a análise do processo está atualizada. Isso ajuda você a interpretar corretamente os Dashboards e KPIs, identificando se está analisando dados quase em tempo real ou um retrato de um período anterior. Por que isso importa Indica o nível de atualização dos dados, garantindo que você saiba o quanto a análise do processo está atualizada. Onde obter Este é um atributo de metadados, normalmente gerado e registrado em cada registro durante o pipeline de ingestão de dados. Exemplos 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Usuário aprovador ApproverUser | O ID do usuário que aprovou ou rejeitou o lançamento contábil. | ||
| Descrição Este atributo identifica o usuário responsável por revisar e tomar uma decisão sobre um lançamento contábil enviado. Em um Workflow de aprovação com vários níveis, pode haver vários aprovadores para um único lançamento contábil. Essas informações são essenciais para analisar o processo de aprovação em detalhes. Elas ajudam a medir a carga de trabalho de diferentes aprovadores, calcular os tempos individuais de aprovação e identificar gargalos na cadeia de aprovação. O atributo dá suporte direto ao Dashboard "Atividade e produtividade dos usuários". Por que isso importa Identifica a pessoa responsável pela aprovação, permitindo analisar a carga de trabalho, a performance e os gargalos do processo de aprovação. Onde obter Obtido a partir de logs do Workflow, como SWW_WI2OBJ e SWWLOG, ou de tabelas de documentos de alteração, como CDHDR e CDPOS, rastreando quem executou a etapa de aprovação. Exemplos DMILLERFWHITEKCHEN | |||
Record to Report - Atividades dos lançamentos contábeis
| Atividade | Descrição | ||
|---|---|---|---|
| Lançamento contábil aprovado | O lançamento contábil recebe a aprovação final de um gerente autorizado, confirmando sua validade e precisão. Esta atividade é o último controle antes que o documento possa ser lançado no razão geral. | ||
| Por que isso importa Este é um marco crítico que encerra o ciclo de aprovação. O tempo necessário para chegar a esta etapa é um componente importante da duração total do processo e um indicador essencial da eficiência dos aprovadores. Onde obter Este evento é inferido a partir de um registro de Workflow que mostra a etapa de aprovação final ou uma alteração de status no documento. O ID do usuário aprovador e o registro de data e hora podem ser obtidos nos dados do Workflow ou nos registros de alteração. Captura Identifique o registro de data e hora da etapa de aprovação final nos registros de Workflow ou a alteração de status para “Aprovado” nos documentos de alteração. Tipo de evento inferred | |||
| Lançamento contábil compensado | Um item em aberto de um lançamento contábil é compensado por outro lançamento, como um pagamento que compensa uma fatura. Esta atividade marca a reconciliação de itens de linha específicos, encerrando-os efetivamente. | ||
| Por que isso importa Esta atividade representa a etapa final de reconciliação de muitos lançamentos contábeis, especialmente os que envolvem contas transitórias ou contas gerenciadas por itens em aberto. Analisar o tempo entre o lançamento e a compensação ajuda a medir a eficiência da reconciliação. Onde obter Este evento é inferido a partir da tabela de itens de linha (BSEG ou a visão ACDOCA). Quando um item é compensado, os campos de data de compensação (AUGDT) e documento de compensação (AUGBL) são preenchidos para essa linha. Captura Use a data de compensação (BSEG-AUGDT) do item de linha como registro de data e hora do evento. Tipo de evento inferred | |||
| Lançamento contábil criado | Esta atividade marca a criação inicial de um documento de lançamento contábil no sistema. O registro é criado na tabela de cabeçalho (BKPF), mas ainda não foi lançado no razão geral. Este é o ponto de partida do ciclo de vida do lançamento contábil. | ||
| Por que isso importa Este é o principal evento de início do processo. Analisar o tempo entre este evento e o lançamento é essencial para medir o tempo total do ciclo e identificar atrasos iniciais na entrada de dados. Onde obter Este evento pode ser capturado explicitamente na tabela BKPF do SAP usando os campos de data de criação (CPUDT) e hora de criação (CPUTM) para um determinado número de documento (BELNR). Captura Use BKPF-CPUDT e BKPF-CPUTM como registro de data e hora do evento. Tipo de evento explicit | |||
| Lançamento contábil efetuado | O lançamento contábil é registrado oficialmente no razão geral, impactando as demonstrações financeiras da empresa. Este é o momento em que o documento se torna um registro financeiro permanente. | ||
| Por que isso importa Este é o principal marco de sucesso e marca o fim do ciclo central de processamento. Analisar a vazão dos lançamentos efetuados e o tempo necessário para chegar a esta etapa são métricas fundamentais de Process Mining. Onde obter Este é um evento explícito marcado pela data de lançamento (BUDAT) na tabela BKPF. Um documento lançado tem o status do documento (BSTAT) em branco, diferenciando-o de documentos estacionados (“V”) ou retidos (“D”). Captura Use a data de lançamento (BKPF-BUDAT) e a data de entrada (BKPF-CPUDT) para registrar o evento. Um BKPF-BSTAT em branco indica um documento lançado. Tipo de evento explicit | |||
| Lançamento contábil enviado para revisão | O criador do lançamento contábil envia formalmente o documento para o Workflow de revisão e aprovação. Esta atividade representa a transferência da entrada de dados para o processo formal de controle e inicia o ciclo de aprovação. | ||
| Por que isso importa Este ponto marca o início do tempo do ciclo de aprovação. Medir o período entre este momento e a aprovação ou rejeição final ajuda a isolar os gargalos especificamente nas etapas de revisão e aprovação. Onde obter Isso geralmente é capturado nos registros de Workflow, nas tabelas SWW_WIHEAD e SWWLOG, vinculados ao objeto de negócio. Também pode ser inferido a partir de uma alteração de status em um campo personalizado do cabeçalho do documento (BKPF). Captura Registro de data e hora da criação do item de Workflow ou alteração de um campo de status para “Enviado” ou “Em revisão”. Tipo de evento inferred | |||
| Processo de estorno do lançamento contábil concluído | Um lançamento contábil efetuado anteriormente é estornado com a criação de um novo documento com lançamentos inversos. Essa ação é tomada para corrigir erros em documentos lançados e é uma transação explícita e auditável. | ||
| Por que isso importa Os estornos indicam que ocorreu um erro em um documento lançado. Uma taxa alta de estornos sugere problemas subjacentes no processo de aprovação ou na qualidade da entrada de dados, e acompanhar esse indicador ajuda a melhorar a precisão na primeira execução. Onde obter O estorno é um evento explícito. O cabeçalho (BKPF) do novo documento de estorno contém uma referência ao documento original no campo Número do documento estornado (STBLG). A data de lançamento do novo documento é o momento do evento. Captura Identifique os documentos em que BKPF-STBLG esteja preenchido. O registro de data e hora do evento é a data de lançamento do documento de estorno. Tipo de evento explicit | |||
| Documentação de suporte anexada | Um usuário anexa um ou mais documentos de suporte, como faturas ou planilhas, ao lançamento contábil. Normalmente, isso é feito para fornecer evidências e contexto da transação financeira durante o processo de revisão e auditoria. | ||
| Por que isso importa Garantir que a documentação esteja anexada antes da revisão é fundamental para a conformidade e a eficiência das aprovações. Esta atividade ajuda a medir a aderência às políticas de documentação e seu impacto no tempo do ciclo de aprovação. Onde obter Normalmente, isso é inferido verificando o registro de data e hora de criação dos anexos vinculados por meio do Generic Object Services (GOS). A tabela SRGBTBREL vincula o objeto de negócio, como o documento BKPF, ao anexo. Captura Consulte as tabelas de anexos do GOS, como SRGBTBREL, em busca de links para o objeto BKPF e use o registro de data e hora de criação do anexo. Tipo de evento inferred | |||
| Lançamento contábil alterado após o lançamento | Um usuário modifica um conjunto limitado de campos de um lançamento contábil depois que ele já foi lançado no razão geral. Embora a maior parte dos dados financeiros seja imutável após o lançamento, alguns campos, como texto ou atribuições, podem ser alterados. | ||
| Por que isso importa Esta atividade é um sinal crítico de conformidade. Alterações após o lançamento podem indicar tentativas de modificar registros e devem ser monitoradas de perto para evitar fraudes e garantir a integridade dos dados. Onde obter Isso pode ser inferido com segurança a partir das tabelas de documentos de alteração (CDHDR e CDPOS). Uma entrada na CDHDR para o número do documento com data de alteração posterior à data de lançamento indica uma alteração após o lançamento. Captura Encontre os registros na CDHDR em que o registro de data e hora da alteração (UDATE/UTIME) seja posterior à data de lançamento do documento (BKPF-BUDAT). Tipo de evento inferred | |||
| Lançamento contábil corrigido | O usuário modifica um lançamento contábil depois que ele foi rejeitado ou devolvido para alterações. Isso representa o esforço de retrabalho necessário para corrigir os problemas identificados durante a revisão antes do reenvio. | ||
| Por que isso importa Esta atividade quantifica os ciclos de retrabalho. Analisar a frequência e a duração das correções ajuda a localizar as fontes de ineficiência e destaca oportunidades de treinamento e esclarecimento do processo. Onde obter Isso pode ser inferido acompanhando a data de “Última alteração” (AEDAT) na tabela BKPF de um documento que anteriormente estava no estado “Rejeitado”. Os documentos de alteração fornecem detalhes mais específicos sobre o que foi modificado. Captura Use o registro de data e hora dos cabeçalhos dos documentos de alteração (CDHDR-UDATE) para alterações feitas após um evento de rejeição. Tipo de evento inferred | |||
| Lançamento contábil estacionado | Um usuário salva um lançamento contábil incompleto sem lançá-lo, permitindo sua conclusão ou revisão posterior. Esta é uma ação explícita que cria um registro de cabeçalho do documento com status “estacionado”, mantendo-o em um estado não lançado. | ||
| Por que isso importa Estacionar o documento é uma etapa comum antes do envio. Acompanhar a duração desse estado ajuda a identificar atrasos na conclusão e na preparação dos dados antes do início do processo formal de revisão e aprovação. Onde obter Na tabela BKPF, um documento estacionado é identificado quando o campo de status do documento (BSTAT) tem o valor “V”. O registro de data e hora do evento é a data de criação (CPUDT). Captura Filtre os documentos em que BKPF-BSTAT = “V” no momento da criação. Tipo de evento explicit | |||
| Lançamento contábil rejeitado | Um revisor ou aprovador rejeita o lançamento contábil, impedindo que ele seja lançado. Normalmente, o documento é devolvido ao criador para correção, iniciando um ciclo de retrabalho. | ||
| Por que isso importa Acompanhar as rejeições é essencial para entender a qualidade do processo e identificar erros comuns. Taxas altas de rejeição indicam problemas na precisão dos dados, na compreensão das políticas ou na documentação de suporte inadequada. Onde obter Este evento é inferido a partir de uma alteração de status em um registro de Workflow ou em um campo de status personalizado do documento de lançamento contábil. Os registros de alteração de documentos (CDHDR/CDPOS) no campo de status relevante podem fornecer o registro de data e hora. Captura Identifique a alteração do campo de status para “Rejeitado” por meio dos documentos de alteração (CDHDR/CDPOS) ou dos registros de Workflow. Tipo de evento inferred | |||
| Lançamento manual identificado | O lançamento contábil foi lançado usando um código de transação manual, e não por meio de uma interface automatizada ou de um job em lote. Este não é um evento temporal, mas uma classificação da atividade de lançamento. | ||
| Por que isso importa Identificar lançamentos manuais é essencial para iniciativas de automação. Uma taxa alta de lançamentos manuais indica oportunidades de simplificação por meio da integração de subsistemas ou do uso de programas automatizados de lançamento. Onde obter Isso é calculado analisando o campo de código de transação (TCODE) na tabela de cabeçalho do documento (BKPF). Uma lista de T-Codes manuais conhecidos, como FB01, F-02 e FB50, é usada para classificar o lançamento. Captura Classifique o evento com base em BKPF-TCODE, comparando-o com uma lista predefinida de códigos de transação manuais no momento do lançamento. Tipo de evento calculated | |||
Guias de extração
Etapas
- Pré-requisitos e acesso: confirme que você tem um usuário com as autorizações necessárias para consultar o banco de dados subjacente do SAP S/4HANA ou executar relatórios ABAP. Você precisará de acesso de leitura às CDS views I_JournalEntry, I_JournalEntryItem e às tabelas CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ e SWWLOGHIST. Normalmente, o acesso é concedido por meio de um cliente de banco de dados, como SAP HANA Studio ou DBeaver, ou usando as SAP ABAP Development Tools (ADT) para Eclipse.
- Identifique as configurações específicas do sistema: antes de executar a consulta, identifique os códigos de tarefa usados no seu Workflow de aprovação de lançamentos contábeis. Consulte o administrador do Workflow SAP para encontrar os IDs das tarefas, como TS12345678, correspondentes aos eventos de envio, rejeição e aprovação. Eles são necessários nos placeholders da consulta final.
- Prepare a consulta SQL: copie a consulta SQL completa fornecida na seção
querypara o cliente SQL ou a ferramenta de desenvolvimento escolhida. - Defina os parâmetros da consulta: localize os placeholders na consulta e substitua-os pelos seus valores específicos. Isso inclui definir os parâmetros
[YourCompanyCode],[StartDate]e[EndDate]. Você também deve substituir os IDs de tarefa do Workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) pelos valores identificados na etapa anterior. - Execute a consulta de extração: execute a consulta SQL modificada no banco de dados SAP S/4HANA. Dependendo do período e do volume de dados, a consulta pode levar bastante tempo para ser concluída. Recomenda-se executá-la fora dos horários de pico.
- Revise os resultados iniciais: quando a consulta terminar, examine as primeiras linhas da saída para confirmar que todas as colunas, como JournalEntryId, ActivityName e EventTime, foram preenchidas conforme esperado. O conjunto de resultados deve conter uma linha para cada evento de negócio distinto no ciclo de vida do lançamento contábil.
- Exporte os dados para CSV: exporte todo o conjunto de resultados da sua ferramenta SQL para um único arquivo CSV. Confirme que o arquivo usa 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 que o arquivo CSV contém os cabeçalhos necessários. Os dados já estão estruturados como um Event Log, portanto, nenhuma transformação ou transposição adicional deve ser necessária.
Configuração
- Core Data Services (CDS) Views: a extração usa principalmente
I_JournalEntrypara os dados do cabeçalho eI_JournalEntryItempara os detalhes dos itens e valores. Essas views oferecem uma interface simplificada e semanticamente rica para o universal journal (ACDOCA). - Tabelas de suporte: para capturar uma visão completa do processo, a consulta também faz junções com várias tabelas padrão do SAP:
CDHDReCDPOSpara acompanhar alterações nos documentos.SRGBRELeSOODpara identificar quando anexos são vinculados por meio do Generic Object Services (GOS).SWW_WI2OBJeSWWLOGHISTpara extrair eventos importantes do Workflow de aprovação.
- Filtragem por período: é fundamental filtrar os dados por um período específico para controlar a performance. Use o campo
I_JournalEntry.CreationDateTimena cláusulaWHERE. Para uma análise inicial, recomenda-se um período de 3 a 6 meses. - Filtragem organizacional: sempre filtre por
CompanyCodepara limitar a extração às entidades legais relevantes. Consultar todos os códigos de empresa de uma só vez em um sistema grande pode gerar tempos de execução extremamente longos. - IDs de tarefas do Workflow: a consulta contém placeholders para os IDs de tarefas do Workflow, como
[Workflow Approved Task ID]. Eles são exclusivos de cada instalação SAP e devem ser configurados corretamente para que as atividades do Workflow sejam extraídas. Sem eles, nenhum evento de envio, aprovação ou rejeição será capturado. - Pré-requisitos: o usuário que executará a consulta precisa de amplas autorizações de leitura para tabelas financeiras, do sistema e do Workflow. Essas permissões não são padrão e devem ser atribuídas especificamente.
a Consulta de exemplo sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Etapas
- Confirme que o acesso SQL direto ao banco de dados SAP HANA foi aprovado e que o usuário da extração tem autorização de leitura para BKPF e ACDOCA, além de quaisquer fontes configuradas de Workflow, anexos, histórico de alterações, compensação ou estorno exigidas pelo seu sistema. O acesso direto ao banco de dados normalmente é feito com SAP HANA Database Explorer, SAP HANA Studio ou um cliente SQL aprovado. Não execute consultas de extração em uma transação de aplicação SAP, a menos que o seu sistema ofereça suporte explícito a esse acesso.
- Confirme o esquema físico de BKPF e ACDOCA, incluindo o campo de mandante, o campo de código da empresa, o campo de exercício fiscal, o campo de número do documento, o campo de tipo de documento, o campo de data de lançamento, o campo de data de criação, o campo de hora de criação, o campo de usuário, o campo de valor na moeda local e quaisquer campos de estorno ou compensação. As implementações do SAP S/4HANA podem variar no esquema e na disponibilidade dos campos. Portanto, substitua os placeholders entre colchetes na consulta pelos campos verificados no seu sistema.
- Identifique as fontes oficiais dos eventos de Workflow e anexos. BKPF e ACDOCA fornecem dados de documentos contábeis e itens, mas não expõem de forma confiável, por si só, todos os eventos de estacionamento, envio, rejeição, correção, aprovação ou anexos. Substitua os placeholders entre colchetes das fontes de Workflow e anexos por views ou tabelas aprovadas da sua implementação. Se uma fonte não estiver disponível, não invente eventos. Configure a fonte correspondente ou exclua a atividade com aprovação documentada.
- Defina os parâmetros de extração para o período necessário, os códigos de empresa, os tipos de documento e o mandante. Para a validação inicial, recomenda-se um período de três a seis meses. Use o intervalo de timestamps dos eventos operacionais e o intervalo de datas de lançamento dos eventos contábeis, de acordo com o escopo de processo acordado.
- Execute a consulta SQL completa no cliente SQL HANA aprovado. A consulta cria uma linha de evento para cada atividade extraída explicitamente. Ela usa BKPF e ACDOCA para os eventos contábeis e views de origem configuradas para eventos de Workflow, anexos, alterações, compensações e estornos. A consulta não infere atividades com base apenas na existência de um documento.
- Revise o esquema da saída. JournalEntryId é o identificador do caso, ActivityName é o rótulo da atividade e EventTime é o timestamp do evento. Os atributos de negócio recomendados são retornados quando disponíveis. Confirme que EventTime é um timestamp e que todas as linhas têm JournalEntryId e ActivityName preenchidos.
- Faça a reconciliação da população contábil comparando os valores distintos de JournalEntryId com a população esperada de BKPF para o mandante, os códigos de empresa, os exercícios fiscais e o período selecionados. Faça a reconciliação das populações de Workflow e anexos separadamente, pois as regras de retenção e timestamp podem ser diferentes das dos dados contábeis.
- Valide a ordenação dos eventos e o comportamento de duplicidade. Vários itens de linha em ACDOCA não devem criar eventos contábeis duplicados, a menos que o desenho do processo exija intencionalmente eventos no nível do item. Use a lógica de agregação da consulta para produzir um evento contábil por lançamento e tipo de evento, mantendo os identificadores dos eventos de origem configurados quando disponíveis.
- Exporte o resultado como CSV UTF-8 ou outro formato tabular compatível com o ProcessMind. Preserve os nomes exatos das colunas JournalEntryId, ActivityName e EventTime. Ordene o arquivo por JournalEntryId e EventTime e mantenha os atributos adicionais como colunas. Faça o upload do arquivo para o ProcessMind e configure JournalEntryId como identificador do caso, ActivityName como atividade e EventTime como timestamp do evento.
Configuração
- Período: comece com três a seis meses. Use um período menor para testar a performance e amplie somente depois de validar a quantidade de linhas e a cobertura de eventos.
- Escopo de mandante e empresa: defina o [Client parameter] e restrinja CompanyCode às entidades legais necessárias. Não omita o predicado do mandante em um sistema com vários mandantes.
- Escopo contábil: configure [Document type filter] e, quando apropriado, os filtros de exercício fiscal e data de lançamento. Inclua documentos lançados e não lançados somente se a fonte selecionada os representar de forma confiável.
- Escopo do Workflow: configure [Workflow event source] e seus mapeamentos de tipo de evento para as atividades de envio, rejeição, correção e aprovação. Confirme se os timestamps representam a criação, a execução ou a conclusão da ação do Workflow.
- Escopo de anexos: configure [Attachment event source] e o campo de relacionamento que vincula um anexo ao lançamento contábil. Confirme se a fonte registra a criação, a substituição ou a exclusão do anexo.
- Escopo de alterações: configure [Change history source] para alterações após o lançamento. Confirme que a fonte identifica o lançamento contábil e fornece um timestamp de alteração confiável.
- Escopo de compensação: configure [Clearing source] e o relacionamento entre o documento contábil compensado e o documento de compensação. Decida se o evento deve ser atribuído ao lançamento original, ao documento de compensação ou a ambos.
- Escopo de estorno: configure [Reversal source] e o relacionamento entre os documentos original e de estorno. A consulta atribui a atividade de estorno ao JournalEntryId original quando esse relacionamento está disponível.
- Classificação de lançamento manual: configure [Manual posting source] ou um campo de origem do lançamento verificado. Manual Posting Identified é um evento de classificação e deve usar o timestamp do lançamento ou outro timestamp aprovado de forma consistente.
- Valor em moeda: ACDOCA é baseada em itens de linha. A consulta agrega os valores em moeda local por lançamento contábil. Confirme a convenção de sinais e se as linhas estatísticas, específicas do ledger ou do extension ledger devem ser incluídas.
- Performance: selecione apenas as colunas necessárias, filtre no início, evite varreduras irrestritas de ACDOCA e execute a consulta durante uma janela de relatórios aprovada. Use o particionamento por meio dos predicados de mandante, exercício fiscal, código da empresa e data de lançamento quando houver suporte.
- Tratamento de duplicidades: use os identificadores dos eventos de origem quando disponíveis. Se uma fonte puder conter registros técnicos repetidos, aplique a regra de deduplicação documentada sem agrupar ações de Workflow genuinamente distintas.
- Pré-requisitos: autorizações de banco de dados necessárias, conectividade SAP HANA aprovada, acesso às fontes configuradas de Workflow e anexos, configuração adequada do SAP Financial Accounting e do Workflow e um formato de exportação compatível com o ProcessMind.
a Consulta de exemplo sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Etapas
- Crie o programa ABAP: acesse o ABAP Editor usando o código de transação
SE38. Informe um nome para o novo programa, por exemplo,Z_PM_JE_EXTRACT, e clique em 'Criar'. Defina um título adequado, selecione 'Programa executável' em 'Tipo' e salve-o como objeto local ou dentro de um pacote. - Defina a tela de seleção: no programa, defina parâmetros e select-options que permitam aos usuários filtrar os dados. Isso deve incluir um período para a data de criação do lançamento contábil (
P_CPUDT_FR,P_CPUDT_TO), um select-option para o código da empresa (SO_BUKRS) e um caminho de arquivo para a saída no servidor de aplicação (P_FPATH). - Declare as estruturas de dados: defina uma estrutura de tabela interna que corresponda ao formato necessário do Event Log. Essa estrutura armazenará a saída final. Declare também tabelas internas e áreas de trabalho para as tabelas SAP das quais você fará a seleção, como BKPF, ACDOCA, CDHDR, CDPOS e várias tabelas de Workflow.
- Implemente a lógica de seleção de dados: escreva a lógica ABAP principal para recuperar os dados de cada uma das 12 atividades necessárias. Crie sub-rotinas separadas (FORMs) para cada atividade, mantendo o código organizado. Por exemplo, crie um FORM para
get_created_events,get_parked_events,get_workflow_eventsetc. - Selecione os eventos 'Created' e 'Posted': leia a tabela BKPF com base nos critérios da tela de seleção do usuário. Uma entrada em BKPF indica criação. Um documento com status
BSTAT = ' 'é considerado lançado. Use o timestamp de criação (CPUDT,CPUTM) como horário do evento. - Selecione os eventos 'Parked': leia a tabela VBKPF, que armazena os cabeçalhos de documentos estacionados. O timestamp de criação nessa tabela representa o evento de estacionamento.
- Selecione os eventos de 'Workflow' (Submitted, Approved, Rejected): consulte tabelas de Workflow, como SWW_WI2OBJ, para vincular um objeto de lançamento contábil a uma instância de Workflow, e SWWLOGHIST ou SWWIHEAD, para obter os detalhes e o horário de etapas específicas. Você precisará identificar os IDs específicos das tarefas de envio, aprovação e rejeição no seu sistema.
- Selecione os eventos de 'Change' e 'Correction': consulte as tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item) para
OBJECTCLAS = 'BELEG'. Para 'Changed After Posting', filtre as alterações cujo timestamp seja posterior à data de lançamento do documento. Para 'Corrected', filtre as alterações em documentos estacionados ou rejeitados. - Selecione os eventos de 'Reversal' e 'Cleared': identifique os estornos encontrando documentos cujo campo
STBLG(número do documento estornado) em BKPF esteja preenchido. O horário do evento de estorno é o horário de criação do documento de estorno. Identifique os eventos de compensação selecionando a data de compensação mais recente (AUGDT) da tabela ACDOCA para os itens de um determinado lançamento contábil. - Combine e ordene os dados: à medida que os dados de cada atividade forem selecionados, acrescente os resultados à tabela interna mestre final. Depois que todas as seleções forem concluídas, ordene a tabela mestre por
JournalEntryIdeEventTimepara garantir a ordem cronológica de cada caso. - Gere o arquivo de saída: use as instruções
OPEN DATASET,LOOP AT... TRANSFEReCLOSE DATASETpara gravar o conteúdo da tabela interna final ordenada no caminho de arquivo especificado no servidor de aplicação SAP. O arquivo deve estar no formato CSV e conter uma linha de cabeçalho. - Agende a execução: para extrações regulares, use o código de transação
SM36para criar um job em background que execute o programaZ_PM_JE_EXTRACTem uma programação definida, como semanal ou mensal. Isso automatiza o processo de exportação de dados.
Configuração
- Período: a tela de seleção deve ter um período obrigatório para a data de criação do lançamento contábil (
CPUDT). Recomenda-se extrair os dados em blocos gerenciáveis, como 3 a 6 meses por vez, para garantir uma boa performance. - Código da empresa (
BUKRS): este é um filtro essencial para limitar a extração às entidades legais específicas relevantes para a análise de Process Mining. Não é recomendável extrair todos os códigos de empresa de uma só vez. - Tipo de documento (
BLART): você pode adicionar este filtro opcional para se concentrar em tipos específicos de lançamentos contábeis, como 'SA' para lançamento em conta do razão ou 'KR' para faturas de fornecedores. Isso pode reduzir o volume de dados e aumentar a relevância do conjunto de dados. - Caminho do arquivo: o programa exige um caminho lógico de arquivo no servidor de aplicação SAP, onde o arquivo de saída será gravado. Confirme que o caminho é válido e que o usuário do sistema SAP tem as autorizações de gravação necessárias para esse diretório. Use a transação
AL11para gerenciar e visualizar os diretórios do servidor. - IDs de tarefas do Workflow: a lógica de extração dos eventos de Workflow (Submitted, Approved, Rejected) deve ser configurada com os IDs específicos das tarefas usadas no Workflow de aprovação de lançamentos contábeis da sua organização. Eles geralmente são personalizados e devem ser identificados por um consultor ou desenvolvedor de Workflow.
- Pré-requisitos: o usuário ou a conta do sistema que executará o programa precisa de autorizações de desenvolvedor para criar e executar programas ABAP (
S_DEVELOP) e amplo acesso de leitura às tabelas financeiras (BKPF, ACDOCA), às tabelas de logs de alterações (CDHDR, CDPOS) e às tabelas de Workflow (SWW*).
a Consulta de exemplo abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Pronto para começar?
Use este Template para preparar seus dados com confiança e obter insights importantes sobre seu processo Record to Report - Journal Entry. Comece hoje sua jornada rumo à excelência operacional.
Agilize o Record to Report Journal Entry para alcançar a máxima eficiência
Transforme seu processo e reduza em 30% o tempo de ciclo do Record to Report journal entry.
Não é necessário cartão de crédito. Configure em poucos minutos.