# Prompt

Implementar a primeira etapa do módulo de emissão fiscal, com foco exclusivo na configuração de
NFC-e dentro da tela **Minha Empresa**.

Antes de alterar o código, analisar a documentação da API fiscal em
`emissor-api/docs/DOCUMENTACAO-IA.md`, a implementação atual da tela e os componentes, padrões
visuais, validações e serviços existentes.

Adicionar a seção **Configuração de NFC-e**, com toggles para emissão de NFC-e e ambiente de
homologação. Manter produção e homologação separadas, preservar os valores ao alternar, validar
certificado `.pfx`/`.p12`, senha, CSC, ID do CSC, série, próximo número e demais campos fiscais
obrigatórios. Certificado e senha não podem ir para `localStorage`, logs ou ser reenviados sem
alteração. Um certificado existente deve ser apresentado somente por identificação segura.

Integrar somente os endpoints, payloads e propriedades documentados. Se faltar contrato no
backend, preparar a estrutura, documentar a pendência e não usar mocks silenciosos. Não implementar
a emissão da NFC-e nesta etapa.

# Resposta

Implementada a configuração de NFC-e na tela Minha Empresa, com integração aos endpoints fiscais
documentados, separação entre produção e homologação, validações e tratamento seguro de
certificado, senha e CSC.

Validações executadas até o momento:

- `php -l back/Controllers/EmpresaController.php`
- `npx vue-tsc --build`
- `git diff --check`

O `npm run build` aguarda confirmação, conforme a regra do projeto.

## Continuação do prompt

Melhorar o input de certificado, substituindo o campo simples de arquivo por um dropzone do
PrimeVue que permita somente um arquivo. Analisar a documentação fiscal atualizada e integrar a
rota disponível para testar se o certificado é válido.

## Continuação da resposta

O certificado passou a usar o `DropzoneComponent` baseado no `FileUpload` do PrimeVue, limitado a
um único `.pfx` ou `.p12`. Foi integrada a rota documentada
`POST /fiscal/certicate/test`, sem persistência, com validação do CNPJ retornado, vigência e
feedback seguro na tela. Certificados novos ou substituídos precisam passar no teste antes de
salvar.

Validação estática executada novamente com `npx vue-tsc --build` e `git diff --check`. O
`npm run build` continua aguardando confirmação.

## Ajuste visual solicitado

Removido o aviso vazio de certificado não validado. O campo de senha, o controle de
visualização/ocultação e o botão para testar o certificado agora formam um único `input-group`.

## Resolução automática dos códigos IBGE

Removidos da interface os campos de código IBGE da UF e do município. O backend de Minha Empresa
agora resolve `codigo_uf` e `codigo_municipio` automaticamente nas tabelas `estados` e `cidades`,
usando a UF e a cidade do endereço cadastrado. O frontend recebe os códigos calculados apenas para
compor o payload fiscal.

## Continuacao do prompt: Configuracao de Venda Fiscal

Criar na tela de Configuracoes a nova opcao **Venda Fiscal**, com os toggles **Emitir NFC-e** e
**Emitir em contingencia**. A alteracao de banco foi autorizada, desde que a migracao seja salva
em `back/Database/`.

## Continuacao da resposta

Adicionada na tela de Configuracoes a secao **Venda Fiscal**, com as opcoes **Emitir NFC-e** e
**Emitir em contingencia**. As preferencias sao independentes, salvas pelo endpoint existente de
configuracoes e persistidas nas colunas `venda_fiscal_nfce` e `venda_fiscal_contingencia`.

A alteracao do banco foi autorizada e registrada em
`back/Database/2026_07_15_add_venda_fiscal_to_logic_configuracoes.sql`.

## Continuacao do prompt: Opcoes fiscais no PDV

Exibir no pagamento do PDV as opcoes **Emitir NFCE** e **Emitir em contingencia**, inicializadas
pela configuracao de Venda Fiscal, e registrar as duas escolhas na tabela de vendas. Nesta etapa,
nao emitir nota fiscal nem chamar a API fiscal.

## Continuacao da resposta

Os toggles foram adicionados ao rodape do pagamento e seus valores sao enviados ao finalizar a
venda. O backend somente valida e persiste os indicadores `emitir_nfce` e
`emitir_contingencia`; nenhuma rotina de emissao fiscal foi adicionada.

## Continuação do prompt: Emissão de NFC-e na finalização

Implementar a emissão de NFC-e no fluxo de finalização da venda conforme a documentação fiscal
atualizada. Venda fiscal não pode gerar comprovante não fiscal, inclusive em falhas. Validar
configuração, ambiente, produtos e pagamentos; persistir tentativas e retorno fiscal; impedir
duplicidade; reconciliar respostas incertas; imprimir o DANFE na impressora do caixa ou abrir o
documento em nova aba; e reimprimir sempre a emissão existente, sem emitir outra nota. Alterações
de banco necessárias foram autorizadas e devem ser aplicadas e registradas em `back/Database/`.

## Continuação da resposta

O fechamento fiscal passou a gravar a venda como pendente, chamar `POST /fiscal/nfce/` pelo
backend e finalizar caixa, financeiro e comanda somente após autorização. Tentativas anteriores
são conciliadas por `POST /fiscal/emissoes` antes de qualquer reenvio. XML, PDF, chave, protocolo,
série, número, ambiente, status e erros seguros são armazenados em tabela própria. O fluxo fiscal
não cria comprovante não fiscal.

Foram adicionados os dados fiscais opcionais ao cadastro de produtos e snapshots desses dados nos
itens da venda. O DANFE salvo é impresso via QZ Tray ou servido pela rota autenticada
`GET /private/vendas/{id}/danfe`; a reimpressão apenas consulta a venda existente. As migrações
foram aplicadas ao banco local. Nenhuma emissão real foi executada durante a validação.

## Ajuste posterior: feedback e fallback não fiscal

Quando a validação fiscal retornar problemas, o PDV deve apresentar ao operador todas as mensagens
recebidas. Se a NFC-e não tiver sido enviada ou houver rejeição/falha 4xx conclusiva, a venda deve
continuar como não fiscal, como se a opção de emissão estivesse desativada.

O PDV agora finaliza automaticamente uma nova venda sem NFC-e após erros de validação e apresenta
os motivos em um alerta prolongado. Rejeições confirmadas convertem a mesma venda pendente para não
fiscal, geram o comprovante normal e preservam a tentativa fiscal com status
`CONVERTIDA_NAO_FISCAL`. Respostas em processamento, timeout e estados incertos continuam sem
fallback para evitar uma venda não fiscal quando a NFC-e possa já ter sido autorizada.

## Catálogos fiscais no cadastro de produtos

Validar o NCM digitado consultando `POST /ncm/` com `filter.codigo`; aceitar somente códigos com 8
dígitos encontrados pela API. Substituir o campo manual de CFOP por um select carregado de
`POST /cfop/`, armazenar o `id` retornado no banco e enviar esse ID como CFOP na venda fiscal. As
alterações necessárias no banco foram autorizadas.

O frontend passou a validar o NCM após 400 ms, exibindo o resultado ao lado do campo, e o backend
repete a validação ao salvar. O select de CFOP é carregado por uma rota interna, e o backend também
confirma o ID selecionado antes da persistência. As colunas `cfop` de produtos e snapshots de itens
foram renomeadas para `id_cfop`; o payload fiscal continua usando a propriedade documentada
`cfop`.

## Preferência permanente de linguagem e experiência do usuário

Todo feedback visual deve ser escrito para usuários gerais, sem pressupor conhecimento de
desenvolvimento ou da arquitetura do sistema. Não mencionar API, endpoint, payload, HTTP, backend,
banco de dados, integração ou outros detalhes internos em mensagens, alertas, validações, estados
de carregamento e tooltips. Informar apenas o que está acontecendo, o resultado e, quando aplicável,
o que o usuário precisa fazer. Termos do próprio domínio, como NCM, CFOP, NFC-e e certificado
digital, continuam permitidos quando necessários.

Os textos adicionados nesta implementação foram revisados seguindo essa regra. Por exemplo,
`Consultando NCM na API fiscal` foi substituído por `Verificando NCM`.

## Ajuste da abertura do DANFE no PDV

Ao concluir uma venda fiscal sem impressora configurada, a aba do DANFE era aberta antes do fim da
venda e navegava diretamente para uma rota protegida. Isso deixava uma aba vazia durante o
processamento e, depois, exibia uma mensagem de sessão não identificada em vez do documento.

O PDV deixou de abrir uma aba antecipadamente. Após a venda ser concluída e a NFC-e estar
autorizada, o sistema usa o PDF retornado na própria venda para criar uma URL temporária no
navegador e somente então abre o DANFE. A rota protegida não é mais acessada diretamente pela
nova aba.

## Respeitar a confirmação antes de imprimir

A opção **Sempre perguntar antes de imprimir** deve controlar tanto o comprovante não fiscal
quanto o DANFE da NFC-e. A emissão e o salvamento da nota continuam ocorrendo durante a finalização
da venda, mas nenhuma impressão ou abertura em nova aba pode acontecer antes da confirmação do
operador.

O fluxo fiscal foi unificado com a confirmação de comprovantes. Quando houver impressora, o
diálogo pergunta se o DANFE deve ser impresso. Sem impressora, pergunta se o DANFE deve ser aberto
em uma nova aba. Escolher não imprimir ou não abrir fecha somente a confirmação e não altera a
venda nem a NFC-e já autorizada.

## Ajuste visual da rolagem do menu lateral

A barra de rolagem nativa do menu lateral estava larga, com setas, e reduzia a largura disponível
para os blocos inferiores. A rolagem foi contida na área interna do menu e passou a usar um
indicador fino, neutro e sem trilha aparente. O menu externo agora oculta qualquer rolagem duplicada,
evitando que o conteúdo fique comprimido ou cortado.

## Documento opcional do cliente na finalização do PDV

Ao finalizar uma venda no PDV, abrir um diálogo solicitando o CPF ou CNPJ do cliente. O documento
deve ser opcional e o operador pode continuar sem preencher. Quando informado, validar se o CPF ou
CNPJ é válido, exibir o documento no comprovante não fiscal e enviá-lo também na venda fiscal.

A alteração da estrutura do banco foi aprovada para adicionar o campo opcional
`cliente_documento` na venda.

## Correção do envio do documento à NFC-e

O primeiro envio usou incorretamente `documento` na raiz do corpo da emissão, com base no sistema
antigo. A documentação atual exige o objeto `cliente`, contendo `nome`, `tipo_documento` e
`documento`. O envio foi corrigido para usar essa estrutura documentada. Notas já autorizadas não
podem ter o DANFE alterado; a correção se aplica às próximas emissões.

## Continuação do prompt: menu Fiscal e gestão de NFC-e

Quando a conta estiver configurada para venda fiscal, criar o menu **Fiscal** com o submenu
**NFC-e**. A tela deve ser dividida nas abas **Pendentes**, **Autorizadas** e **Canceladas**.

Nesta etapa, trabalhar principalmente com as pendentes: listar todas as vendas que não possuem
NFC-e autorizada, seja porque o usuário optou por não emitir no momento da venda ou porque houve
erro. Cada venda pendente deve ter uma ação para emitir a NFC-e. Todo erro ocorrido em uma
tentativa de emissão, independentemente da tela de origem, deve ser salvo e apresentado na
listagem para ajudar o usuário a corrigir o problema.

## Continuação da resposta

Foi adicionado o menu **Fiscal**, visível quando a emissão de NFC-e está ativa nas configurações
da conta, com o submenu e a tela **NFC-e**. A tela possui as abas Pendentes, Autorizadas e
Canceladas, paginação pelo servidor, filtros recolhidos em diálogo e exportação CSV/PDF.

A aba Pendentes reúne vendas não canceladas sem NFC-e autorizada, incluindo vendas feitas sem
solicitar nota e tentativas que falharam. Cada linha possui a ação de emissão e exibe o último
retorno salvo. A emissão posterior reaproveita o fluxo fiscal existente, preserva os movimentos
financeiros já registrados e usa os dados fiscais armazenados na venda ou, em vendas antigas, os
dados atuais dos respectivos cadastros.

O fluxo do PDV também passou a criar a venda antes da validação fiscal, permitindo guardar os
motivos de falha. Falhas inesperadas durante o processamento agora são persistidas, e vendas não
fiscais novas passam a manter os dados fiscais necessários para uma possível emissão posterior.

Validações executadas:

- `php -l back/Controllers/VendasController.php`
- `php -l back/Routers/Routers.php`
- `npm exec vue-tsc -- --noEmit`
- `git diff --check`

O `npm run build` aguarda confirmação, conforme a regra do projeto.

## Correção: impressão igual para vendas fiscais e não fiscais

Foi relatado que vendas não fiscais não respeitavam as opções **Sempre perguntar antes de
imprimir** e **Sempre imprimir**, enquanto o DANFE das vendas fiscais seguia o fluxo de impressão.
O comportamento deve ser o mesmo para qualquer venda.

O PDV agora consulta a preferência atual no momento em que a venda é concluída e sempre prepara o
documento correspondente. Com impressora de caixa configurada, comprovante não fiscal e DANFE são
enviados para ela. Sem impressora configurada, ambos abrem o respectivo PDF em uma nova aba. No
modo **Sempre perguntar**, ambos aguardam a confirmação do operador; no modo **Sempre imprimir**,
ambos iniciam o respectivo fluxo automaticamente. A venda não fiscal não abre a tela de impressão
do navegador.

Validações executadas após a correção:

- `vue-tsc --noEmit`
- `prettier --check src/views/app/pdv/PdvView.vue`

O `npm run build` continua aguardando confirmação, conforme a regra do projeto.

## Ajustes na aba de NFC-e pendentes

Remover a coluna **Último retorno** da listagem. Quando uma venda possuir erro de emissão, exibir
um badge **Erro** junto ao número da venda. Adicionar a coluna **Opções**, com ações em ícones para
emitir a NFC-e, visualizar os erros em um diálogo e cancelar a venda.

A listagem passou a concentrar a indicação de falha na coluna Venda e os detalhes ficam disponíveis
somente no diálogo de erros. O cancelamento exige confirmação, não é permitido para uma NFC-e
autorizada nem enquanto o resultado da emissão estiver sendo confirmado, marca a venda como
cancelada e cancela seus lançamentos financeiros vinculados. A aba Canceladas passou a considerar
todas as vendas canceladas, inclusive as que ainda não possuíam tentativa fiscal.

## Ajustes na aba de NFC-e autorizadas

Na aba **Autorizadas**, remover a coluna **Último retorno** e adicionar uma coluna de ações com as
opções de visualizar o cupom fiscal, visualizar o XML e cancelar a NFC-e. A opção de cancelamento
deve existir somente durante os 30 minutos posteriores à autorização. A solicitação inicial de
Carta de Correção após esse prazo foi retirada, pois esse evento não existe para NFC-e. Na aba
**Pendentes**, remover também a coluna **Situação**, já que todos os registros da aba representam
vendas sem NFC-e autorizada.

## Continuação da resposta

A aba Pendentes deixou de exibir a coluna Situação, inclusive nas exportações. A aba Autorizadas
mantém a listagem sem Último retorno e ganhou ações em ícones para abrir o DANFE, abrir o XML
autorizado e cancelar a NFC-e. DANFE e XML são carregados com a sessão do usuário e abertos em uma
nova aba.

O cancelamento solicita uma justificativa de 15 a 255 caracteres e usa o fluxo próprio de
cancelamento de NFC-e. O botão é disponibilizado somente dentro dos 30 minutos da autorização e a
tela atualiza a linha quando o prazo termina. O servidor também valida o prazo antes de enviar o
cancelamento, evitando que uma tela antiga permita a operação fora do período. Após a confirmação,
a venda passa para Canceladas e seus lançamentos financeiros vinculados são cancelados.

## Correção das colunas e da largura da tabela de NFC-e

A coluna **Situação** não deve existir em nenhuma das abas, pois Pendentes, Autorizadas e
Canceladas já informam a situação dos seus próprios registros. A coluna também foi removida das
exportações CSV e PDF.

A largura mínima fixa da tabela foi retirada. A tabela de NFC-e agora ocupa a largura disponível
do card, sem criar rolagem horizontal quando as colunas cabem normalmente na tela.

## Impressão após emitir uma NFC-e pendente

Ao emitir com sucesso a NFC-e de uma venda na aba Pendentes, perguntar ao usuário se deseja
imprimir o DANFE. Se ele confirmar e existir uma impressora de caixa configurada, enviar o PDF
diretamente para essa impressora, respeitando a quantidade de cópias configurada. Quando não
existir impressora configurada, abrir o DANFE em uma nova aba.

As listagens de NFC-e devem permanecer sempre ordenadas da venda mais recente para a mais antiga.
A ordenação padrão da tabela não deve substituir a ordem decrescente da data de registro.

## Continuação da resposta

Após uma emissão pendente ser autorizada, a tela consulta a configuração atual de impressão e
abre uma confirmação específica para o DANFE. Ao confirmar, usa a impressora de caixa e a
quantidade de cópias configuradas; sem impressora, carrega o PDF autenticado e o abre em uma nova
aba. Rejeições e emissões ainda em processamento não apresentam a pergunta de impressão.

A ordenação interativa foi desativada nessa listagem e todas as consultas da tela enviam
`data_registro:DESC`, mantendo as vendas mais recentes no início em todas as abas, filtros,
paginação e exportações.

## Diagnóstico da rejeição 594 no cancelamento

Ao cancelar a NFC-e da venda 29, a SEFAZ retornou a rejeição 594, informando que a sequência do
evento era maior que a permitida. A Logiccom envia ao emissor somente CNPJ, chave e justificativa;
ela não envia nem calcula a sequência.

O fluxo do emissor e a biblioteca fiscal foram inspecionados. O cancelamento usa o evento 110111 e
a biblioteca fixa `nSeqEvento=1`, conforme a regra oficial. Uma geração local do mesmo evento, sem
transmissão, confirmou `nSeqEvento=1` e o identificador do evento terminado em `01`. Não existe
cancelamento salvo para a chave no banco do emissor, e uma consulta de situação à SEFAZ/MG
retornou `cStat=100`, confirmando que a NFC-e continua autorizada.

Com essas evidências, a sequência não está sendo incrementada pela Logiccom nem pelo código local
da API. A rejeição foi produzida pelo autorizador de homologação de Minas Gerais apesar do evento
estar montado com a sequência prevista. Não se deve alterar a sequência para zero ou dois. O passo
seguro seguinte é registrar no emissor os campos não sensíveis da requisição e da resposta do
evento e repetir o teste com outra NFC-e de homologação; se a rejeição se repetir, encaminhar esses
dados à SEF/MG.