Capítulo 08

Financeiro, Comissões e Compras

Comissões, contas a receber, custos fixos, lotes de compra e aprovações.

Este capítulo cobre a parte do iMportex que lida com dinheiro que entra, dinheiro que sai e dinheiro que se acumula em custo. No fluxo macro (compra/recebimento no Paraguai → triagem com laudo e grade → assistência técnicainventárioexpedição/logística pra SP → venda B2B com cotações), este é o pedaço que roda por trás de tudo: quem trouxe o aparelho e por quanto (Compras & Lotes), quanto o vendedor ganha por cada aparelho vendido (Comissões), quanto falta receber de cada cliente (Contas a Receber), quanto a empresa gasta pra existir todo mês (Custos Fixos) e se, no final das contas, o mês deu lucro ou prejuízo (Fechamento Mensal). Também mora aqui a fila de Aprovações: todo desconto de venda ou custo extra de conserto que passa de um limite não anda sozinho — alguém com poder de gestão (ADMIN ou GERENTE) precisa dar o sinal verde antes.

A regra que atravessa quase toda tela deste capítulo é a que o time chama de "regra de visibilidade de dinheiro" da casa: dinheiro e margem só aparecem pra quem lida com dinheiro por função — ADMIN, GERENTE e FINANCEIRO. Os seis perfis operacionais (VENDEDOR, OPERADOR_PY, OPERADOR_SP, TESTADOR, TECNICO_PROPRIO, SUPERVISOR_ASSISTENCIA) não veem custo de aparelho nem margem da loja — a única exceção é o próprio VENDEDOR, que enxerga a própria comissão e as próprias vendas pendentes de aprovação, nunca a folha ou a fila inteira.

Fluxo do módulo em 1 olhada

  1. Compras & Lotes (/compras/lotes) é onde a mercadoria nasce no sistema: um lote de compra trava o câmbio USD→BRL do dia (ou um valor manual, se for o caso) e vira o "guarda-chuva" sob o qual os IMEIs comprados são importados.
  2. Dentro de cada lote, Importar IMEIs (/compras/lotes/[id]/imeis) lê uma planilha do fornecedor (ou CSV simples), valida cada IMEI e grava os aparelhos — já com o custo de compra convertido pelo câmbio congelado do lote.
  3. Enquanto a operação roda, toda vez que uma venda com desconto acima do limite é criada, ou toda vez que uma OS de assistência adiciona um custo extra acima do limite, o item entra na fila de Aprovações (/aprovacoes) — e fica parado ali até ADMIN ou GERENTE decidir.
  4. Quando uma venda é efetivada (direto ou depois de aprovada), o sistema calcula a comissão do vendedor automaticamente e a deixa PENDENTE em /comissoes. No fim do mês, ADMIN/GERENTE fecham o mês do vendedor (PENDENTE→FECHADA) e depois marcam como paga (FECHADA→PAGA).
  5. Se a venda foi a prazo, ela gera parcelas que aparecem em Contas a Receber (/contas-receber) — vencidas, vencendo hoje ou nos próximos 7 dias — até alguém do Financeiro confirmar o pagamento (com comprovante obrigatório).
  6. Em paralelo, o Financeiro lança as despesas fixas da empresa (aluguel, salário administrativo, internet, energia, hospedagem, outros) em Custos Fixos (/custos-fixos).
  7. No fechamento do mês, a tela de Fechamento Mensal (/custos-fixos/fechamento) soma a margem bruta de todas as vendas efetivas do mês e subtrai os custos fixos lançados — o resultado é o lucro líquido (ou prejuízo) do mês.

Compras & Lotes

Compras & Lotes

Pra que serve: cadastrar um lote de compra (a "nota" de uma remessa vinda de um fornecedor) e, a partir dele, importar os IMEIs dos aparelhos comprados. É o ponto de entrada de todo aparelho que chega por compra formal (diferente da "entrada avulsa" ou "entrada legado", portas usadas para aparelho que já está no galpão sem registro formal — fora do escopo deste capítulo). O lote também é onde o câmbio USD→BRL fica congelado: o custo de cada aparelho comprado em dólar é convertido pela taxa do dia em que o lote foi criado, e essa taxa nunca é recalculada depois — nem quando alguém edita o lote por outro motivo (trocar fornecedor, corrigir frete).

⚠️ Atenção: editar um lote sem querer mexer no câmbio já causou, num caso real, um deslocamento de R$ 222.372 de custo entre lotes da empresa. Por isso o formulário de edição só recaptura um câmbio novo se o lote nunca teve nenhum (lote antigo, de antes dessa regra existir).

Quem usa:

  • ADMIN e GERENTE têm acesso total — criam, editam e excluem lotes, veem o valor da nota, o câmbio e a fonte.
  • FINANCEIRO a lista de lotes reais (câmbio, valor, fornecedor) — não pode criar, editar nem excluir um lote (a trava está no banco). Se um usuário FINANCEIRO tentar salvar uma edição, a tela devolve "Sem permissão para editar este lote".
  • OPERADOR_SP aparece no menu com o link "Compras & Lotes", mas não enxerga os lotes reais — o banco só deixa ele ver um lote fictício chamado "Estoque Legado"/"Avulso (Individual)", que existe só pra sustentar a entrada avulsa dele em outra tela. Na prática, se o operador de SP clicar neste link, a lista aparece vazia (ou quase) pra ele — não é bug, é uma trava de acesso do banco protegendo o custo de compra real dos aparelhos.
  • Nenhum outro perfil (VENDEDOR, OPERADOR_PY, TESTADOR, TECNICO_PROPRIO, SUPERVISOR_ASSISTENCIA) tem este link no menu. Quem chegasse direto pela URL cairia na mesma trava do banco: zero lotes reais visíveis, zero permissão de escrever.

Ações principais:

  • "Novo Lote de Compra": escolher fornecedor, data da compra, moeda (USD ou BRL), valor total, valor da nota em USD (opcional, referência), até 2 freteiros/trechos com percentual e base de cálculo do frete, e o campo "Câmbio manual" — quando marcado, o usuário digita a taxa; quando desmarcado, o sistema busca a cotação automática de um provedor externo de câmbio (com um provedor reserva, caso o principal falhe).
  • Editar um lote existente (ícone de lápis) — mesmo formulário, câmbio protegido pela regra acima.
  • Excluir (ícone de lixeira; fica oculto da lista, mas não é apagado de verdade) — pede confirmação explícita porque o lote pode já ter IMEIs importados e custo investido em cima dele.
  • "Importar IMEIs" (link por linha) — leva para a tela de importação de IMEIs daquele lote específico (documentada a seguir).
  • A tabela mostra, por lote: fornecedor, data, valor total, câmbio (com selo "(override)" quando foi manual), fonte do câmbio, status, e uma barra de progresso "recebidos/total" de aparelhos daquele lote.

Fluxo correto:

  1. ADMIN ou GERENTE cria o lote informando fornecedor, data, moeda e valor — decide ali, na hora, se o câmbio é automático ou manual.
  2. Confirma o lote. O câmbio gravado nesse instante é definitivo.
  3. Clica em "Importar IMEIs" do lote recém-criado e segue para a tela de importação (próxima seção).
  4. Se precisar corrigir fornecedor, frete ou observação depois, edita o lote — o câmbio permanece intocado, a não ser que o lote nunca tivesse um.

Se pular ou errar:

  • Criar o lote com câmbio errado (ou deixar no automático quando deveria ser manual) contamina o custo de todos os aparelhos importados sob aquele lote — e não tem correção "de leve" depois: editar não recalcula.
  • Um FINANCEIRO tentando editar um lote recebe um erro claro (não um erro cru de sistema) — mas se o fluxo de trabalho esperava que ele pudesse ajustar algo, a operação trava até um ADMIN/GERENTE entrar.
  • Excluir um lote que já tem IMEIs importados não apaga os aparelhos, mas o lote some da listagem — sem cuidado, isso pode confundir quem for procurar "de onde veio" aquele aparelho depois.

Detalhes e estados:

  • O formulário de edição sempre reabre sem marcar a opção de câmbio manual — então um lote que tinha o câmbio manual ligado corria risco de, numa edição de rotina, cair no caminho automático e reescrever a taxa por baixo. Isso já foi corrigido, mas é o tipo de comportamento que volta se alguém mexer no formulário sem entender a regra.
  • Toda vez que alguém liga o câmbio manual (na criação ou na edição), o sistema registra num log de auditoria — sempre dá pra saber quem mudou e quando.
  • O status de cada lote mostra "REGISTRADO" como padrão quando o campo vem vazio.

Importar IMEIs

Importar IMEIs

Pra que serve: dar entrada, um a um, nos aparelhos de um lote de compra já cadastrado — a partir de uma planilha (XLSX do fornecedor, com todas as colunas: modelo, capacidade, cor, status de bloqueio, preço em USD) ou de um CSV simples (só a coluna de IMEI). Cada IMEI validado vira um aparelho novo no sistema, com status inicial "Aguardando chegada" e já amarrado ao lote (todo aparelho tem que ter um lote — é regra dura do sistema).

Quem usa: a tela em si só exige que o usuário esteja logado — não tem uma trava de perfil própria. Na prática, quem consegue usar isso de forma útil é limitado por duas camadas do banco:

  1. Só ADMIN, GERENTE e FINANCEIRO conseguem ler um lote real (a mesma regra de "Compras & Lotes") — outro perfil batendo nesta URL para um lote real recebe "não encontrado".
  2. Para gravar aparelhos novos (o passo de confirmar a importação), o banco aceita ADMIN, GERENTE, OPERADOR_SP, OPERADOR_PY e TESTADOR — mas os três últimos só numa combinação que envolve o lote fictício de entrada avulsa/legado, não o fluxo normal de "Compras & Lotes" com nota real.

Na prática do dia a dia, é uma tela de ADMIN/GERENTE (e FINANCEIRO pode acompanhar o status, mas não confirmar importação — a ação de gravar tem a mesma trava de escrita do lote).

Ações principais:

  • Escolher o arquivo (CSV ou XLSX) e clicar em analisar — o sistema processa o arquivo no servidor (nunca no navegador de quem está usando) e devolve uma prévia: cabeçalhos detectados, qual coluna é o IMEI, quantos IMEIs são válidos, quantos são inválidos (com o motivo: "luhn" — falhou no algoritmo de checagem de IMEI — ou "vazio"), quantos já existem no sistema e quantos estão duplicados dentro do próprio arquivo.
  • Revisar a prévia — se a coluna do IMEI não foi detectada automaticamente, escolher manualmente numa lista.
  • "Confirmar" — grava de fato os aparelhos válidos (excluindo duplicados e já existentes) como registros novos. Desde 06/09, se algum aparelho entrar sem custo (planilha sem preço naquela linha, CSV simples sem coluna de preço, ou lote sem câmbio congelado), a tela mostra na hora um aviso âmbar com a contagem exata — não é mais preciso descobrir isso numa auditoria depois.
  • Painel de status das verificações de IMEI (bloqueio de iCloud, lista negra/ blacklist, gerenciamento remoto corporativo — MDM — ainda ativo, peça não original) — só aparece quando a checagem automática de IMEI está ligada (ver Detalhes e estados).

Fluxo correto:

  1. A partir da tela de lotes, clicar em "Importar IMEIs" do lote certo.
  2. Escolher o arquivo do fornecedor (de preferência o XLSX padrão, que já traz modelo/capacidade/cor/preço — o CSV simples só grava o IMEI, sem esses dados).
  3. Analisar, revisar a prévia com atenção especial a "já existentes" (IMEI duplicado no sistema é sinal de erro de digitação ou de reenvio do mesmo arquivo) e "duplicados no arquivo".
  4. Confirmar — os aparelhos entram como "Aguardando chegada", prontos para seguir no fluxo de recebimento e triagem.

Se pular ou errar:

⚠️ Atenção: importar um CSV simples (sem enriquecimento) faz o aparelho entrar sem modelo, capacidade, cor ou custo — Prefira sempre o XLSX do fornecedor. Desde 06/09 esse aparelho não passa mais em silêncio: o painel de resultado mostra um aviso grande ("N aparelho(s) entraram sem custo — a planilha não trouxe preço, ou o lote está sem câmbio congelado") e um toast na hora da confirmação, porque em agosto 778 aparelhos entraram assim de uma vez e ninguém percebeu até a auditoria de setembro. Enquanto o custo não é lançado na mão, esse aparelho segue inflando a margem em todo relatório.

  • Se o lote não tiver nenhum câmbio gravado, o custo em reais de cada aparelho importado fica em branco mesmo vindo de um XLSX com preço em dólar — o sistema não inventa uma taxa, e esse aparelho entra na mesma contagem de "sem custo" acima.
  • Confirmar a importação sem revisar duplicados pode gerar erro de linha (IMEI já existe) — a ação recusa o IMEI individualmente e lista o motivo, não trava a importação inteira.

Detalhes e estados:

  • Existe uma chave de configuração (liga/desliga uma função sem precisar mexer no sistema) que controla a verificação automática de IMEI contra bloqueio de iCloud/lista negra/MDM — hoje ela vem desligada por padrão. Desligada, a importação de aparelhos funciona 100% normal, só não enfileira as checagens nem mostra o painel de status. Ou seja: se um dia a operação achar que "o sistema não está checando IMEI bloqueado", o primeiro lugar a olhar é essa configuração, não um bug.
  • O custo do aparelho é calculado automaticamente: o custo em dólar do aparelho multiplicado pelo câmbio do lote vira o custo em reais, e o frete do primeiro trecho (EUA→Paraguai) é somado por cima quando o lote tem percentual de frete configurado — isso tudo acontece na hora da importação, não depois.
  • Ao final de uma importação bem-sucedida, o sistema tenta (sem travar a resposta pra quem está usando) disparar o processamento automático das checagens de IMEI — se essa chamada falhar, ninguém percebe na hora; existe um botão manual "Processar verificações agora" como reforço.
  • O número da nota fiscal do fornecedor só é gravado no lote se ele ainda não tiver um número — a importação nunca sobrescreve um número já existente.

Fila de Aprovações

Fila de Aprovações

Pra que serve: é a "caixa de entrada" de tudo que precisa do sinal verde de um gestor antes de seguir. Duas filas independentes convivem na mesma tela: (1) movimentações de aparelho com custo extra acima do limite (por exemplo, uma OS de assistência técnica que gastou mais que o permitido sem aprovar antes) e (2) vendas com desconto acima do limite, que ficaram paradas no status "Aguardando aprovação" e não chegam a mexer em estoque, comissão ou parcela até serem aprovadas.

Quem usa:

  • ADMIN, GERENTE e FINANCEIRO enxergam a fila inteira (todas as movimentações e vendas pendentes da empresa).
  • VENDEDOR enxerga só as próprias vendas aguardando aprovação (ele negociou o desconto, então acompanha o andamento) — nunca vê a fila de custo extra de OS, que é informação de custo/margem, fora do alcance dele.
  • Só ADMIN e GERENTE efetivamente aprovam ou rejeitam. O FINANCEIRO vê a fila inteira, mas os botões de Aprovar/Rejeitar não aparecem para ele — é leitura, não ação. Qualquer outro perfil (OPERADOR_PY, OPERADOR_SP, TESTADOR, TECNICO_PROPRIO, SUPERVISOR_ASSISTENCIA) é redirecionado pro painel principal se tentar acessar a tela direto.
  • Separação de deveres na aprovação de venda (desde 06/09): GERENTE não aprova desconto da própria venda. Numa loja onde o gerente também vende, ele não pode dar um desconto grande numa venda sua e aprovar sozinho — a tela recusa com "Você não pode aprovar o desconto de uma venda sua. Peça a aprovação para um ADMIN". ADMIN aprova a própria venda normalmente (é o dono da empresa — no máximo decide o próprio preço, que é direito dele; e toda empresa tem pelo menos um ADMIN, então nunca fica sem pra quem escalar). Quem aprovou fica sempre registrado, inclusive quando é a própria venda do ADMIN.

Ações principais:

  • Na seção de vendas: "Aprovar" (venda por venda) ou "Aprovar tudo" (todas de uma vez, com confirmação mostrando o total em R$); rejeição individual pede motivo.
  • Na seção de movimentações: "Aprovar" ou "Aprovar tudo"; "Rejeitar" pede motivo — rejeitar zera o custo extra da movimentação e devolve a OS de "Aguardando aprovação" para "Em andamento", ou seja, o técnico segue trabalhando, só sem aquele custo lançado.
  • Cada venda pendente mostra, além do desconto que o vendedor declarou, um desconto real recalculado na hora — comparando o preço efetivamente cobrado contra o preço de tabela vigente. Isso existe porque um vendedor conseguia digitar um preço bem abaixo da tabela e declarar desconto 0%, contornando a aprovação sem tocar no campo "desconto" — o desconto real fecha esse desvio.

Fluxo correto:

  1. Venda é criada com desconto acima do limite (ou custo extra de OS acima do limite) → entra automaticamente na fila, sem a operação normal (baixa de estoque, comissão, parcela) rodar ainda.
  2. ADMIN ou GERENTE abre a fila de Aprovações, revisa o item — inclusive o desconto real, não só o declarado — e decide.
  3. Aprovar uma venda efetiva ela de verdade: move os aparelhos, dá baixa no estoque (por grade — lote de aparelhos idênticos vendido junto — ou por SKU, o código de um item avulso), gera parcelas se for a prazo, calcula a comissão e gera o pacote de entrega — tudo isso só acontece na aprovação, não na criação.
  4. Aprovar uma movimentação libera o custo extra que estava represado — a OS de assistência segue seu fluxo normal com aquele custo já contabilizado.
  5. Rejeitar uma venda cancela ela (nada foi efetivado, então é seguro). Rejeitar uma movimentação zera o custo extra e devolve a OS ao andamento.

Se pular ou errar:

⚠️ Atenção: uma venda "Aguardando aprovação" não é uma venda de verdade ainda — não aparece como vendida no estoque, não gera comissão, não gera parcela. Se a fila travar (ninguém aprova), o vendedor fica com uma venda no limbo e o cliente sem confirmação.

  • O sistema tem uma trava contra clique duplo ou duas pessoas aprovando a mesma venda ao mesmo tempo em telas diferentes: a segunda tentativa vê "esta venda já foi aprovada" em vez de duplicar a reserva de estoque.
  • Se a aprovação de uma venda falhar no meio do processo (por exemplo, dar erro ao mover o aparelho), o sistema desfaz a transição e a venda volta pra "Aguardando aprovação" — ela não fica "meio aprovada".

Detalhes e estados:

  • O limite de desconto sem aprovação vem de uma configuração da empresa, com 5% como valor padrão caso a configuração não exista.
  • O limite de custo extra sem aprovação também vem de uma configuração da empresa, com R$ 200 como padrão — e, importante: se essa configuração falhar ao ser lida, o sistema assume o lado mais seguro (exige aprovação), nunca o contrário.
  • ADMIN aprovando uma venda que também tinha crédito de troca (trade-in) acima do saldo do cliente libera esse crédito na mesma aprovação; GERENTE aprovando não libera — é uma distinção fina que só aparece em vendas com as duas situações combinadas ao mesmo tempo.

Comissões

Comissões

Pra que serve: mostrar, fechar e pagar a comissão dos vendedores. A regra de cálculo vigente é valor fixo por aparelho vendido: cada aparelho (identificado por IMEI ou vendido por grade, contado por unidade) numa venda gera um valor fixo de comissão para o vendedor daquela venda; itens de acessório (SKU) não contam.

Quem usa:

  • ADMIN, GERENTE e FINANCEIRO enxergam a folha inteira (todos os vendedores, todos os meses).
  • VENDEDOR enxerga só a própria comissão — nunca a de outro vendedor, e nunca o custo ou a margem por trás da venda.
  • Nenhum dos seis perfis operacionais restantes (OPERADOR_PY, OPERADOR_SP, TESTADOR, TECNICO_PROPRIO, SUPERVISOR_ASSISTENCIA) chega nesta tela — quem não tem nem a visão total nem a própria comissão é redirecionado pro painel principal.
  • ADMIN e GERENTE veem os botões de ação (fechar mês / marcar como paga) — mesmo um usuário FINANCEIRO com visão total não tem esses botões.

Ações principais:

  • "Fechar mês" (por vendedor + mês): todas as comissões "Pendente" daquele vendedor naquele mês viram "Fechada" (congeladas — depois de fechada, não dá pra voltar a mexer nelas por aqui).
  • "Marcar paga" (só depois de fechada): todas as "Fechada" daquele vendedor naquele mês viram "Paga", com data de pagamento registrada na hora.
  • "Relatório por vendedor": informando um mês (AAAA-MM), mostra a soma de comissão por vendedor, quebrada por status. O sistema não tem, hoje, coluna de salário fixo cadastrada — o relatório mostra explicitamente "salário fixo não disponível no schema atual" em vez de inventar um número.
  • Cartões-resumo com total geral, total pendente, fechado e pago.

Fluxo correto:

  1. Uma venda é efetivada (na criação direta, ou na aprovação, se tinha desconto acima do limite) → o sistema busca a regra de comissão vigente para aquele vendedor (ou a regra geral, se não houver uma específica) na data da venda e grava uma comissão "Pendente", automaticamente — ninguém precisa lançar isso à mão.
  2. Ao longo do mês, as comissões do vendedor se acumulam como "Pendente".
  3. No fechamento do mês, ADMIN/GERENTE clicam em "Fechar mês" para cada vendedor — as "Pendente" daquele mês congelam em "Fechada".
  4. Quando o pagamento sai de fato (folha, PIX, etc., fora do sistema), ADMIN/GERENTE clicam em "Marcar paga" — vira "Paga" com a data de agora.

Se pular ou errar:

  • Não existe caminho de "Pendente" direto para "Paga" passando por cima do fechamento — a ação de pagar só transiciona quem já está "Fechada". Isso é proposital: fechar é o momento de "travar a foto" do mês antes de pagar.
  • Uma venda sem regra de comissão vigente na data (nenhuma regra ativa cobrindo aquele vendedor ou geral, dentro da vigência) não gera comissão nenhuma — silenciosamente, não é erro. Se um vendedor reclamar que "não recebeu comissão de uma venda", o primeiro lugar a checar é se havia uma regra vigente na data daquela venda.

Detalhes e estados:

  • Estados possíveis de uma comissão: "Pendente", "Fechada" e "Paga".
  • O valor da comissão por aparelho vem de uma configuração cadastrada (com data de início e fim de vigência) — não é um número fixo escrito no sistema. Para saber o valor exato vigente hoje, é preciso consultar esse cadastro, não supor um número.
  • O registro de comissão não guarda a empresa diretamente — o sistema sempre busca essa informação através da venda relacionada. É uma decisão deliberada, pra nunca deixar essa informação dessincronizar da venda.

Contas a Receber

Contas a Receber

Pra que serve: o painel de tudo que a empresa ainda tem pra receber de clientes — parcelas de vendas a prazo, organizadas em vencidas, vencendo hoje e vencendo nos próximos 7 dias — e o lugar onde o Financeiro confirma que um pagamento efetivamente entrou (sempre com comprovante).

Quem usa: só quem tem permissão de ver dados financeiros — ADMIN, GERENTE e FINANCEIRO. Qualquer outro perfil batendo na URL é barrado pela própria página (ela exige a permissão antes de renderizar qualquer coisa, diferente de outras telas deste capítulo que só filtram depois). Dentro desses três, todos podem confirmar pagamento — não há uma distinção adicional aqui como há em Comissões (onde FINANCEIRO vê mas não age).

Ações principais:

  • "Confirmar pagamento" por parcela: abre um formulário que exige comprovante obrigatório (arquivo) — sem ele, a ação recusa a confirmação — e permite informar o cambista responsável (ou herdar o da venda, se não informado).
  • "Reprocessar atrasadas": um botão de reforço manual que roda a rotina que marca parcelas vencidas como "Atrasado" no banco (útil quando a rotina automática não rodou sozinha).
  • Busca por nome de cliente, que filtra a lista sem mudar os totais/ indicadores (o indicador é sempre da carteira inteira).
  • Exportação e link direto pro cadastro do cliente a partir da lista.
  • Cartão de indicador: percentual de parcelas vencidas, com meta de ficar abaixo de 5% (verde/vermelho conforme o resultado).

Fluxo correto:

  1. Uma venda a prazo gera parcelas automaticamente na efetivação.
  2. A tela mostra o status de cada parcela calculado na hora que a página abre (não depende de nenhuma rotina noturna ter rodado) — "vencida" é sempre relativo a hoje, no fuso do negócio (Brasil/Paraguai, não o horário cru do servidor).
  3. Quando o cliente paga, alguém do Financeiro clica em "Confirmar pagamento", anexa o comprovante (recibo, print do PIX, etc.) e confirma.
  4. O sistema recalcula o status da venda inteira: se todas as parcelas ficaram pagas, a venda vira "Paga"; se só parte, vira "Parcialmente paga".

Se pular ou errar:

  • Tentar confirmar pagamento sem anexar comprovante é recusado pela ação — não existe atalho "confio e confirmo sem anexo".
  • Uma parcela já paga não pode ser paga de novo (a ação recusa explicitamente); uma parcela cancelada também não aceita pagamento.
  • Se ninguém clicar em "Reprocessar atrasadas" e a rotina automática também não rodar, o status visual continua correto (é calculado na hora que a página abre), mas os registros no banco (usados por relatórios que dependem do valor já salvo) podem ficar desatualizados — por isso o botão existe como reforço manual, não como a única fonte de verdade.

Detalhes e estados:

  • Status possíveis de uma parcela: "Pendente", "Pago", "Atrasado", "Cancelado". Parcelas canceladas nunca aparecem nesta tela.
  • Vendas em dólar (moeda USD, típico do Paraguai) mostram o valor da parcela em US$ em vez de R$, e os totais de US$ e R$ nunca são somados entre si — aparecem sempre lado a lado, separados.
  • O comprovante fica guardado num espaço privado de arquivos; o link exibido na tela é gerado na hora (válido por 1 hora) — o link salvo expira, e é normal a tela gerar um novo automaticamente ao carregar uma parcela paga.

Custos Fixos

Custos Fixos

Pra que serve: cadastrar as despesas fixas mensais da empresa (o que não varia com o volume de vendas) — aluguel, salário administrativo, internet, energia, hospedagem, e uma categoria genérica "Outro" — para que entrem na conta do lucro líquido do mês.

Quem usa:

  • ADMIN, GERENTE e FINANCEIRO conseguem ver a tela (mesma permissão de "ver dinheiro" usada em Fechamento Mensal).
  • ADMIN e FINANCEIRO conseguem criar, editar ou excluir um lançamento — a trava está no banco (a permissão de escrita não inclui GERENTE). Na prática, isso significa que um GERENTE a tela de Custos Fixos normalmente, mas se tentar salvar um lançamento novo ou editar um existente, recebe "Sem permissão para editar este lançamento" — é uma das poucas telas do sistema onde GERENTE tem menos poder de escrita que FINANCEIRO.

Ações principais:

  • Lançar um novo custo: categoria (Aluguel, Salário Administrativo, Internet, Energia, Hospedagem, Outro), descrição livre opcional, valor em R$ (sempre maior que zero — não existe custo fixo de R$ 0 ou negativo), mês de referência (AAAA-MM) e um marcador "pago" (sim/não).
  • Editar ou excluir um lançamento existente.
  • Filtro por categoria e por mês de referência na listagem.
  • Link "Fechamento mensal" — leva direto para a tela de resultado do mês.

Fluxo correto:

  1. Financeiro (ou ADMIN) lança cada despesa fixa do mês assim que ela é conhecida — não precisa esperar o fim do mês.
  2. Ao longo do mês, os lançamentos se acumulam por categoria.
  3. No fechamento, a tela de Fechamento Mensal soma tudo automaticamente.

Se pular ou errar:

  • Esquecer de lançar uma despesa fixa do mês faz o Fechamento Mensal mostrar um lucro líquido maior do que o real — o sistema não avisa que "falta" um lançamento, ele só soma o que existe no banco naquele instante.
  • Lançar no mês de referência errado (ex.: digitar "2026-07" em vez de "2026-08") faz a despesa entrar no fechamento do mês errado — não há validação cruzada com a data de hoje.

Detalhes e estados:

  • Custo fixo nunca entra no custo do aparelho. Existe uma regra dura no sistema: custo fixo é somado no relatório de fechamento mensal — ele jamais toca o cálculo de custo de um aparelho específico nem a margem já "travada" de uma venda já feita. Ou seja: lançar, editar ou excluir um custo fixo não muda a margem de nenhuma venda passada, só o resultado agregado do mês.
  • As 6 categorias são uma lista fechada do sistema — não dá pra criar uma categoria nova pela tela; só as 6 listadas existem hoje.

Fechamento Mensal

Fechamento Mensal

Pra que serve: mostrar o resultado (lucro ou prejuízo) da operação num mês específico: soma a margem bruta de todas as vendas efetivas do mês e subtrai o total de custos fixos lançados naquele mês.

Quem usa: mesma permissão de "ver dinheiro" — ADMIN, GERENTE e FINANCEIRO. Esta tela é só de leitura (não tem nenhuma ação de escrita) — não há distinção adicional de quem pode "fazer" algo aqui, porque não há o que fazer além de consultar.

Ações principais:

  • Escolher o mês de referência; sem informar, usa o mês corrente no fuso do negócio (não pula pro mês seguinte de madrugada por causa do fuso do servidor).
  • Visualizar 3 números principais: Margem Bruta Total, Custos Fixos Total (mostrado com sinal de menos) e Lucro Líquido — este último em verde quando positivo, em vermelho quando é prejuízo. Desde 06/09, quando o mês teve venda em dólar (venda do Paraguai), a Margem Bruta Total mostra também o valor em US$ ao lado, nunca somado ao BRL.
  • Ver a quebra de custos fixos por categoria daquele mês.

Fluxo correto:

  1. ADMIN/GERENTE/FINANCEIRO acessa a tela (direto, ou pelo link "Fechamento mensal" dentro de Custos Fixos).
  2. Confere se o mês certo está selecionado.
  3. Lê o resultado: margem bruta das vendas menos custos fixos lançados.
  4. Se o mês não bate com o esperado, a causa mais comum é custo fixo não lançado, ou vendas canceladas ou ainda em rascunho — que não entram na conta (só vendas efetivas contam).

Se pular ou errar:

  • Consultar o fechamento antes de lançar todos os custos fixos do mês dá um resultado otimista demais — a tela não avisa "faltam lançamentos", ela só soma o que já existe no banco naquele instante.

Detalhes e estados:

  • Margem bruta de cada venda usa o custo travado no momento da venda (o retrato tirado quando o item foi vendido) — não o custo atual do aparelho. Isso é proposital: o lucro de uma venda de maio não muda se o custo de reposição daquele modelo mudar em agosto.
  • Preço e custo dos itens da venda são valores unitários — para itens de grade/SKU com quantidade maior que 1, o sistema multiplica pela quantidade antes de somar.
  • Venda em dólar entra na margem bruta desde 06/09. Até então, as 4 telas de lucro (Dashboard, Financeiro, Relatório de Lucro e este Fechamento Mensal) só liam as colunas de preço/custo em real — que são sempre nulas numa venda USD — e a venda do Paraguai contribuía exatamente zero pro lucro, sem erro nem aviso. O Lucro Líquido continua sendo só BRL menos custos fixos (que são só BRL); a margem em dólar aparece ao lado, informativa, porque a venda não congela nenhuma cotação de câmbio — somar as duas moedas exigiria escolher uma taxa, e o lucro de um mês já fechado mudaria de valor conforme o dia em que alguém olhasse.
  • Desconto aprovado agora reduz a margem (também desde 06/09). Antes, o preço usado no cálculo era sempre o de tabela — uma venda com desconto aprovado mostrava lucro maior do que o dinheiro que de fato entrou. Agora o desconto aprovado é aplicado proporcionalmente ao preço de cada item (o custo não muda), e uma margem que fica negativa por causa disso não é escondida — prejuízo é informação real, igual ao resto da tela. Crédito de troca aplicado numa venda não reduz a margem — crédito é forma de pagamento, não desconto na receita.
  • Prejuízo é exposto de verdade, nunca escondido ou zerado na tela — um mês ruim aparece em vermelho, não como "R$ 0,00".
  • Quando não há nenhuma venda efetiva nem nenhum custo lançado no mês escolhido, a tela mostra um estado vazio explícito em vez de zeros enganosos.

Erros comuns e como evitar

  1. Editar um lote de compra achando que vai "atualizar" o câmbio — não vai (e não deve). O câmbio fica congelado desde a criação; se o lote nasceu com câmbio errado, a correção certa não é editar esperando recalcular sozinho — é entender que qualquer edição normal preserva a taxa antiga.
  2. Importar CSV simples achando que o custo do aparelho vai aparecer sozinho — sem o XLSX enriquecido do fornecedor (ou preenchimento manual depois), o aparelho entra com custo R$ 0 e distorce toda margem calculada em cima dele.
  3. Esperar a comissão aparecer para vendas que não tinham regra ativa — se não existir uma regra de comissão cobrindo aquele vendedor (ou geral) e aquela data, a venda simplesmente não gera comissão nenhuma, sem aviso.
  4. Confundir "Fechar mês" com "Marcar paga" em Comissões — são dois cliques diferentes e obrigatoriamente nessa ordem; não existe atalho de Pendente direto pra Paga.
  5. Tentar confirmar pagamento de parcela sem comprovante — a ação recusa; comprovante é sempre obrigatório, sem exceção para "cliente de confiança".
  6. Um GERENTE tentando lançar um custo fixo — vai ver a tela normalmente (tem permissão pra ver dinheiro) mas vai receber um erro de permissão ao salvar, porque a escrita em Custos Fixos é ADMIN/FINANCEIRO, não ADMIN/GERENTE como na maioria das outras telas financeiras. É a exceção da casa, não a regra.
  7. Lançar custo fixo no mês de referência errado — o campo é texto livre no formato AAAA-MM, sem validação contra a data atual; um dígito errado desloca a despesa pro fechamento do mês seguinte ou anterior sem aviso.
  8. Achar que "Aprovar tudo" na fila de Aprovações é reversível como um clique normal — aprovar uma venda dispara a efetivação real (move estoque, gera parcela e comissão); depois de aprovada não tem "desfazer aprovação" nesta tela — o caminho de volta seria cancelar a venda já efetivada, um fluxo diferente, tratado no capítulo de Vendas.
  9. Achar que o Fechamento Mensal já mostrava a venda em dólar antes de 06/09 — não mostrava: contribuía zero pro lucro do mês, em silêncio, nas 4 telas de lucro do sistema. Hoje ela aparece separada, em US$, ao lado do BRL.
  10. Um GERENTE aprovando desconto da própria venda — desde 06/09 é bloqueado ("peça a aprovação para um ADMIN"). Só o ADMIN aprova a própria venda; se o gerente também vende, uma venda dele com desconto acima do limite precisa subir pro dono.