Seu Template de Dados de Gestão de Despesas
Seu Template de Dados de Gestão de Despesas
- Atributos recomendados para análise
- Atividades principais para rastrear no seu processo
- Orientações para extração de dados
Atributos de Gestão de Despesas
| Nome | Descrição | ||
|---|---|---|---|
|
ID do Relatório de Despesa
ExpenseReportId
|
O identificador exclusivo de um relatório de despesas, servindo como o identificador principal do caso para rastrear seu ciclo de vida. | ||
|
Descrição
O ID do Relatório de Despesas é a base do processo. Ele agrupa todas as atividades relacionadas — da criação e submissão à aprovação e reembolso — em um único caso. No Process Mining, este ID permite a análise ponta a ponta da jornada de cada relatório. Ele é usado para reconstruir o caminho exato percorrido, medir tempos de ciclo totais, identificar loops de retrabalho (quando os relatórios voltam para revisão) e analisar variantes para entender fluxos comuns e exceções.
Por que é importante
Este ID é essencial para rastrear o ciclo de vida completo do relatório, permitindo a análise de tempos, gargalos e desvios.
Onde obter
Identificador principal no módulo do Brex, disponível em exportações de dados e endpoints de API.
Exemplos
ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
|
|||
|
Nome da Atividade
ActivityName
|
O nome de um evento ou tarefa específica ocorrida no ciclo de vida do relatório de despesas. | ||
|
Descrição
O Nome da Atividade descreve uma etapa do processo, como 'Relatório de Despesas Submetido', 'Aprovado pelo Gestor' ou 'Reembolso Executado'. Esses eventos formam a sequência de ações que compõem o fluxo. A análise dessas atividades permite a visualização do mapa do processo, a identificação de gargalos entre as etapas e o cálculo da frequência de resultados como aprovações ou reprovações. É a base para entender o que realmente acontece na sua gestão de despesas.
Por que é importante
Este atributo é crítico para construir o mapa do processo e entender a sequência de eventos de cada relatório.
Onde obter
Esta informação é derivada dos logs ou status de transação no Brex. Pode exigir o mapeamento de códigos para nomes mais amigáveis.
Exemplos
Relatório de Despesa CriadoAprovado pelo GerenteRejeitado pelo FinanceiroReembolso Executado
|
|||
|
Tempo do Evento
EventTime
|
O timestamp que indica quando uma atividade ou evento específico ocorreu. | ||
|
Descrição
O Event Time traz a data e hora exatas de cada ação. Essa info é a base do Process Mining, pois define a ordem cronológica de tudo. Este timestamp serve para calcular tempos de ciclo, esperas e atrasos. Ele alimenta métricas como 'Tempo Médio de Revisão do Gestor', apoiando diretamente a análise de gargalos e o monitoramento de performance.
Por que é importante
O timestamp é essencial para calcular todas as métricas temporais, como tempos de ciclo e de espera, fundamentais para identificar atrasos.
Onde obter
Todo evento ou transação no Brex deve ter um timestamp associado, disponível nas respostas da API ou exportações de relatórios.
Exemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Departamento do Colaborador
EmployeeDepartment
|
O departamento do colaborador que submeteu o relatório de despesas. | ||
|
Descrição
Este atributo identifica o departamento (Vendas, Engenharia, Marketing, etc.) do colaborador. É uma dimensão organizacional essencial para a análise. Analisar dados por departamento ajuda a identificar variações de processo, gargalos ou problemas de conformidade específicos de certas áreas. Por exemplo, se um departamento tem uma taxa de reprovação muito maior, pode ser necessário um treinamento focado. Também é vital para o controle orçamentário e alocação de custos.
Por que é importante
Permite filtrar e comparar o desempenho entre unidades de negócio, ajudando a identificar tendências ou problemas específicos de cada departamento.
Onde obter
Esta informação geralmente vem do perfil do colaborador no Brex, sincronizado com o sistema de RH.
Exemplos
VendasEngenhariaMarketingFinanças
|
|||
|
Sinalização de Violação de Política
PolicyViolationFlag
|
Um sinalizador booleano indicando se o relatório de despesa foi marcado por violação de política. | ||
|
Descrição
Este atributo é um indicador (verdadeiro/falso) definido quando o motor de políticas do Brex detecta uma violação, como um gasto acima do limite ou um recibo ausente. Essa sinalização é a base para a análise de conformidade e para o KPI de 'Taxa de Violação de Política'. Ela permite filtrar rapidamente relatórios irregulares para entender o impacto nos tempos de processamento e taxas de reprovação, ajudando a refinar as políticas internas.
Por que é importante
Apoia o monitoramento de conformidade e quantifica o impacto das violações na eficiência e no retrabalho.
Onde obter
Provavelmente um campo booleano ou indicador de status nos dados do Brex, gerido pelo motor de políticas.
Exemplos
verdadeirofalse
|
|||
|
Status do Relatório
ReportStatus
|
O status atual do relatório de despesas em seu ciclo de vida. | ||
|
Descrição
O Status do Relatório fornece um panorama de onde a despesa se encontra no processo, como 'Pendente de Aprovação do Gestor', 'Aprovado', 'Pago' ou 'Reprovado'. Este atributo é crucial para o monitoramento operacional, especialmente no dashboard de 'Monitor de Status de Relatórios Abertos'. Ele permite que gestores e equipes financeiras visualizem rapidamente a carga de trabalho atual, identifiquem relatórios travados e priorizem ações. Analisar o tempo gasto em cada status ajuda a identificar gargalos e ineficiências no processo.
Por que é importante
Fornece um panorama atual da posição de um relatório de despesas no workflow, algo vital para dashboards operacionais e monitoramento de status.
Onde obter
Este é um campo de status fundamental no objeto de relatório de despesas do Brex.
Exemplos
PENDING_APPROVALAPPROVEDREPROVADOPAGO
|
|||
|
Usuário do Evento
EventUser
|
O usuário que realizou a atividade, como o gestor que aprovou o relatório. | ||
|
Descrição
O atributo Usuário do Evento identifica o indivíduo responsável por uma atividade, seja o funcionário que submeteu o relatório, o gestor que revisou ou o analista financeiro que processou o reembolso. Esse atributo é essencial para análise de carga de trabalho e acompanhamento de performance, conforme mostrado no dashboard de 'Performance e Carga de Trabalho do Aprovador'. Ele ajuda a identificar quais aprovadores lidam com mais relatórios, quem tem os tempos mais rápidos e se há pessoas que se tornaram gargalos no processo, permitindo uma distribuição de trabalho mais equilibrada.
Por que é importante
Identifica o responsável pela ação, permitindo analisar carga de trabalho e performance individual.
Onde obter
Esses dados costumam ser capturados na trilha de auditoria ou no histórico de eventos do relatório no Brex.
Exemplos
john.smith@example.comjane.doe@example.comfinance-bot
|
|||
|
Valor Total
TotalAmount
|
O valor monetário total do relatório de despesas. | ||
|
Descrição
Este atributo representa o valor total solicitado no relatório. É uma métrica financeira crítica para entender os padrões de gastos e o impacto financeiro. Na análise, o valor total pode segmentar relatórios em faixas de valor (alto vs. baixo), que podem ter fluxos de aprovação ou níveis de auditoria distintos. Também é essencial para relatórios financeiros e análise orçamentária por departamento.
Por que é importante
Este atributo permite análises financeiras, como identificar relatórios de alto valor que podem exigir maior escrutínio ou ter tempos de aprovação mais longos.
Onde obter
Campo padrão de todo relatório no Brex, encontrado no objeto principal em respostas de API ou exportações.
Exemplos
150.752500.0079,99
|
|||
|
Aprovação de Primeira
FirstPassApproval
|
Um sinalizador indicando se o relatório foi aprovado de primeira, sem rejeições ou revisões. | ||
|
Descrição
Este atributo booleano identifica as instâncias mais eficientes do processo. É 'verdadeiro' apenas se o relatório passar da submissão à aprovação final sem reprovações ou pedidos de revisão. É a base do KPI 'Taxa de Aprovação de Primeira', uma medida essencial de qualidade. Uma taxa alta indica que os funcionários submetem relatórios corretos e que o fluxo de aprovação é ágil. Analisar os relatórios que falham nesse critério ajuda a localizar pontos de atrito e erro.
Por que é importante
Mede a qualidade dos envios iniciais e a eficiência do workflow ao identificar relatórios que fluem sem interrupções.
Onde obter
Este atributo é calculado na plataforma de Process Mining analisando a sequência de atividades para verificar a ausência de reprovações ou revisões.
Exemplos
verdadeirofalse
|
|||
|
Categoria da Despesa
ExpenseCategory
|
A categoria atribuída à despesa, como viagens, refeições ou software. | ||
|
Descrição
A Categoria da Despesa é a classificação escolhida pelo colaborador para descrever a natureza do gasto. Ela é usada para contabilidade, orçamento e aplicação de políticas. No Process Mining, categorizar as despesas permite uma visão granular. Ajuda a determinar se certas categorias, como viagens internacionais, têm ciclos de aprovação mais longos ou taxas de reprovação mais altas. Essa análise apoia o refinamento de políticas para tipos específicos de gastos.
Por que é importante
Permite analisar o processo por tipo de gasto, revelando comportamentos ou gargalos específicos para cada categoria.
Onde obter
Campo padrão em itens de despesa, que precisaria ser agregado ao nível do relatório caso existam múltiplas categorias.
Exemplos
Passagem AéreaAlimentação e EntretenimentoAssinaturas de SoftwareMateriais de escritório
|
|||
|
Detalhes da Violação de Política
PolicyViolationDetails
|
Uma descrição textual da política específica que foi violada. | ||
|
Descrição
Enquanto a Sinalização de Violação indica que algo ocorreu, este atributo explica o 'porquê'. Ele detalha a regra quebrada, como 'Limite de refeição excedido' ou 'Recibo obrigatório acima de R$ 50'. Esse nível de detalhe é valioso para a 'Análise de Violação de Política e Retrabalho', permitindo identificar as causas raiz. Esses insights orientam ações focadas, como o esclarecimento de políticas, envio de lembretes aos colaboradores ou ajuste de regras automáticas no sistema.
Por que é importante
Fornece a causa raiz das violações de política, permitindo melhorias focadas nas diretrizes, no treinamento de usuários e nas configurações do sistema.
Onde obter
Esta informação estaria disponível na seção de notas de revisão de despesas sinalizadas no Brex.
Exemplos
Despesa excede o limite da categoria.Recibo ausente.Despesa duplicada detectada.
|
|||
|
É Automatizado
IsAutomated
|
Um sinalizador booleano indicando se a atividade foi realizada por um robô ou usuário do sistema. | ||
|
Descrição
Este atributo identifica se uma atividade foi automática (como uma verificação de política do sistema) ou humana (como uma aprovação manual). Diferenciar atividades manuais de automáticas é crucial para entender o nível de automação do processo. Ajuda a avaliar a eficácia de sistemas baseados em regras e a identificar oportunidades para automatizar ainda mais, guiando esforços para aumentar o processamento sem toque humano (touchless).
Por que é importante
Mede o nível de automação e identifica quais etapas são feitas por humanos ou pelo sistema.
Onde obter
Derivado da checagem do usuário associado ao evento. Eventos do sistema geralmente usam usuários genéricos como 'system'.
Exemplos
verdadeirofalse
|
|||
|
É Retrabalho
IsRework
|
Um sinalizador calculado que é verdadeiro se o relatório foi devolvido para revisão pelo menos uma vez. | ||
|
Descrição
Este atributo booleano é derivado do fluxo do processo. Ele é 'verdadeiro' para qualquer relatório que tenha a atividade 'Relatório Enviado para Revisão' no histórico, facilitando a análise de retrabalho. Essa sinalização alimenta o KPI de 'Taxa de Retrabalho' e o dashboard de 'Análise de Violação de Política'. Ela permite comparar casos que fluem sem problemas com aqueles que retornam, ajudando a quantificar o tempo e o custo do retrabalho.
Por que é importante
Identifica relatórios que exigiram correção, permitindo analisar as causas e os custos do retrabalho.
Onde obter
Este atributo não está no sistema de origem. Ele é calculado verificando se a sequência de atividades contém 'Relatório Enviado para Revisão'.
Exemplos
verdadeirofalse
|
|||
|
End Time
EndTime
|
O timestamp que indica quando uma atividade foi concluída. | ||
|
Descrição
Enquanto o StartTime marca o início de uma atividade, o EndTime marca sua conclusão. Isso é muito relevante para etapas que possuem duração, como a revisão de um gestor. A presença de ambos permite o cálculo preciso do tempo de processamento, separando-o do tempo de espera anterior. Isso ajuda a medir quanto tempo o trabalho em si leva para ser realizado, um componente fundamental na análise de gargalos.
Por que é importante
Permite calcular o tempo real de execução de cada atividade, separando-o do tempo de espera, para uma análise de gargalos mais precisa.
Onde obter
O EndTime costuma ser o StartTime da próxima atividade. Também pode ser um campo específico na data de origem para tarefas com duração definida.
Exemplos
2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
|
|||
|
Meio de Pagamento
PaymentMethod
|
Indica como a despesa foi paga (ex: cartão corporativo ou fundos pessoais). | ||
|
Descrição
Este atributo diferencia despesas feitas no cartão corporativo Brex daquelas pagas do próprio bolso pelo funcionário que exigem reembolso. Essa distinção é importante pois o processo varia conforme o método de pagamento. Transações de cartão corporativo seguem um fluxo de conciliação, enquanto reembolsos seguem um fluxo de solicitação e pagamento. Analisar por método de pagamento ajuda a isolar problemas únicos de cada fluxo e otimizá-los de forma independente.
Por que é importante
O fluxo do processo e as etapas exigidas costumam variar entre despesas no cartão corporativo e reembolsos; por isso, este é um atributo essencial para a análise de variantes.
Onde obter
Esta informação é inerente aos dados de transação no Brex.
Exemplos
Cartão Corporativo BrexReembolsoPagamento de Contas
|
|||
|
Moeda
Currency
|
O código da moeda para o valor total do relatório de despesas. | ||
|
Descrição
O atributo Moeda especifica a unidade do Valor Total, como BRL, USD ou EUR. Isso é fundamental para uma análise financeira precisa, especialmente em empresas multinacionais. Este atributo garante que os dados financeiros sejam interpretados corretamente, permitindo a agregação e comparação adequada dos valores, muitas vezes exigindo a conversão para uma moeda comum de relatório. Isso evita erros analíticos ao somar valores monetários de moedas diferentes.
Por que é importante
Garante a precisão financeira em cenários multimoeda e permite a consolidação correta dos valores nos relatórios.
Onde obter
Este campo costuma estar disponível junto ao campo de valor nos dados do Brex.
Exemplos
USDEURGBP
|
|||
|
Motivo da Rejeição
RejectionReason
|
O motivo fornecido por um gestor ou usuário do financeiro ao reprovar um relatório de despesas. | ||
|
Descrição
Este atributo captura o motivo (texto livre ou predefinido) dado quando um relatório é reprovado. Isso é diferente de um alerta automático e representa uma decisão manual do aprovador. Analisar os motivos de reprovação é fundamental para entender as causas de falhas e retrabalho. Ajuda a identificar erros comuns de submissão, políticas confusas ou falhas de comunicação. Essa informação pode ser usada para melhorar treinamentos e FAQs, reduzindo as taxas de reprovação.
Por que é importante
Explica o motivo das rejeições manuais, servindo como feedback para treinar usuários e reduzir erros futuros.
Onde obter
Geralmente um campo de comentário preenchido pelos aprovadores ao selecionar 'Reprovar' na interface do Brex.
Exemplos
Categoria de despesa incorreta selecionada.Por favor, forneça uma justificativa de negócio mais detalhada.Esta compra não foi pré-aprovada.
|
|||
|
Nome do funcionário
EmployeeName
|
O nome do colaborador que criou e submeteu o relatório de despesas. | ||
|
Descrição
Este atributo especifica o nome do colaborador dono do relatório. Enquanto o Usuário do Evento identifica quem agiu, o Nome do Colaborador identifica o sujeito da despesa. Isso permite rastrear despesas por funcionário, ajudando a identificar quem submete relatórios com violações frequentes ou reprovações constantes, o que pode indicar necessidade de treinamento. Também auxilia na compreensão dos padrões de gastos por cargo ou função.
Por que é importante
Identifica o dono da despesa, permitindo analisar a qualidade e conformidade dos envios por colaborador.
Onde obter
Informação fundamental em todo relatório, vinculada ao perfil do criador no Brex.
Exemplos
Alice JohnsonRobert WilliamsMaria Garcia
|
|||
|
País
Country
|
O país associado ao colaborador ou à transação de despesa. | ||
|
Descrição
Este atributo indica o país da unidade ou centro de custo do colaborador. Para empresas globais, é uma dimensão essencial para análise comparativa. Analisar o processo por país pode destacar diferenças regionais em performance, taxas de conformidade ou comportamento de gastos. Por exemplo, tempos de aprovação podem ser maiores em um país devido a leis locais ou estruturas de gestão diferentes, permitindo padronizar processos globais respeitando necessidades locais.
Por que é importante
Permite analisar a performance e conformidade em diferentes regiões, o que é vital para empresas multinacionais.
Onde obter
Obtido das informações do perfil do colaborador no Brex, que geralmente são sincronizadas com um sistema de RH central.
Exemplos
EUACANGBRDEU
|
|||
|
Recibos Anexados no Prazo
ReceiptsAttachedOnTime
|
Um sinalizador indicando se os recibos foram anexados antes da submissão do relatório. | ||
|
Descrição
Este atributo mede a adesão à melhor prática de anexar recibos antes da submissão. É 'verdadeiro' se 'Recibos Anexados' ocorrer antes de 'Relatório de Despesas Submetido'. Essa sinalização alimenta o dashboard de 'Aderência e Impacto de Recibos' e o KPI correspondente. Ajuda a quantificar a frequência de recibos ausentes e a correlacionar esse comportamento com atrasos e reprovações.
Por que é importante
Mede a conformidade no envio de recibos, ajudando a identificar causas comuns de atrasos e rejeições.
Onde obter
Calculado na ferramenta comparando os timestamps de 'Recibos Anexados' e 'Relatório de Despesas Submetido'.
Exemplos
verdadeirofalse
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados, que neste contexto é o 'Brex'. É importante para governança e rastreabilidade, especialmente quando dados de múltiplos sistemas são combinados. Na análise, ajuda a filtrar e segmentar dados de diferentes fontes, garantindo que métricas e mapas de processo sejam interpretados corretamente conforme a origem. Para uma visão de sistema único, serve como validação constante da fonte dos dados.
Por que é importante
Oferece contexto essencial sobre a origem dos dados, garantindo a rastreabilidade e permitindo a filtragem correta em ambientes com múltiplos sistemas.
Onde obter
Valor estático, 'Brex', adicionado durante a fase de extração e transformação dos dados.
Exemplos
BrexBrex-API-v2.1
|
|||
|
Tempo de Ciclo
CycleTime
|
O tempo total decorrido desde a criação do relatório de despesas até sua conclusão final. | ||
|
Descrição
O Tempo de Ciclo (Cycle Time) mede a duração total de cada caso. Ele é calculado pela diferença entre o timestamp do primeiro evento (ex: 'Expense Report Created') e o último (ex: 'Reimbursement Executed'). É um dos KPIs mais fundamentais para medir a eficiência, alimentando diretamente o dashboard de Tempo de Ciclo de Ponta a Ponta. Analisar essa métrica ajuda a identificar casos demorados, entender tendências e medir o impacto das melhorias aplicadas.
Por que é importante
Este é um KPI que mede a velocidade e eficiência geral do processo de gestão de despesas do início ao fim.
Onde obter
Calculado subtraindo o timestamp do primeiro evento do timestamp do último evento para cada caso.
Exemplos
3 dias e 4 horas10 dias 1 hora22 horas e 30 minutos
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O registro de data e hora da última atualização dos dados do sistema de origem. | ||
|
Descrição
Este atributo indica a atualidade dos dados. Ele registra a data e hora da última extração de dados bem-sucedida do Brex. Saber quando os dados foram atualizados pela última vez é crucial para que os usuários entendam a tempestividade dos insights. Isso ajuda a determinar se os dashboards refletem o estado atual das operações ou se são baseados em dados mais antigos, alinhando as expectativas sobre a precisão da análise.
Por que é importante
Informa sobre a atualidade da data, o que é vital para decisões operacionais precisas.
Onde obter
Timestamp gerado pela ferramenta de extração ao final de uma coleta de dados bem-sucedida do Brex.
Exemplos
2023-11-20T02:00:00Z2023-11-21T02:00:00Z
|
|||
Atividades de Gestão de Despesas
| Atividade | Descrição | ||
|---|---|---|---|
|
Aprovado pelo Financeiro
|
O departamento financeiro concluiu a revisão e deu a aprovação final. Este é o último portão de aprovação antes do processamento do reembolso. | ||
|
Por que é importante
Este é um marco crítico que autoriza o pagamento. É o ponto final para medir o ciclo de aprovação completo e o ponto inicial para o KPI de atraso na execução do reembolso.
Onde obter
Este evento deve ser registrado na trilha de auditoria com o ID do aprovador final e o timestamp.
Captura
Capturado via event log ou mudança de status para 'Finance Approved' ou 'Approved for Payment'.
Tipo de evento
explicit
|
|||
|
Aprovado pelo Gerente
|
O gestor direto revisou e aprovou o relatório. Este é um ponto de decisão fundamental que move o processo para a próxima etapa, geralmente a revisão do financeiro ou aprovação automática. | ||
|
Por que é importante
Marco que encerra a aprovação inicial. Essencial para medir tempos de ciclo, carga de trabalho e a taxa de aprovação de primeira.
Onde obter
Este evento costuma ser registrado em uma tabela de histórico de aprovação, contendo o ID do aprovador e o timestamp.
Captura
Capturado via event log ou mudança de status para 'Manager Approved' com o respectivo timestamp.
Tipo de evento
explicit
|
|||
|
Lançamento Contábil Realizado
|
Representa a etapa final onde os dados da despesa são lançados com sucesso na contabilidade ou no ERP da empresa. Isso conclui a conciliação financeira do relatório. | ||
|
Por que é importante
Esta atividade confirma que o processo está concluído do ponto de vista contábil. Atrasos entre o reembolso e o lançamento podem indicar problemas de integração ou de workflow contábil.
Onde obter
Capturado via confirmação de API ou atualização de status após a sincronização com o sistema contábil.
Captura
Registrado após o retorno da API ou atualização de status pelo ERP integrado.
Tipo de evento
explicit
|
|||
|
Reembolso Executado
|
Esta atividade marca o momento em que o pagamento é efetivamente desembolsado para o colaborador. É a etapa final sob a ótica do funcionário e o encerramento bem-sucedido do processo. | ||
|
Por que é importante
Ponto final de sucesso do processo. Necessário para calcular o 'Tempo de Ciclo Médio Ponta a Ponta' e o atraso no reembolso.
Onde obter
Este evento deve ser capturado dos logs de transação de pagamento ou via API, correspondendo à data real de execução do pagamento.
Captura
Capturado pelo log de transações de pagamento, que inclui um timestamp de execução.
Tipo de evento
explicit
|
|||
|
Relatório de Despesa Criado
|
Esta atividade marca o início de um relatório de despesas por um colaborador. O sistema captura esse evento quando um novo registro é gerado, seja como rascunho ou com itens iniciais. | ||
|
Por que é importante
Evento inicial do processo. Analisar o tempo até a submissão ajuda a entender o comportamento do funcionário e atrasos no relato de despesas.
Onde obter
Este evento é capturado do timestamp de criação do objeto no banco de dados do Brex, correspondendo ao primeiro registro do ID do Relatório.
Captura
Identificado pela data de criação do registro principal do relatório.
Tipo de evento
explicit
|
|||
|
Relatório de Despesa Enviado
|
Esta atividade ocorre quando o colaborador submete formalmente o relatório para aprovação, alterando o status de 'Rascunho' ou 'Aberto' para 'Pendente de Aprovação'. | ||
|
Por que é importante
Marco importante que inicia o workflow de aprovação. O tempo entre a submissão e o aval final é um componente crítico do tempo total de ciclo.
Onde obter
Evento explícito no log ou inferido da mudança de status para 'Submetido' com seu respectivo timestamp.
Captura
Capturado via event log ou campo 'submission_timestamp' no registro do relatório.
Tipo de evento
explicit
|
|||
|
Relatório Enviado para Revisão
|
Um aprovador (gestor ou financeiro) devolve o relatório para correção. É diferente de uma rejeição definitiva e inicia um loop de retrabalho. | ||
|
Por que é importante
Esta atividade é o principal indicador de retrabalho. Rastrear sua frequência é essencial para o KPI de 'Taxa de Retrabalho' e para as análises de eficiência.
Onde obter
Inferido de uma mudança para 'Necessita Revisão' ou 'Devolvido'. O sistema captura o timestamp dessa atualização.
Captura
Inferido pela mudança para um status como 'Needs Revision', geralmente com comentários.
Tipo de evento
inferred
|
|||
|
Gestor Rejeitou
|
O gestor direto revisou e reprovou o relatório. Essa ação geralmente interrompe o processo ou devolve o relatório ao colaborador para correção. | ||
|
Por que é importante
Esta atividade representa um resultado negativo e uma exceção. É crucial para calcular a 'Taxa de Reprovação' e identificar falhas no primeiro nível de aprovação.
Onde obter
Deve ser registrado no histórico de aprovação ou trilha de auditoria, com timestamp e código do motivo.
Captura
Capturado via event log ou mudança de status para 'Manager Rejected' com o respectivo timestamp.
Tipo de evento
explicit
|
|||
|
Recibos Anexados
|
Representa a ação de um usuário carregando ou anexando uma imagem de recibo ou documento a um item de despesa. Geralmente é capturado como um evento explícito com timestamp para cada anexo. | ||
|
Por que é importante
Rastrear esta atividade é crítico para o dashboard de 'Aderência e Impacto de Recibos', ajudando a correlacionar atrasos com a falta de documentos.
Onde obter
Registrado em uma tabela que vincula anexos aos itens de despesa, cada um com seu próprio timestamp de criação.
Captura
Registrado quando o usuário faz o upload de um arquivo vinculado à despesa.
Tipo de evento
explicit
|
|||
|
Reembolso Agendado
|
Após a aprovação final, o relatório entra na fila de pagamento. Esta atividade representa a transferência da aprovação para o sistema de pagamentos. | ||
|
Por que é importante
Etapa que revela atrasos entre a aprovação final e o pagamento real, separando gargalos de aprovação de ineficiências no sistema de pagamento.
Onde obter
Pode ser inferido do status 'Pronto para Pagamento' ou ser um evento explícito de integração com o ERP.
Captura
Inferido pela mudança para 'Pending Payment' ou pela criação de um lote de pagamento.
Tipo de evento
inferred
|
|||
|
Rejeitado pelo Financeiro
|
O departamento financeiro reprovou o relatório, geralmente por motivos de política, conformidade ou falta de documentação. Esta é uma reprovação final que encerra o processo. | ||
|
Por que é importante
Este é um evento de exceção chave. Analisar sua frequência é vital para entender falhas de conformidade e calcular a 'Taxa de Reprovação'.
Onde obter
Como toda decisão de aprovação, deve ser registrada em trilha de auditoria com ID do aprovador, timestamp e motivo.
Captura
Capturado via event log ou mudança de status para 'Finance Rejected'.
Tipo de evento
explicit
|
|||
|
Revisão do Gestor Iniciada
|
Esta atividade marca o ponto em que o relatório entra na fila de aprovação do gestor. Geralmente é inferida pela mudança de status para 'Pendente de Aprovação do Gestor'. | ||
|
Por que é importante
Sinaliza o início da primeira fase de aprovação. Medir a duração até o aval ou reprovação do gestor é a chave para o KPI de tempo médio de revisão.
Onde obter
Inferido do timestamp de quando o status muda para 'Pendente de Aprovação do Gestor', coincidindo geralmente com a submissão.
Captura
Inferido pelo timestamp da mudança para 'Pending Manager Approval'.
Tipo de evento
inferred
|
|||
|
Revisão Financeira Iniciada
|
Marca quando o relatório entra na fila do financeiro para revisão final. Geralmente ocorre após a aprovação do gestor. | ||
|
Por que é importante
Sinaliza o início da fase final de aprovação. Analisar sua duração ajuda a identificar gargalos no departamento financeiro.
Onde obter
Inferido de quando o status muda para 'Pendente de Aprovação do Financeiro' após o aval do gestor.
Captura
Inferido pelo timestamp da mudança para 'Pending Finance Review'.
Tipo de evento
inferred
|
|||
|
Violação de Política Sinalizada
|
Evento (manual ou automático) indicando que um item viola a política da empresa. Ocorre quando uma regra do sistema é acionada ou um revisor marca o problema. | ||
|
Por que é importante
Esta atividade é crucial para o dashboard de 'Análise de Violação de Política e Retrabalho' e para o KPI de 'Taxa de Violação de Política'.
Onde obter
Derivado do atributo 'Policy Violation Flag' marcado como true. O timestamp é de quando esse status foi atualizado.
Captura
Inferido pela mudança em um sinalizador booleano ou campo de status indicando violação.
Tipo de evento
inferred
|
|||