Pular para o conteúdo principal

Faturamento e Pagamento (Mock)

Última atualização: 16 de julho de 2026

Visão Geral​

Faturamento e pagamento são as duas sub-telas mais incompletas deste fluxo: nenhuma das duas tem um service dedicado, nenhuma faz chamada de rede, e nenhuma tem hoje um botão real que leve até ela a partir da listagem ou dos detalhes de venda. sale.controller.ts ainda exporta onPressInvoice e onPressPayment, mas nenhum dos dois é referenciado dentro de sale.tsx, a view não os chama de lugar nenhum.

Arquivos-chave​

ArquivoResponsabilidade
app/faturamento-venda.tsxRota de faturamento
features/sale/subscreens/sale-invoice/sale-invoice.controller.tsEscolha de TOP/tipo de faturamento
features/sale/subscreens/sale-invoice-itens/sale-invoince-itens.controller.tsSeleção de itens a faturar
app/pagamento-venda.tsxRota de pagamento
features/sale/subscreens/sale-payment/sale-payment.controller.tsGeração de PIX/link de pagamento

Faturamento: escolha de TOP real, itens inteiramente hardcoded​

A primeira tela (sale-invoice.controller.ts) monta as opções de TOP (tipo de operação de destino) a partir de sale.TOPSDEST, um campo real vindo da venda recebida via parâmetro de rota, e guarda localmente o tipo de faturamento escolhido (normal, por estoque, por estoque pendente, direto) e a data de saída. Não há nenhuma chamada de API aqui, o botão final só navega para a próxima tela levando esse estado como parâmetro.

A segunda tela (sale-invoice-itens.controller.ts) é onde o mock fica evidente: os itens exibidos não têm nenhuma relação com a venda selecionada, vêm de uma lista fixa de cinco produtos fictícios:

const INITIAL_ITEMS: InvoiceItem[] = [
  { id: "1", productCode: "114", reference: "REF-114-A", description: "Vinho do porto 700ml", pending: "20", value: 238.29, selected: false },
  { id: "2", productCode: "256", description: "Pao de queijo 500gr", /* ... */ },
  // ...
];

A variável sale do parâmetro de rota só é usada para exibir número, TOP, parceiro e empresa nos cabeçalhos informativos, nunca para os itens de fato. Os botões "Cancelar" e "Concluir" no rodapé apenas chamam router.back(), sem enviar ou persistir nada.

Não existe, em todo o diretório services/, nenhum service relacionado a fatura, nota fiscal ou faturamento. E como o app decide se uma venda já foi faturada não acontece nesta tela, acontece via rótulo de status (Faturado, AguardandoFaturamento em LOCAL_STATUS_META, documentado em Detalhes de Venda), puramente cosmético na listagem.

Pagamento: tudo simulado, incluindo o resultado​

sale-payment.controller.ts não importa nenhum dos services de pagamento reais que existem no projeto (services/payment-method, services/payment-slip), e simula a geração/atualização de PIX ou link de pagamento com um temporizador:

// sale-payment.controller.ts
const isLinkPayment = sale.USAPIX !== "S";
const paymentLink = String("https://lin.ae/1q2w3e4");

const handleGenerateOrUpdate = useCallback(() => {
  if (!isGenerated) { setIsGenerated(true); return; }
  if (isLoading) return;

  setIsLoading(true);
  loadingTimerRef.current = setTimeout(() => {
    setRefreshVersion((v) => v + 1);
    setIsLoading(false);
    setIsSuccess(true);
  }, 1600);
}, [/* ... */]);

Praticamente todo dado visual na tela é fixo, sem relação com a venda:

  • CNPJ do estabelecimento hardcoded ("85502053000163"), em vez de vir de sale.empresa.
  • Imagem de QR Code apontando para uma URL de terceiro genérica, sem relação com o pedido.
  • "Código PIX" mostrado como uma string EMV fixa e truncada, não um payload real gerado pra essa venda.
  • Data de expiração fixa ("Expiracao: 02/08/2024 17:24") tanto no fluxo PIX quanto no de link.
  • Os botões "Compartilhar" e "Copiar" do código não têm onPress, são puramente visuais.

O único dado real vindo da venda selecionada é o valor total (sale.VLRNOTA), o nome do cliente (sale.RAZAOSOCIAL/sale.NOMEPARC) e a decisão entre mostrar PIX ou link de pagamento (sale.USAPIX === "S").

Nenhuma das duas telas está conectada à máquina de status real​

Diferente da tela de detalhes, nem faturamento nem pagamento consomem sale-status.utils.ts em nenhum ponto, não checam codStatus, não chamam isErpIntegratedFinalizedSale. Isso reforça que são protótipos isolados, sem integração com o restante da feature de vendas.

Armadilhas conhecidas​

Não trate essas duas telas como funcionalidades em uso: hoje não existe nenhum caminho de navegação real até elas a partir de nenhuma tela do app (nem lista de vendas, nem detalhes). Se forem retomadas no futuro, o trabalho envolve tanto reconectar um ponto de entrada na UI quanto substituir toda a simulação por chamadas reais a serviços de faturamento e pagamento (que hoje não existem no projeto para faturamento, e existem mas não estão conectados para pagamento).