Construa um app de folha de ponto com regras de horas extras que suporte submissão semanal, aprovações de gerentes e exportações limpas das horas aprovadas para payroll.
Um app de folha de ponto com regras de horas extras não é só sobre registrar horas. É sobre evitar confusão, reduzir erros de pagamento e dar a todos um processo previsível.
Quando folhas de ponto vivem em planilhas ou mensagens, pequenos problemas se acumulam rápido. Pessoas usam modelos diferentes, esquecem de registrar intervalos ou editam entradas depois sem que ninguém perceba. Gerentes passam tempo correndo atrás de horas faltantes em vez de checar se a semana faz sentido. No dia da folha, você está juntando informação parcial torcendo para que bata com o que os empregados lembram.
Horas extras são onde começam as disputas. Se a regra não for consistente (ou não estiver escrita de um jeito que as pessoas possam seguir), dois empregados com a mesma jornada podem acabar pagos de forma diferente. Mesmo quando todos agem de boa fé, regras pouco claras geram retrabalho: recálculos, edições retroativas e conversas desconfortáveis.
As aprovações são o portão de segurança antes de o dinheiro ser movido. A etapa de aprovação do gerente confirma que a semana está completa, que os códigos de trabalho ou projeto (se usados) fazem sentido e que as horas extras estão justificadas. Também cria um momento claro de “isso é final”, para que a folha não pegue números de um rascunho em andamento.
A submissão semanal deve virar um hábito simples: todo mundo trabalha dentro de uma semana definida (por exemplo, seg–dom), envia até um prazo claro (por exemplo, segunda-feira, 10:00) e recebe lembretes antes do vencimento. Após a submissão, edições devem ser bloqueadas ou exigir reaprovação, e o status deve ser óbvio (Draft, Submitted, Approved, Rejected).
Esse tipo de app só funciona se todos concordarem com o básico desde o início: quando as pessoas enviam, quem pode mudar o quê e o que conta como horas extras. Se você não delimitar cedo, o app vira uma discussão semanal.
Comece pelo ritmo de submissão. Submissão semanal mantém as coisas simples para a maioria das equipes: as pessoas podem lançar tempo durante a semana e enviar uma vez. O limite chave é se você permite edições após a submissão. Uma regra comum é que as entradas ficam editáveis até o botão Submit semanal ser pressionado.
Regras de horas extras têm de ser inequívocas. Decida se horas extras são acionadas por limites diários (por exemplo, mais de 8 horas no dia), limites semanais (mais de 40 horas na semana) ou ambos. Se ambos se aplicarem, diga qual prevalece quando houver sobreposição para não contar horas extras duas vezes.
A aprovação do gerente deve ser um ciclo curto para que seja rápida: aprovar (horas tornam-se finais), pedir mudanças (empregado edita e reenviam) ou rejeitar (empregado corrige e reenvia).
Depois de aprovado, bloqueie o período. O bloqueio evita edições de última hora e mantém a folha consistente. Se correções forem necessárias, use uma ação “desbloquear com motivo” que registre quem desbloqueou e por quê.
A exportação para a folha de pagamento deve incluir apenas horas aprovadas. Faça disso um limite rígido: qualquer coisa não aprovada fica fora das exportações, mesmo que pareça completa.
O objetivo não é rastrear tudo. É capturar o suficiente para calcular horas, aplicar política e provar quem aprovou o quê.
Comece por funções. A maioria das equipes precisa de três: empregados que lançam horas, gerentes que aprovam e payroll (ou um admin) que pode exportar e configurar. Mantenha permissões simples para que pessoas não fiquem bloqueadas.
Pense em três camadas: pessoas, uma folha semanal e entradas individuais.
Armazene o básico de cada pessoa (nome, ID do empregado ou email, função, gerente e equipe ou centro de custo). Para cada folha, guarde o proprietário, a data de início da semana, o fuso horário usado naquela semana e um status (Draft, Submitted, Approved, Rejected). Para cada entrada, capture data, hora de início, hora de término, minutos de intervalo, projeto ou tarefa e uma nota curta.
Você também vai querer configurações de calendário como o dia de início da semana (seg ou dom) e o fuso horário usado nas regras. Se a folha precisar, adicione contexto opcional como local ou departamento.
Aprovações são onde as discordâncias acontecem, então mantenha uma trilha de auditoria pequena, chata e clara:
Exemplo: um empregado em Berlim submete no domingo à noite. Se você armazenar o fuso horário usado para aquela semana, evita o problema clássico em que o horário de submissão parece segunda-feira para um gerente em Nova York.
Se você capturar apenas esses campos, pode rodar regras de horas extras, encaminhar aprovações e exportar totais limpos para a folha de pagamento sem transformar o app num sistema complexo de RH.
Escreva a política em frases simples que qualquer pessoa possa ler. Se você não consegue explicar com clareza, o app vai criar surpresas na folha de pagamento.
Comece escolhendo o gatilho: horas extras após 8 horas por dia, após 40 horas por semana, ou ambos. Se usar ambos, decida a ordem. Uma escolha comum é calcular horas extras diárias primeiro e depois aplicar horas extras semanais apenas sobre as horas regulares restantes.
Seja explícito sobre quais tempos contam. Intervalos não remunerados mudam tudo, então diga de forma clara: “O almoço é não remunerado e não conta como hora trabalhada.” Se você arredonda tempo, escreva isso também. Por exemplo: “Arredonde cada entrada e saída para o múltiplo de 5 minutos mais próximo.” Ao longo de um mês, pequenas escolhas de arredondamento somam.
Depois, trate dias especiais. Fins de semana, feriados e tempo de deslocamento frequentemente têm regras de pagamento diferentes. Mesmo que você não pague extra, ainda precisa de uma declaração clara como: “Horas de sábado são tratadas como dias de semana, a menos que as horas semanais totais excedam 40.”
Frases de política que você pode copiar e adaptar:
Depois que essas frases forem acordadas, construir a lógica vira uma tarefa de tradução em vez de um debate.
Um fluxo semanal funciona melhor quando todos sabem o que conta como “esta semana” e quando deve ser submetido. Escolha um único dia de início de semana (frequentemente segunda-feira) e um prazo claro (por exemplo, segunda-feira às 10:00 no fuso horário do empregado). Submissões atrasadas devem ser possíveis, mas visíveis.
Defina uma semana como um intervalo de datas fixo e armazene isso na folha. Isso evita confusão quando alguém abre o app no meio da semana ou viaja. Inclua um campo de status desde o primeiro dia (Draft, Submitted, Approved, Rejected).
Mantenha a edição de entradas simples: data, hora de início, hora de término (ou total de horas), tempo de intervalo, projeto ou código de custo (se necessário) e uma nota curta. Permita que empregados copiem a entrada de ontem e editem. Esse atalho reduz bastante o esforço semanal.
Enquanto as entradas são adicionadas, mostre totais da semana no topo: horas totais, horas regulares, horas extras. A divisão pode ser estimada até a semana ser completa, mas deve atualizar em tempo real para que empregados percebam erros cedo.
Se campos obrigatórios estiverem faltando, mostre um aviso claro em vez de deixar os totais parecerem “errados”.
Submit deve fazer três coisas: validar entradas (sem tempo negativo, sem sobreposições, notas obrigatórias), mudar o status para Submitted e bloquear a edição. Se uma mudança for necessária, encaminhe via “Return to Draft” (geralmente acionado por um send-back do gerente ou rejeição).
Uma vez submetido, o gerente precisa de uma fila simples: nome do empregado, intervalo da semana, horas totais, problemas sinalizados (como notas faltando) e uma tela de revisão rápida. Esse é também o lugar certo para notificações automáticas quando uma folha muda para Submitted.
Um gerente deve abrir uma tela e ver imediatamente o que precisa de atenção. Mostre uma fila curta de semanas submetidas, cada uma com nome do empregado, intervalo da semana, horas totais, horas extras (se houver) e um indicador rápido para notas. Esse resumo ajuda gerentes a identificar problemas sem clicar em cada dia.
Quando o gerente abrir uma semana, mantenha as decisões consistentes:
Comentários importam. Exija um motivo curto para send-back e reject, e armazene isso com o registro para que o empregado saiba exatamente o que corrigir.
Seja claro sobre o que pode ser alterado após cada decisão. Após send-back ou reject, o empregado pode editar entradas e notas, e então reenviar. Após approve, edições devem ser bloqueadas por padrão. Se você permitir mudanças, use uma ação “reopen week” que inicie um novo ciclo de aprovação (e, se necessário, uma segunda aprovação).
Planeje para ausências. Atribua um aprovador substituto por equipe (ou por empregado) e permita que RH ou um papel admin reatribua aprovações durante férias.
Mantenha uma trilha de auditoria: quem submeteu, quem aprovou (ou delegou), timestamps e um log simples de mudanças (qual campo mudou e quando).
Horas extras parecem simples até aparecer a primeira semana complicada. Você precisa de uma única fonte de verdade para a matemática, e ela deve bater com o que empregados veem, o que gerentes aprovam e o que a folha exporta.
Comece decidindo de onde você calcula: totais diários, totais semanais ou ambos. Muitas políticas tratam as primeiras 8 horas por dia como tempo regular e contam qualquer coisa acima disso como horas extras. Outras ignoram limites diários e olham apenas para horas semanais (por exemplo, qualquer coisa acima de 40 horas). Se sua política usar ambos, defina a ordem para não contar horas duas vezes. Uma abordagem prática é: calcular horas extras diárias primeiro e depois calcular horas extras semanais sobre as horas regulares remanescentes.
Essas situações normalmente quebram totais ou criam disputas:
Pessoas se autocorrigem mais rápido quando podem ver uma decomposição clara. Mostre as horas regulares e extras de cada dia e os intervalos não remunerados, depois um resumo semanal. Se algo parecer errado, destaque a entrada exata que causa o problema (por exemplo: “Sobrepõe com 14:00–16:00”).
Mantenha os cálculos consistentes em todos os lugares. Reuse a mesma lógica de horas extras na tela do empregado, na visão do gerente, nos relatórios e na exportação para a folha.
Equipes de folha de pagamento raramente precisam de tudo o que o app rastreia. Elas precisam de um arquivo previsível com os nomes das colunas exatos que o sistema delas espera, entregue em uma programação. Decida isso cedo para não entrar em trocas semanais.
Comece concordando o formato de exportação. CSV é comum porque a maioria dos sistemas de folha consegue importar, mas a chave real é a lista de campos e os nomes das colunas. Se payroll disser que a coluna deve se chamar EmployeeID, combine exatamente.
Um arquivo de exportação prático geralmente inclui ID do empregado (não só nome), a data de término da semana (ou início e fim da semana), horas regulares e horas extras em colunas separadas, um centro de custo ou código de projeto (se alocar mão de obra) e o timestamp de aprovação mais o ID do aprovador.
Exporte apenas semanas totalmente aprovadas. Trate a aprovação como um portão: sem aprovação, sem exportação.
Correções são onde equipes ficam presas. Uma abordagem limpa é evitar editar um registro exportado no lugar. Em vez disso, crie uma linha de ajuste que a folha importe como um delta. Por exemplo, se a Semana 42 foi exportada com 5.0 horas extras mas deveria ter 4.0, gere uma linha de ajuste de -1.0 horas extras ligada à semana e ao empregado originais.
Armazene exportações como lotes para que a folha possa reexecutar com segurança. Dê a cada lote um export ID, a data e hora de geração e os filtros exatos usados (por exemplo, “Semanas aprovadas terminando em 2026-01-18”). Se payroll importar o mesmo lote duas vezes, o export ID ajuda a detectar duplicatas.
Esses apps normalmente falham por motivos simples: estados “finais” pouco claros, limites de tempo confusos e exportações que não batem com o que a folha espera.
A primeira armadilha é permitir que pessoas editem tempo depois que uma semana foi aprovada. Parece flexível, mas quebra a confiança nos números. Trate Approved como bloqueado. Se alguém realmente precisar mudar, exija um pedido de correção que reabra a semana e deixe uma trilha de auditoria do que mudou e por quê.
Alterar regras de horas extras no meio do período é outra fonte comum de disputa. Se a política mudar numa quarta-feira, documente a data efetiva e a versão usada para cada semana. Caso contrário, duas pessoas podem ter horas idênticas e resultados de horas extras diferentes. Mesmo uma nota simples como “Política v2 vigente a partir de 15 de jan” anexada à semana pode evitar discussões.
Decisões sobre fuso horário podem arruinar totais silenciosamente. Escolha uma regra e mantenha: use o fuso local do empregado ou o fuso da folha da empresa. Se você não fizer nada, turnos tardios podem migrar para o dia errado e alterar totais diários e horas extras.
Aprovações sem comentários desperdiçam tempo. Quando um gerente rejeitar ou enviar de volta uma semana, exija um motivo curto para que o empregado saiba o que corrigir.
Algumas regras que valem a pena impor:
Antes de alguém começar a registrar tempo, concorde as configurações que decidem se o processo parece justo e previsível.
Trave as regras do calendário: dia de início da semana (segunda vs domingo) e o cutoff de submissão (por exemplo, “submeter até segunda às 10:00 para a semana anterior”). Coloque isso por escrito e repita na interface para que as pessoas não adivinhem.
Escreva sua política de horas extras em frases simples e depois teste com alguns exemplos reais. Não teste só uma semana “normal”. Tente 3 a 5 cenários incluindo um turno tardio, um intervalo perdido e um turno dividido.
Mantenha as verificações de rollout práticas:
Preste atenção especial ao bloqueio. Submitted deve impedir edições, a menos que um gerente envie de volta. Approved deve ser efetivamente imutável, exceto por um fluxo de correção rastreado. Caso contrário, a folha vira um alvo móvel.
Faça a exportação para a folha ser entediante. Ela deve produzir os mesmos números para o mesmo período e incluir apenas horas aprovadas. Se reexecutar a exportação do mês passado alterar o resultado, pause o rollout e corrija isso primeiro.
Uma equipe de depósito paga horas extras por qualquer coisa acima de 40 horas na semana (segunda a domingo), e só horas aprovadas podem ser pagas. Cada trabalhador submete uma vez por semana e um gerente deve aprovar até segunda ao meio-dia.
Jordan trabalha no turno da manhã. Na sexta, Jordan registrou 38 horas. No sábado, Jordan ficou até tarde para uma remessa urgente e registrou mais 6 horas. No domingo à noite, Jordan revisa a semana, adiciona uma nota curta na entrada de sábado e submete a folha com 44 horas totais.
Na segunda de manhã, o gerente confere a submissão. O app mostra uma divisão simples: 40 horas regulares e 4 horas extras. O gerente nota que a entrada de sábado foi criada depois do término do turno e pede detalhes. Jordan percebe que a hora de início está 30 minutos errada e precisa corrigir.
Como a folha já está submetida, a correção passa por um fluxo de reenvio: o gerente rejeita a folha com um motivo (“Corrigir hora de início do sábado, depois reenviar”). Jordan edita a entrada de sábado, reenviam, e as horas extras recalculem para 3,5 horas.
Quando o gerente aprova, a folha recebe uma exportação limpa para aquela semana: ID e nome do empregado, datas de início e fim da semana, horas regulares aprovadas e horas extras aprovadas, centro de custo ou local opcional (Warehouse A), além do timestamp de aprovação e nome do aprovador.
Após o lançamento, a equipe acompanha alguns números simples: submissões tardias (após domingo), taxa de rejeição (com que frequência gerentes devolvem folhas) e tempo médio de submissão até aprovação. Se esses números aumentarem, geralmente apontam para regras pouco claras ou lembretes ausentes.
Trate a primeira versão como um teste controlado, não uma troca em toda a empresa. Escolha uma equipe piloto com uma mistura normal de horas regulares e extras e comece com uma política clara de horas extras. Isso mantém o feedback focado e permite comprovar o fluxo de ponta a ponta.
Rode o piloto por 2 a 4 ciclos semanais. Isso é suficiente para ver onde as pessoas hesitam, onde gerentes travam e se a exportação bate com o que o financeiro espera.
Um plano de rollout prático:
Pequenas mudanças de texto na interface eliminam muitos tickets de suporte. Mantenha o fluxo de submissão curto e adicione texto de ajuda apenas onde as pessoas realmente tropeçam.
Decida cedo quem é dono das atualizações de política. RH pode ser dono das definições de horas extras, payroll dono dos formatos de exportação e gerentes donos das aprovações. Torne essas permissões explícitas para que um admin bem-intencionado não mude uma configuração no meio do período de pagamento.
Se você quiser construir isso sem código personalizado, AppMaster (appmaster.io) é uma opção para prototipar e lançar com modelos de dados visuais, fluxos drag-and-drop para submissões e aprovações, e construtores de UI web/mobile. Comece com o fluxo mínimo e expanda só depois que o piloto provar que a lógica de horas extras e a exportação para payroll batem com seu processo.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
