Seu Template de dados para o processo de registro contábil até a emissão de relatórios, lançamentos contábeis
Seu Template de dados para o processo de registro contábil até a emissão de relatórios, lançamentos contábeis
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações práticas para extração
Atributos do processo de registro contábil até a emissão de relatórios, lançamentos contábeis
| Nome | Descrição | ||
|---|---|---|---|
| Atividade ActivityName | Nome da atividade de negócio realizada em um determinado momento do processo de lançamentos contábeis. | ||
| Descrição A Atividade representa uma etapa ou um evento específico do ciclo de um lançamento contábil, como 'Lançamento contábil criado', 'Lançamento enviado para revisão' ou 'Lançamento contábil registrado'. Essas atividades geralmente são obtidas de logs 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. Essa análise é fundamental para calcular métricas como frequência das atividades, tempos de espera entre etapas e taxas de conformidade. Por que isso importa Define as etapas do processo e permite visualizar mapas de processo e analisar padrões de fluxo de trabalho. Onde encontrar Obtida de várias fontes, incluindo campos de status nas tabelas de cabeçalho e de itens, como BKPF-BSTAT, logs de documentos de alteração (CDHDR/CDPOS) e logs do Workflow. Exemplos Lançamento contábil criadoLançamento contábil estacionadoLançamento enviado para revisãoLançamento contábil aprovadoLançamento contábil registrado | |||
| Data e hora do evento EventTime | Data e hora que indicam quando uma atividade específica ocorreu no processo do lançamento contábil. | ||
| Descrição Data e hora do evento correspondem ao momento exato em que uma atividade de negócio foi executada e registrada no sistema. Cada atividade de um caso tem sua própria data e hora, formando 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ção entre atividades, tempos de espera e distribuição temporal do trabalho. Datas e horas precisas são fundamentais para criar um modelo de processo confiável e calcular indicadores-chave de performance, como o tempo de ciclo da aprovação. Por que isso importa Fornece a ordem cronológica dos eventos, essencial para calcular todas as métricas de duração e entender a linha do tempo do processo. Onde encontrar Obtida nos logs de documentos de alteração (CDHDR-UDATE, CDHDR-UTIME), nos logs do Workflow ou nos campos de data e hora de criação ou 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 | Identificador exclusivo de um lançamento contábil, usado como 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 do lançamento, desde a criação ou o estacionamento até os fluxos de aprovação, o registro final e um possível estorno ou compensação. Na análise de Process Mining, esse ID vincula todas as atividades relacionadas em um único caso. Ao agrupar os eventos pelo mesmo ID do lançamento contábil, os analistas podem reconstruir o fluxo do processo de ponta a ponta, medir os tempos de ciclo e identificar variações ou gargalos em cada transação financeira. 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 e permite analisar a jornada completa de cada lançamento contábil. Onde encontrar Esta é uma chave composta, geralmente 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 e representa uma entidade legal independente para a qual são geradas demonstrações financeiras. Cada lançamento contábil é associado 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 visualização do processo por entidade legal, comparar as taxas de rejeição entre códigos de empresa ou identificar variações específicas de cada região. 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 encontrar 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, determinando 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. Em Process Mining, a data de lançamento é usada em análises de coorte ao longo do tempo, como comparar processos de fechamento mensal ou analisar tendências de performance em diferentes períodos fiscais. Também permite medir o intervalo entre a criação do lançamento e seu registro financeiro efetivo. Por que isso importa É essencial para o contexto financeiro e permite analisar a performance do processo em períodos contábeis específicos, como o fechamento mensal ou anual. Onde encontrar 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 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 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 um provisionamento simples (tipo SA) pode ser bem mais simples que o de uma aquisição complexa de ativo (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 variações e a performance do processo em diferentes tipos de transação financeira. Onde encontrar 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 da empresa ou o ID de um sistema para 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 certos usuários têm taxas de rejeição mais altas ou destacar pessoas com melhor performance. Este atributo é essencial para o Dashboard "Atividade e produtividade dos usuários". Por que isso importa Relaciona as atividades do processo a usuários específicos, permitindo analisar a performance, equilibrar a carga de trabalho e identificar oportunidades de treinamento. Onde encontrar 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 o valor financeiro do lançamento contábil. Em geral, 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 valores permite segmentar o processo de acordo com o impacto financeiro. Por exemplo, lançamentos de alto valor podem passar por um processo de aprovação mais rigoroso que os de baixo valor. Isso ajuda a priorizar melhorias nos processos de transações que representam maior risco financeiro. Por que isso importa Informa o valor financeiro do lançamento e permite analisar como o comportamento do processo muda de acordo com o valor envolvido. Onde encontrar Calculado pela soma dos valores dos itens da tabela BSEG (campo DMBTR) de um lançamento contábil (BELNR), convertida em um valor positivo. Exemplos 1500.75125000.0050.20 | |||
| Ano fiscal FiscalYear | O ano fiscal ao qual pertence o lançamento contábil. | ||
| 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 ao qual o documento se refere. Na análise, o ano fiscal é usado para identificar tendências de longo prazo e garantir que o identificador do caso seja exclusivo. 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 É um componente essencial para identificar documentos de forma exclusiva e permite analisar a performance do processo ano a ano. Onde encontrar Tabela BKPF do SAP S/4HANA, campo GJAHR (ano fiscal). Exemplos 202320242022 | |||
| Código da transação TransactionCode | O código da transação SAP usado para criar ou alterar o lançamento contábil. | ||
| Descrição O código da transação (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, por exemplo, FB01 para lançamento manual no razão geral, FV50 para estacionar um documento ou um código automatizado para lançamentos gerados pelo sistema. Este atributo é um forte indicador de que uma atividade foi realizada manualmente por um usuário ou automaticamente pelo sistema. É fundamental 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 de forma automática. É essencial para analisar a automação e entender as variações do processo. Onde encontrar Tabela BKPF do SAP S/4HANA, campo TCODE (código da transação). Exemplos FB01FV50F-02 | |||
| É lançamento manual IsManualPosting | Indicador booleano que informa se o lançamento contábil foi registrado manualmente por um usuário. | ||
| Descrição Este atributo identifica lançamentos contábeis registrados com intervenção manual de um usuário, em vez de serem processados automaticamente por uma tarefa do sistema ou por uma interface. Em geral, ele é derivado do código da transação usado para registrar o documento. Este 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 de Record to Report. Ao filtrar os lançamentos manuais, os analistas podem identificar os cenários que ainda exigem intervenção humana e avaliar o potencial de automação. Por que isso importa Diferencia os lançamentos feitos por pessoas daqueles processados pelo sistema, algo essencial para medir o nível de automação e identificar oportunidades de automatizar. Onde encontrar Este atributo calculado é derivado de TransactionCode. Uma lista predefinida de códigos de transação manuais, como "FB01" e "F-02", é usada para definir o indicador como "verdadeiro". Exemplos truefalse | |||
| É retrabalho IsRework | Indicador booleano que informa se o lançamento contábil passou por retrabalho, como uma correção após rejeição. | ||
| Descrição Este atributo calculado sinaliza lançamentos contábeis que se desviaram do caminho ideal do processo. Em geral, recebe o valor verdadeiro quando uma atividade como "Lançamento contábil rejeitado" ou "Lançamento contábil corrigido" ocorre no caso. Este 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 de casos com e sem retrabalho. Identificar os fatores que levam ao retrabalho é um dos principais objetivos de muitas iniciativas de melhoria de processos. Por que isso importa Sinaliza casos que exigiram correções ou etapas adicionais, facilitando a quantificação e a análise de causa raiz das ineficiências do processo. Onde encontrar Este atributo calculado é derivado da sequência de atividades de um caso. Ele recebe o valor "verdadeiro" quando há uma atividade como "Lançamento contábil rejeitado". Exemplos truefalse | |||
| Hora de término EndTime | Data e hora que indicam 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, indicando um evento instantâneo. Já em 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 das atividades e o tempo de espera. Assim, você consegue diferenciar o período em que uma tarefa estava sendo executada do tempo em que ficou parada em uma fila. Por que isso importa Permite calcular com precisão o tempo de processamento das atividades e separar o tempo de trabalho ativo do tempo de espera. Onde encontrar Em geral, é igual a StartTime em eventos atômicos. Para atividades com duração, pode vir dos logs do fluxo de trabalho ou ser calculado com base em eventos posteriores. Exemplos 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Motivo do estorno ReversalReason | Código que indica por que um lançamento contábil registrado foi estornado. | ||
| Descrição Quando um lançamento contábil registrado está incorreto, ele não pode ser excluído: é preciso estorná-lo com um novo documento. O código do motivo do estorno explica por que isso foi feito, por exemplo, devido a uma data ou um valor de lançamento incorreto. Analisar os motivos de estorno ajuda a identificar as causas raiz dos erros no processo de Record to Report. A frequência elevada de um motivo específico pode indicar problemas sistêmicos, como treinamento insuficiente ou falhas de controle, que precisam ser resolvidos para melhorar a qualidade na primeira execução. Por que isso importa Ajuda a diagnosticar as causas raiz dos erros que levam a estornos, fornecendo insights para reduzir o retrabalho e melhorar a qualidade do processo. Onde encontrar Tabela BKPF do SAP S/4HANA, campo STGRD (motivo do estorno). Exemplos 010205 | |||
| Sistema de origem SourceSystem | Identifica o sistema de origem de onde os dados dos lançamentos contábeis foram extraídos. | ||
| Descrição Este atributo especifica o sistema de registro de onde vieram os 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, 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, essencial para analisar e comparar processos com precisão em ambientes com vários sistemas. Onde encontrar Normalmente, é um valor estático adicionado durante a extração de dados, que identifica a instância específica do SAP S/4HANA, por exemplo, 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 está o lançamento contábil. Por exemplo, um documento "estacionado" foi salvo, mas ainda não foi lançado no razão geral; um documento "lançado" já foi finalizado. Analisar o status ajuda a entender o fluxo de trabalho e identificar gargalos. Um grande volume de documentos que permanece por muito tempo como "estacionado" ou "aguardando aprovação" pode indicar ineficiências no processo. O status também é uma fonte importante para identificar as atividades do processo. Por que isso importa Mostra em que etapa do ciclo de vida está o lançamento contábil e ajuda a identificar filas e gargalos. Onde encontrar Tabela BKPF do SAP S/4HANA, campo BSTAT (status do documento). Exemplos VAB | |||
| Tempo de ciclo da aprovação ApprovalCycleTime | O tempo entre o envio de um lançamento contábil para aprovação e sua aprovação ou rejeição. | ||
| Descrição Esta métrica calculada se concentra 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 seguinte, "Lançamento contábil aprovado" ou "Lançamento contábil rejeitado". Este KPI é essencial para identificar gargalos no fluxo de trabalho de aprovação. Tempos de ciclo de aprovação elevados 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 pontos específicos que precisam de melhorias. Por que isso importa Isola a duração da etapa de aprovação e ajuda a identificar e resolver gargalos no fluxo de trabalho de revisão e aprovação. Onde encontrar Calculado pela diferença entre a data e a hora do evento "Lançamento contábil enviado para revisão" e as do 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 | Data e hora que indicam quando os dados deste registro foram atualizados pela última vez 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. Assim, você sabe se os dados analisados estão atualizados. Saber quando ocorreu a última atualização é importante para entender o quão atuais são os dados usados na análise do processo. Isso ajuda você a interpretar corretamente os Dashboards e os KPIs, sabendo se está consultando dados quase em tempo real ou um retrato de um período anterior. Por que isso importa Indica o quão atuais são os dados, para que você saiba até que ponto a análise do processo está atualizada. Onde encontrar Este atributo de metadados costuma ser gerado e registrado em cada registro durante o processo 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 decidir sobre um lançamento contábil enviado para aprovação. Em um fluxo de trabalho de aprovação com vários níveis, um mesmo lançamento pode ter vários aprovadores. Essa informação é essencial para analisar o processo de aprovação em detalhes. Ela ajuda a medir a carga de trabalho de cada aprovador, calcular os tempos individuais de aprovação e identificar gargalos na cadeia de aprovação. Também é usada no Dashboard "Atividade e produtividade dos usuários". Por que isso importa Identifica a pessoa responsável pela aprovação e permite analisar a carga de trabalho, a performance e os gargalos do processo de aprovação. Onde encontrar Obtido nos logs do fluxo de trabalho, como SWW_WI2OBJ e SWWLOG, ou nas tabelas de documentos de alteração (CDHDR/CDPOS), identificando quem executou a etapa de aprovação. Exemplos DMILLERFWHITEKCHEN | |||
Atividades do processo de registro contábil até a emissão de relatórios, lançamentos contábeis
| Atividade | Descrição | ||
|---|---|---|---|
| Estorno de lançamento contábil processado | Um lançamento contábil registrado anteriormente é estornado com a criação de um novo documento com lançamentos inversos. Essa ação corrige erros em documentos registrados e é uma transação explícita e auditável. | ||
| Por que isso importa Os estornos indicam que houve um erro em um documento registrado. Uma taxa alta de estornos sugere problemas no processo de aprovação ou na qualidade da entrada de dados. Acompanhar esse indicador ajuda a melhorar a precisão desde a primeira tentativa. Onde encontrar 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 corresponde à data do evento. Coleta Identifique os documentos em que BKPF-STBLG está preenchido. A data e a hora do evento correspondem à data de lançamento do documento de estorno. Tipo de evento explicit | |||
| Lançamento contábil aprovado | Um gerente autorizado aprova definitivamente o lançamento contábil, confirmando sua validade e precisão. Esta atividade é a última etapa antes de o documento 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 até essa etapa representa uma parte importante da duração total do processo e é um indicador essencial da eficiência dos aprovadores. Onde encontrar Esse evento é identificado em um log do Workflow que mostra a etapa de aprovação final ou uma alteração de status no documento. O ID do usuário aprovador e a data e hora do evento podem ser obtidos nos dados do Workflow ou nos logs de alteração. Coleta Identifique a data e a hora da etapa de aprovação final nos logs do Workflow ou a alteração de status para 'Approved' 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 no caso de um pagamento que compensa uma fatura. Esta atividade marca a conciliação de itens de linha específicos e efetivamente os encerra. | ||
| Por que isso importa Para muitos lançamentos contábeis, especialmente os que envolvem contas transitórias ou gerenciadas por itens em aberto, esta atividade representa a etapa final de conciliação. Analisar o tempo entre o lançamento e a compensação ajuda a medir a eficiência da conciliação. Onde encontrar Esse evento é identificado na tabela de itens de linha (BSEG ou na 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. Coleta Use a data de compensação do item de linha (BSEG-AUGDT) como 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 do lançamento contábil. | ||
| Por que isso importa Este é o principal evento de início do processo. Analisar o tempo entre esse evento e o lançamento é essencial para medir o tempo de ciclo total e identificar atrasos iniciais na entrada de dados. Onde encontrar Este evento pode ser capturado diretamente na tabela SAP BKPF, usando os campos de data de criação (CPUDT) e hora de criação (CPUTM) para um determinado número de documento (BELNR). Coleta Use BKPF-CPUDT e BKPF-CPUTM para registrar a data e a hora do evento. Tipo de evento explicit | |||
| Lançamento contábil registrado | O lançamento contábil é registrado oficialmente no razão geral e afeta as demonstrações financeiras da empresa. A partir desse momento, o documento passa a ser um registro financeiro permanente. | ||
| Por que isso importa Este é o principal marco de sucesso e marca o fim do ciclo central de processamento. Analisar o volume de lançamentos registrados e o tempo até essa etapa são métricas fundamentais de Process Mining. Onde encontrar Este é um evento explícito, marcado pela data de lançamento (BUDAT) na tabela BKPF. Um documento lançado tem o campo de status do documento (BSTAT) em branco, o que o diferencia de documentos estacionados ('V') ou retidos ('D'). Coleta Use a data de lançamento (BKPF-BUDAT) e a data de entrada (BKPF-CPUDT) para registrar a data e a hora do evento. Um campo BKPF-BSTAT em branco indica um documento lançado. Tipo de evento explicit | |||
| Lançamento enviado para revisão | O criador do lançamento contábil envia formalmente o documento para o fluxo de revisão e aprovação. Esta atividade marca a transferência da entrada de dados para o processo formal de controle e dá início ao ciclo de aprovação. | ||
| Por que isso importa Este evento marca o início do tempo de ciclo da aprovação. Medir o período entre esse ponto e a aprovação ou rejeição final ajuda a localizar gargalos nas etapas de revisão e aprovação. Onde encontrar Esse evento costuma ser capturado nos logs do Workflow, nas tabelas SWW_WIHEAD e SWWLOG, vinculados ao objeto de negócio. Também pode ser identificado por uma alteração de status em um campo personalizado do cabeçalho do documento (BKPF). Coleta Data e hora de criação do item do Workflow ou alteração de um campo de status para 'Submitted' ou 'In Review'. Tipo de evento inferred | |||
| Documentação comprobatória anexada | Um usuário anexa um ou mais documentos comprobatórios, como notas fiscais ou planilhas, ao lançamento contábil. Isso costuma ser feito para fornecer evidências e contexto da transação financeira durante a revisão e a auditoria. | ||
| Por que isso importa Anexar a documentação antes da revisão é essencial para a conformidade e a eficiência das aprovações. Esta atividade ajuda a medir a adesão às políticas de documentação e o impacto no tempo de ciclo das aprovações. Onde encontrar Em geral, esse evento é identificado pela data e hora de criação dos anexos vinculados por meio do Generic Object Services (GOS). A tabela SRGBTBREL associa o objeto de negócio, como um documento BKPF, ao anexo. Coleta Consulte as tabelas de anexos do GOS, como SRGBTBREL, para encontrar vínculos com o objeto BKPF e use a data e a hora de criação do anexo. Tipo de evento inferred | |||
| Lançamento contábil alterado após o registro | Um usuário altera um conjunto limitado de campos de um lançamento contábil depois que ele já foi registrado no razão geral. Embora a maioria dos dados financeiros não possa ser alterada após o lançamento, alguns campos, como texto ou atribuições, podem ser modificados. | ||
| Por que isso importa Esta atividade é um alerta crítico de conformidade. Alterações após o lançamento podem indicar tentativas de modificar registros e devem ser monitoradas de perto para prevenir fraudes e garantir a integridade dos dados. Onde encontrar Esse evento pode ser identificado com segurança nas tabelas de documentos de alteração (CDHDR e CDPOS). Um registro em CDHDR para o número do documento, com data de alteração posterior à data de lançamento, indica uma mudança feita após o lançamento. Coleta Localize os registros em CDHDR cuja data e hora da alteração (UDATE/UTIME) sejam posteriores à data de lançamento do documento (BKPF-BUDAT). Tipo de evento inferred | |||
| Lançamento contábil corrigido | O usuário altera um lançamento contábil depois que ele é rejeitado ou devolvido para correção. Esta atividade representa o retrabalho necessário para resolver os problemas identificados durante a revisão antes de reenviar o documento. | ||
| 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 fontes de ineficiência e oportunidades de treinamento e esclarecimento do processo. Onde encontrar Esse evento pode ser identificado acompanhando a data da última alteração (AEDAT) na tabela BKPF para um documento que estava anteriormente com status 'Rejected'. Os documentos de alteração fornecem detalhes mais específicos sobre o que foi modificado. Coleta Use a data e a hora dos cabeçalhos dos documentos de alteração (CDHDR-UDATE) para as mudanças feitas após uma rejeição. Tipo de evento inferred | |||
| Lançamento contábil estacionado | Um usuário salva um lançamento contábil incompleto sem lançá-lo, para concluí-lo ou revisá-lo mais tarde. Essa ação explícita cria um registro de cabeçalho do documento com status de estacionado, mantendo-o sem lançamento. | ||
| Por que isso importa Estacionar o lançamento é uma etapa comum antes do envio. Acompanhar por quanto tempo ele permanece estacionado ajuda a identificar atrasos na conclusão e na preparação dos dados antes do início da revisão e aprovação formal. Onde encontrar Na tabela BKPF, um documento estacionado é identificado pelo campo de status do documento (BSTAT) com o valor 'V'. A data e a hora do evento correspondem à data de criação (CPUDT). Coleta 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. Em geral, o documento volta para o criador fazer as correções, iniciando um ciclo de retrabalho. | ||
| Por que isso importa Acompanhar as rejeições é essencial para entender a qualidade do processo e identificar erros comuns. Uma taxa alta de rejeição indica problemas na precisão dos dados, no entendimento das políticas ou na documentação comprobatória. Onde encontrar Esse evento é identificado por uma alteração de status no log do Workflow ou em um campo de status personalizado do documento de lançamento contábil. Os logs de alteração do documento (CDHDR/CDPOS) referentes ao campo de status podem fornecer a data e a hora do evento. Coleta Identifique a alteração do campo de status para 'Rejected' nos documentos de alteração (CDHDR/CDPOS) ou nos logs do Workflow. Tipo de evento inferred | |||
| Lançamento manual identificado | O lançamento contábil foi registrado usando um código de transação manual, em vez de uma interface automatizada ou de um processamento 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 proporção alta de lançamentos manuais indica oportunidades para simplificar processos, integrando subsistemas ou usando programas automatizados de lançamento. Onde encontrar Essa classificação é feita pela análise do campo de código de transação (TCODE) na tabela de cabeçalho do documento (BKPF). Uma lista de códigos de transação manuais conhecidos, como FB01, F-02 e FB50, é usada para classificar o lançamento. Coleta Classifique o evento comparando BKPF-TCODE 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 se 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 e I_JournalEntryItem, além das tabelas CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ e SWWLOGHIST. Em geral, o acesso é feito por um cliente de banco de dados, como SAP HANA Studio ou DBeaver, ou pelas 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 fluxo de trabalho de aprovação dos lançamentos contábeis. Consulte o administrador do fluxo de trabalho SAP para encontrar os IDs das tarefas (por exemplo, TS12345678) correspondentes aos eventos de envio, rejeição e aprovação. Você precisará desses IDs para preencher os campos indicados na consulta final.
- Prepare a consulta SQL: Copie a consulta SQL completa da seção
querypara o cliente SQL ou a ferramenta de desenvolvimento escolhida. - Defina os parâmetros da consulta: Localize os campos indicados na consulta e substitua-os pelos valores específicos do seu sistema. Informe
[YourCompanyCode],[StartDate]e[EndDate]. Substitua também os IDs de tarefa do fluxo de trabalho ([Workflow Submitted Task ID],[Workflow Rejected Task ID]e[Workflow Approved Task ID]) pelos valores identificados na etapa anterior. - Execute a consulta de extração: Execute a consulta SQL atualizada no banco de dados do SAP S/4HANA. O tempo de execução pode ser longo, dependendo do período e do volume de dados. Recomendamos executá-la fora dos horários de pico.
- Confira os resultados iniciais: Quando a consulta terminar, examine as primeiras linhas e confirme se todas as colunas, como JournalEntryId, ActivityName e EventTime, foram preenchidas como esperado. O resultado 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 resultado da ferramenta SQL para um único arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres especiais.
- Prepare o arquivo para carregamento: Antes de carregar o arquivo em uma ferramenta de Process Mining, confirme se o CSV contém os cabeçalhos necessários. Como os dados já estão estruturados como um Event Log, não deve ser necessário fazer outras transformações ou reorganizar as colunas.
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 diário universal (ACDOCA). - Tabelas de apoio: Para apresentar uma visão completa do processo, a consulta também combina 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 fluxo de trabalho de aprovação.
- Filtro por período: É essencial filtrar os dados por um período específico para controlar a performance. Use o campo
I_JournalEntry.CreationDateTimena cláusulaWHERE. Para a análise inicial, recomendamos um período de 3 a 6 meses. - Filtro 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 levar muito tempo. - IDs de tarefas do fluxo de trabalho: A consulta contém campos para informar os IDs das tarefas do fluxo de trabalho (por exemplo,
[Workflow Approved Task ID]). Esses IDs são exclusivos de cada instalação SAP e precisam ser configurados corretamente para que as atividades do fluxo de trabalho sejam extraídas. Sem eles, os eventos de envio, aprovação e rejeição não serão capturados. - Pré-requisitos: O usuário que executa a consulta precisa de amplas autorizações de leitura para tabelas financeiras, do sistema e do fluxo de trabalho. Essas permissões não são padrão e precisam ser concedidas especificamente.
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 se o acesso SQL direto ao banco de dados SAP HANA foi aprovado e se o usuário de extração tem autorização de leitura para BKPF e ACDOCA, além de quaisquer fontes configuradas de fluxo de trabalho, anexos, histórico de alterações, compensação ou estorno necessárias no seu sistema. Normalmente, o acesso direto ao banco de dados é feito pelo SAP HANA Database Explorer, SAP HANA Studio ou um cliente SQL aprovado. Não execute consultas de extração em uma transação de aplicativo SAP, a menos que o sistema ofereça suporte explícito a esse acesso.
- Confirme o esquema físico de BKPF e ACDOCA, incluindo os campos de cliente, código da empresa, exercício fiscal, número do documento, tipo de documento, data de lançamento, data de criação, hora de criação, usuário, valor na moeda local e quaisquer campos de estorno ou compensação. As implementações do SAP S/4HANA podem variar no esquema e nos campos disponíveis. Por isso, substitua os campos entre colchetes na consulta por campos verificados no seu sistema.
- Identifique as fontes oficiais dos eventos de fluxo de trabalho e de anexos. BKPF e ACDOCA fornecem dados de documentos contábeis e itens, mas, por si só, não mostram de forma confiável todos os eventos de documentos estacionados, enviados, rejeitados, corrigidos, aprovados ou com anexos. Substitua os campos entre colchetes das fontes de fluxo de trabalho e de anexos por views ou tabelas aprovadas na 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, os códigos de empresa, os tipos de documento e o cliente necessários. Para a validação inicial, recomendamos um período de três a seis meses. Use o período do timestamp do evento para eventos operacionais e o período da data de lançamento para eventos contábeis, de acordo com o escopo do processo definido.
- 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 eventos contábeis e views de origem configuradas para eventos de fluxo de trabalho, anexos, alterações, compensação e estorno. A existência de um documento não é usada para inferir atividades.
- Confira o esquema dos resultados. JournalEntryId é o identificador do caso, ActivityName é o nome da atividade e EventTime é o timestamp do evento. Os atributos de negócio recomendados são retornados quando disponíveis. Confirme se EventTime é um timestamp e se todas as linhas têm valores não vazios em JournalEntryId e ActivityName.
- Faça a conciliação da população contábil comparando os valores distintos de JournalEntryId com a população esperada de BKPF para o cliente, os códigos de empresa, os exercícios fiscais e o período selecionados. Faça a conciliação das populações de fluxo de trabalho e de anexos separadamente, pois as regras de retenção e timestamp podem ser diferentes das aplicadas aos dados contábeis.
- Valide a ordem dos eventos e o tratamento de duplicatas. Vários itens de linha em ACDOCA não devem gerar eventos contábeis duplicados, a menos que o desenho do processo exija eventos por item. Use a lógica de agregação da consulta para gerar 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 em UTF-8 ou em outro formato tabular compatível com o ProcessMind. Mantenha exatamente os nomes de coluna JournalEntryId, ActivityName e EventTime. Ordene o arquivo por JournalEntryId e EventTime e mantenha os atributos adicionais em colunas. Carregue o arquivo no 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-o somente depois de validar a quantidade de linhas e a cobertura dos eventos.
- Escopo de cliente e empresa: Defina [Client parameter] e restrinja CompanyCode às entidades legais necessárias. Em sistemas com vários clientes, não omita o filtro de cliente.
- 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 fluxo de trabalho: Configure [Workflow event source] e os mapeamentos de tipo de evento para 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 no fluxo de trabalho.
- Escopo dos 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 de anexos.
- Escopo das alterações: Configure [Change history source] para alterações feitas após o lançamento. Confirme se a fonte identifica o lançamento contábil e fornece um timestamp confiável para a alteração.
- Escopo da compensação: Configure [Clearing source] e o relacionamento entre o documento contábil compensado e o documento de compensação. Defina se o evento deve ser associado ao lançamento original, ao documento de compensação ou a ambos.
- Escopo do estorno: Configure [Reversal source] e o relacionamento entre os documentos original e de estorno. Quando esse relacionamento estiver disponível, a consulta associa a atividade de estorno ao JournalEntryId original.
- Classificação de lançamentos manuais: 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 na moeda: ACDOCA é organizada por item de linha. A consulta agrega os valores na moeda local por lançamento contábil. Confirme a convenção de sinais e se linhas estatísticas, específicas do ledger ou de ledgers de extensão devem ser incluídas.
- Performance: Selecione somente as colunas necessárias, aplique os filtros desde o início, evite varreduras irrestritas de ACDOCA e execute a consulta em uma janela de relatórios aprovada. Quando houver suporte, use a eliminação de partições com filtros de cliente, exercício fiscal, código da empresa e data de lançamento.
- Tratamento de duplicatas: Use os identificadores dos eventos de origem quando disponíveis. Se uma fonte puder conter registros técnicos repetidos, aplique a regra documentada de deduplicação sem agrupar ações distintas do fluxo de trabalho.
- Pré-requisitos: Autorizações necessárias para o banco de dados, conectividade aprovada com SAP HANA, acesso às fontes configuradas de fluxo de trabalho e anexos, configuração adequada do SAP Financial Accounting e do fluxo de trabalho, além de um formato de exportação compatível com o ProcessMind.
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 Editor ABAP 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 como objeto local ou dentro de um pacote. - Defina a tela de seleção: No programa, defina parâmetros e opções de seleção para permitir que os usuários filtrem os dados. Inclua um período para a data de criação do lançamento contábil (
P_CPUDT_FR,P_CPUDT_TO), uma opção de seleção para o código da empresa (SO_BUKRS) e um caminho de arquivo para a saída no servidor de aplicativos (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 que serão consultadas, como BKPF, ACDOCA, CDHDR, CDPOS e várias tabelas do fluxo de trabalho.
- Implemente a lógica de seleção de dados: Escreva a lógica ABAP principal para recuperar os dados das 12 atividades necessárias. Crie sub-rotinas separadas (FORMs) para cada atividade e mantenha o código organizado. Por exemplo, crie um FORM para
get_created_events,get_parked_eventseget_workflow_events. - Selecione os eventos 'Criado' e 'Lançado': Leia a tabela BKPF de acordo com os critérios definidos na tela de seleção. Um registro em BKPF indica a 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 'Estacionado': 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 do 'Fluxo de trabalho' (Enviado, Aprovado, Rejeitado): Consulte tabelas do fluxo de trabalho, como SWW_WI2OBJ (para vincular um objeto de lançamento contábil a uma instância do fluxo de trabalho) e SWWLOGHIST ou SWWIHEAD (para obter detalhes e horários de etapas específicas). Identifique os IDs das tarefas de envio, aprovação e rejeição usados no seu sistema.
- Selecione os eventos 'Alterado' e 'Corrigido': Consulte as tabelas de documentos de alteração CDHDR (cabeçalho) e CDPOS (item) para
OBJECTCLAS = 'BELEG'. Para 'Alterado após o lançamento', filtre as alterações cujo timestamp seja posterior à data de lançamento do documento. Para 'Corrigido', filtre as alterações feitas em documentos estacionados ou rejeitados. - Selecione os eventos 'Estornado' e 'Compensado': Identifique os estornos procurando documentos com o campo
STBLG(número do documento estornado) preenchido em BKPF. 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) na tabela ACDOCA para os itens de linha de um lançamento contábil. - Combine e ordene os dados: À medida que os dados de cada atividade forem selecionados, acrescente os resultados à tabela interna principal. Depois de concluir todas as seleções, ordene a tabela 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 aplicativos 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 segundo plano que execute o programaZ_PM_JE_EXTRACTem uma agenda definida, por exemplo, semanal ou mensal. Assim, a exportação dos dados será automatizada.
Configuração
- Período: A tela de seleção deve exigir um período para a data de criação do lançamento contábil (
CPUDT). Recomendamos extrair os dados em blocos gerenciáveis, como períodos de 3 a 6 meses, para manter uma boa performance. - Código da empresa (
BUKRS): Este filtro é essencial para limitar a extração às entidades legais relevantes para a análise de Process Mining. Não recomendamos extrair dados de 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 tornar o conjunto de dados mais relevante. - Caminho do arquivo: O programa precisa de um caminho lógico no servidor de aplicativos SAP para gravar o arquivo de saída. Confirme se o caminho é válido e se 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 consultar os diretórios do servidor. - IDs de tarefas do fluxo de trabalho: A lógica de extração dos eventos do fluxo de trabalho (Enviado, Aprovado, Rejeitado) precisa ser configurada com os IDs específicos das tarefas usadas no fluxo de trabalho de aprovação dos lançamentos contábeis da sua organização. Esses IDs costumam ser personalizados e devem ser identificados por um consultor ou desenvolvedor de fluxo de trabalho.
- Pré-requisitos: O usuário ou a conta do sistema que executa 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 log de alterações (CDHDR, CDPOS) e às tabelas do fluxo de trabalho (SWW*).
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 segurança e obter insights importantes sobre o processo de registro contábil até a emissão de relatórios, com foco nos lançamentos contábeis. Comece hoje a aprimorar seus processos.
Otimize os lançamentos contábeis de R2R para alcançar máxima eficiência
Transforme seu processo e reduza em 30% o tempo de ciclo dos lançamentos contábeis de registro até a emissão de relatórios.
Não é necessário informar cartão de crédito. Configure em poucos minutos.