Validação de chave dos documentos fiscais eletrônicos

[renatonlima]

Resumo

Refatoração do módulo de geração e validação de chaves de acesso de Documentos Fiscais Eletrônicos (DFe), migrando a lógica de edoc.py para um novo módulo dfe.py, com suporte ampliado a mais modelos de documento e mantendo retrocompatibilidade total com a API anterior.

O que mudou

• Novo módulo erpbrasil.base.fiscal.dfe com a classe ChaveDFe (sucessora de ChaveEdoc), cobrindo geração e validação de chave para:
  • NF-e (mod 55) / NFC-e (mod 65)
  • CT-e (mod 57) e CT-e OS (mod 67) — ambos usam o prefixo CTe; a distinção entre os dois é feita apenas pelo campo mod (posições 21-22 da chave), não por um prefixo próprio
  • MDF-e (mod 58)
  • CF-e SAT (mod 59), via ChaveCFeSAT
  • NFCom (mod 62), BP-e (mod 63), NF3e (mod 66), NFAg (mod 75), NFGas (mod 76) — modelos com o campo extra nSiteAutoriz na chave
  • Nova classe ChaveNFSe para chaves de NFS-e (50 dígitos, layout próprio)
• edoc.py mantido como shim de retrocompatibilidade, reexportando ChaveEdoc/detectar_chave_edoc/constantes a partir de dfe.py (@deprecated), sem quebrar código existente que já importa daqui.
• Suporte a procEmi (processo de emissão) com validação cruzada de série (Rejeição 266 da SEFAZ) para NF-e/NFC-e.
• Propriedades usando os nomes oficiais do schema XML da SEFAZ (cUF, dhEmi, mod, serie, nNF, tpEmis, cNF, cDV), mantendo os nomes legados como aliases.
• Documentação nova em docs/dfe.rst e entrada correspondente no índice.
• Testes novos (tests/test_dfe.py, tests/test_new_edocs.py) cobrindo os modelos adicionados e os casos de retrocompatibilidade.
• Ajuste no CI (ci/requirements.txt): removida a dependência twine, que não é usada em nenhum tox env ativo (o único que a usava, pypi-description, está comentado) e estava quebrando o job pypy39 — versões recentes de nh3/cryptography exigem Python ≥3.11 para compilar via PyO3, incompatível com PyPy 3.9.

Testes

• pytest tests/ — 148 testes / 269 subtests, todos passando.

[marcelsavegnago]

cc @CristianoMafraJunior

[renatonlima]

Eu fiz um rebase agora, e fiz um correção no último PR #65 que implementou o suporte a validação da chave para o documento fiscal CT-e OS (modelo 67) adicionou um prefixo incorreto CTeOS que não existe, pois tanto os documentos modelo 57 (CT-e) e o modelo 67 (CT-e OS) usam o mesmo prefixo CTe a única diferença e que nas posições 21-22 da chave o código do documento muda para 67.