LUMINVS Fiscal: transforme XML e PDF em um arquivo fiscal pesquisável no Windows

Empresas acumulam documentos fiscais todos os dias. Um XML chega por e-mail, outro é baixado de um portal, PDFs são recebidos pelo financeiro, arquivos são copiados para pastas mensais e, depois de algum tempo, surge uma estrutura com centenas ou milhares de documentos espalhados entre computador, servidor, Google Drive, OneDrive e diretórios compartilhados.

O problema normalmente aparece quando alguém precisa encontrar um documento específico. O nome do fornecedor é conhecido, mas ninguém lembra o nome do arquivo. Sabe-se o CNPJ, mas não o mês. Existe uma lembrança do produto comprado, mas não do número da nota fiscal. Em outros casos, o documento está na pasta certa, porém existem tantas subpastas que a localização manual continua sendo demorada.

Foi a partir desse tipo de situação que a Luminvs Tecnologia começou a desenvolver o LUMINVS Fiscal: um aplicativo desktop para Windows cujo objetivo é transformar uma pasta cheia de XML e PDF em uma base fiscal pesquisável. Em vez de depender apenas da memória de quem organizou o diretório ou do nome atribuído ao arquivo, o sistema lê os documentos, extrai informações relevantes, cria um índice local e permite pesquisar o conteúdo posteriormente.

A proposta é simples de explicar: selecionar uma pasta, indexar o acervo e depois pesquisar o que existe dentro dele. A implementação, entretanto, envolve várias camadas: leitura segura de arquivos, tratamento de XML, extração de texto de PDF, identificação de NF-e, criação de índices de pesquisa, deduplicação por hash, persistência em banco de dados e mecanismos para recuperar o documento mesmo quando o arquivo original já não está disponível no mesmo caminho.

O problema: documentos fiscais existem, mas nem sempre são encontráveis

Uma pasta fiscal pode estar aparentemente organizada e ainda assim ser difícil de consultar. Estruturas como 2024/Fornecedor/XML, 2025/Entradas/Janeiro ou Notas/Clientes ajudam na navegação, mas continuam exigindo que a pessoa saiba previamente onde procurar.

Isso cria uma diferença importante entre armazenar e indexar. Armazenar significa guardar o arquivo. Indexar significa ler informações do arquivo e construir uma estrutura própria para encontrá-lo depois. Motores de busca, sistemas de gestão documental e bancos de dados fazem justamente isso: criam caminhos de pesquisa que vão além do nome físico do documento.

No cenário fiscal, essa diferença é valiosa. Uma NF-e em XML contém uma estrutura rica de dados. O arquivo pode informar chave de acesso, número da nota, série, data de emissão, emitente, destinatário, CPF ou CNPJ, valor total e produtos. Se essas informações forem extraídas e indexadas, o documento deixa de ser apenas um arquivo chamado 3526...xml e passa a ser um registro pesquisável.

1. O que é o LUMINVS Fiscal?

O LUMINVS Fiscal é, no estágio atual, um MVP desktop desenvolvido em C# sobre .NET 10 e WPF. Ele foi projetado para Windows 10 e Windows 11 e utiliza um banco SQLite local para organizar os dados indexados.

A interface atual apresenta quatro indicadores principais: quantidade total de documentos, quantidade de XML, quantidade de PDF e volume armazenado. O usuário escolhe uma pasta monitorada, inicia a indexação e depois utiliza uma caixa de pesquisa central para localizar os documentos.

O programa foi pensado para trabalhar tanto com uma pasta puramente local quanto com uma pasta que esteja sincronizada no Windows por ferramentas como Google Drive ou OneDrive. Nesse caso, o LUMINVS Fiscal não conversa diretamente com a API desses serviços: ele lê a pasta que o próprio Windows disponibiliza no computador.

2. Como o sistema funciona na prática?

O fluxo começa pela seleção de uma pasta. Essa pasta pode conter outras subpastas; a varredura é recursiva. O sistema enumera os arquivos suportados, atualmente XML e PDF, e verifica quais deles precisam ser processados.

Antes de reler tudo, o programa consulta o estado que já possui no banco. Para cada arquivo previamente indexado, compara tamanho e data de modificação. Se nada mudou, o documento pode ser ignorado naquela rodada. Isso reduz trabalho desnecessário quando o usuário executa novamente a indexação sobre um acervo grande.

Quando um documento precisa ser importado, o conteúdo binário é lido e recebe uma assinatura SHA-256. Depois disso, o comportamento varia conforme o formato. Um XML é enviado ao parser fiscal; um PDF passa pelo extrator de texto. Os metadados e o texto pesquisável são gravados no banco.

Pasta local / Google Drive / OneDrive / Rede
                    │
                    ▼
          Varredura de XML e PDF
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      XML de NF-e         PDF textual
          │                   │
   Parser estruturado    Extração de texto
          └─────────┬─────────┘
                    ▼
              SHA-256 do arquivo
                    │
                    ▼
       SQLite + índice FTS5 local
                    │
                    ▼
 Pesquisa por arquivo, CNPJ, NF, fornecedor,
 destinatário, produto, chave ou conteúdo
                    │
                    ▼
      Abrir original ou cópia preservada

Esse desenho é importante porque o LUMINVS Fiscal não se limita a mostrar uma lista de arquivos. Ele cria uma camada de consulta sobre o acervo.

3. O que o sistema já entende em um XML de NF-e?

O parser atual procura a estrutura infNFe do XML. Quando ela é encontrada, o sistema identifica o documento como uma NF-e e extrai campos centrais da nota.

Entre os dados tratados no MVP estão:

• chave da NF-e;
• número da nota;
• série;
• data de emissão;
• CPF ou CNPJ do emitente;
• nome do emitente;
• CPF ou CNPJ do destinatário;
• nome do destinatário;
• valor total da NF-e.

Além desses campos exibidos e armazenados de maneira estruturada, o parser percorre os itens da nota e acrescenta ao índice informações de produto. Na versão atual, entram nessa área pesquisável o código do produto, a descrição do produto, o NCM e o CFOP.

Na prática, isso significa que uma busca pode chegar a uma nota mesmo quando a pessoa não sabe o número da NF. Se ela lembra o nome do fornecedor, um CNPJ ou um termo da descrição de um produto, esses dados podem servir de caminho para encontrar o documento.

Quando o XML não possui a estrutura de NF-e reconhecida, o programa ainda tenta preservar e indexar seu conteúdo textual como XML genérico. Se o XML estiver inválido e não puder ser interpretado, ele é marcado como XML inválido. Essa distinção evita apresentar como NF-e um arquivo que o parser não conseguiu reconhecer.

4. E os PDFs? O sistema pesquisa dentro deles?

Sim, desde que o PDF tenha texto extraível. O MVP utiliza a biblioteca PdfPig para abrir o documento e ler o texto das páginas. Esse conteúdo é enviado para o índice de pesquisa local.

Isso é particularmente útil em PDFs gerados digitalmente, como DANFEs, relatórios, comprovantes, demonstrativos ou outros documentos em que o texto realmente existe dentro do arquivo.

Há, porém, uma limitação técnica importante na versão atual: PDF escaneado como imagem ainda não recebe OCR. Se alguém digitalizou uma folha em um scanner e o PDF contém somente pixels, não há texto embutido para o extrator atual recuperar. OCR está entre as evoluções planejadas para versões posteriores.

Essa separação é relevante porque evita uma promessa que o produto ainda não cumpre. Hoje, o LUMINVS Fiscal já pesquisa PDFs textuais. Reconhecimento de texto em imagem é uma etapa futura.

5. Como funciona a busca?

A pesquisa combina campos diretos do banco e um índice de texto completo. O banco local usa SQLite FTS5, mecanismo de Full-Text Search do SQLite, para acelerar a localização de palavras no material indexado.

Atualmente, a consulta pode encontrar correspondências em:

• nome do arquivo;
• chave da NF-e;
• número da nota;
• CPF ou CNPJ do emitente;
• CPF ou CNPJ do destinatário;
• nome do emitente;
• nome do destinatário;
• conteúdo textual indexado;
• informações de produtos extraídas do XML;
• texto extraído de PDFs compatíveis.

Na interface, a própria caixa de busca foi desenhada com uma orientação objetiva: “Nome, CNPJ, fornecedor, número da nota, produto ou texto do PDF”. O objetivo é que o usuário não precise conhecer a estrutura interna do banco para pesquisar.

Se nenhuma busca for informada, o sistema apresenta os documentos mais recentemente indexados. Quando existe uma consulta, os resultados são ordenados considerando data de emissão e indexação, dentro do limite definido pela aplicação.

Esse modelo abre espaço para uma experiência semelhante à de um mecanismo de pesquisa interno da empresa: digitar o que se sabe sobre o documento e deixar o índice localizar possíveis correspondências.

6. Preservação do documento e deduplicação por SHA-256

Um dos pontos mais interessantes do MVP é que ele não guarda apenas metadados. O conteúdo binário do XML ou PDF também pode ser preservado dentro do banco local.

Para organizar isso, o sistema calcula um hash SHA-256 de cada arquivo. O hash funciona como uma impressão digital do conteúdo: dois arquivos com os mesmos bytes produzem a mesma assinatura.

No banco, os conteúdos ficam associados a essa assinatura em uma tabela própria de blobs. O registro documental mantém o caminho original e referencia o conteúdo preservado pelo hash. Dessa forma, a aplicação pode evitar armazenar novamente o mesmo conteúdo binário quando a assinatura já existe.

Esse desenho também dá suporte a outra funcionalidade já presente: ao abrir um resultado, o LUMINVS Fiscal verifica primeiro se o arquivo original ainda existe no caminho de origem. Se existir, ele abre esse arquivo. Se o original não estiver mais disponível, o sistema tenta recuperar o conteúdo preservado no SQLite, grava temporariamente uma cópia e a abre.

Além disso, existe o comando Salvar cópia, que permite extrair novamente o XML ou PDF armazenado e escolher um destino no Windows.

Isso não deve ser interpretado como substituto de uma política completa de backup empresarial. O recurso atual é uma camada adicional de preservação documental dentro do MVP. Estratégias formais de backup, retenção e recuperação ainda precisam ser tratadas conforme a realidade de cada organização.

7. Indexação incremental: por que não processar tudo de novo?

Imagine um acervo com dezenas de milhares de arquivos. Se o programa reler e recalcular tudo a cada execução, a experiência se torna desnecessariamente pesada. Por isso, o LUMINVS Fiscal já trabalha com uma lógica incremental.

Antes de importar novamente um documento, a aplicação compara o tamanho e a data da última modificação registrados no banco com o arquivo atual. Quando esses valores permanecem iguais, ele é classificado como sem alteração e ignorado naquela passagem.

Durante a indexação, a interface informa progresso, arquivo atual, quantidade de novos documentos, atualizados, ignorados e erros. O processamento também pode ser cancelado pelo usuário.

Outro cuidado existente no importador são tentativas adicionais de leitura para arquivos que ainda estejam em processo de sincronização ou temporariamente indisponíveis. Esse cenário é comum quando o diretório fica dentro de uma pasta sincronizada. Em vez de tratar imediatamente qualquer falha transitória como erro definitivo, a aplicação possui mecanismo de retry.

A próxima evolução natural prevista para esse fluxo é adicionar observação automática de alterações no sistema de arquivos, usando FileSystemWatcher com debounce. Quando isso for implementado, a tendência é reduzir ainda mais a necessidade de o usuário iniciar manualmente novas indexações.

8. Onde o LUMINVS Fiscal pode ajudar na prática?

Escritórios contábeis

Um escritório contábil lida com documentos de várias empresas e diferentes períodos. Mesmo quando existe uma estrutura de pastas padronizada, localizar rapidamente determinado XML pode consumir tempo. Uma base de pesquisa por CNPJ, número da nota, fornecedor e produto pode reduzir etapas operacionais de busca.

Departamentos fiscais e financeiros

Equipes internas frequentemente precisam recuperar documentos para conferência, pagamento, auditoria, conciliação ou atendimento de solicitações de outros setores. O arquivo pesquisável cria uma camada de acesso sem exigir que cada usuário memorize a árvore de diretórios.

Auditorias internas

Uma pesquisa estruturada pode ajudar a localizar documentos de determinado fornecedor, período ou tipo de operação. O MVP ainda não é uma ferramenta completa de auditoria fiscal, mas funciona como infraestrutura de localização e preservação sobre a qual análises posteriores podem ser construídas.

Empresas com arquivos históricos extensos

Negócios que guardam XML e PDF por vários anos tendem a acumular milhares de documentos. Quanto maior o acervo, menor a eficiência de depender somente do Explorador de Arquivos. A indexação traz outra forma de acesso ao mesmo conjunto documental.

Pastas sincronizadas em nuvem

Se a empresa já usa Google Drive ou OneDrive para manter documentos sincronizados no Windows, o sistema pode trabalhar sobre essa pasta local. Isso permite aproveitar a estrutura existente sem exigir, na versão atual, integração direta com as APIs dos provedores.

Pesquisa por produto ou conteúdo

Um caso particularmente interessante ocorre quando a pessoa não sabe qual nota procurar, mas conhece um item. Como o parser de NF-e inclui descrição de produto, código, NCM e CFOP no conteúdo pesquisável, uma expressão associada ao produto pode ajudar a localizar notas relacionadas.

9. Dados locais: o que isso significa para privacidade e controle?

O MVP foi desenhado para operar com um banco local. Os dados da aplicação ficam no perfil local do Windows, dentro da pasta do LUMINVS Fiscal em %LOCALAPPDATA%. Ali ficam banco SQLite, configurações, logs e arquivos temporários.

Isso significa que a versão atual não depende de um servidor externo da Luminvs para executar a indexação e a pesquisa. O programa lê os documentos acessíveis naquela máquina e grava sua base local.

Esse modelo pode ser adequado para cenários em que a organização deseja manter o processamento próximo aos próprios arquivos. Ao mesmo tempo, ele traz responsabilidades: controle de acesso ao Windows, proteção do dispositivo, criptografia de disco quando aplicável, políticas de backup e segurança da pasta sincronizada continuam sendo importantes.

Também é importante observar que o SQLite armazena cópias dos conteúdos importados. Portanto, quem implanta a solução deve considerar o banco do LUMINVS Fiscal como parte do acervo documental da máquina e protegê-lo de acordo com a sensibilidade dos documentos.

10. Arquitetura técnica do MVP

A versão analisada é identificada como LUMINVS Fiscal v0.1.3. O projeto usa C# e WPF sobre .NET 10 para a interface desktop. O banco é SQLite, acessado com o pacote Microsoft.Data.Sqlite. A leitura de PDFs utiliza PdfPig.

Na camada de dados, existem duas estruturas principais. Uma tabela guarda os blobs binários identificados por SHA-256. Outra armazena os documentos, seus caminhos e os metadados extraídos. Índices convencionais são criados para campos como chave da NF-e, CNPJ, data e tipo, enquanto uma tabela virtual FTS5 mantém o índice textual.

O FTS5 utiliza tokenização Unicode com remoção de diacríticos, recurso útil para pesquisa textual em português. A consulta também normaliza sequências numéricas para permitir buscas por CPF e CNPJ digitados com ou sem formatação.

O banco é inicializado com modo WAL e tempo de espera para situações de concorrência. A importação grava documentos em lotes, reduzindo o custo de confirmar uma transação para cada arquivo individualmente.

Há também registro diário de logs e uma pasta temporária utilizada quando um arquivo precisa ser reconstruído a partir da cópia armazenada antes de ser aberto.

Essas escolhas revelam que o projeto está sendo construído não apenas como uma tela de pesquisa, mas como uma pequena infraestrutura local de indexação documental.

11. O que já funciona e o que ainda está em desenvolvimento?

Como o LUMINVS Fiscal ainda é um projeto em evolução, é importante separar claramente o que existe hoje do que está sendo planejado.

Já existe no MVP v0.1.3:

• seleção de pasta local ou sincronizada;
• varredura recursiva de subpastas;
• importação de XML e PDF;
• banco SQLite local;
• cópia binária preservada no banco;
• hash SHA-256 para deduplicação de conteúdo;
• parser inicial de NF-e;
• extração de texto de PDF textual;
• índice de pesquisa FTS5;
• busca por nome, CNPJ, emitente, destinatário, NF, chave e conteúdo;
• pesquisa de informações de produto extraídas de NF-e;
• abertura do arquivo original;
• recuperação da cópia preservada quando o original não está disponível;
• salvamento manual de uma nova cópia;
• indexação incremental;
• indicadores de total de documentos, XML, PDF e volume armazenado;
• progresso de importação, cancelamento e logs.

Ainda não existe na versão atual: OCR para PDFs escaneados, painel detalhado de itens da NF-e, filtros avançados, multiempresa formal, exportação Excel/CSV, rotina completa de backup do banco, licenciamento da aplicação e mecanismo automático de atualização.

Essa transparência é importante porque um produto em desenvolvimento deve ser apresentado pelo que já entrega, sem confundir roadmap com funcionalidade disponível.

12. Evoluções planejadas para o LUMINVS Fiscal

O roadmap técnico do projeto aponta um caminho claro: transformar o mecanismo atual de indexação em uma plataforma local mais completa de consulta documental e fiscal.

Monitoramento automático de novos arquivos

A ideia é que a pasta possa ser observada continuamente. Quando novos XML ou PDF forem adicionados, o sistema poderá detectar a mudança, aguardar a estabilização do arquivo e atualizar a base automaticamente.

Detalhes da NF-e e itens

Hoje alguns dados de produto já entram no texto pesquisável. Uma tela específica poderá mostrar os itens da nota de forma estruturada, permitindo explorar produto, NCM, CFOP e outras informações sem abrir manualmente o XML.

OCR para documentos escaneados

Esse recurso ampliará a cobertura para PDFs compostos por imagens. O OCR converterá visualmente os caracteres em texto pesquisável, permitindo indexar documentos que hoje ficam fora da busca textual.

Filtros avançados

Período de emissão, tipo documental, CNPJ, faixa de valor e outros campos estruturados poderão se transformar em filtros combináveis. Isso muda a experiência de uma busca simples para uma ferramenta analítica de consulta.

Multiempresa

Para escritórios contábeis e grupos empresariais, separar acervos por empresa ou CNPJ será uma evolução importante. O recurso está listado como planejado e ainda não deve ser tratado como parte do MVP atual.

Exportação para Excel e CSV

A exportação permitirá levar resultados de pesquisa para planilhas, análises externas, conciliações e integrações. Novamente, trata-se de evolução prevista, não de função presente na v0.1.3 analisada.

Backup e manutenção do banco

Como o banco local passa a concentrar índice e cópias preservadas, rotinas próprias de backup e compactação poderão aumentar a segurança operacional da solução.

Licenciamento e atualização automática

Para uma futura distribuição comercial, o roadmap também prevê mecanismos próprios de licenciamento LUMINVS e atualização da aplicação.

Conclusão

O LUMINVS Fiscal nasceu de uma necessidade muito concreta: ter documentos fiscais armazenados não significa conseguir encontrá-los rapidamente. Quanto maior o acervo de XML e PDF, mais evidente fica a diferença entre uma pasta organizada e uma base realmente pesquisável.

O MVP em desenvolvimento pela Luminvs Tecnologia já implementa a infraestrutura central dessa ideia. Ele percorre pastas e subpastas, identifica XML e PDF, extrai metadados de NF-e, lê PDFs textuais, cria uma impressão SHA-256 dos arquivos, preserva o conteúdo em SQLite e monta um índice de busca capaz de localizar informações por diferentes caminhos.

O resultado é uma nova forma de acessar um arquivo fiscal: em vez de começar perguntando “em qual pasta está essa nota?”, o usuário pode começar com o que realmente sabe — o CNPJ, o fornecedor, o número, a chave, o produto ou uma palavra existente no documento.

A versão atual ainda é um MVP e possui limitações deliberadas. OCR, filtros avançados, multiempresa, exportação e automação contínua fazem parte das próximas etapas, não do produto existente hoje. Essa distinção permite acompanhar a evolução do projeto de maneira objetiva.

Para a Luminvs Tecnologia, o LUMINVS Fiscal também representa uma linha de desenvolvimento que combina diferentes áreas em um mesmo produto: software desktop, automação, bancos de dados, pesquisa textual, processamento de documentos e organização de informação.

É esse tipo de problema que orienta o desenvolvimento da solução: pegar um acervo que já existe, reduzir o trabalho manual necessário para consultá-lo e transformar documentos dispersos em informação acessível.

O projeto continuará evoluindo, e este artigo registra publicamente o estágio inicial dessa construção. À medida que novas funções forem incorporadas, novas versões poderão ampliar a pesquisa, a análise e a automação sobre o acervo fiscal, mantendo como princípio central a ideia que originou o sistema: se o documento está guardado, ele também precisa ser encontrável.